Найкращі способи вписати виправлення помилок у процес Scrum? [зачинено]

Я вивчав і читав про Scrum протягом останніх кількох днів і читав про планування та завдання Sprint. Одна проблема, яка мені запам’яталась, - це те, як боротися з помилками в Scrum. Генрік Книберг перераховує кілька способів вирішення цього питання у своїй дуже приємній книзі Scrum and XP from the Trenches :

1. Власник продукту роздруковує найвищі пріоритетні предмети Jira, виводить їх на засідання зі спринтерського планування та ставить на стіну разом з іншими історіями (тим самим неявно визначаючи пріоритет цих предметів порівняно з іншими історіями).
2. Власник продукту створює історії, що стосуються предметів Jira. Наприклад, «Виправте найважливіші помилки звітування бек-офісу, Jira-124, Jira-126 та Jira-180».
3. Виправлення помилок вважається поза спринтом, тобто команда зберігає досить низький коефіцієнт фокусування (наприклад, 50%), щоб переконатися, що вони встигають виправити помилки. Тоді просто передбачається, що команда витрачатиме певний час на кожен спринт, виправляючи помилки, про які повідомила Джіра
4. Помістіть відставання товару в Jira (тобто вирийте Excel). Ставтеся до помилок так само, як до будь-якої іншої історії.

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

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

1. Порівнювання з усіма помилками, пов’язаними з відставанням, може здатися гарною ідеєю в теорії (робота відстежується в одному місці), але на практиці це не працює добре. Зазвичай помилки бувають низького рівня та більш численні, тож якщо ви створите індивідуальну історію користувача для кожної помилки, то "справжні" історії незабаром будуть затемнені.
2. Явний час у кожному спринті, зарезервований для виправлень, непоганий, якщо це зробити таким чином, щоб було видно власнику продукту. Про помилки слід згадувати під час щоденної сутички, а обговорення виправлених помилок має відбуватися під час огляду спринту. В іншому випадку власник продукту не буде в курсі того, що відбувається в проекті.
3. Поміщення всього відставання в інструмент відстеження помилок призводить до того ж набору проблем, що і в 1. Більше того, більшість відстежувачів помилок не розроблені з урахуванням Scrum, і їх використання для цієї мети може бути болючим.

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

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

Насправді я думаю, що найкращим варіантом є відповідь jpeacock на це питання. Чи вважаєте ви години, витрачені на виправлення помилок, до сутички?

Дозвольте навести це:

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

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

Інвентар - це відходи. Відстеження помилок - це інвентаризація. Відстеження помилок - марнотратство.

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

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

Не відстежуйте дефекти у списку, знаходьте їх та виправляйте - Мері Поппендік

Дійсно, якщо інвентар - це марнотратство, то як бути з інвентаризацією дефектів ...

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

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

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

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

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

У нашому випадку (розробка greenfield, 2-3 розробники) виявлені помилки записуються, чітко позначаються як помилка і на основі їх серйозності вони призначаються до наступної ітерації або залишаються у відставанні. У разі критичних та термінових помилок вони додаються до поточної ітерації.

Не знаю, чому щось таке просте, як виправлення помилок, ускладнюється правилами .. У Scrum дуже мало правил, пам’ятаєш? Кожна функція, підтримка, рекомендація чи дефект є проблемою відставання в Scrum, немає диференціації. Отже, як каже керівництво Scrum: завдання в Sprint ніколи не обмежуються тим, що ви вирішите під час зустрічі з планування, Daily Scrum допомагає людям обговорювати "перешкоди" на своєму шляху.

Чому?

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

Краще запитання - як мені перестати створювати помилки на стадії розробки? див. -> http://bit.ly/UoTa4n

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

Це насправді не спритно?

У нашому проекті я запропонував ідею ввести короткий спринт з виправленням помилок кожного третього спринту. Наші поточні спринти три тижні.

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

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

Хтось пробував це чи мав якийсь відгук про те, як, на їх думку, це може працювати?

Ура, Кевіне.