Як управління вимогами працює в довгостроковій перспективі з Agile проектами?

Управління вимогами в короткостроковій перспективі для Agile проектів здається мені вирішеною проблемою.

З точки зору Scrum нові вимоги або зміни існуючих вимог надходять через Історії користувачів. А Історії користувачів, згруповані під епічні або Feature, полегшують доставку більш складних вимог.

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

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

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

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

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

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

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

Отже, що можна зробити, щоб допомогти наступним командам зрозуміти стан проекту, в тому числі, чому і як він туди потрапив?

На мій досвід, такі речі не працюють:

• Догляд за "Блоком", щоб видалити або оновити попередні Історії користувачів, так що Блокування можна прочитати як документ із вимогами.
• Документація Спринти, де учасники команди мають завдання документувати поточний стан системи.
• Документація через тести поведінки . Цей підхід є єдиним, що я бачив, як наблизився до роботи. На жаль, тести кодованої поведінки є жертвою проблеми називання. Хоча тести можуть належним чином задокументувати систему, змусити колективу розробників, що коливається, написати свої тести за тією ж терміналогією, формулюванням та стилем домену майже неможливо.

Отже, ще раз:

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

Мені це здається невимовленим слоном у кімнаті з Agile проектами: як ти запобігти їхньому перетворенню в хаос?

Давайте на мить подивимось на Agile Manifesto. Спритні бажання:

1. Рання та безперервна доставка
2. Отримуючи зміни вимог
3. Часта доставка робочого програмного забезпечення
4. Розробники та бізнес-зацікавлені сторони щодня працюють разом
5. Побудувати проекти навколо мотивованих людей, надаючи їм оточення та підтримку, яка їм потрібна, і довіряючи їм, щоб виконати роботу
6. Розмова віч-на-віч як основний спосіб спілкування
7. Робоче програмне забезпечення як основний показник прогресу
8. Сталий розвиток
9. Постійна увага до технічної досконалості та гарного дизайну
10. Простота - Максимізація роботи, яку вам не доведеться робити
11. Через регулярні проміжки часу команда розмірковує над тим, як стати ефективнішою, а потім налаштовує та відповідно коригує свою поведінку

Я виділив останні чотири. Чому? Тому що саме вони запобігають руйнуванню проекту під власною вагою.

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

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

І він є тим, хто підтримує основний документ.

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

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

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

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

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

На моєму досвіді добре працює зв'язок між діловими вимогами та історіями користувачів в обох напрямках. BR # 1 може бути реалізований за допомогою історій A і B. Історія C може охоплювати БР №2 та №3. Помістіть це у свій інструмент відстеження проектів, електронну таблицю, як би ви не використовували.

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

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

Я фактично працюю над проектом kanban maintenace великого веб-магазину, де оригінальні розробники вже не доступні.

кожна користувацька історія / вимога / помилка має номер квитка, і кожна зміна вихідного коду пов'язана з номером квитка в полі sourcecontrol-comment.

sourcecontrol-checkin-s (svn) атомним чином оновлює квиток на замовлення так, щоб у квитку я мав посилання на всі набори джерел conrtol-change.

Якщо модуль / функція знову реалізована, у вихідному коді є і номери квитків.

У системі квитків (червоний камінь) квитки пов’язані між собою як (дублікат, помилка, уточнення, ....)

тож ви можете слідкувати за квитками та бачити зміни вимог у часі.

Приклад: мені потрібно щось переписати на "orderConfirmation-Web-page". У вихідному коді сторінки я бачу коментар: "створено для" # 4711 "", щоб я міг пов'язати свій новий квиток зі старим квитком "4711" або одним із його наступників.

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

Хоча, це нічого нового.

Якщо ви використовуєте більш масштабовану версію Agile (наприклад, SAFe) ), у вас будуть інші відставання, які не є відставанням реалізації. Це в основному виглядає так:

1. Нестабільність портфеля (Стратегічне планування епосів та бюджетів)
2. Захист програми / випуску (функції та епічні повідомлення)
3. Захист проекту / команди (історії, колоски, помилки)

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

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