Як пояснити бабусі, що таке Agile за 15 хвилин з картинками

ролі

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

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

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

У зацікавлених осіб багато ідей, і Пет допомагає зробити з ідей призначені для користувача історії.

Це команда розробників. Ті, хто будуватиме робочу систему.

Пропускна здатність

Так як команда використовує гнучку методологію розробки, вони не збирають всі ці історії до великого релізу, навпаки, вони випускають їх відразу і якомога частіше. Зазвичай вони випускають 4-6 користувальницьких історій в тиждень. Це їхня пропускна здатність. Її дуже просто виміряти - кількість призначених для користувача історій за 7 днів.

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

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

Проблема полягає в тому, що зацікавлених осіб дуже багато і їх запити неможливо задовольнити 4-6 історіями в тиждень.

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

Що станеться, якщо ми будемо робити все, про що вони нас просять? У нас буде перевантаження.

Припустимо, команда візьметься зробити 10 нових історій за цю неделю.Еслі на вході 10 а на виході 4-6, то команда буде перевантажена. Поспішатиме, перемикатися між завданнями, втрачати мотивацію, в результаті знижується продуктивність і якість. Це свідомо програшна стратегія.

Scrum і XP в цьому випадку використовують метод "вчорашня погода". Команда каже: "За останній час ми робили 4-6 фич в тиждень, які 4-6 фич ми будемо робити на наступному тижні?"

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

Kanban рекомендує обмежитися декількома завданнями - WIP limit. Припустимо команда вирішує, що 5 - це прийнятне кількість призначених для користувача історій, над якими вони зможуть працювати одночасно без перевантаження, що не перескакуючи з однієї на іншу.

Обидва ці підходи добре працюють і обидва вони створюють чергу завдань, які в Scrum називається Backlog, або пріоритезувати список завдань.

Цією чергою теж необхідно управлять.Еслі зацікавлені особи запитують 10 історій в тиждень, а команда реалізує 4-6 історій, то ця черга буде ставати все більше і більше. І скоро ваш Backlog буде розписаний на півроку вперед. Тобто одна історія буде чекати виходу 6 місяців.

Є тільки один спосіб тримати список завдань під контролем - це слово "ні"

Це найбільш важливе слово для власника продуктом. Він повинен тренувати його щодня перед дзеркалом.

Сказати "так" - легко. Але більш важливе завдання - вирішувати, що не треба робити і нести за це відповідальність. Власник продукту так само визначає послідовність, що робимо зараз, а що пізніше. Це складна робота і виконувати її слід разом з командою розробки і мінімум одним зацікавленою особою.

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

Прийняття рішень

Деякі історії вкрай необхідні, а деякі просто бонусні фичи. На розробку одних історій піде пару годин, на розробку інших - місяці.

Як співвідноситься розмір історії та її цінність? Ніяк.

Більше не означає краще. Цінність і складність завдання - ось що допомагає Пет розставляти пріоритети.

Як власник продукту визначає цінність і обсяг історії? Ніяк.

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

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

Однією пріоритетності недостатньо. Щоб випускати історії швидко і часто, потрібно розбивати на шматочки, які можна зробити за пару днів. Ми хочемо щоб на початку воронки були маленькі і чіткі історії а в кінці - великі і невизначені. Вчасно робити таку розбивку ми можемо скористатися нашими останніми відкриттями щодо продукту і потреб користувача. Це все називається очищення Backlogа.

Пет проводить зустріч з очищення Backlogа щосереди з 11 до 12. Зазвичай на ній збирається вся команда і іноді кілька зацікавлених осіб. Зміст зустрічей буває різним. Фокусування на оцінці, на розбивці історій, на умовах приймання.

Власник ІТ-продукту повинен постійно з усіма спілкуватися

Досвідчені власники продукту виділяють 2 компоненти успіху: пристрасть до роботи і спілкування. Які завдання власник продукту вирішує місці з командою.

Баланс між складністю розробки та цінністю для користувача історії

На ранній стадії балансу загрожує невизначеність і відразу кілька ризиків.

ризики

• Бізнес ризик: «Правильну чи річ ми робимо?»
• Соціальний ризик: «Чи зможемо ми зробити те що потрібно?»
• Технічний ризик: «Чи буде проект працювати на цій платформі?»
• Ризики з вартістю і термінами реалізації: «Чи встигнемо і чи вистачить грошей?»

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

Компроміс між цінностями знання і цінностями для клієнта

З точки зору замовника крива виглядає ось так:

З точки зору цінності для замовника ця крива виглядає ось так.

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

Компроміс між короткостроковими та довгостроковими мисленням

Що реалізувати в першу чергу? Терміново усувати помилки або почати розробляти карколомну фичу, яка вразить користувачів. Або робити складний апгрейд платформи, який прискорить роботу в майбутньому. Необхідно постійно дотримуватися балансу між реактивної та проактивного роботою.

Робити правильні речі, робити речі правильно або робити швидко?

В ідеалі - все три одночасно, але в реальності доводиться вибирати.

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

Ми робимо швидко прототип продукту. Для короткострокової перспективи це непогано. У довгостроковій - ми отримуємо технічний ризик. І швидкість розробки знизиться до нуля. або:

Ми ось тут, створюємо прекрасний храм в рекордні терміни. Але користувачеві не потрібен був храм, йому потрібен був житловий фургон.

Між ролями в Scrum існує здорове протистояння

Власник продукту фокусується на побудові правильних речей. Команда фокусується на тому, щоб будувати речі правильно. Scrum-майстер або agile-тренер фокусується на скорочення циклу зворотного зв'язку.

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

Компроміс між розробкою нового продукту і поліпшенням старого

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

Графік знищення історій

Час від часу, зацікавлені особи будуть питати у Пет: "Коли випустять мою фичу?" Або "Скільки фич випустять до Різдва?". Власник продукту повинен вміти управляти очікуваннями користувача. І управляти очікуваннями реалістично.

Два тренда - оптимістичний і песимістичний (можна на око). Відстань між трендами показує наскільки нестабільна швидкість роботи команди. Згодом ці тренди стабілізуються і конус невизначеності буде зменшуватися.

Припустимо, зацікавлена ​​особа запитує, коли ось ця фіча буде зроблена?

Це питання з фіксованим вмістом і невизначеним терміном. Для відповіді Пет використовує дві лінії тренда. Відповідь - у квітні або травні.

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

Зацікавлена ​​особа запитує: «Чи встигнемо ми зробити ось ці фічі до різдва?» Це питання з фіксованими тимчасовими рамками і фіксованим змістом. Орієнтуючись на тренди, Пет відповідає: «Ні». Додаючи: «До Різдва ми встигнемо зробити стільки, а ось стільки часу нам знадобиться щоб завершити всю цю роботу повністю.»

Зазвичай краще зменшувати вміст проекту, ніж збільшувати час. Якщо ми зменшуємо зміст, у нас буде можливість відсунути терміни. Ми можемо випустити дещо тут, а решта - пізніше.

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

кілька команд

Нехай у нас кілька власників продукту і кілька команд. Модель та ж - управління пропускною спроможністю, комунікація з зацікавленими особами, прийняття рішень з приводу відхилення користувальницьких історій. Швидкість дорівнює сумі швидкостей всіх команд. Прогнозування може бути загальне або по кожній команді. У власників продуктів з'являється додаткова задача - спілкування з іншими власниками продукту. Потрібно організувати роботу над Backlogамі так, щоб мінімізувати залежності і забезпечити синхронізацію. У великих проектах потрібно Головний власник продукту (CPO), щоб синхронізувати всіх інших.

Відео англійською

відео російською