Agile

Маніфест повністю

Спершу весь документ — бо його можна прочитати за дві хвилини і його цитують значно частіше, ніж читають. Чотири цінності й дванадцять принципів, відтворені точно так, як їх записали сімнадцять авторів у лютому 2001 року, і пронумеровані тут, щоб на рядок можна було послатися: «ми постійно порушуємо 2.8» — це розмова, яку команда може провести, а «ми не дуже agile» — це настрій. Кожен розділ нижче посилається на ці номери.

Українською — в офіційному перекладі, опублікованому на тому самому сайті, — декларація починається так: «Ми постійно відкриваємо для себе досконаліші методи розробки програмного забезпечення, займаючись розробкою безпосередньо та допомагаючи у цьому іншим. Завдяки цій роботі ми змогли зрозуміти, що:»

1. 1.Чотири цінності

   1. 1.1Люди та співпраця важливіші за процеси та інструменти
   2. 1.2Працюючий продукт важливіший за вичерпну документацію
   3. 1.3Співпраця із замовником важливіша за обговорення умов контракту
   4. 1.4Готовність до змін важливіша за дотримання плану

2. 2.Дванадцять принципів

   1. 2.1Найвищим пріоритетом для нас є задоволення потреб замовника, шляхом завчасного та регулярного постачання програмного забезпечення.
   2. 2.2Схвальне ставлення до змін, навіть на заключних стадіях розробки. Agile-процеси надають можливість використовувати зміни задля забезпечення конкурентоспроможності замовника.
   3. 2.3Працюючий продукт слід випускати якомога частіше, з періодичністю від пари тижнів до пари місяців.
   4. 2.4Впродовж усього проекту розробники і представники бізнесу повинні працювати разом щодня.
   5. 2.5Над проектом повинні працювати вмотивовані професіонали. Щоб робота була виконана, створіть їм умови, надайте підтримку і повністю на них покладіться.
   6. 2.6Особиста комунікація – найефективніший та найпрактичніший метод як донести інформацію до команди, так і поширити її всередині.
   7. 2.7Працюючий продукт – головний показник прогресу.
   8. 2.8Інвестори, розробники і користувачі повинні мати можливість підтримувати постійний ритм як завгодно довго. Agile допомагає налагодити такий сталий процес розробки.
   9. 2.9Постійна увага до технічної досконалості і якості проектування підвищує гнучкість проекту.
   10. 2.10Простота – мистецтво мінімізації зайвої роботи – вкрай необхідна.
   11. 2.11Найкращі вимоги, архітектурні та технічні рішення виникають у командах, що здатні самоорганізовуватись.
   12. 2.12Команда регулярно намагається знайти способи підвищення ефективності та відповідно корегує свою роботу.

І завершується: «Тобто, хоча, цінності, що справа важливі, ми все ж цінуємо більше те, що зліва.» Автори: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland і Dave Thomas. © 2001, вищезазначені автори: маніфест можна вільно копіювати в будь-якій формі, але лише повністю й разом із цим повідомленням. Переклад українською виконали Олексій Солнцев, Сергій Мовчан, Андрій Мудрий, Сергій Євтушенко, Ліна Шишкіна та Тім Євграшин.

Шар переконань, а не процес

Тепер про непорозуміння, з яким приходить майже кожен. Люди кажуть «ми працюємо за Agile» і мають на увазі двотижневі спринти, щоденну зустріч і дошку з колонками. Перечитайте шістнадцять рядків вище: нічого з цього там немає. В Agile немає ні ролей, ні церемоній, ні артефактів, і він узагалі не каже працювати спринтами.

Ось що сталося насправді. 11–13 лютого 2001 року сімнадцять розробників зустрілися на гірськолижному курорті Snowbird у штаті Юта. Вони працювали різними іменованими способами — Extreme ProgrammingExtreme Programmingagile-метод, що починається з інженеріїAgile-методологія кінця 1990-х, збудована навколо інженерних практик: розробка від тестів, парне програмування, безперервна інтеграція, рефакторинг і невеликі часті релізи. Від неї походить більшість того, що тепер називають технічною гнучкістю, і команда, яка переймає події Scrum без цих практик, зазвичай бачить, як її спринти сповільнюються.Усі терміни, Scrum, DSDM, Crystal, Adaptive Software Development, Feature-Driven Development, за книжками Pragmatic Programmer — і хотіли записати, що в цих підходах спільного. Спільними виявилися переконання, а не практики, і вони вмістилися на одну сторінку.

Тож спринти й стендапи беруться деінде — з методологій, збудованих поверх цих переконань. Корисно побачити весь стек одразу, бо більшість суперечок про те, чи «робимо ми Agile», насправді точиться між двома людьми, які говорять про різні його шари.

