Чи корисно написати специфікації вимог за розповідями?

Наразі ми використовуємо гнучкі методи в моєму поточному проекті, і ми маємо купу таких історій:

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

• Як замовник, я хочу оплатити покупку, щоб я міг отримати свій товар.

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

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

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

Чи хороша ідея написання специфікацій на основі оповідань? Ми написали розповіді неправильно?

Це може бути суперечливим, але ось так!

Ми працювали над системами в реальному часі, коли один із минулих моїх начальників запропонував зробити АГІЛ! На цьому дійсно легко було виграти управління; однак це було легше сказати, ніж зробити.

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

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

2. Вимоги повинні відповідати розмірам та кількісно вимірюваним способом, інакше ви ніколи не матимете потреби в більш ніж 1 великій історії! Що утворює саме 1 історія?

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

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

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

Тож підходячи до вашого питання:

Чи хороша ідея написання специфікацій на основі оповідань? Ми написали розповіді неправильно?

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

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

> Writing specs by stories? a good idea?

Так, якщо ви можете керувати взаємозалежностями та пріоритетами своїх історій.

Ось стаття про карти історії, які можуть допомогти вам замовити та керувати багатьма користувачами.

На час написання цієї відповіді я зрозумів, що справа не в тестуванні, а в документації. Спершу слід прочитати проворний маніфест :

[Ми цінуємо] робоче програмне забезпечення над вичерпною документацією

Отже, ви повинні зробити свої технічні характеристики виконуваними, тобто записати їх як повністю автоматизований набір тестів.

Чи хороша ідея написання специфікацій на основі оповідань?

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

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

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

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

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

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

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

Ми написали розповіді неправильно?

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

І знову тестування специфікацій не є заміною одиничного тестування. Детальніше

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

Написання специфікацій за розповідями? гарна ідея?

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

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

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

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

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

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