This page has been robot translated, sorry for typos if any. Original content here.

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

Agile за 15 хвилин з картинками
Велика картинка відкриється після натискання в новому вікні!

Гнучка методологія розробки (англ. Agile software development, agile-методи) - серія підходів до розробки програмного забезпечення, орієнтованих на використання итеративной розробки, динамічне формування вимог і забезпечення їх реалізації в результаті постійної взаємодії всередині самоорганізованих робочих груп, що складаються з фахівців різного профілю. Існує кілька методик, що відносяться до класу гнучких методологій розробки, зокрема екстремальне програмування, DSDM, Scrum, FDD.

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

Agile-методи роблять упор на безпосереднє спілкування віч-на-віч. Більшість agile-команд розташовані в одному офісі, іноді званому англ. bullpen. Як мінімум, вона включає і «замовників» (англ. Product owner - замовник або його повноважний представник, який визначає вимоги до продукту; цю роль може виконувати менеджер проекту, бізнес-аналітик або клієнт). Офіс може також включати тестувальників, дизайнерів інтерфейсу, технічних письменників і менеджерів. Основний метрикою agile-методів є робочий продукт. Віддаючи перевагу безпосередньому спілкуванню, agile-методи зменшують обсяг письмової документації в порівнянні з іншими методами. Це призвело до критики цих методів як недисциплінованих.

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

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

ролі

Agile за 15 минут с картинками

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

Agile за 15 минут с картинками

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

Agile за 15 минут с картинками

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

Agile за 15 минут с картинками

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

Agile за 15 минут с картинками

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

Agile за 15 минут с картинками

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

Agile за 15 минут с картинками

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

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

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

Agile за 15 минут с картинками

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

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

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

Agile за 15 минут с картинками

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

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

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

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

Agile за 15 минут с картинками

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

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

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

Agile за 15 минут с картинками

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

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

Agile за 15 минут с картинками

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ризики

Agile за 15 минут с картинками

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

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

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

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

Agile за 15 минут с картинками

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

Agile за 15 минут с картинками

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

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

Agile за 15 минут с картинками

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

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

Agile за 15 минут с картинками

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

Agile за 15 минут с картинками

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

Agile за 15 минут с картинками

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

Agile за 15 минут с картинками

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

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

Agile за 15 минут с картинками

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

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

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

Agile за 15 минут с картинками

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

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

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

Agile за 15 минут с картинками

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

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

Agile за 15 минут с картинками

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

Agile за 15 минут с картинками

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

Agile за 15 минут с картинками

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

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

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

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

Agile за 15 минут с картинками

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

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

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

Via Agile Product Ownership in a nutshell & habrahabr.ru & wiki