Чотири цінності — і що кожна на що міняє

Кожна цінність написана в одній формі: «A важливіше за B». Обидві сторони — справжні речі зі справжньою цінністю, і завершальне речення декларації каже про це прямо. Твердження стосується лише того, що переважає, коли вони справді конфліктують, — а конфліктують вони регулярно, тому документ і сформульовано саме так.

1.1 Люди та співпраця важливіші за процеси та інструменти

Процес описує, що має відбуватися. Інструмент фіксує, що відбулося. Жоден із них не може розвʼязати суперечку про те, що означає «готово», і жоден не помітить, що двоє людей зрозуміли ту саму вимогу по-різному.

Практична версія цієї цінності така: коли щось іде не так, спершу подивіться на розмову, а вже потім на процес. Команда, яка на кожну проблему відповідає новим обовʼязковим полем у шаблоні тікета, робить прямо протилежне тому, чого просить ця цінність.

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

Саме цю цінність найчастіше читають як «не пишіть документацію». Вона такого не каже. Вона каже, що коли треба обрати, куди піде наступна година, робочий продукт — чесніша міра прогресу. Рядок 2.7 далі формулює це вже як принцип.

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

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

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

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

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

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

У термінах контракту вибір зазвичай стоїть між fixed pricefixed priceузгоджений обсяг за узгоджену сумуКонтракт, у якому узгоджений обсяг віддають за узгоджену суму, тож вартість усього, що займе довше за план, несе виконавець. Саме тому fixed price приходить із найсуворішим контролем змін: будь-яка зміна обсягу є комерційною подією, а не лише плановою.Усі терміни, який фіксує обсяг і перетворює кожне відкриття на запит на зміну, і time and materialstime and materialsоплата за витрачені годиниКонтракт, у якому клієнт платить за фактично відпрацьований час, а не за фіксований обсяг, тож зміна напряму коштує грошей, а не перемовин. Ризик переходить до клієнта — тому ця модель приходить із більшою звітністю й важчою розмовою про те, що саме купили ці години.Усі терміни, де платять за час команди, а порядок робіт лишається за замовником. Agile-роботі значно природніше пасує друге. Поширений середній шлях — фіксований бюджет на ітерацію й обсяг, який узгоджують наново на кожному огляді: замовник може зупинитися після будь-якої ітерації й лишити собі те, що працює.

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

План — це гіпотеза про майбутнє, написана з тією інформацією, яка була в день його створення. Це не докір, а просто те, чим план є. Питання в іншому: що відбувається, коли зʼявляється нова інформація.

Триматися плану після того, як дані змінилися, — це не дисципліна. Це помилка втоплених витрат із графіком проєкту на додачу. Ця цінність просить сприймати переплановування як очікуваний наслідок того, що ви щось дізналися, а не як визнання, що початковий план був некомпетентним.

Ставка під усім цим: зміна має бути дешевою

Рядок 2.2 вітає зміну вимог «навіть на заключних стадіях розробки». Це має сенс лише за однієї умови: пізня зміна не повинна коштувати значно більше за ранню. Зверніть увагу, що це за умова. Це припущення про ваш код, ваші тести й ваш процес релізу — а не про ваші зустрічі.

Класичний погляд, який 1981 року виклав Баррі Боем, такий: вартість зміни множиться з кожною фазою, яку вже збудували на старому рішенні. Вимога, що виявилася хибною під час тестування, означає переробити дизайн, код і тести, збудовані на ній. Контртвердження Кента Бека 1999 року для Extreme Programming: криву можна тримати майже пласкою — з автотестами, безперервною інтеграцією, рефакторингом і простим дизайном.

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

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

Agile поруч із Waterfall

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

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

Петлі, а не фази

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

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

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

Читайте схему знизу. Лише реліз реальним користувачам може сказати, чи змінив продукт те, що вони роблять, — кожна петля вище відповідає на вужче питання про код чи план. І саме цю петлю команди найчастіше лишають розімкненою. Команда з двотижневими спринтами й квартальними релізами дізнається про своїх користувачів чотири рази на рік, хоч би що показувала її дошка, — і саме тому рядок 2.3 надає перевагу коротшому строку.

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

Дванадцять принципів — дванадцять перевірок

Цінності кажуть, чому надавати перевагу. У принципах ховаються справжні вказівки, і кожен можна перетворити на те, що ви помітите у своїй команді протягом тижня. І в кожного є підробка: практика, яка здалеку на нього схожа, а робить протилежне.

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

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

Шість програм — і рядок, який кожна перевірила

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

