В мире IT разработки программного обеспечения и управления проектами термин «эстимейт» или «оценка» означает наше лучшее “предсказание” о том, что и за какое время можно сделать. Это не точное предсказание, а скорее ориентир, который помогает принимать решения и планировать работу на проекте.

Но в каких ситуациях оценки действительно имеют значение?
Давайте подробнее разберемся…

Когда оценки важны

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

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

3. Прогноз и планирование. Пример из реальной жизни: прогноз погоды — это оценка будущего на основе имеющихся данных. Он помогает лучше спланировать активности на неделю.

4. Выбор оптимального варианта. При выборе между разными вариантами — например, пример из реальной жизни, какой автомобиль купить за определенный бюджет — эстимейты помогают выбрать наиболее выгодный вариант с учетом соотношения цены качества.

5. Достижения общего понимания. Например, когда супруги спорят о переезде в новый дом, совместная проверка предположений может помочь прийти к согласию и лучше понять точку зрения друг друга.

Что говорит Scrum об эстимейтах

В Scrum Guide 2020 слово “estimate” не встречается хотя в версии 2017 оно упоминалось девять раз! Estimates все равно остаются важной частью методологии.

Scrum не обязывает оценивать задачи и не навязывает конкретных техник оценки. Нет ни обязательных методов покер планирования, ни обязательных единиц измерения — будь то story points, часы, дни, размер футболок или другие показатели.

Однако оценка “estimate” задач это распространенная практика для лучшего планирования в Scrum.

Поэтому все Product Backlog Items по-хорошему должны быть оценены

Без оценок бэклог продукта не будет прозрачным и понятным. Продукт оунер всё равно должен согласовывать приоритеты, помогать команде разработки находить оптимальное решение, прогнозировать так сказать погоду для клиентов и заинтересованных лиц. Нужно помнить, когда мы оцениваем элементы бэклога продукта, мы не пытаемся предсказать точное время их выполнения. Поэтому команда может выбрать технику оценки, которая лучше всего подходит для ее нужд. Многие Scrum команды используют стори поинты или размеры футболок (но Scrum не требует использовать ни то, ни другое). Ежедневные дейлики хорошо помогают координировать работу и зависимости, мониторить прогресс.

Оценка новых айтемов бэклога может быть частью регулярных мероприятий по уточнению бэклога. Это помогает команде прийти к общему пониманию требований. Покер планирование — отличная техника, которая помогает убедиться, что все в команде находятся на одной волне.

Пять частых проблем с эстимейтами из практики Scrum

1. Проблема с точной оценкой проекта

Представьте себе: вы — скрам мастер свеженькой команды, и до запуска проекта осталось всего неделя. Вдруг заказчик присылает требования и спрашивает: «Ну а сколько примерно времени и кэша понадобится, чтобы всё это реализовать?» Вы решаете заглянуть в священную книгу — Scrum Guide...

Ответ: В скраме нет никакого фиксированного срока или точных оценок. Требования постоянно уточняются с помощью продукт оунера и команды, и таски сжигаются командой. Нет ни дат, ни цифр, зато есть предсказания, основанные на производительности команды — velocity. Только вот знать это можно будет не раньше, чем через полтора-два месяца, — так что заказчик, увы, придется подождать. Или лучше — начать сразу, а каждые две недели радовать его новыми кусками готового продукта. А денег — запаситесь запасом, вдруг пригодится…

2. Проблема планирования: как угадать будущее, когда команда меняется

Прошло 1,5–2 месяца, и вы узнали, что ваша команда работает в среднем со скоростью 20 story points в первый спринт, потом 40, а потом — снова 15. Можно ли по этим цифрам понять, сколько времени займет весь проект? Обычно — нет. На старте команда еще притирается, а «стандарты» — как фигура на песке: постоянно меняются.

И тут вам говорят, что один из фулстек разрабов хочет взять отпуск на неделю, а дизайнера уже затянуло в другой проект так как у вас не dedicated team. В результате, вы смотрите в Scrum Guide и задаетесь вопросом: что делать?

