Agile

Чим Agile є насправді

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

Agile не є методологією. Він не каже вам проводити жодну зустріч, використовувати жодну дошку чи взагалі працювати спринтами. У ньому немає ні ролей, ні церемоній, ні артефактів.

Ось що сталося насправді. У лютому 2001 року сімнадцять розробників зустрілися на гірськолижному курорті в Юті. Усі вони працювали по-різному — хтось за методом Extreme Programming, хтось за Scrum, хтось інакше — і хотіли знайти те спільне, що є в цих підходах. За два дні вони написали документ із чотирьох речень і дванадцяти коротких принципів. Це і є Agile Manifesto, і він уміщається на одній сторінці.

То звідки ж беруться спринти й щоденні зустрічі? З методологій. Scrum, Kanban, XP і SAFe — це методології, і кожна конкретно каже, що робити: які зустрічі проводити, які є ролі, як планувати. Agile — це шар під ними: спільні переконання, на яких ці методології збудовані.

Чотири цінності по черзі

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

Люди та взаємодія понад процеси й інструменти

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

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

Робочий продукт понад вичерпну документацію

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

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

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

Співпраця із замовником понад узгодження умов

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

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

Реагування на зміни понад дотримання плану

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

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

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

Під чотирма цінностями лежать дванадцять принципів. Їх зазвичай пропускають, і це прикро: цінності кажуть, чому надавати перевагу, а от у принципах ховаються справжні вказівки.

Їх легше засвоїти чотирма групами, ніж списком із дванадцяти. Ось кожна група і те, чого вона від вас вимагає простими словами.

• Постачання цінності (1, 3, 7)

  Задовольняти замовника ранньою та безперервною поставкою. Випускати кожні кілька тижнів, віддаючи перевагу коротшому строку. Вимірювати прогрес робочим продуктом, а не закритими задачами чи створеними документами.

• Прийняття змін (2, 4)

  Вітати зміну вимог навіть на пізніх етапах. Бізнес і розробники мають працювати разом щодня, а не передати роботу на старті й зустрітися наприкінці.

• Довіра до людей (5, 6, 11)

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

• Утримання темпу (8, 9, 10, 12)

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

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

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

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

Як це виглядає як ритм

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

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

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

Agile поруч із Waterfall

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

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

Як це виявляється в реальній поставці

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

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

Типові збої

• Ітерації без готового до релізу інкременту — цикл існує на дошці, але не в production.
• Ретроспективи, що дають обговорення, але жодної дії з конкретним відповідальним.
• Беклог, яким володіє комітет, — пріоритет узгоджується, а не ухвалюється.
• Velocity як показник продуктивності — це надійно роздуває оцінки, а не результат.
• Стійкий темп тихо забувають перед кожним релізом і ніколи не повертають борг.

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

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

• МенеджментScrumScrum — це найпоширеніший спосіб організувати роботу команди розробки. Scrum ділить роботу на короткі фіксовані цикли — спринти, дає трьом ролям чіткі зони відповідальності й обкладає роботу невеликим набором регулярних зустрічей, щоб проблеми спливали за дні, а не за місяці. На цій сторінці ми пройдемо кожну з цих зустрічей — включно з кількома, які реальні команди проводять, хоча в офіційному посібнику їх немає.
• МенеджментKanbanKanban — це спосіб керувати роботою, який починається з наявного процесу й покращує його під вимірюванням. Kanban не додає ні ролей, ні спринтів. Він додає одне правило — обмеження кількості задач, над якими можна працювати одночасно, — і саме це обмеження змушує працювати все інше в методі. На цій сторінці ми розберемо дошку, метрики, сім регулярних зустрічей, які метод визначає, і те, як на практиці встановити це обмеження.
• МенеджментWaterfallWaterfall — це спосіб вести проєкт у строгому порядку: завершити й затвердити кожну фазу до початку наступної. Waterfall зазвичай викладають як застаріле, що його замінив Agile, і це водночас несправедливо й некорисно. Це правильний вибір щоразу, коли змінити рішення пізніше коштує дорожче, ніж ретельно описати зараз, — а таке трапляється частіше, ніж підказує його репутація.