Estimates or Guesstimates? Обираємо метод оцінювання задач

Стаття написана у співавторстві з Віталієм Шквирою.

Процес планування проєктів складний, а плани нерідко виходять за межі реальності. Як наслідок, команди часто опиняються в одній із двох діаметрально протилежних ситуацій: вони або повністю відмовляються від планування, або витрачають стільки сил на створення планів, що починають вірити в їхню правильність. Команди, які відмовляються від планування, не можуть відповісти собі на фундаментальні запитання, наприклад «Коли завдання буде виконано?» та «Чи можемо ми очікувати на випуск продукту до дня Х?» Парадоксально, проте ретельно пропрацьований план не обов’язково вирізнятиметься високою точністю й інформативністю.

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

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

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

• Story Points;
• Man/Days або Man/Hours;
• No Estimate.

Story Points

Почнемо з простого й сучасного тренду — оцінювання в Story Points. Це один з абстрактних типів оцінювання, який показує складність, обсяг і рівень невизначеності елементів беклогу один щодо одного й більше підходить для Agile-проєктів. Story Points зазвичай використовують, коли немає чітких дедлайнів та фіксованого бюджету на весь проєкт, а вимоги зафіксовано на високому рівні. Детальне оцінювання виконують лише для найближчих ітерацій, тоді як інші етапи можна оцінювати абстрактніше (наприклад методом T-Shirt Sizes).

Одним з обов’язкових принципів оцінювання є те, щоб кожен член команди мав однакове розуміння, чому дорівнює 1 story point.

Story point — це найменша абстрактна величина, яка виражає зусилля, потрібні для виконання поставленої задачі.

Параметри, які враховують під час оцінювання:

• Обсяг роботи для виконання поставленої задачі — наскільки великою є user story й скільки часу займає реалізація.
• Складність роботи — наскільки складною буде реалізація завдання.
• Ризики й невизначеність під час виконання задачі — які змінні та невідомі фактори можуть вплинути на цю user story.
• Знання — як багато команді відомо про цю задачу.

Обов’язково враховуйте кожен із цих параметрів, коли вимірюєте роботу в Story Points.

Якщо додати оцінювання в Story Points для всіх елементів беклогу, то ми отримаємо загальний розмір проєкту.

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

Ключовий момент Agile-підходу до оцінювання та планування полягає в тому, що ми оцінюємо розмір і на основі цих даних визначаємо час виконання. Припустимо, що ми оцінили всі User Stories і сума цих оцінок становить 100 Story Points. Це розрахунковий розмір системи. До прикладу, з минулого досвіду нам відомо, що швидкість команди становить 10 Story Points за ітерацію, і ми можемо припустити, що команда працюватиме з такою самою швидкістю й у цьому проєкті. Коли нам відомі розрахунковий розмір і швидкість команди, ми можемо визначити строк виконання 10 ітерацій. Відрахуємо 10 ітерацій у календарі й отримаємо календарний графік.

Розгляньмо переваги й недоліки цього методу оцінювання:

Переваги

Недоліки

Добре поєднується з Agile-практиками. Адаптивний. Точність зростає з кожною ітерацією. Не вимагає багато часу. Досвід і навички окремих людей не важливі для оцінювання й реалізації. Дає змогу приблизно оцінити строки виконання (підходить для оцінювання дати релізу або окремої фази). Немає потреби переглядати зроблені оцінки після зміни членів команди. Розміри елементів беклогу зіставні між собою. Сприяють крос-функціональній взаємодії в команді.

Вимагає уваги (команди нерідко завищують оцінку роботи в гонитві за продуктивністю). Складність розуміння story point для команди (точність оцінювання знижується). Залежить від історичних даних (низька точність на перших ітераціях). Знижується точність оцінювання концептуально нових елементів беклогу. Швидкість виконання задач (Velocity) залежить від знань і досвіду команди розробників. Будь-які зміни в складі команди впливатимуть на швидкість, а відповідно, і на оцінювання на цьому етапі. Не дає змоги точно оцінити строки (не підходить для оцінювання ітерації — докладніше в статті Mike Cohn).

Техніки оцінювання

• Planning Poker
• Bucket System
• Dot-voting
• Affinity Mapping
• Big/Small/Uncertain
• T-Shirt Sizes Estimation

Man/Days або Man/Hours

