Історії для завдань з усунення помилок: чи підходить це Scrum?

Мені просто цікаво, чи слід присвоювати точки історії завданням виправлення помилок чи ні. JIRA, наші проблеми відстеження програмного забезпечення, не має поле точки історія для Bug питань типу (це тільки історія з і Епічна s).

Чи слід додати тип проблеми помилки до застосовних типів випусків у полі «Точки історії» ? Які плюси і мінуси? Чи підходить це для Scrum?

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

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

З точки зору бізнесу, виправлення помилок і функції теж однакові: або ви це робите (сценарій B), або ні (сценарій A); в обох сценаріях пов’язані витрати та вигоди, а порядна ділова людина просто зважить їх і піде з тим, що приносить їм більший прибуток (довгостроковий або короткостроковий залежно від бізнес-стратегії).

Так що так, будь-якими шляхами присвоюйте помилки. Як інакше ви будете надавати пріоритет помилкам та особливостям та помилкам проти помилок? Вам потрібна певна міра розвитку обох, і це краще порівняти.

Найбільша проблема в цьому полягає в тому, що виправлення помилок часто важче оцінити: 90% або більше фактичних зусиль лежить у пошуку причини; як тільки ви його знайшли, ви можете придумати точну оцінку, але майже неможливо судити, скільки часу займе пошук. Я навіть бачив неабияку частку помилок, де більшу частину часу проводили, просто намагаючись відтворити помилку. З іншого боку, залежно від характеру помилки, часто можна звузити пошук за допомогою деяких мінімальних досліджень, перш ніж робити оцінку.

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

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

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

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

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

Можливо, корисне посилання:

http://www.infoq.com/news/2011/01/story-points-to-bugs

Я рекомендую розглянути помилку як історію користувача та призначити їй декілька пунктів. Я б не обов'язково писати це у форматі "Як X, я хочу Y так, щоб Z", як це часто зустрічається з історіями користувачів - я б писав це як "Як X, коли відбувається IY, Z, але Z '- очікувана поведінка ".

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

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

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

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

Звичайно, помилка чи історія, з боку бізнесу не має значення, з чим має справу колектив. Обидва можуть виробляти рівну величину вартості для власника продукту.

У нашій команді ми експериментували з деякими методами оцінки помилок:

1. Оцінка абсолютно невідомих помилок
2. Лише оцінки помилок, які вже були проаналізовані
3. Виділяючи час для виправлення помилок та не оцінюючи помилки, а розміщуйте їх замість виключно на основі вартості бізнесу

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

На основі співвідношення 90/10 (аналіз до виправлення помилок) варіант оцінки 2 варіант означав, що нам довелося планувати аналіз, який не був охоплений спринтерським плануванням (ми дізналися з варіанту 1, але не мали реального рішення як продовжувати аналізувати помилки). Результатом було те, що аналіз помилок не робився, оскільки натомість спринт зосередився на запланованих елементах. Команда не встигла зосередитись на помилках із відставання. Тож врешті вони теж не закінчилися.

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

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

Тож залежить, чи підходять тобі сюжети. Я б спробував спочатку оцінити помилки, використовуючи сюжетні точки. Якщо це не вдалося спробувати мій варіант 3. Це змусило нашу команду (понад 30 спринтських старих) знову зосередитись на старих помилках, які містять велику ділову цінність. Це також звільнило нас від спроб доставити те, що команда просто не може оцінити. Це сприйняття невідомого наблизило нас до реальності, а також зробило наші спринти знову успішними , надаючи великий шматок (виходячи з співвідношення помилок та історії) ділової цінності за допомогою виправлень помилок. Співвідношення, яке ми використовували нещодавно, було 50/50.

Я маю не погодитися з головною відповіддю щодо присвоєння балів історії. Сюжети повинні бути подані за новою цінністю. Якщо ви збираєтесь присвоювати бали вартості товарів та цінностям, ви можете просто оцінити та відстежити години.

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

По-іншому, чому навіть відстежувати точки на помилки? Так що в кінці дня ви знаєте, скільки "роботи" зробив кожен член? Зупинити це! Поганий менеджер! :) Виміряйте команду, а не гравця. Заохочуйте команду керувати собою, якщо одна людина не тягне за собою вагу. Набагато ефективніше. Якщо робити пункти історії сюжету, не повинно відчувати себе краще, але команда в цілому повинна відчувати себе краще, коли вони беруть на себе зобов'язання в кінці спринту. Чи є в спорті ціль корисною для команди чи окремої людини? Якщо індивід грає для себе, команда з часом програє.

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

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

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

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

Створення бюджету може бути виконано двома різними способами для вирішення помилок. Ось кілька ідей, які я ефективно використав:

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

Ваша мета - виправити якомога більше недоліків у межах виділеного бюджету. Обговоріть зі своїми клієнтськими стратегіями визначення пріоритетності повідомлених дефектів. Наприклад, ви сортуєте дефекти за критичністю, а потім за пріоритетом? Суворий пріоритет? Чи слід нападати на "низько висячі фрукти" спочатку? Помилки в інтерфейсі спочатку?

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

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

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

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

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

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

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

Я використовую Pivotal Tracker (я просто JIRA, Trak, Trello та інші), а Pivotal Tracker також не робить балів за справи або помилки. Це зроблено з тих самих вагомих причин, що вище, що також є правдою в JIRA, як ви бачите себе.