У цій статті йдеться про ітерацію, яка включає всі етапи розробки ПЗ, від зародження ідеї до випуску релізу. Не плутати з ітераціями, які використовуються на етапі реалізації в каскадо-водоспаді, план таких ітерацій будується на підставі вже добре опрацьованого ТЗ та архітектури, а в кінці кожної ітерації немає збору зворотного зв'язку та зміни вимог.
Невеликий екскурс: молода і невелика компанія, що успішно застосовує Agile-підходи і Scrum зокрема, вела всю розробку ПО одним відділом, розбитим на кілька Scrum-команд. Кожна Scrum-команда розробляла свій продукт і все було добре.
Загроза прийшла звідки не чекали. Паралельно з розробкою ПЗ сформувався і розвивався відділ аналітики. Перший час аналітики були зайняті методологічними документами і на розробку ПЗ майже не мали ніякого впливу. Методологічні документи розроблялися на замовлення однієї великої софтверної компанії. Розробка з ними велася настільки щільно, що наші аналітики і керівництво нашої компанії не могли не прознати про те, як у них все влаштовано. А було все влаштовано по класичному каскадо-водоспаду. Софтверна компанія була настільки великою і авторитетною, що керівництво нашої компанії прийняло все на віру і вирішило обов'язково впровадити їх підхід до розробки.
Спочатку, можливо, не розуміючи для чого, а згодом пояснивши це необхідністю замовної розробки, керівництвом компанії був прийнятий небезпечний коктейль наступних рішень:
- Замість ролі Product Owner нам потрібен Головний аналітик;
- Командам розробників суворо заборонено безпосередньо взаємодіяти із замовником. Тільки аналітики мають на це право;
- Команда розробників повинна отримувати всі завдання від команди аналітиків. Результати виконання цих завдань повинні здаватися їм же;
- Якщо розробникам так потрібен Agile, то нехай використовують Agile у себе всередині, ми навіть залишимо ітерації і аналітики будуть передавати розробникам не все ТЗ цілком, а невеликі порції вимог, скориговані з урахуванням останньої демонстрації тестової версії програми замовнику;
- Проектуванням бізнес-процесів, моделі предметної області та користувацького інтерфейсу займаються аналітики. Вони роблять це ітераціями. Під час передачі кожної порції вимог розробникам також передається відповідна ним документація.
Все це призвело до того, що два проекти, які можна було зробити за квартал, робилися майже рік і так і не дійшли до першого релізу на продакшен. Це сталося через те, що:
- Від ітерації до ітерації доводилося змінювати архітектурні рішення, що іноді призводило до дуже великих рефакторингів і викидань у кошик великих шматків коду. Розробники не бачили всю картину в цілому, вони були відірвані від замовника, не брали участі в процесі аналітики і не бачили ТЗ цілком. Аналітики, не знаючи реалізації, також не могли передбачати зміни в архітектурних рішеннях;
- Часто прості речі аналітики робили неймовірно складними, почасти через малий досвід у розробці, а почасти через новий девіз компанії «Ми вирішуємо складні завдання!»;
- Головний аналітик став мега зіркою і вимагав особливого підходу до своєї персони;
- Розробники і як не дивно аналітики були демотивовані. Часто спалахували конфлікти. Наприклад, аналітики почали скаржитися на те, що розробники ставлять багато питань і це сильно відволікає їх від поточних завдань. Після того як головний аналітик поскаржився начальству, було прийнято рішення, що програмісти можуть ставити питання тільки в процесі передачі завдання, після того як завдання прийнято, питання ставити не можна!
- Були великі проблеми з керованістю проекту. Ніхто не хотів брати на себе повну відповідальність за проект в цілому (в тому числі і менеджер проекту).
Підсумок
Наявність ітеративності не врятувала ці проекти, а тільки погіршила ситуацію. Як відомо ітераційна розробка дозволяє своєчасно змінювати напрямок розвитку продукту. Це досягається за рахунок випуску релізу в кінці кожної ітерації, а також збору та аналізу зворотного зв'язку. Зміна напряму в ітераційній розробці досить часте явище, тому немає сенсу писати детальне ТЗ, воно буде застарівати швидше ніж писатися. Відсутність ТЗ компенсується єдиним інформаційним простором команди, в якому невеликими порціями накопичуються знання, завдяки спільним зусиллям всієї команди. Таким чином, ітеративність це необхідна, але не достатня умова для Agile розробки, як мінімум ще повинна бути єдина команда розробників (системні аналітики, дизайнери, архітектори, програмісти, тестувальники)!
Каскадо-водоспад і Agile самі по собі прекрасні методології розробки ПЗ. Кожна з них має свої плюси і мінуси, за набором яких можна зробити правильний вибір на користь однієї з них для кожного проекту. Якщо у вас фіксований бюджет, терміни і вимоги, то використовуйте каскадо-водоспад. Якщо у вас немає термінів (продукт розвивається безперервно протягом усього життєвого циклу) і немає необхідності в жорсткій фіксації вимог, то використовуйте Agile. Але не в якому разі не змішуйте ці два підходи!