На відміну від попереднього методу Man/Days або Man/Hours використовуємо для оцінювання, коли в нас є визначений беклог і ми знаємо всі деталі проєкту й обіцяємо клієнту виконання роботи за конкретний відрізок часу. Ми не можемо написати клієнту, що його завдання оцінять у стільки-то Story Points, бо це буде непрофесійно й незрозуміло. Натомість слід показати результат у днях і годинах, які можна легко перевести в гроші.

У софтверному проєкті ідеальний час для виконання певної задачі відрізняється від загального витраченого часу через природні непродуктивні витрати, як-от час, витрачений на електронні листи, консультації колег, мітинги тощо. Також враховуємо фокус-фактор: незаплановані вихідні й лікарняні, різні часові зони, розподілені локації (перелік можна продовжувати). Коли ми говоримо про ідеальний час, то повинні розуміти, що хороший інженер може ефективно працювати від 5 до 6 годин на день. У результаті, коли бачимо, що член команди оцінив свою задачу в 8 годин, ми розуміємо, що ефективно він працюватиме від 62 до 75% того часу. Відповідно, коли ми визначаємо Capacity Per Day, то задача, яку ми початково оцінили у 8 годин, прораховуємо фактично як 10,7 години. Якщо ж для оцінювання використовувати ідеальні дні, то треба враховувати лише час, витрачений безпосередньо на реалізацію проєкту.

Переваги й недоліки цього методу оцінювання:

Переваги

Недоліки

Поширений і зрозумілий метод для команди та стейкхолдерів. Нескладно прорахувати вартість роботи. Простий у використанні. Можливе (навіть бажане) використання досвіду інших проєктів (аналогове оцінювання). Використовується для планування точних дат ітерацій, фази й релізу (якщо вимоги достатньо точні та докладні). Дає можливість контролювати хід виконання робіт, аналізуючи відхилення від плану (Plan vs Fact / Burndown Chart). Зручніший для роботи з ризиками. Знижує рівень стресу, що, врешті, позитивно впливає на якість виконання (за моїми спостереженнями, приблизно 40% помилок під час розробки програмного забезпечення зумовлені стресом команди внаслідок відсутності належного планування). Точні оцінювання підвищують довіру до команди.

Вимагає істотних часових затрат. Необхідність декомпозиції задач — задачі, виконання яких займає більше ніж 4 години, оцінити важко. Передбачає наявність чітких та детальних вимог, розуміння продукту, домену й архітектури. Оцінювання конкретної задачі актуальне лише коли її оцінює виконавець (зміна виконавця вимагає переоцінювання задачі). Людям властиво оцінювати за ідеальних умов (Sunny Day Scenario), що, врешті, занижує оцінку. Вимагає високого рівня компетентності та навиків команди. Ідеальні години можуть бути різними в кожного з членів команди.

Техніки оцінювання

• Експертне оцінювання (Expert Judgement)
• Методи оцінювання за трьома точками (Three Point Estimation)
• Аналогове оцінювання (Analogous Estimation)
• Оцінювання за параметрами й моделювання (Parametric Model)
• Оцінювання від окремих елементів до загального оцінювання (Bottom-up Estimation)

No Estimate

До цього методу варто вдаватися, коли ви не бачите сенсу витрачати час на оцінювання. З точки зору Lean-практик, зусилля варто спрямовувати лише на ті активності, які приносять користь (Value) — замовнику або клієнту. Найчастіше такий підхід використовують команди, що займаються тільки підтримкою або підтримкою і розробкою нового функціонала одночасно. Ми не фокусуємося на визначенні дати виконання тієї чи іншої задачі, працюємо за принципом just in time: задача буде виконана настільки швидко, наскільки це можливо.

Усе ж підхід No Estimate — не зовсім про відсутність оцінювання проєкту як такого, а більше про мінімізацію витрат часу на оцінювання. Тут з’являються інші метрики для команди — Work in Progress (WIP) та Idle Time (час затримки на кожному етапі).

Тепер оцінимо плюси й мінуси цього підходу.

Переваги

Недоліки

Суттєво зменшує/наближає до нуля час на оцінювання, який у середньому становить 40% від загального часу планування. Передбачає однакові або схожі за розміром задачі, що дає змогу ефективно вимірювати продуктивність. Ефективний за умов високої невизначеності й частих змін (Cycle Time < Time for changing requirements). Використовується, коли пропускна спроможність команди задовольняє потреби клієнта. Залежить від етапу проєкту. NoEstimates — це не лише про розробку без використання оцінювання загалом, а про те, щоб проводити оцінювання якомога швидше з кожним новим етапом проєкту.