Ответ: Если меняется хотя бы один человек в команде — это новая команда. Прошлая производительность больше не подходит, и начинать все заново — единственный выход. Заказчик радуется прогрессу, но без понятия, когда же это закончится. А если команда стабильна и вы используете среднюю velocity? Обычно бэклог на пару спринтов вперед — это максимум, а дальше — только высокоуровневые пожелания, которые команда еще не изучила. Scrum тут ничего не подскажет — оценки грубые и очень приблизительные.

3. Отсутствие личных показателей производительности сотрудников, размытая ответственность

Вы замечаете: Что мидл фулстек разработчик, быстро закрывает задачи, Тимлид в основном, комментит чужой код и читает статьи. Тим лида хватает на пару больших задач и тратит на них весь спринт. И вроде бы всё хорошо, ведь он успевает, да? Что говорит Scrum Гайд?

Ответ: Вся команда — одна семья. Все несут коллективную ответственность за результат. Личные показатели тут не при делах — никто никого не хвалит и не ругает поименно. В итоге, ответственность за итог всей работы размыта, и кто как работает — неважно.

4. Проблема «золотых» стори-поинтов и их раздувания

Вы решаете разобраться, как один мидл разработчик из команды умудряется закрывать больше всех, не потея. И оказывается, что стори-поинты — это не сроки, а сложность задач. И тут начинается магия — используют planning poker, где все вместе оценивают задачу карточками.

В итоге, возникает примерно такой диалог:

— Во сколько оценим?

— 3.

— 8.

— Почему так много?

— Там еще пару кейсов нужно учесть, тесты, выделение классов...

И все соглашаются, потому что лучше перестраховаться. В результате, цифры растут, а команда показывает «успех» — а заказчик ждет-ждет и никак не дождется релиза. Что говорит Scrum Гайд?

Ответ: Команда сама решает, кто, что и как делать. Scrum-мастер — не может сам вмешиваться, он только задает наводящие вопросы и фасилитирует. Что бы не происходила раздувание оценок команда должна быть зрелой, и честно обсуждать реальную сложность задач.

5. Проблема специализации и сложность с эстимейтами

Проект развился и команда увеличилась. Новые User Stories становятся все сложнее — и вдруг вы замечаете: не успеваете взять задачу, даже если она на 40 story points при мощности команды в 80 SP. Почему? Потому что внутри бэклога могут быть «только бэкенд» или «только фронтенд» задачи, и разделение труда становится все более очевидным. Члены команды начинают делиться на мини-подразделения, которые следят за своим «кусочком» и не интересуется что у других, а полностью закрывать задачи вместе становится всё труднее. Иногда даже заливка на продакшн не попадает в спринт, и в итоге, команда сама нарушает свои же стандарты definition of done ради того, чтобы хоть как-то сделать инкремент. Что говорит Scrum?

Ответ: Команда должна быть кросс функциональной — то есть, у каждого должна быть вся необходимая компетенция для выполнения работы. А роль разработчика — одна: разработчик скрам не признает виды разработчиков и проблему их синхронизации.
Продакт-оунер, по сути, становится «богом», который должен понимать задачу и с продуктовой стороны так и со стороны разработки: фронт, бэк, девопс qa, чтобы правильно приоритизировать бэклог. Перекос в любую сторону — спринт рухнет, как карточный домик.

При этом скрам требует, чтобы в команде только один человек отвечал за бэклог. Но на практике появляется целая армия помощников — прокси-продакты, бизнес-аналитики, консультанты, — чтобы не нагружать одного человека.

Заключение

В конце концов, работа с эстимейтами — это как тренировки в спортзале: чем больше практики, тем лучше результат. И пусть иногда оценки бывают не совсем точными, главное — обучаться, развиваться и практиковаться!

Напишите в комментариях, какие способы оценки вы используете на своих проектах? С какими трудностями вы столкнулись при оценке задач и планирование и как вы их преодолели?