Де це вироджується в театр

Спершу чесна межа: доказів на користь Agile менше, ніж маркетингу. Найцитованіші цифри — ніби agile-проєкти вдаються в рази частіше — походять зі звітів CHAOS від Standish Group. 2010 року Евеленс і Верхуф застосували визначення Standish до 1211 реальних проєктів і показали, що ці визначення міряють, як був зміщений прогноз, а не чи вдався проєкт. Твердження, що виживає, вужче: там, де зміна дешева, а користувачі досяжні, короткі петлі знаходять помилки, поки ті ще дешеві. Зробити зміну дешевою чи замовника досяжним Agile не може.

Найгостріші критики — серед авторів. У березні 2014 року Дейв Томас, один із сімнадцяти, написав, що «agile» став іменником на продаж — сертифікати, інструменти, консультанти, — і закликав лишити собі прикметник. У травні 2018 року Рон Джеффріс, ще один підписант, закликав розробників відмовитися від того, що їм навʼязують під цією назвою. Коли двоє авторів кажуть, що слово захоплено, корисний хід — перестати сперечатися про слово й подивитися на петлі.

• Спринти, дошка й стендап, а релізи досі щокварталу — словник без петлі (2.3).
• «Agile» як виправдання для відсутності плану, документації й контракту — ніби права частина цінностей нічого не варта.
• Agile-трансформація, яка на старті фіксує обсяг, дату й бюджет, а решту називає agile.
• Ітерації без робочого інкременту — цикл існує на дошці, а не в production (2.7).
• VelocityVelocityскільки вміщується у спринтСкільки команда реально завершує за спринт, усереднено за кілька. Це допоміжна величина для планування однієї конкретної команди й нічого більше: порівнювати velocity двох команд чи ставити її за ціль означає надійно отримати роздуті оцінки, а не більше роботи.Докладніше в статті →Усі терміни чи story pointsstory pointsвідносний розмір, не годиниОдиниця для оцінки відносного розміру задач беклогу — 8 приблизно вдвічі більше за 5, — навмисно не привʼязана до годин. Корисні для планування однієї команди й більше ні для чого: перетворені на ціль чи порівнювані між командами, вони роздуваються замість вимірювати.Докладніше в статті →Усі терміни як показник продуктивності — це надійно роздуває оцінки, а не результат.
• Ретроспективи, що дають обговорення, але жодної дії з конкретним відповідальним (2.12).
• Стійкий темп тихо забувають перед кожним релізом і ніколи не повертають борг (2.8).
• Беклог, що лише росте, без жодного механізму рішення чогось не будувати (2.10).
• Оргструктура іншої компанії, взята за модель без рефлексії, яка її породила (2.11, 2.12).
• Сертифікати й інструменти, які зараховують як упровадження, хоча до користувачів нічого не доходить швидше.

Коли це застосовувати

Пов’язані сторінки

• МенеджментScrumScrum — це фреймворк, у якому команда до десяти людей видає придатний інкремент у фіксованих циклах до місяця — спринтах — і коригує курс на пʼяти подіях. Він визначає три зони відповідальності, три артефакти й ці пʼять подій — і свідомо нічого не каже про інженерію. Сторінка починається з усього фреймворку на одному екрані — кожна подія з таймбоксом, хто присутній і що вона дає; далі — теорія, на якій він тримається, кожна подія по черзі разом із чотирма зустрічами, які додають реальні команди, зони відповідальності й чому межа — десятеро, Definition of Done і що стається, коли вона зупиняється зарано, пʼять задокументованих епізодів і де все це вироджується.
• МенеджментKanbanKanban — це спосіб керувати роботою, який починається з наявного процесу й покращує його, обмежуючи незавершену роботу й вимірюючи, як вона тече. Він не додає ні ролей, ні спринтів. Сторінка починається з усіх елементів Kanban-системи на одному екрані — що команда записує і як виглядає відсутність кожного; далі — чому дошка сама по собі ще не Kanban і хто визначає метод, шість принципів і шість практик, чотири метрики потоку й арифметика під ними, прогноз з історії замість оцінок, сім ритмів, пʼять задокументованих випадків і де все це вироджується.
• МенеджментЧекліст PM на новому проєктіПерші дев’яносто днів проєктного менеджера на проєкті, який почав не він, — це діагноз і далі невелика кількість свідомих змін, а не реорганізація. Перший місяць — з’ясувати, як робота тече насправді; другий — домовитися, що саме ви зміните і з ким; третій — приземлити перші зміни й уміти показати, що вони зрушили. Ця сторінка і є тим чеклістом, разом із ситуативним судженням, яке вирішує, які його частини стосуються саме вас.