Прогнозування вимагає наявності історичних даних і базується на кореляціях та припущеннях. Імовірність серйозних змін через відсутність попереднього досвіду або детальних вимог. Не підходить для проєктів з фіксованим Scope, Schedule або Budget.

Метод оцінювання — Forecasting Based on Lead and Cycle Time.

Порівняння методів оцінювання

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

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

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

Важливо: діаграми, наведені вище, ґрунтуються виключно на досвіді авторів, але достатньо точно відображають загальний досвід в індустрії.

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

• 5 розробників;
• 2 тестувальники;
• 1 DevOps-інженер;
• 1 проєктний менеджер.

Story Points

Проєкт

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

Умови

Можливість часто й безболісно вносити зміни до вимог і існуючого функціонала. Регулярна доставка випущеного функціонала (наприкінці кожної ітерації). Product Owner володіє довгостроковим баченням продукту на високому рівні й детальним на рівні короткострокового планування (1-3 ітерації). Запити на зміни й пріоритети надходять регулярно, як правило, наприкінці ітерації. Випуск інкременту в кінці кожної ітерації.

Метрики

• Velocity — швидкість роботи команди.
• Accuracy — точність оцінювання.

Переваги

• Достатньо точний прогноз на найближчі 1-3 ітерації.
• Орієнтовний прогноз на найближчий реліз або весь проєкт.
• Відносна гнучкість внесення змін.

Man/Hours

Проєкт

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

Умови

Виконання проєкту в межах узгоджених строків і бюджету й високий ступінь прогнозованості. Product Owner, або Замовник, володіє довгостроковим баченням продукту на детальному рівні. Запити на зміни й пріоритети надходять регулярно, зазвичай наприкінці ітерації.

Метрики

• Cost Performance Index (CPI) — індекс виконання бюджету.
• Schedule Performance Index (SPI) — індекс виконання графіка.
• Variances — відхилення від бюджету або графіка.

Переваги

• Точне розуміння строків і бюджету всього проєкту або окремого релізу/фази.

No Estimate

Проєкт

Систему запущено в продакшен. Обсяг роботи й бюджет зафіксовано на високому рівні, і жорстких обмежень немає. Проєкт ґрунтується на Roadmap’і продукту.

Умови

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

Метрики

• Work In Progress (WIP) — кількість задач, які одночасно перебувають у роботі.
• Idle Time — час простою.
• Lead Time — період між появою нової задачі у воркфлоу і її закриттям.
• Cycle Time — час між початком роботи і доставкою результату роботи споживачеві.
• Throughput — кількість робочих задач, які команда може виконати в заданий період часу (тиждень, місяць тощо).

Переваги

• У роботі лише актуальні й пріоритетні завдання (коротке планування відбувається щодня).
• Заощадження часу планування, який інвестовано в роботу над задачами.
• Користувачі отримують Value у вигляді оновлень, які регулярно доставляють.

Висновки й рекомендації

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

• Проєкти з обмеженнями завжди вимагають оцінювання. Якщо обмеження жорсткі, оцінювання виконуйте в Man/Hours або Man/Days.
• Для проєктів, які передбачають підтримку (тим більше з фіксованою угодою про SLA-рівень послуг), є сенс застосовувати No Estimate.
• Завжди враховуйте ризики, складність завдань і ступінь невизначеності. Залучайте до оцінювання команду і стейкхолдерів.
• Уточнюйте, що важливо для спонсора проєкту. Як правило, прозорість і прогнозованість переважають над вартістю й строками.
• Приділяйте час процесам незалежно від підходу до оцінювання, який ви використовуєте. Неконтрольований процес оцінити неможливо.
• Враховуйте всі види робіт, а не лише кодування й тестування.
• Залучайте експертів до перевірки оцінювань і не занижуйте оцінку роботи розробників без аргументації :)

Як бонус пропоную список рекомендованої літератури:

• Software Estimation: Demystifying the Black Art by Steve McConnell;
• NoEstimates by Vasco Duarte;
• Agile Estimating and Planning by Mike Cohn;
• When will the Agile Project be done? by Michael Küsters.

Сподіваюся, стаття буде корисною для вас. Буду радий вашим коментарям і запитанням.

Головне зображення: Thinking Techniques