Дизайнерські документи як частина Agile

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

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

Чи існує ефективний стандарт для цього?

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

"невиразні вимоги, погані критерії прийняття, удача!"

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

Отже ... був придуманий спритний спосіб зрозуміти, що це відбувається, і працювати з ним, а не намагатися працювати проти цього.

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

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

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

Перш за все, обов'язково прочитайте цю статтю про Agile / Lean Documentation . Дуже добре читати.

По-друге, я б настійно радив вам переглянути проекти дизайнерських документів після попередньої роботи над історіями. Ми вже пробували це раніше, і це виявилося марно. У середині останнього випуску ми вирішили оновити документи дизайну ТІЛЬКИ ПІСЛЯ коду для сюжету. І зараз я думаю навіть про це занадто рано.

Вам потрібно запитати себе, чому ви хочете робити документи дизайну до кодування. Для нас це були причини:

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

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

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

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

Отже, що я рекомендував би:

1. Спочатку виготовляйте тимчасові конструкції / моделі достатньо, щоб ваша команда могла провести інтелектуальну розмову до кодування. Не сподівайтесь на те, що вони будуть зберігатися, і не витрачайте час на їх формалізацію.
2. Випускайте офіційну проектну документацію лише в тому випадку, коли комусь це буде потрібно (тобто ваша команда має реальну потребу в організаційній пам'яті)
3. Випускайте лише проектну документацію за кодом, який був стабілізований. Немає сенсу намагатися документувати модуль, який постійно змінюється в кожній ітерації.
4. Виготовте проектні документи, які повністю описують модуль (або частину виробу). Раніше ми писали дизайнерські документи, які задокументували зміни, які необхідно внести. Ці документи були абсолютно нікчемними, як тільки було випущено реліз.
5. Тримайте документ на високому рівні. Якщо ви пишете 20 сторінок, що охоплюють архітектуру та дизайн високого рівня, цей документ буде: а) насправді читатимуть інші люди; б) допоможе людям ознайомитись із загальним компонуванням вашого коду. Для детальної інформації люди можуть перейти прямо до коду. Якщо ви пишете 700 сторінок з детальною специфікацією, вони майже завжди не відповідають дійсності, це занадто багато для того, щоб хтось читав, і вам доведеться підтримувати та оновлювати 700 сторінок замість 20, коли будуть зроблені майбутні зміни.

Спритна "мантра" не обходиться без документації повністю.

Agile mantra - віддати перевагу " Робочому програмному забезпеченню над вичерпною документацією ". Але зверніть увагу на біт внизу маніфесту.

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

Дядько Боб має добру політику щодо документації

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

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

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

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

тобто. Зробіть потребу негайною та значною.

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

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

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

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

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

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

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

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

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