Як обліковувати ітерацію виправлення помилок?

9

Ми впровадили Scrum досить успішно протягом останніх 5 місяців. Хоча, ми 3 тижні від PROD без коли - або робити якісь - або інтеграційний тест від кінця до кінця. ТАКОЖ! Мені потрібна допомога. Не вирішуючи причин цього (у цьому пункті), нам зараз потрібно спланувати поточну ітерацію, яка складається з незначних вдосконалень та МЕНЮ досі невідомих виправлень помилок. Як ви враховуєте цей сценарій? Як ви плануєте ітерацію виправити помилки, які ще не знайдені?

scrum bug planning

— Помаріо
джерело

16

"Ми реалізуємо Scrum досить успішно ... ніколи не роблячи жодного тесту інтеграції. Вибачте, що ви зробили це неправильно. Ви повинні були мати можливість відправляти в кінці кожної ітерації.

— xsace

3

@xsAce це 6-місячна ітерація

— Барт

3

Питання само по собі добре, але опис процесу змушує мене відчувати, що ви заперечуєте, наскільки добре все працює. Якщо ви більше нічого не робите, скажіть PO, що наразі команда не може взяти на себе дату виходу. Найкраще, що ви можете зробити, - це зобов’язати його / її, що ви сфокусуєтеся на оцінці якості в наступній ітерації. Проведіть серйозну дискусію в команді на наступній ретроспективі.

— ГайР

1

Переглядаючи на цьому веб-сайті питання, пов’язані з Scrum, зрозуміло, що ваша компанія займається «не такою річчю», як Scrum, і натомість звучить як команда людей, що набагато комфортніше і знайоміша з розвитком водоспаду. Не те, що Водоспад по суті "поганий", але просто визнає, коли керівництво любить використовувати такі слова, як "Agile", "Scrum", "Sprint", "Backlog" та "Планування покеру" як гучні слова, але не повністю присвячені культурі та зміна управління, необхідна для виконання цих речей. Вони хочуть переваг Scrum, не зобов'язуючись Scrum.

— maple_shaft

4

Це пуристичні процеси, як і ви, хлопці, які відключають людей від цього. Якби він не визнав, що у нього є проблеми, він би не ставив цього питання. З'ясувати, куди ви пішли не так, і вжити кроків, щоб зробити кращі в майбутніх ітераціях - це те, що спритно все. Індивіди та взаємодія над процесами та інструментами.

— Карл Білефельдт

7

Скажіть чи ні, помилки в принципі неможливо передбачити. Я вважаю, що ви можете зробити це:

Почніть тестування негайно, без початкової оцінки, коли це буде зроблено.
Виявивши кожну помилку, зробіть початковий аналіз до того моменту, як зможете її оцінити.
Оцініть помилку та вирішіть, чи потрібно її виправляти та чи потрібно її виправляти на початковому випуску.
Якщо його потрібно виправити, додайте його до ітерації.
Складіть схему згоряння. В якийсь момент вона почне зменшуватися, тобто ви більше не знаходите помилок швидше, ніж вам вдасться їх виправити. У цей момент ви зможете дати приблизну оцінку (і прогресивно більш точну), коли реліз можна буде зробити.

Тоді як слід переконатися наступного разу, коли ви розпочнете тестування на ранньому етапі та виправлення помилок у процесі роботи. Усі розумні методології, спритні чи ні, вимагають виправити відомі помилки, перш ніж перейти до нових функцій. Також слід врахувати, скільки часу було витрачено на виправлення кожної функції, щоб ви могли покращити свою оцінку щодо використання функції у налагодженому стані в майбутньому.

Оцінка та виправлення помилок чудово висвітлюються Джоелем Спольським у складі планування, заснованого на доказах, та виправлення помилок з жорстким оцінкою . Це не пов'язано з Scrum, але я думаю, що це досить загально, що багато чого стосується.

— Ян Худець
джерело

5

Як обліковувати ітерацію виправлення помилок? Як ви плануєте ітерацію виправити помилки, які ще не знайдені?

Що стосується "виправлення помилок ітерації". До знайдених помилок слід поводитися не по-різному з розповідями. Попрацюйте з командою, щоб оцінити зусилля (сюжетні точки), щоб виправити кожну помилку, і співпрацюйте з власником продукту / замовником, щоб вирішити, чи повинна помилка перейти до наступної ітерації.

Щодо "помилок ще не знайдено". Переважно, команда знаходить і виправляє проблеми кожної ітерації. Якщо це не так, то обговоріть це в наступній ретроспективі. Якщо якість продукту настільки низька, що випуск неможливий, то негайно перемістіть найкращі " пошукові помилки " на пошук помилок (не виправлення). Якщо якість досить висока, щоб забезпечити бета-версію для вибраних користувачів - зробіть це. Якщо ви не можете, то, як мінімум, надайте живі демонстрації користувачів, які обговорюють слабкі області, які ви рекомендуєте, потребує вдосконалення.

— ГайР
джерело

+1. Коли ви перебуваєте на етапі бета-якості, ви також можете розглянути можливість проведення сеансів експертного тестування.

— louisgab

2

Ми не плануємо «виправлення помилок ітерацій», але ми плануємо ітерації тестування системи перед кожним випуском. Тест на систему - це тести на інтеграцію, регресію та повторні випробування на всіх частинах виробу. Тестери тестують продукт (досить велика застаріла система), і розробники виправляють будь-які виявлені помилки. Якщо помилок не виявлено, ми або починаємо розслідувати графіки функцій наступного проекту або працювати над внутрішніми вдосконаленнями.

Наразі ми плануємо шість тижнів системних тестів після заморожування коду (для п'ятимісячного проекту, включений тест на систему), щоб переконатися, що все працює. Це понад усе тестування, яке робиться під час ітерацій впровадження.

— Паула
джерело

1

Потрібно визначити набір критеріїв "випуску". Сюди можна віднести:

Середній час між відмовою
Кількість виявлених дефектів на день
Вираженість виявлених дефектів за добу
Кількість виявлених дефектів

тощо.

Потім наприкінці кожної ітерації ви проводите тестування (вручну або за допомогою автоматизованих тестів), а інші перевіряють, чи відповідає вашим критеріям. Якщо ви тоді відпустите, якщо ні, тоді перейдіть до іншої ітерації.

Повинна бути можливість переосмислити це, а також часто необроблені цифри не представляють реалістичної картини програми. У вас може бути кілька справді серйозних дефектів, але вони проявляються лише в рідкісних умовах, з якими ви зможете жити в короткі терміни.

— ChrisF
джерело

1

Один із способів зробити це - написати історії для інтеграційного тестування, під час яких ви пишете нові історії для будь-яких виявлених помилок, а потім виправляйте історії помилок у наступній ітерації.

Ще один спосіб зробити це - просто скласти історію, яка говорить "Виправлення помилок, виявлених при тестуванні інтеграції". З попередніх випусків ви повинні мати уявлення про те, скільки проблем зазвичай зустрічається та як їх важко виправити, тож ви можете призначити точки історії на основі цих знань. Ви можете, можливо, розділити його на компоненти, якщо це зробить його більш керованим. У цьому завжди неминуча невизначеність. Додайте кілька додаткових точок сюжету для його обліку.

Ви, мабуть, запізніло зрозуміли, що найкращий спосіб - включити тестування на інтеграцію у кожну ітерацію, якщо це можливо. Вітаємо вас із визнанням цього та покращенням вашого процесу лише для наступного випуску.

— Карл Білефельдт
джерело