Як ви відстежуєте документ про вимоги про спритну команду?

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

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

По-перше, майже нічого у відповіді @ DXM не відповідає моєму досвіду роботи з Agile, і особливо не з Scrum.

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

Індивіди та взаємодія над процесами та інструментами

Працює програмне забезпечення над всеосяжною документацією

Співпраця з клієнтами щодо укладання договорів

Відповідаючи на зміни протягом наступного плану

Тобто, хоча в елементах праворуч є значення, ми більше цінуємо предмети зліва.

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

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

Отож, у будь-якому випадку, коли історія зроблена - команда створила, протестувала та розгорнула щось, що відповідає критеріям прийняття, історія НЕ БЕЗПЕЧЕНА, вона просто позначена як зроблена на відсталі - тому відставання має певну ознаку про те, що було зроблено в кожному спринті - історії та моменти, пов’язані з ними. Це те, що дозволяє обчислити швидкість, і це цінна документація сама по собі.

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

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

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

Зрештою, це залежить від вашої потреби. Якщо головне - швидко прискорити людей, швидше за все, хтось має намір написати бортовий документ, щоб допомогти їм. Тож майте хтось це робити. Як я вже згадував, Wiki - це чудовий інструмент для збереження подібних речей, тому ви можете розглянути рішення компанії Atlassian, які можуть інтегрувати Вік злиття з Джирою та Greenhopper для відстеження ваших історій / завдань / дефектів та управління вашим проектом загалом. Тут також можна вибрати багато інших інструментів.

[update # 1] Як зазначив @MatthewFlynn, його досвід роботи з Agile, як і багато інших (включаючи мою власну), сильно відрізняється від відповіді, яку я даю тут. Відповідь тут ґрунтується на моїх спостереженнях того, що робив і не працював над моєю власною командою в минулому, в поєднанні з багатьма книгами та блогами, які я читав на цю тему ...

Більша частина прагнення до спритного розвитку спеціально спрямована на усунення вимог до документів.

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

• найменш точний
• найважче в обслуговуванні
• найменш корисний

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

Однак відставання не слід плутати з вимогами doc:

• У відставанні лише деталь із N кількості оповідань повинна бути заповнена деталями. Чим далі розповідь, тим менше деталей ви повинні вкладати в неї (тобто не витрачайте час на спроби визначити щось, що не відбудеться протягом півроку ).
• Поза певним моментом, пункти "вимог" навіть не повинні розміщуватися у відставанні, якщо вони перевищують більше 2 циклів випуску (так само потенційні збільшення (PSI)). Навіть якщо ви знаєте, що вимога є важливою і її потрібно виконати в якийсь момент, протистоять спокусі додавати її до відставання. Якщо це дійсно важливо, хтось згадає це у наступному випуску. Якщо його ніхто не пам’ятає, швидше за все це тому, що це було не так важливо.

Як тільки історія завершена, ця історія вилучається із відставання та ЧУКОВО ⁽¹⁾ . Знову ж таки, історії не є вимогами. ТІЛЬКИ вони повідомляють команді, над чим працювати далі; вони не для історичного запису.

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

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

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

⁽¹⁾ - Оскільки я отримав декілька відповідей на "забиту" частину. За 5 років з моменту переходу на рухливість моя команда ніколи не відкидала жодної історії, навіть 30% тих, хто запланував, потім відклав і потім забув. Мій бос хотів тримати їх "для довідок", але ще ніхто не переглядав жодної з цих історій.

Люди, як правило, прив’язані до своїх даних, і я знаю, що важко зрозуміти, що щось викинеш, коли ти вже це маєш, але зберігання інвентарю (будь то фізичний чи електорський) під рукою не є безкоштовним, і чим більше я думаю про це, тим більше я згоден з "патроном". Це з розділу "Agile Software Requirements: Lean Requirements Practices for Teams, Programs and Enterprise" (стор.190) - "Історії користувачів можна безпечно викинути після впровадження. Це забезпечує їх легку вагу, зберігає їх дружніми командами та сприяє переговорам, але тести прийняття зберігаються протягом життя програми ... "

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

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

Це справді важливо? Іноді це може бути. Здебільшого ви просто хочете переглядати історії / UML / що завгодно разом із тестами та самим кодом в даний час, проте коли виникають питання щодо того, чому функція реалізована певним чином, це часто може бути корисно поглянути на історію, щоб побачити , як функція змінилася з плином часу, щоб намалювати чіткішу картину, чому варіант реалізації X був обраний замість опції Y .

Є кілька способів, як ви можете відстежувати такі артефакти. Одним з кращих варіантів може бути збереження ваших історій у інструменті, який дозволяє вам перетворювати текст розповіді аналогічно версії вашого вихідного коду. Wiki має тенденцію бути дуже хорошим у цьому, тому також є деякі інструменти управління проектами / проблемами, такі як Trac або Redmineякі зберігають історію змін самих проблем, а також сторінок вікі в цих системах. Це можна зробити трохи далі, щоб покращити здатність відстежувати зміни від випуску до особливостей, гарантуючи, що нові історії чи проблеми певним чином пов'язані зі старими пов'язаними питаннями та розповідями. Це може бути таким же простим, як додавання старого ідентифікатора випуску / історії до тексту нової кількості випуску / історії, але може бути значно вдосконалено, включивши будь-який номер випуску чи ідентифікатора сюжету до коментаря, коли ви здійснюєте зміни до системи управління версіями. . Цей метод має найбільшу цінність, якщо ваші зобов'язання часті і обмежені однією історією чи проблемою.

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

Це було сказано раніше, але я думаю, що суть його полягає в цьому:

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

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

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

Розглянемо легендарний приклад онлайн-зоомагазину:

• Ця історія може говорити: "Як користувач, я хочу бачити ПДВ, надрукований у квитанції, ...". Тепер обчислення ПДВ (податку на додану вартість) може бути складним питанням і, ймовірно, потребує більше роботи, ніж ця історія пропонує.
• Можливо, є додаткова історія, яка вимагає зробити розрахунок ПДВ (скажімо, помножте загальну суму продажів на ставку ПДВ ), але, ймовірно, не будуть включені всі варіанти цього розрахунку.
• Спочатку команда зосередилась на наданні базового модуля, скажімо, взяти перелік товарів та їх продажну ціну та повернути суму ПДВ. Це те, що команда може досягти за спринтерський проміжок часу.
• Ймовірно, буде ще багато історій, які висвітлюють усі можливі випадки нарахування ПДВ.
• Щоб зберегти безліч різноманітних правил обчислення ПДВ в межах та за межами окремих спринтів, має сенс зберігати окремий документ із вимогами, який перераховує всі різні способи обчислення ПДВ. Цей документ може розвиватися з часом. Фактично, додавання до нього нового розділу може бути частиною завдання, яке потрібно виконати.

Ви можете використовувати freemind для збору списку функцій. Як це робиться, погляньте в цей підручник (десь посередині).

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

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

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