Як планувати і оцінювати проекти в Agile?

Кілька років тому Тренер Luxoft Agile Practice — В'ячеслав Москаленко зіткнувся з проблемою, що багато Скрам-команди не оцінюють всі історії в Бэклоге Продукту. А дарма, адже оцінка дає нам прозору картину реального прогресу і можливість управляти очікуваннями наших замовників, не чекаючи фінішній прямій нашого проекту, коли вже пізно щось міняти.

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

Коли я в перший раз провів гру-розмальовку на одному з майстер-класів місцевої ПМ-тусовки, навіть не очікував, що досить консервативні менеджери проведуть так весело час та отримають пояснення „Що таке відносний сторі поінт? В чому його цінність?“. З тих пір я провів цю гру на багатьох тренінгах та кількох конференціях, включаючи SECR-2015 і Agile Days Russia 2016».



Мета
Показати як використання ітераційно-інкрементального підходу в сукупності з відносною оцінкою дає більше прозорості в прогнозуванні термінів виконання проекту.


Зазвичай гра займає близько однієї години, включаючи обговорення.

  • 15 хвилин – оцінка
  • 35 хвилин – завершити зафарбовування (тривалість ітерації = 1 хвилина)
  • 10 хвилин – обговорення
<habracut/>Підготовка:

  • Розбити групу на команди з 3-5 чоловік
  • Команди повинні сидіти за столом
  • Один чистий аркуш фліп-чарт папери на пункт
  • Один фліп-чарт маркер на одного учасника

Інструкції

Оцінка

1. Для кожної групи підготувати однакові фліп-чарти з порожніми фігурками. См. приклад нижче

image
2. Ведучий гри готує на фліп-чарті таблицю, в якій він буде фіксувати метрики всіх команд:

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

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

Виконання

1. Довжина однієї ітерації не більше хвилини.

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

3. Запускаємо першу ітерацію:

image
4. Ведучий приймає роботу. Зараховуємо тільки ідеально зафарбовані фігури, або сегменти (якщо була попередня розбивка). Команда вважає Velocity.

5. Частково зроблена робота переоцінюється у сторі-пойнтах в бік зменшення, але різниця не додається в сумарну швидкість (тобто швидкість показує тільки прийняту роботу). У мене часто запитують «чому»? Я розумію, що прикро втрачати поінти, коли історія в кінці спринту завершено на 90% (поінти пройдуть як-би повз команди). Питання тільки в тому чого хоче команда, показати високу швидкість або завищити очікування замовника? Можливо у цієї незакінченої історії дійсно залишилося 10% робіт. Але раптом, доробляючи ці 10%, ви виявляєте дефект, на рішення якого ви витратите ще +50% вашого часу. А замовникам то вже показали високу швидкість? Саме тому спільнота скрам-практиків не рекомендує включати швидкість (Velocity) будь-недороблені історії.

6. Команда перераховує суму залишилися сторі-поінтів на фліп-чарті і прогнозує термін виконання проекту за формулою.

Час виконання = Сума сторі-поінтів\Velocity

Швидше за все термін виконання буде відрізнятися від спочатку запланованого

7. Повторюємо кроки 1-6 до виконання проекту за закраске:

image
8. Команда святкує завершення проекту.

image

Обговорення

1. Якщо ще перед першою ітерацією у команд вийшли різні оцінки, обговоріть як замовник може зрозуміти хто правий? У підсумку може виявитися (а це найімовірніший результат), що всі неправі, тому що обіцяти точні терміни в комплексній системі справа невдячна. Обговоріть як не потрапити в пастку своїх невірних оцінок?

2. Якщо команди не заробили очок після першої ітерації. Обговоріть чому важливо в кінці ітерації мати готовий інкремент? Чому наполовину готовий інкремент не показує прогрес? Чому наполовину готовий інкремент може дати великі похибки у підрахунку прогнозу виконання проекту?

3. Продемонструйте як намалювати Release Burn-Down Chart, використовуючи дані з таблиці.

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

5. Зібрати і зафіксувати зворотний зв'язок від учасників. Що дізналися нового? Чого навчилися? Що вправи можна пробувати в реальному житті?

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

7. Дослідіть цінність поділу великих завдань\історій (фігур) і як команди поліпшувалися між ітераціями.

Спасибі за увагу!

P. S. 29-31 серпня В'ячеслав проводить сертифікований тренінг Professional Scrum Master в Москві.
Джерело: Хабрахабр

0 коментарів

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