На цьому тижні виповнюється 20 років Agile-маніфесту розробки програмного забезпечення. Його створення певною мірою призвело до революції у галузі ПЗ, а нині продовжує впливати також на інші галузі. До цієї події публікуємо уривок із книги Майкла Кона, співзасновника Agile Alliance і автора однієї з найповніших видань з гнучкого управління проєктами.

"Хороший план, складений сьогодні, кращий за ідеальний план, що може з’явитися наступного тижня", - Генерал Джордж C. Паттон

Хоча насправді пошук нових підходів розпочався ще багато років тому, офіційно Аgile-рух існує з моменту прийняття Agile-маніфесту в лютому 2001 р. Цей маніфест був розроблений і підписаний сімнадцятьма «ідеологами полегшених підходів», як вони називали себе на той час. Документ дав назву підходу, який вони використовували для розробки ПЗ, і  навів перелік цінностей. Автори Agile-маніфесту писали, що передусім вони розділяють наступні цінності:

1. Люди та взаємодії важливіші за процеси та інструменти. 

2. Працюючий продукт важливіший за вичерпну документацію. 

3. Співпраця із замовником важливіша за обговорення умов контракту.

4. Готовність до змін важливіша за дотримання плану.
   
   

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

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

Співпраця із  замовником цінується вище за переговори щодо умов контракту, бо Аgile-команди прагнуть до того, аби всі учасники проекту працювали над досягненням спільних цілей. Переговори щодо умов контракту іноді від самого початку змушують команду розробників і клієнта зайняти непримиренні позиції. Мені подобається більшість ігор, і коли моїй старшій доньці виповнилося чотири, я подарував їй «кооперативну гру», оскільки вона, на мою думку, мала б їй сподобатися. На той час я  не мав жодного уявлення, наскільки захопливими є кооперативні ігри. У грі, яку я придбав, на принцесу було накладено закляття, і гравцям потрібно було долати перешкоди (рівчак, зачинені двері тощо), аби дістатися принцеси. Гравці робили ходи по черзі, як і в більшості інших ігор, проте мета полягала в спільному подоланні перешкод і порятунку принцеси. Усі учасники гри або вигравали, або програвали. Гра, як не дивно, виявилася веселою, і мені хотілося б, аби команди зі створення ПЗ і клієнти підходили до проектів, керуючись таким самим ставленням до співробітництва й досягнення спільних цілей. Звісно, контракти необхідні, однак умови та деталі контракту можуть спричинити істотний вплив на те, як будуть взаємодіяти сторони проекту — на засадах співробітництва або суперництва.

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

З урахуванням чотирьох головних тверджень Agile-маніфесту ми розглянемо в  цьому розділі, що означає Аgile-підхід до проекту, і  що таке Аgile-підхід до оцінки та планування.

Agile-підхід до проектів 

Тепер, маючи уявлення про чотири основні цінності Аgile, ми можемо звернути увагу на те, що собою являє Аgile-команда на практиці. Разом узяті чотири цінності призводять до розробки ПЗ ітераційними й поетапними процесами, що дозволяє отримати працездатну й  добре протестовану програму наприкінці кожної ітерації. Наступні розділи присвячені деяким з основних способів роботи Аgile-команд, якщо вони:

1.     Працюють єдиною командою.
2.     Працюють короткими ітераціями. 
3.    Поставляють щось після кожної ітерації. 
4.    Фокусуються на бізнес-пріоритетах. 
5.    Інспектують та адаптують.

Agile-команда працює як єдине ціле

Критично важливим для успіху проекту є те, аби всі учасники проекту вважали себе членами однієї команди, яка націлена на спільну мету. В Аgileпроектах немає місця мисленню на кшталт «я свою частину зробив, далі вже не моя проблема». Аналітики не вмивають руки після передачі вимог дизайнерам. Дизайнери та системні архітектори не самоусуваються після передачі дизайну програмістам, а програмісти не залишають без підтримки тестувальників. Успішній Аgile-команді необхідне постійне відчуття: «ми — в одному човні». Однак, хоча Аgile-команда має працювати як єдине ціле, у ній існує ціла низка конкретних ролей. Варто визначити й уточнити ці ролі, що є частиною Аgile-підходу до оцінки та планування.

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

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

