Ще раз про оцінювання задач

#testing #process

Минулого тижня я прочитав дві вкрай практичні статті про те, як робити естімейти.
- Rules of Thumb for Software Development Estimations
- My Software Estimation Technique

Далі я наводжу мої короткі нотатки (авжеж краще ознайомитись із оригіналом!)

Про оцінки
- Не існує двох повністю ідентичних проєктів
- Невизначеність буде завжди
- Комунікації між командою та бізнесом впливають на оцінки

Як НЕ треба робити естімейти
- Намагатись “вгадати” чи взяти оцінку з довідника “стеля”
- Користуватись одним та тим самим підходом для будь-яких задач
- “Забивати” на зовнішні фактори
- Відмовлятись переглядати оцінки з часом

Яку техніку естімації пропонує Jacob Kaplan-Moss:
1. Розбийте роботу на невеликі менш складні підзадачі. В залежності від складності це можуть бути small, medium, large та extra-large задачі.
2. Оцініть невизначеність. Розробіть свою виміру: чим більше невизначеність, тим більший множник. Для низького рівня множник може бути 1.1, для найбільшого - 5.0.
3. Виконайте розрахунки. Для кожної задачі розрахуйте очікуваний час виконання, а також час з урахуванням невизначеності.
4. Уточніть дані, якщо є потреба. Якщо у вас багато extra-large задач, спробуйте або розбити їх, або додати окремі задачі на research - щоб зменшити ризики та невизначеність.
5. Відстежуйте точність, щоб покращуватись із часом. Порівнюйте, наскільки ваші оцінки відрізняються від реального часу виконання задачі - та робіть відповідні зміни у своїх підходах.

Які ще техніки оцінки задач існують
- Program Evaluation and Review Technique
- Evidence-based scheduling
- Fruit-salad scrum

Як допомогти менеджеру та команді робити оцінки краще
- Більше комунікуйте
- Користуйтеся своїм досвідом
- Не забувайте про ризики
- Заохочуйте культуру, де задавати питання та уточнення - це нормально

P.S. Наче нічого кардинально нового, але ...
P.P.S. Думаю, Артем та Артур можуть доповнити замітки щодо оцінок ... 😉