Знайомтеся, water-scrum-fall!
знайомство
Ласкаво просимо в WaterScrumFall!
«Немає ніяких сумнівів в тому, що Agile став основним напрямком руху, але реальність така, що найбільший сегмент команд, 40 відсотків, не є пуристами [1]. наступними якої-небудь однієї пропонуються методології. Не існує жодного скоєного процесу - срібної кулі, - Waterfall, Agile (Scrum), RUP чи іншого »- написав він потім в своєму звіті.
У ньому Дейв Уест і його колеги написали, що за 10 років спостережень за впровадженням Agile в організаціях компанія Forrester дійшла висновків: «Те, як Agile реалізується на практиці, сильно відрізняється від оригінальних ідей, описаних в Маніфесті і багато в чому ця реалізація схожа з тим, що Forrester називає Water-Scrum-Fall ».
Явище, про яке йде мова в цих звітах - Water-Scrum-Fall, - це гібридна методологія процесу створення ПО. Вона виникла як відповідна реакція на спроби адаптації Agile до реальних умов роботи організацій.
Типова схема Water-Scrum-Fall показана на малюнку 1. Ця схема відображає часто зустрічається розподіл робіт за стадіями Water, Scrum і Fall.
Малюнок 1. Water-Scrum-Fall
На стадії Water виконується розробка вимог і проектування системи на їх основі, що використовується потім для оцінки вартості всього проекту і його планування. На стадії Scrum - ітеративна розробка ПО і unit-тестування. А на стадії Fall - системне тестування випущеного релізу, за результатами якого він або вирушає на доопрацювання, або отримує «добро» на поставку і розгортання. При необхідності на цій стадії здійснюється і інтеграційне тестування. У разі успіху здійснюється випуск продукту.
На початку шляху здавалося, що Agile методології повинні досить швидко завоювати ринок розробки ПО і виникають то тут, то там гібридні методології сприймалися як тимчасове, перехідне явище на шляху від класики до Agile. Однак час ішов, а гібридні методології не вмирали, не дивлячись на всі зусилля з просування Agile. Сьогодні вони виявилися живіший за всіх живих. І це вже не можна ігнорувати, потрібні пояснення їх живучості.
Причини живучості Water-Scrum-Fall
- Почуття самозбереження.
- Правила управління інвестиціями.
- Життєвий цикл продукту.
Розглянемо їх детальніше.
А. Почуття самозбереження
Сьогодні «робити Agile» модно і асоціюється з інноваціями. Але керівники організацій та їх власники проявляють обережність і впроваджують Agile тільки частково, поширюючи його в кращому випадку на групу розробки ПО, в той час як планування, проектування, управління релізами і навіть тестування залишаються в руслі якої-небудь звичної і працює класичної методології. Причини таких рішень пояснюються впливом кількох чинників.
По-перше, це вплив корпоративної культури.
Культура їсть стратегію на сніданок
- сказав великий Пітер Друкер (Peter Drucker).
Інакше кажучи, культура організації чинить опір впровадженню нових стратегій і методологій, тому що вони несуть в собі загрозу і цю культуру і структуру організації [29,40,41].
По-друге, впровадження нової методології вимагає інвестицій в зміна структури організації, менеджмент, ІТ, навчання і т.д. Але сьогодні немає методик, що дозволяють розрахувати економічний ефект від впровадження Agile в уже працює і приносить доходи виробництво. Є тільки підсумкові дані про чужий досвід, представлені в статистичних звітах. Однак і ці підсумкові дані неодноразово піддавалися серйозним сумнівам і в США і в Європі [36,37]. Методики побудови статистичних вибірок і їх обробки в цих звітах, як правило, закриті і це не дозволяє зробити однозначних висновків ні про якість даних, ні про якість отриманих на них результатів. Дебати на цю тему йдуть вже друге десятиліття, але дослідницькі компанії відмовляються надати доступ до використовуваних методик.
Розуміючи це, керівники організацій виявляють здорове почуття самозбереження і не поспішають ламати працююче підприємство просуванням Agile далі групи розробки ПО.
B. Правила управління інвестиціями
У США фінансовий облік і звітність будь-яких проектів ведуться відповідно до встановлених FASB (Financial Accounting Standards Board) і FASAB (Federal Accounting Standards Advisory Board) стандартами для державних і приватних компаній.
Правила фінансового обліку та звітності, встановлені в стандартах SoP 98-1 [33] FASB і SFFAS 10 [34] і TR-16 [35] FASAB такі, що використання Agile методологій при створенні ПЗ для внутрішніх проектів не викликає проблем. І це одна з причин успіхів впровадження Agile у внутрішні ІТ-проекти в США.
Із зовнішніми проектами зовсім інша картина. Їх фінансування потрапляє в США під правила обліку для капітальних вкладень (CAPEX) - тут в силу вступають інші вимоги регулятора. Зокрема, фінансистам замовника ПО необхідно попередньо розрахувати вартість проекту і передбачуваний дохід від його створення і впровадження. Зробити вони це можуть тільки на основі розроблених вимог до створюваного програмного продукту. При цьому точність розрахунку вартості проекту і доходу від його реалізації безпосередньо залежать від детальності розроблених вимог і їх якості.
Вирішення цієї проблеми і знайшло своє відображення у вигляді компромісного рішення - гібридної методології: для відповідності правилам регулятора організації виконують розробку вимог, а потім оцінку вартості їх реалізації та здійснюють планування в рамках стадії Water. А далі, результати цієї стадії надходять в групу розробки, практикуючих, наприклад, SCRUM.
C. Життєвий цикл продукту
Досить часто ПЗ не має самостійної цінності для споживача. Так, в проектах зі створення телевізорів, автомобілів, супутників і т.д. ПО - це лише складова частина цих продуктів. В цьому випадку процес розробки ПЗ є однією з стадій процесу створення продукту і адаптується до його умов.
Зазвичай процес створення таких продуктів вимагає детального проектування системи в цілому до початку її реалізації - виготовлення «заліза» і ПО.
Це необхідно для:
- визначення архітектури системи - складу компонентів і їх взаємозв'язків;
- виділення вимог до конкретних компонентів, що підлягають реалізації;
- перевірки вимог на реалізація;
- розпаралелювання робіт зі створення частин продукту;
- визначення можливості використання існуючих виробничих потужностей або необхідності їх переоснащення;
- визначення необхідності розробки нових технологій створення компонентів продукту;
- синхронізації поставок компонентів продукту для їх інтеграційного тестування.
Тому спроби впровадження Agile в життєвий цикл таких продуктів локалізуються на рівні розробки ПО. При цьому розробка ПО виконується за раніше розробленим вимогам. Так і утворюються стадії Water і Scrum (див. Рис 2).
Малюнок 2. Типова схема випуску продукту по Water-Scrum-Fall
Далі, для фінального тестування ПО необхідно дочекатися поставки «заліза», щоб забезпечити реальні умови перевірки функцій ПО. Таким чином, весь процес завершується інтеграцією і комплексним тестуванням продукту в цілому - стадія Fall.
Все сказане вище можна застосувати не тільки до проектів зі створення інтелектуальної техніки, але і до складних інформаційних систем - без розпаралелювання робіт терміни поставки таких систем були б неприйнятними, а распараллелить роботи неможливо без попереднього проектування системи в цілому [39]. Фінальна збірка і тестування, також є необхідним етапом життєвого циклу таких систем.
висновок
Таким чином, причини виникнення та живучості Water-Scrum-Fall носять об'єктивний характер, і на сьогодні немає фактів, які вказували б на швидке зникнення цього явища.
Правила управління бізнесом, фінансового обліку та звітності при виробництві ПО в США залишаються незмінними. Незмінна і залежність процесу створення ПО від процесу створення продуктів в цілому. А корпоративна культура як і раніше протидіє змінам в відпрацьованих і приносять прибуток процесах і перешкоджає впровадженню «чистого» Agile [42,43].
І парадокс цього явища полягає в тому, що чим більше організацій намагаються впровадити Agile, тим більшого поширення набувають гібридні методології.
[1] пуристів-борець за чистоту моралі, релігії