Как оценивать сроки завершения работы | OnAgile Consulting

Как оценивать сроки завершения работы

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

Оценка задач в человеко-часах и ее альтернативы

Сначала об одной из частых ошибок — оценке задач в человеко-часах.

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

Например, работы по отдельной задаче команда оценивает так: аналитику нужно 2 дня, разработчику 6 дней, тестировщику 3 дня. Получаем общую сумму в 11 дней, кладем на календарь, получаем дату окончания работ = день начала + 11 дней.

И примерно в 100% случаев результат по задаче выдается позже озвученной даты и наши заказчики начинают становиться недовольными.

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

Есть два способа улучшить точность оценки, не сделав ее процесс сложнее.

1. Использовать понятие «идеальный час» — это час рабочего времени, когда мы в субботу сидим одни в комнате, все прочие дела сделаны, в наушниках играет любимая музыка и мы максимально погружены в решение задачи без единого отвлекающего фактора.

То есть процесс оценки в часах обычно выглядит так: «если тебя никто не будет отвлекать, ты сядешь и целиком погрузишься в задачу — сколько часов тебе потребуется, чтобы ее сделать?»

Теперь остается умножить полученную оценку на некий коэффициент, отражающий соотношение идеального времени к реальному в вашей команде, например, на 1,4.

Раньше такой коэффициент называли фокус-фактор, но поскольку в целом оценка в часах признана мировым сообществом слишком неточной, от нее так или иначе уходят на следующий способ.

2. Самая точная и при этом быстрая оценка задач (вернее сказать, пользовательских историй) — в сторипоинтах.

Это относительные размеры историй друг к другу, без привязки к часам, работам определенной роли (анализ, разработка, тестирование) и вообще календарю.

Например, задача по выпуску виртуальной карты может иметь оценку в 13 поинтов, а задача по отображению ее реквизитов — оценку в 3 поинта.

Что это для нас значит?

Что реквизиты примерно в 4 раза проще выпуска карты и очевидно более определенные с точки зрения требований, зависимостей и возможных рисков.

Предположим команда в двухнедельный спринт делает историй в среднем на 20 поинтов. Исходя из этого можно научиться достаточно точно планировать как объем спринта, так и сроки по набору историй из бэклога, и, конечно, выполнять обязательства.

В чем вообще проблема с оценками? 

Почему в общем случае крайне сложно дать точную оценку? (Говоря об оценке работ так называемого умственного труда, knowledge work.)

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

2.  Требования, которые у нас есть на старте - не описывают будущий продукт на 100%, какими бы объемными и детальными они ни были. В отличие от, например, изготовления детали по чертежу или строительство дома по готовой проектной документации. 

3.  И самое главное — проблема в ДНК процесса оценки.

Когда нас просят что-то оценить, нам говорят буквально следующее «На основе информации, которая есть у вас сейчас и вашего опыта, когда, как вам кажется, вы могли бы это сделать?».

Мы говорим (применяя любую методику оценки), например, через 20 дней, или к 17 ноября. И это тот оценочный срок, который нас попросили назвать.

Но в ту же секунду, те кто нас спрашивает о сроках (заказчики), воспринимают его как дедлайн, под который мы только что сами подписались. Отсюда и возникают недоверие и напряженность в отношениях между заказчиками и командой. И, конечно, сорванные сроки.

Поэтому нужно искать кардинально иные способы прогнозирования сроков поставки результата.

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

 

Интересно узнать подробнее?

Приходите на один из наших тренингов, где вы в деталях разберете эту тему и сможете задать тренеру свои вопросы.

Вопросы и ответы по теме

Почему команды в Agile отказываются от оценки в человеко-часах?

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

Как правильно использовать story points для оценки задач в Скраме?

Story points (сторипоинты) в Scrum используются для относительной оценки сложности задач. Команда выбирает эталонную задачу и присваивает ей определенное количество points, затем оценивает остальные задачи относительно эталона. Это помогает точнее планировать спринты и прогнозировать сроки разработки, основываясь на реальной производительности команды (velocity).

Какие методы оценки задач используются в современной IT-разработке?

В современной IT-разработке используется несколько основных методов оценки задач: сторипоинты в Scrum, идеальные часы с учетом фокус-фактора, покер планирования для командной оценки, T-shirt sizing для быстрой приблизительной оценки. Выбор метода зависит от используемого фреймворка (Scrum, Kanban) и специфики проекта.

Как правильно планировать спринт, чтобы не срывать сроки?

Для эффективного планирования спринта в Scrum важно: использовать исторические данные о velocity команды, учитывать capacity (доступность) участников, правильно оценивать задачи в story points, оставлять буфер на непредвиденные работы. Команды, использующие такой подход, значительно реже срывают дедлайны.

Как фокус-фактор помогает в оценке задач?

Фокус-фактор в Agile показывает, какую часть рабочего времени команда реально тратит на разработку. Например, при факторе 0.6 из 8 часов рабочего дня эффективными являются около 5 часов. Это помогает точнее планировать спринты и оценивать время разработки новых фич. Однако современные команды чаще используют velocity и story points для оценки.

Почему даже подробные требования не гарантируют точную оценку сроков?

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

Еще публикации по Agile в Agile, Scrum, Kanban–метод

Новая версия Scrum Guides
Публикация Agile, Scrum, Kanban–метод

Новая версия Scrum Guides

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

Покер планирования — совместная оценка задач командой с помощью Planning poker
Публикация Agile, Scrum, Kanban–метод

Покер планирования — совместная оценка задач командой с помощью Planning poker

Planning poker — техника командной оценки задач в относительных единицах. Впервые описана в 2002 году Джеймсом Гренингом, одним из авторов Agile-манифеста. В дальнейшем популяризирована Майком Коном в книге «Agile Estimating and Planning».

Топ-3 книги по Agile, которые стоит прочитать
Публикация Agile, Scrum, Kanban–метод

Топ-3 книги по Agile, которые стоит прочитать

Мы собрали проверенные временем издания об Agile — те, что читают, цитируют и к которым возвращаются. Если вы в поиске надёжных источников — начните с этих.

Ближайшее обучение по Agile и Scrum

С 2015 года мы помогаем адаптировать к изменениям культуру и процессы компании

Связаться с нами

Дмитрий Лобасев

Managing Partner

+7 495 221 87 39

dmitry@onagile.ru

Наш Telegram канал об Agile и гибких организациях, присоединяйтесь!