Зацікавлені сторони мають узгодити, що саме входить у конкретну ітерацію розробки, реліз або продукт. Саме для цього й існують базові лінії.
Як бізнес-аналітик (BA), ви працювали із зацікавленими сторонами над формуванням набору вимог, що описують рішення для досягнення бізнес-цілей. Далі команда розробки має визначити підмножину цих вимог, виконання яких вона може взяти на себе в межах конкретного часовго проміжку або інкременту розробки — тобто сформувати базову лінію вимог.
Визначення базової лінії вимог
Базова лінія — це узгоджений і затверджений набір вимог для конкретного циклу розробки, який слугує основою для подальшої роботи. Її ключова цінність — вирівнювання очікувань: усі сторони погоджуються щодо переліку вимог і зобов’язань з постачання. Це один із інструментів управління очікуваннями.
Дехто може вважати поняття базової лінії вимог застарілим, «спадком» часів водоспадної моделі. Це помилка. Кожного разу, коли agile-команда бере зобов’язання реалізувати певну групу user stories в межах ітерації, вона фактично встановлює базову лінію вимог. Нічого складнішого тут немає.
Базова лінія може бути як невеликою (наприклад, двотижнева ітерація), так і масштабною (реліз продукту або навіть усе рішення). Вона «закріплює» групу вимог як зріз у часі: на момент узгодження, наскільки всім відомо, ці вимоги є коректними, повними та сприятимуть досягненню очікуваних бізнес-результатів. Базова лінія вимог визначає обсяг (scope) конкретного інкременту розробки.
Визначення базової лінії вимог дає змогу:
-
зацікавленим сторонам розуміти обсяг, запланований для майбутніх ітерацій;
-
команді розробки оцінити розмір робіт і необхідні ресурси для базової лінії;
-
команді забезпечення якості (QA) фіналізувати тестування;
-
команді розробки зафіксувати зобов’язання щодо постачання (delivery commitments).
Базування (baselining) низькоякісних вимог не приносить користі, тож перед встановленням базової лінії оцініть, чи готовий набір вимог слугувати надійним фундаментом. Будь-які зміни до вимог після їх базування мають проходити через командний процес управління змінами (change process). Затвердження таких змін і їх включення в поточну роботу фактично формує нову базову лінію.
Визначення базової лінії не означає, що змін не буде — вони будуть. Однак базова лінія дає впевненість усім учасникам, що команда може рухатися вперед із низьким ризиком суттєвих змін.
До теми: Як проводити інтерв’ю із замовником
Розмір базової лінії або формальність її встановлення менш важливі, ніж явна домовленість: стейкхолдери погодили зміст, а команда готова переходити до реалізації. Базова лінія може включати поєднання програмної функціональності, ручних операцій і бізнес-процесів. Усі взаємопов’язані елементи мають бути поставлені, щоб відповідна частина рішення була корисною.
Дві стратегії встановлення базової лінії
Під час визначення базової лінії вимог команда має два підходи: за часом (time-bound) або за обсягом (scope-bound).
Базова лінія, обмежена часом (time-bound), починається з фіксації таймбоксу: ітерації, групи ітерацій або запланованого релізу. Далі команда наповнює базову лінію найпріоритетнішими елементами з беклогу доти, доки не буде вичерпано пропускну спроможність розробки та тестування в межах цього таймбоксу.
Такий підхід потребує, щоб команди розробки й тестування виконували оцінювання (sizing/estimation) вимог, аби розуміти, коли ліміт спроможності досягнуто. Time-bound базові лінії найчастіше використовуються в agile-проєктах, де кожна ітерація має власну базову лінію; однак і релізно-орієнтовані ітеративні проєкти також можуть їх застосовувати.
Базові лінії, обмежені обсягом (scope-bound), натомість складаються з логічно згрупованого набору фіч, функціональних вимог або user stories, які затверджуються як єдине ціле та реалізуються, тестуються й розгортаються разом. У цьому підході рішення про встановлення базової лінії ухвалюють, не обов’язково знаючи її розмір або графік постачання. Після цього команди розробки та тестування оцінюють обсяг, щоб сформувати прогноз за термінами та зобов’язаннями постачання.
Якщо оцінки виявляються неприйнятно високими, ключові стейкхолдери мають узгодити компроміси. Команда може зменшити обсяг і сформувати переглянуту базову лінію з раннішою датою постачання, залучити додаткові ресурси або переконати стейкхолдерів погодитися з поточно оціненим терміном. Ще один варіант — пожертвувати якістю заради швидкого постачання повного обсягу базової лінії, але автор цього не рекомендує.
Зверни увагу: ВІГЕРСОПЕДІЯ: Основні практики для успішного управління проектами
Більшість команд використовує лише одну з цих двох стратегій. Працюйте зі стейкхолдерами та командою розробки, щоб визначити, який підхід найкраще відповідає вашій організації та продукту.
Визначення, які вимоги входять до базової лінії
Потрібно однозначно ідентифікувати вимоги, виділені в базову лінію. Один із варіантів — вибрати підмножину з вимогової специфікації для конкретного циклу розробки, зафіксувавши її, наприклад, у окремому документі. Якщо ви використовуєте інструмент управління вимогами, можна застосувати метадані (атрибути вимог), щоб позначити, до якої базової лінії або релізу належить кожна вимога.
В agile-команді user stories можуть бути призначені конкретній ітерації в інструменті планування. Тоді цей набір історій стає пропозицією базової лінії, яку команда розглядає під час планування ітерації. Переконайтеся, що кожен може безпомилково знайти вимоги, які формують пропозицію базової лінії: через місце в документі, запит до бази даних або визначення ітерації.
Різні аналітичні моделі можуть візуально відображати базові лінії. Наприклад, кольорове кодування у дереві фіч може показувати, які фічі та підфічі входять до певної ітерації або релізу. Так само можна підсвічувати елементи діаграми потоків даних (DFD) або ERD, щоб показати процеси та об’єкти даних, які формують кожну базову лінію для майбутніх циклів розробки. Елементи контекстної діаграми можна анотувати або закодовувати кольорами, щоб проілюструвати, які інтеграції із зовнішніми системами будуть реалізовані і коли.
Узгодження базової лінії
Щоб базова лінія стала офіційною, усі релевантні зацікавлені сторони мають її затвердити. До них можуть належати product owner, команди розробки й QA, продуктові «чемпіони», маркетинг, ключові клієнти та/або представники менеджменту. Затвердження може бути простим і неформальним (наприклад, узгодження списку stories на ітерацію), або формальним — із документованим погодженням (signoff) від кількох представників.
Команда має визначити процес встановлення та затвердження базових ліній. Також визначте, як саме фіксуватимете й зберігатимете погодження: таблиця погоджень у документі, атрибути в інструменті управління вимогами або, наприклад, статус stories для поточної ітерації в backlog-інструменті.
Можуть траплятися стейкхолдери, які не поспішають затверджувати базову лінію. Можливо, вони бояться, що погодження означає неможливість подальших змін. Команди розробки, які не впевнені, що зможуть поставити всі запитані вимоги вчасно, також можуть неохоче брати зобов’язання. Однак небажання когось зафіксувати згоду зі змістом базової лінії може блокувати прогрес.
Один варіант — повідомити, що після певної дати погодження вважатиметься отриманим навіть без явної відповіді. Кращий підхід — зрозуміти причини відмови кожної групи. Якщо причина — страх неможливості змін після затвердження, посилайтеся на задокументований процес управління змінами, щоб підтвердити, що зміни можливі (і бажано — не надто обтяжливі). Запитання «Що потрібно, щоб ви затвердили базову лінію?» — хороший старт для обговорення.
Якщо частина стейкхолдерів усе одно не затверджує базову лінію, підкресліть ризик, який це додає подальшій розробці. Якщо ризик мінімальний, задокументуйте відсутність погодження та її наслідки (потенційно пропущені або некоректні вимоги) і обережно продовжуйте реалізацію базової лінії. Якщо ж ризик високий і без buy-in команда може побудувати неправильне рішення, попрацюйте з ними над отриманням погодження або переглядом базової лінії до варіанта, який вони зможуть прийняти.
Управління кількома базовими лініями та змінами
Команда має керувати змінами до затверджених базових ліній. Щоразу, коли нова або змінена вимога затверджується через change process, слід визначити й комунікувати новий «знімок» базової лінії. Продовжуйте оновлювати базову лінію за потреби через процес управління змінами, доки команда не розгорне (deploy) відповідний інкремент.
У певний момент у вас може бути кілька базових ліній одночасно: деякі ще в розробці, інші — на тестуванні (Рисунок 1). Коли надходять зміни, важливо чітко розуміти, до якої саме базової лінії вони застосовуються, щоб усі члени команди завжди знали, над чим саме вони мають працювати.
Деякі команди створюють рішення в межах визначених ітерацій розробки, але не постачають результат кожної ітерації користувачам. Натомість вони інтегрують виходи кількох ітерацій і розгортають отримане рішення як реліз продукту. У такій ситуації ви можете встановити базову лінію вимог для релізу в цілому, а також визначити базову лінію виділених і затверджених вимог для кожної ітерації розробки.
Буде корисно: ВІГЕРСОПЕДІЯ: Візьміть зміни під контроль, поки вони не взяли під контроль вас
На Рисунку 2 показано, як цей підхід може працювати для релізу, що охоплює три ітерації. Product owner або BA може змінювати user stories або переміщувати їх між ітераціями, доки вони залишаються частиною загальної базової лінії релізу. Підтримання базових ліній релізу та ітерацій в актуальному стані відображає, які user stories наразі заплановані для кожної ітерації.
Є ймовірність, що те, що команда фактично поставить, не повністю відповідатиме тому, що планувалося для конкретної базової лінії. Такою є практична реальність розробки ПЗ. Тому, якщо виникають розбіжності, варто оновлювати початкову документацію базової лінії вимог (план) так, щоб вона відображала те, що команда справді реалізувала (факт).
Узгодження зі стейкхолдерами обсягу, який буде реалізовано, є критичною передумовою для старту або продовження розробки. Формальне встановлення базової лінії вимог запускає процес контролю змін вимог (change control). Управління цією базовою лінією до моменту розгортання (deployment) забезпечує, що всі залучені чітко розуміють, що саме команда поставить. Управління базовими лініями — це спосіб зменшити «ефект неприємних сюрпризів», який так часто трапляється в програмних проєктах.