Як управляти змінами у вимогах за допомогою версіонування. Розбираємо приклад

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

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

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

Сподіваюсь, матеріал буде цікавим як аналітикам-початківцям, так і досвідченим бізнес-аналітикам.

Варіанти внесення змін у вимоги

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

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

  • Написати нову версію вимог з нуля — пишемо «в лоб» нові вимоги, не шукаючи старі вимоги.
  • Відкоригувати існуючі вимоги — відкриваємо наявний документ з вимогами і правимо «по живому».
  • Зробити нову версію існуючих вимог і внести зміни в неї — копіюємо вимоги і вносимо правки в копію.

Як обрати який варіант використовувати? Розгляньте наступні параметри, які впливають на вибір варіанту документування змін.

  1. Швидкість оформлення вимог або «На коли треба?». Часто вимоги треба «на вчора», та іноді саме швидкість оформлення вимог може бути визначальною для конкретного проєкту.
  2. Аналіз впливу змін на іншу функціональність системи або «Чи нічого ми не пропустили і чи нічого не поломиться, якщо ми то зробимо?». Даний параметр можна деталізувати на два підпараметри:
    1. можливість мати повний та актуальний опис функціональності дозволяє знайти усі елементи якоїсь системи (функції), щоб не пропустити нічого;
    2. можливість бачити взаємозв’язки з іншими компонентами системи, щоб бути впевненим, що не поламаємо нічого.
  3. Контроль статусу окремої версії змінених вимог або «Що вже зроблено, що в процесі, а що пізніше будемо робити?».
    Особливо це стає важливим, якщо змін багато та усі вони в одній і тій самій функціональності. Тоді потрібно чітко розуміти, які з них ще в беклозі, які вже заплановані або в роботі, а які вже включені в робочу версію продукту. Суттєво це відчувається, коли запланована зміна певної функціональності продукту протягом кількох ітерацій (наприклад, зараз ми додаємо одне поле на якусь форму, в наступному релізі ми додаємо ще одне поле, а через один реліз ми міняємо функціональність першого поля, бо додаємо третє.
  4. Актуалізація вимог або «Як ця штука працює зараз на проді?». Вимоги повинні відповідати реальній функціональності системи і при цьому бажано не робити подвійну роботу: спочатку описувати вимоги для розробників, а потім оновлювати документацію про цей функціонал для інших користувачів.
  5. Історія зміни вимог або «Який дурень це придумав та навіщо ми це робили» (часто відповідь буває «Трясця, так це ж я то запропонував» :)). Історія змін у вимогах дозволяє прослідкувати розвиток продукту, зрозуміти його поточну функціональність та навіть краще зрозуміти код.

Крім вище перелічених параметрів вибір варіанта документування змін залежить і від таких зовнішніх факторів як:

  • системи управління вимогами (далі — СУВ), яка використовується в проєкті;
  • навантаженням на аналітика в проєкті;
  • віку системи;
  • організації роботи команди в проєкті.

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

Наприклад, Confluence, Google Docs та MS Word мають функціонал ведення історії зміни документа. Використовуючи ці інструменти, можна вести реєстр версій, в якому вказувати, яка версія з історії є актуальною, а яка — в роботі.

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

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

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

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

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

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

Документування змін відносно складне, потребує середньої кількості часу та зусиль.

Документування змін відносно просте, потребує мало часу та зусиль.


Параметр

Варіант 1. Нова вимога «з нуля»

Варіант 2. Коригування чинних вимог

Варіант 3. Версіонування вимог

Організація роботи з вимогами

Швидкість оформлення вимог

Витрачаємо час на написання нової вимоги.

Витрачаємо час на пошук актуальної вимоги + час на коригування знайдених вимог.

Аналіз впливу змін (нічого не пропустити і не поламати)

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

Якщо вимоги актуальні, то достатньо проаналізувати тільки чинні вимоги.

Контроль статусу роботи з вимогами

Можна контролювати як окремий артефакт вимог.

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

Можна контролювати кожну версію окремо.

Актуалізація вимог

Потрібно окремо підтримувати актуальну документацію та змінювати її кожен раз, коли створено новий артефакт вимог (подвійна робота).

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

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

Історія зміни вимог

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

Якщо СУВ підтримує версіонування, то історію змін побачити досить просто.

Кожна версія повинна мати посилання на попередню версію, і визначити історію змін можна через ці взаємозв’язки.

Особливості проєкту

Система управління вимогами (СУВ)

Не має значення — яка різниця, де писати нові вимоги.

СУВ повинна підтримувати історію змін в документі.

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

Навантаження на аналітика

Найпростіший варіант при великому навантаженні на аналітика.

Можна використовувати при великому навантаженні на аналітика.

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

Вік системи та/ або велика кількість змін

Високий ризик щось поламати або пропустити.

Можна використовувати, якщо є актуальні вимоги. Складно використовувати, якщо зміни відбуваються часто.

Низький ризик щось поламати або пропустити.

Організація роботи в команді

Відносно простий спосіб оформлення вимог.

Команда повинна навчитись працювати з версіями.

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

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

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

Трохи про проєкт

Проєкт, в якому ми застосували описаний далі підхід — це розробка медичної системи для американського ринку. Коли я прийшов в проєкт, він вже розвивався понад чотири роки. В проєкт входить зараз 8 застосунків, 6 з яких були вже розроблені на час мого приходу в проєкт. Система складається з більш ніж 25 функціональних модулів та над нею постійно працюють від 3 до 6 бізнес-аналітиків, склад яких періодично змінюється.

