Чи дійсно “гнучкі вимоги” настільки відрізняються від вимог на інших проектах?
Наразі більшість організацій принаймні частково використовують гнучкі підходи до розробки. Зі збільшенням популярності гнучких методів, бізнес-аналітики та власники продуктів часто використовують термін “гнучкі вимоги” для позначення своєї роботи.
Разом з моїм співавтором, Джоєм Бітті, ми не використовували термін “гнучкі вимоги”, оскільки він передбачає, що вимоги для гнучких проектів якісно інші ніж ті, що використовують в проектах з іншими життєвими циклами. Проте ми стверджуємо, що незалежно від життєвого циклу, розробник повинен мати ту саму інформацію, щоб правильно втілити потрібну функціональність.
На гнучких та традиційних проектах робота з вимогами відбувається по-різному. Особлива відмінність полягає у тому скільки триває та як глибоко проходить процес збору вимог, а також у розмірі письмової документації. Тим не менше, більшість технік розробки та управління вимогами можуть бути корисними на гнучких проектах, якщо їх правильно застосувати, як це описано у нашій книзі “Вимоги до програмного забезпечення, 3-є видання”. Тому ми віддаємо перевагу терміну “вимоги для гнучких проектів” замість “гнучких вимог”.
Традиційні підходи, такі як каскадна розробка, намагаються мінімізувати ризик проекту шляхом ретельної специфікації та планування перед початком розробки програмного забезпечення. Таким чином, менеджери проекту та бізнес-аналітики впевнені що всі зацікавлені сторони розуміють, що саме буде виконано, перш ніж розпочнеться розробка. Можливо це добре працює, якщо вимоги зрозумілі вже з початку та ймовірно залишаються відносно сталими впродовж проекту.
Гнучкі підходи призначені для адаптації до неминучих змін, що відбуваються на багатьох проектах. Вони також добре підходять для проектів з високим рівнем невизначеності чи змінюваних вимог. Проте гнучкі проекти все ж потребують тих самих фундаментальних активностей з вимогами, як і традиційні проекти розробки.
Хтось все одно повинен визначити класи користувачів та інших зацікавлених сторін, виявити вимоги від відповідних представників користувачів, проаналізувати та документувати різні види вимог на відповідному рівні деталей та переконатися, що вимоги відповідають бізнес-цілям проекту. Однак детальні вимоги не документують одразу на початку гнучкого проекту. Замість цього на ранній стадії проекту часто виявляють високорівневі вимоги для планування та встановлення пріоритетів. Зазвичай ці вимоги у формі історій користувачів.
Різниця все ж є
Основні відмінності щодо проведення активностей для роботи з вимогами на гнучких та традиційних проектах можна поділити на наступні категорії:
Ролі та відповідальності
На гнучких проектах часто не призначають окремого бізнес-аналітика для виявлення, аналізу, специфікації та огляду вимог. Розробка інформації, пов’язаної з вимогами, є спільним процесом в якому беруть участь люди, які незалежно від їхніх реальних посад, виконують ролі аналітика, відповідних представників користувачів та інших зацікавлених сторін. Роль аналітика зазвичай виконує група людей, зокрема власник продукту, розробники та ключові зацікавлені сторони.
На гнучкому проекті власник продукту зазвичай відповідає за беклог продукту та готовність історій користувачів до реалізації. Розробники відповідальні за перевірку історій користувачів на наявність достатньої інформації перед прийняттям їх у розробку. Іноді роль власника продукту виконує той, хто раніше виконував функцію бізнес-аналітика, якщо ця особа добре розуміє бізнес і може ефективно представляти різні групи користувачів. Інші проекти можуть мати окремого бізнес-аналітика, який тісно співпрацює з власником продукту для забезпечення достатньої деталізації та пріоритезації історій користувачів для розробки.
Час проведення активностей зі збору вимог
У будь-якому підході до розробки програмного забезпечення, починаючи з загального дослідження вимог на високому рівні абстракції, можна провести початкову пріоритезацію, оцінку та послідовність робіт. Традиційні підходи наголошують на створенні досить повної та деталізованої специфікації вимог на ранній стадії проекту. На відміну від цього, гнучкі команди створюють деталізовані вимоги вже перед реалізацією конкретної функціональності. Це зменшує ризик, що інформація буде застарілою на момент коли розробники та тестувальники будуть з нею працювати, і команда зможе краще перерозподілити пріоритети.
Проте користуючись таким підходом «саме на коли потрібно», складніше визначити залежності між вимогами а також архітектурні наслідки, які слід було розглянути з самого початку. Для зменшення ризику помилок в архітектурі гнучкі команди часто дивляться на широкий обсяг на ранніх ітераціях і враховують, які основні архітектурні рішення можуть бути необхідні.
Як показано на Рисунку 1, історії користувачів в гнучких методологіях розподіляються на конкретні ітерації для реалізації, і деталі для кожної історії уточнюють якраз перед чи під час цієї ітерації. Функціональні вимоги можуть продовжувати розробляти невеликими частинами впродовж всього проекту, навіть до самого випуску продукту.
Рисунок 1. Стандартні активності щодо роботи з вимогами проводять в межах кожної гнучкої ітерації.
Як і з архітектурою, важливо досліджувати нефункціональні вимоги на ранній стадії, щоб систему можна було спроектувати так, щоб досягти критичної продуктивності, зручності використання, доступності та інших якісних цілей. Розв’язання цих питань на пізніших етапах проекту може вимагати значних та затратних перероблень. Як і у традиційних підходах, методи гнучкої розробки спрямовані на зниження ризику до такої міри щоб можна було рухатися вперед. Основна відмінність полягає в тому, що гнучкі проекти передбачають певну кількість рефакторингу та переробки, тому команди вже на ранніх етапах приймають те що буде більше невизначеності щодо вимог.
Форми виконавчих документів
На верхньому рівні історії користувача подібні до варіантів використання, які є популярними на традиційних проектах. Знову ж таки, відмінність полягає у тому, наскільки детально ви їх прописуєте і чи записуєте ви те, що ви дізналися. Історії користувача часто відповідають окремим потокам в межах варіанту використання. БА на традиційному проекті може працювати з варіантами використання, щоб розробити багатший набір функціональних вимог. У гнучких проектах, навпаки, команда зазвичай уточнює окремі деталі історії користувача, розробляючи приймальні тести, які покажуть, чи була дана історія належним чином реалізована.
Я підтримую розробку тестів разом з вимогами вже майже 25 років – задовго до того як народився Agile-маніфест! Проте на практиці функціональні вимоги та відповідні детальні тести – це два способи щоб представити одну і ту ж інформацію: один описує що треба побудувати, а інший вказує, як перевірити, чи було побудовано саме те що потрібно.
Великою перевагою того щоб обмірковувати вимоги, використовуючи тести, є те, що вони більш схильні виявляти виключення, які часто не помічають при формалізації вимог. Проте недолік використання лише одного з цих підходів полягає в тому, що ви залишаєте лише одне втілення знань про вимоги. Якщо у вас є лише один погляд на вимоги, ви повинні вірити, що він правильний.
Я зрозумів, що написання як і вимог, так і тестів надає потужну комбінацію, особливо якщо з одного джерела інформації одна людина розробляє тести, а інша пише вимоги. Порівнюючи ці два альтернативних погляди, можна знайти прогалини, неоднозначності та різниці в інтерпретації. На гнучких проектах це зазвичай не практикують через ролі в команді, оскільки власники продуктів зазвичай пишуть як історії користувачів, так і критерії приймання.
Термінологія
Різні форми які використовують для представлення вимог призводять до цікавої але не дуже суттєвої відмінності в термінології на традиційних і гнучких проектах. Більшість гнучких проектів посилаються на історії користувачів і критерії приймання, у той час, як на традиційних проектах зазвичай використовують варіанти використання та функціональні вимоги. Але насправді це та сама інформація! Не дуже важливо як ви це називаєте або як саме ви це представляєте, важливо лише те, щоб ви розробляли та комунікували цю інформацію таким чином, щоб розробники та тестувальники могли якісно та ефективно виконувати свою роботу.
Деталі документації
Люди іноді вважають, що команди на гнучких проектах не повинні писати вимоги. Насправді це не так. Замість цього методи гнучкої розробки приймають принцип легкої документації. Тісна співпраця між клієнтами з розробниками на гнучких проектах означає, що вимоги можна документувати менш детально, ніж на традиційних проектах. Натомість аналітики або інші особи, відповідальні за вимоги, розвинуть необхідну точність, проводячи додаткові розмови та розробляючи документацію, коли це потрібно.
Будь-яка документація крім тієї, яка необхідна розробникам та тестувальникам (або є обов’язковою відповідно до правил чи стандартів), потенційно є марною витратою зусиль , якщо в майбутньому в ній не буде чіткої потреби. Деякі історії користувачів можуть мати мало деталей, із зазначенням лише найризиковіших або найбільш впливових функціональних можливостей, зазвичай у формі критеріїв приймання та відповідних моделей візуального аналізу.
Я вважаю, що витрати на фіксацію інформації малі порівняно з витратами на отримання цієї інформації. Існує вагоме обґрунтування щодо створення постійної групової пам’яті в письмовій формі, оскільки людські спогади неповні, непослідовні та погіршуються з часом. Люди приходять і йдуть з команд проекту, і, звісно ж, продукт існує довше, ніж проект розробки. Кожен проект повинен вибрати розумний баланс точної документації, достатньої для управління цими ризиками, без витрати надмірного часу на фіксацію інформації, яка не буде використовуватися.
Коли встановлювати пріоритети
Пріоритезація беклогу – це постійна активність на гнучкому проекті, щоб вибрати які робочі пункти додадуть до майбутньої ітерації, а які викинути із беклогу. Пріоритети, призначені для пунктів беклогу, не обов’язково мають залишатися незмінними назавжди, вони залишаються незмінними лише на період розробки кожного з цих пунктів. Команди завжди запитують себе: “Що є найважливішим для роботи наступного разу?”
У порівнянні, більшість традиційних проектів намагаються визначити пріоритети вимог заздалегідь і рідко їх переглядають. Але насправді всі проекти, не тільки гнучкі, повинні динамічно управляти пріоритетами роботи яка залишилася в беклозі, оскільки він швидко змінюється.
Чи справді є різниця?
Нещодавно я побачив список “Принципів бізнес-аналізу” з IIBA® Agile Extension до BABOK® Guide, де перелічено численні практики у кількох категоріях. Мені важко знайти там щось, що не було б корисним на будь-якому програмному проекті. Чи не кожна команда має застосовувати техніки, щоб побачити всю картину, думати як клієнт, заохочувати співпрацю та уникати даремних витрат?
На всіх проектах слід визначати, що означає бізнес-цінність, переконуватись що активності на проекті а також бізнес-процеси додають цінність, і використовувати практичні методи пріоритезації. Техніки, такі як персонажі, управління беклогом, відносна оцінка і ретроспективи, є цінними практиками, які будуть корисними практично на будь-якому проекті. То чим ці принципи і практики бізнес-аналізу особливі саме для гнучких проектів?
Можна було б заперечити, що традиційні проекти часто не відповідають цим принципам або можливо не ефективно застосовують будь-які із цих добре продуманих практик бізнес-аналізу. Це, ймовірно, правда. Можливо, так само правда для гнучких проектів, які можуть не мати органічної експертизи з бізнес-аналізу. Але основна ідея полягає в тому, що ті самі цінності, принципи і практики вимог є однаково вживаними на будь-якому програмному проекті, коли вони ретельно адаптовані, масштабовані та синхронізовані так, щоб досягти цілей проекту. Тому я просто не розумію ідеї, що “гнучкі вимоги” якісь особливі чи вони відрізняються.
Оригінальна стаття – Agile Requirements: What’s the Big Deal?, переклад Ольга Романчак, ревью – Олександра Серебрянська (Business Analysis Community Kyiv). Оригінальне зображення з сайту www.freepik.com.