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

«Будь-яку справу завжди триває довше, ніж очікується, навіть якщо врахувати закон Хофштадтера.»
— закон Хофштадтера

image
Найбільш проглядається ролик на YouTube по темі agile. 744 625 переглядів на момент публікації даної статті. Легкий стиль викладу, картинки і лише 15 хвилин — найкраще що я бачив. TED відпочиває.

Ролі

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


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


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


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


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

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

Так як команда використовує гнучку методологію розробки, вони не збирають всі ці історії до великого релізу, навпаки, вони випускають їх відразу і як можна частіше. Звичайно вони випускають 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), щоб синхронізувати всіх інших.

Велика картинка
Ісходник — Agile Product Ownership in a nutshell
відео англійською
відео російською

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.