Ще одна суттєва роль — це розробник. Я використовую поняття розробник у дуже широкому сенсі, маючи на увазі будь-кого, хто розробляє ПЗ. Це програмісти, тестувальники, аналітики, інженери баз даних, юзабіліті-експерти, технічні письменники, системні архітектори, дизайнери тощо. Навіть власник продукту у багатьох проектах може вважатися розробником.

Остання роль  — менеджер проекту. Як зазначає Гайсміт (2004a), роль менеджера проекту змінюється в  разі застосування Аgile-методів. Менеджери Аgile-проектів зосереджені переважно на лідерстві, ніж на управлінні. У деяких Аgile-проектах особа, яка виконує роль менеджера проекту, також може виступати в іншій ролі: часто як розробник, а інколи і як власник продукту.

Agile-команди працюють короткими ітераціями

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

Ітерації обмежуються в  часі; це означає, що вони завершуються вчасно, навіть якщо доводиться скорочувати функції. Часові рамки часто дуже жорсткі. Більшість Аgile-команд працюють з  ітераціями тривалістю від двох до чотирьох тижнів, однак деякі команди зберігають гнучкість з ітераціями тривалістю до трьох місяців. Більшість команд обирають відносно постійну довжину ітерацій. Деякі, однак визначають потрібну довжину перед початком кожної ітерації.

Agile-команда поставляє щось після кожної ітерації

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

    Принципово важливо, аби по завершенні кожної ітерації продукт був потенційно готовий до поставки. На практиці це не означає, що команда має виконати абсолютно все необхідне для постачання продукту, оскільки вона не зобов’язана випускати продукт після кожної ітерації. Наприклад, я  працюю з  командою, якій потрібно два місяці для тестування середнього терміну наробітку між відмовами (mean time between failure, або MTBF) перед випуском продукту, що включає як апаратну частину, так і  програмне забезпечення. Команда не може скоротити цей термін, оскільки він обумовлений клієнтом у контракті, і саме стільки часу необхідно для виявлення збоїв в апаратній частині. Команда працює чотиритижневими ітераціями, й  окрім двомісячного тестування MTBF, доводить свій продукт до працездатного стану наприкінці кожної ітерації. 

    Оскільки однієї ітерації зазвичай недостатньо для включення до ПЗ нової функціональності, що задовольняло б потреби користувача або клієнта, вводиться ширша концепція релізу. Реліз містить одну або кілька (зазвичай більше) ітерацій, що послідовно доповнюють одна одну, утворюючи повний набір пов’язаних функцій. Хоча ітерації найчастіше тривають від двох до чотирьох тижнів, на реліз зазвичай потрібно від двох до шести місяців. Наприклад, у системі управління інвестиціями один реліз може включати в себе всі функції, пов’язані з купівлею і продажем паперів пайових фондів і  фондів грошового ринку. Завершення такого релізу може потребувати шість двотижневих ітерацій (приблизно три місяці). Другий реліз може додати торгівлю акціями та облігаціями  — для цього потрібні додаткові чотири двотижневі ітерації. Релізи можуть відбуватися з різними інтервалами. Підготовка до першого релізу може тривати шість місяців. Наступний реліз — три місяці і т. д. 

Agile-команди фокусуються на бізнес-пріоритетах 

Agile-команди демонструють свою відданість бізнес-пріоритетам двома шляхами.

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

 По-друге, Аgile-команди зосереджуються на завершенні та реалізації цінних для користувачів функцій, а не на виконанні окремих завдань (що зрештою об’єднуються в цінну для користувачів функцію). Одним із кращих підходів до цього є робота з  користувацькими історіями — легковісною технікою вираження вимог до ПЗ [Cohn, 2004]. Користувацька історія — це короткий опис функціональності з погляду користувача або клієнта системи. Користувацькі історії викладаються у  довільній формі, будь-які синтаксичні правила до їх складання відсутні. Проте загалом непогано дотримуватися такої форми: «Як [тип користувача] я хочу отримати [можливість], аби отримати [бізнес цінність]». Скориставшись цим шаблоном, ви можете написати, наприклад, таку історію: «Як покупець книжок, я хочу здійснювати пошук книжок за номером ISBN для того, аби швидко відшукати потрібне мені видання»