Вимоги оформляються історіями користувачів в Jira. В проєкті зараз близько 4 тисяч історій користувачів, з яких більш як 2 тисячі — актуальні. Тільки за останніх 12 місяців ми створили близько тисячі нових історії користувачів.

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

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

Спочатку всі зміни оформлялись новими тікетами з типом «Запит на зміни (Change request)», в яких описувались тільки ті Критерії приймання, які зазнали змін у форматі «Як є» та «Як має бути» (Варіант 1 оформлення змін в таблиці вище). Такий підхід дозволяв швидко оформляти вимоги на зміни, але аналізувати поточний стан функціональності та взаємозв’язки між вимогами було дуже складно. Від критичних багів в результаті імплементації змін рятувала лише досвідчена команда, яка добре знала систему.

Коли через різке зростання команди з’явилась потреба мати актуальний опис роботи системи, в тому числі і для забезпечення передачі знань та досвіду між «старими» та «новими» учасниками команди, ми зрозуміли що потрібно змінити наш підхід до документування змін.

Враховуючи, що вимоги документуються в тікетах Jira, і змінювати підхід ми не планували, то варіант з коригуванням наявних вимог ми одразу відкинули.

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

Параметр

Стан проєкту

Як було
Варіант 1
Нові вимоги «з нуля»

Як стало

Варіант 3
Версіонування вимог

Організація роботи з вимогами

Швидкість оформлення вимог

З одного боку команда аналітиків достатньо укомплектована, тому є можливість якісно працювати з вимогами; з іншого — темп розробки достатньо високий і вимоги потрібно розробляти швидко.

Для оформлення зміни у вигляді нового тікета в Jira багато часу не потрібно. Основний час йде на аналіз впливів та взаємозв’язків.

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

Аналіз впливу змін (нічого не пропустити і не поламати)

Ризик щось зламати є високий, оскільки функціональності багато, часто функції є взаємозалежними

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

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

Контроль статусу роботи з вимогами

Часто функціональність розробляється поступово, тому зміни заплановані на кілька релізів наперед.

Створення нових тікетів в Jira (як для окремих запитів на зміни, так і для нових версій) дозволяє відслідковувати статус кожного з них.

Актуалізація вимог

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

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

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

Історія зміни вимог

Змін багато, і періодично виникає питання, чому саме так зробили.

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

Кожна версія містить коментарі, автора та номер версії, а також посилання на попередню версію, тому визначити історію змін досить просто.

Особливості проєкту

Система управління вимогами

Jira + Confluence

Вимоги документуються в Jira, тому створення нових тікетів швидке і просте.

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

Навантаження на аналітика

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

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

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

Вік системи та/ або велика кількість змін

Система з історією, яка постійно розвивається.

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

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

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

Організація роботи в команді

Процеси розробки в команді на високому рівні, вимоги для розробників є «джерелом правди», тому якість вимог суттєво впливає на результат роботи команди.

Досвідченим учасникам команди, які знають функціонал, було простіше працювати з новими тікетами, де були описані тільки зміни. Але от «новенькі» витрачали багато часу на аналіз чинного функціоналу.

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

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

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

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

Як версіонувати історії користувачів

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

Як ми версіонуємо історії користувачів я хочу показати на простому прикладі.

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

Далі клієнт захотів додати по батькові та стать. Для цього ми копіюємо теперішню версію користувача та робимо версію 2:

В новій версії ми використовуємо наступні елементи:

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

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

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

Щоб розуміти, яка версія є актуальною, яка в роботі, а яка вже застаріла, ми використовуємо статуси В роботі (In progress), Зроблено (Done), та Архів (Archive):

Таким чином, можна швидко знайти актуальні версії вимог за допомогою фільтру (статус = Зроблено).

Враховуючи, що вимог у нас багато, то знайомитись з вимогами в Jira не дуже зручно. Тому ми для кожної функціональності створили окрему сторінку в Confluence, де зібрали актуальні вимоги й ті, які ще в роботі. Щоб не робити подвійну роботу, ми використали фільтри, які підтягують опис функціональності з епіка [1], фільтр з актуальними версіями вимог [2] та фільтр для тікетів в роботі [3], який можна сховати:

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

Переваги та недоліки такого підходу

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

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

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

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

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

Звичайно, поточний процес не ідеальний. Ми виявили наступні недоліки такого підходу:

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

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

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

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

Сподобалась стаття? Натискай «Подобається» внизу. Це допоможе автору виграти подарунок у програмі #ПишуНаDOU

👍ПодобаєтьсяСподобалось12
До обраногоВ обраному5
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Дякую за статтю, Олександре. Цікавий досвід і серйозний підхід до покращення процесу управління вимогами.

Схоже, що на даному проекті було досить багато обмежень (4000+ user stories, 8 додатків, підозрюю, немаленька команда та кількість стейкхолдерів) і змінювати щось було достатньо складно і вимагало обережності.
Питання: чи замислювались ви, як би ви побудували систему управління вимог, якби починали подібний проект спочатку? Чи використовували б модель, до якої дійшли зараз?

Дякую за статтю!
Бачу ще один великий недолік — актуальна версія історії виглядатиме абсолютно нечитабельно, якщо кольором виділятимуться абсолютно всі зміни (від першої версії до, н-д, 8-ї).
Чи ви маєте на увазі виділяти кольором тільки проміжні зміни між останньою і попередньою версією?

Так, виділяються кольором тільки зміни в даній версії відносно попередньої

Підписатись на коментарі