Оцінка всього беклогу as early as possible

Так, так – у Agile проекті потрібно робити якомога повну оцінку всього беклогу. Так – це буде не точна та не повна оцінка. Але це оцінка!

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

Що поганого коли ми не робимо оцінку:

  • Виникають оптимістичні очікування – вони мультиплікуються ланцюгом (Product Onwer -> Sponsor -> Investor -> Stakeholder)
  • Невірно робиться пріоритизація – PO здається фіча простою та незначною
  • Невірно робить оцінка готовності фіч – PO може вважати що це готово, є платформі
  • Великий ризик того що інженери не в курсі проекту. Оцінка буде вимагати від них розуміння проекту в цілому.

Чому потрібна оцінка якомога раніше?

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

Чому потрібно ставитись обережно до оцінки беклогу:

  • Це не буде точна оцінка – не потрібно перебільшувати точність оцінки.
  • Це не буде commitment команди – не потрібно через два місяці казати що як так розробка займає в два рази більше ніж ви оцінювали
  • Ми не враховуємо зміни – а вони будуть. І це має бути додатковим процентом типового обсягу змін для такого класу проектів.
  • Ми не враховуємо неповноту та неточність вимог – а вона є. І це має буди коефіцієнтом корегування.
  • Попередня оцінка не має впливати на оцінку перед виконанням – її потрібно проводити більш ретельно.
  • Зазвичай випадає тестування та стабілізація. Тому використовуйте щонайменше коефіцієнт для корективи на обсяг роботи з тестування та виправлення помилок.
  • А ще всі забувають про обсяг роботи з менеджмент
  • аналіз вимог, роботу з замовником
  • …. R&D якщо є нові технології, нові бібліотеки тощо
  • … і про комунікації. Щоденні сінкапи,

Що потрібно робити під час точних оцінок для найближчих ітерацій:

  • Порівнювати первинну оцінку з детальною. Визначати коефіцієнт похибки. Використовувати його для корегування очікувань.
  • Аналізувати що змінилось. Якщо саме ці зміни можуть вплинути на інших частини беклогу – можна зробити оновлення попереднього розрахунку

Залишити відповідь