Визначення V-циклу
V-цикл в управлінні проектами випливає з теорії теорії водоспаду, теоретизованої в 1970-х роках, що дає можливість представляти процеси розвитку лінійно та послідовно.
Цей спосіб управління проектами був розроблений у 1980 -х роках і застосовувався у сфері промислових проектів, а потім був поширений і на ІТ -проекти. Це було поставлено під сумнів з початку 2000-х років під впливом прискорення технологічних змін, віддавши перевагу більш так званим «спритним» методам.
Буква V посилається на схематичний вигляд цього циклу, який має форму V: низхідна фаза, за якою слідує висхідна фаза. V-цикл пов'язує з кожною фазою впровадження фазу валідації, як показано на діаграмі нижче:
Переваги цієї методології
Основна перевага V-циклу в тому, що він уникає повернення знову і знову, щоб переосмислити початкові специфікації, як храповик. Кожен етап проектування вимагає складання точної та вичерпної документації, де кожна точка має бути підтверджена кінцевим продуктом. Після того, як крок підтверджено, ми не повертаємось і не переходимо до наступного кроку на міцній основі; це основна сила V-циклу.
Завдяки строгому та інтуїтивно зрозумілому аспекту, V-цикл залишається простим процесом для реалізації. Попередня робота з визначення специфікацій на початку проекту означає, що після початку всі етапи відомі працівникам, які легко можуть зорієнтуватися у часових рамках проекту та знати мету своїх завдань. Подібним чином документація, необхідна для кожного кроку, може бути відтворена з одного проекту в інший за їх структурою (специфікації, специфікації тестування тощо).
Загалом, V-цикл більше підходить для багатосайтових структур, тому що він не вимагає щоденних зустрічей, а лише керівних зборів, щоб діяти як перехід від однієї фази до іншої. Тому її лінійний аспект дозволяє створити роздроблену географічну організацію, де робота разом із працівниками не є ключовою у цьому процесі.
Недоліки
Основний недолік V-циклу можна підсумувати двома словами: тунельний ефект. Після етапу точного визначення продукту, який команда повинна завершити, проект запускається в «тунелі», що складається з вищезгаданих фаз. Але що робити, якщо вихідні специфікації перевищено? Що робити, якщо потреба замовника змінюється або була виражена погано? Тому V-цикл погано справляється зі змінами, що є як його сильною стороною, так і його основною слабкістю.
Таким чином, він пропонує меншу реактивність стосовно технологічного та економічного контексту, запитів клієнтів, несподіваних подій; ризик буде систематично обмежуватися. Ефект тунелю також викликається значною роботою з виготовлення документації на початку проекту, яка не може бути виправлена згодом. Нарешті, зображення тунелю ілюструє (іноді дуже) тривалий час між вираженням потреби та рецептом кінцевого продукту.
V цикл проти спритні методи
Загалом, можна сказати, що V-цикл зосереджений на процесі, тоді як спритні методи віддають перевагу продукту.
Як частина гнучких методів (Scrum, XP, RAD, …), проект уточнюється ітерацій , через повторення циклу операцій ( спринт як частина методу Scrum). Як ми бачили, V-цикл визначає весь кінцевий продукт на ранніх стадіях і залишає мало місця для адаптації пізніше в циклі.
Тоді спритні методи дають можливість розробити продукт шляхом приріст . Щоразу ми виробляємо трохи більше, по шматочках, щоб досягти кінцевого результату. Натомість V-цикл концентрує реалізацію цілого в одній фазі, яка повністю розроблена вгору та перевірена нижче.
Ця відсутність адаптації та гнучкості V-циклу саме призвела до появи гнучких методів, особливо у сфері програмного забезпечення та маркетингу, для реагування на все більш швидкі зміни технологій та вимог споживачів.
Реалізація V-циклу
Для яких проектів?
З огляду на представлені вище елементи, такі елементи сприяють використанню V-циклу:
- Дуже конкретні вимоги, які висуває замовник, наприклад, у контексті тендеру.
- Наявність постачальника послуг, який контролює всі етапи впровадження і, отже, вимагає менше спілкування між різними акторами.
- Можливість дотримуватися незмінних специфікацій від початку до кінцяn, за характером продукту чи проекту.
- Проект, де технологічне середовище змінюється дуже мало, таким чином обмежуючи ризики затримки, властиві ефекту тунелю.
Важливий етап: дизайн
Потреби клієнта повинні бути зібрані всебічно і суворо. Функціональні специфікації повинні підлягати подальшому та остаточному процесу валідації. Вони повинні синтезувати запити замовника, охоплюючи всю програму проекту.
Опис засобів досягнення кінцевого продукту, зі свого боку, повинен втручатися лише на етапі технічних специфікацій (загальний проект), щоб запобігти визначенню засобом кінцевого результату!
Хто підтверджує?
І останнє, але не менш важливе за замовчуванням V-цикл визначає етапи, не визначаючи їх ролей або обов'язків. Тому доцільно на початку проекту визначити людей чи організації, які виконуватимуть роль (шляхом збільшення рівня деталізації):
- Управління проектами (функціональне), або MOA
- Управління проектами (система), або МНС
- Архітектурна команда, або загальний дизайн (технічний, бізнес)
- Команда розробників (за складовими)
На діаграмі вище ролі позначені послідовністю V-образних кілець.
