О различных методиках оценки времени выполнения технических задач написано много теоретических изысканий.

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

Не работает формула «умножить на два и прибавить еще 30%».
Не работает формула «написать детальные требования и разбить проект на мелкие задачи».
Не работает формула «оценивать в идеальных часах, а в день программист работает 4 идеальных часа».
Не работает формула «выбрать задачу и оценивать сложность числами Фибоначчи относительно ее».

То, что написано ниже тоже, скорее всего не работает. Просто так случайно получилось.

Недавно я писал про опыт работы в iversity. В этой статье я хочу рассказать про то, как мы подходим к оценке задач. Прикол в том, что методика ходу-бедно работает уже пол года(т., т., т.). Может быть, скоро работать перестанет. Как говорится — берем, пока дают.

Почему все так печально

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

• Понимание сложности задачи разработчиками, что автоматически предполагает наличие опыта в данном классе задач.
• Стабильность команды. Новая команда всегда несет много непроизводственных рисков, которые так или иначе влияют на производительность.

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

Предпосылки

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

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

Нам хотелось чего-то, что позволяет оценивать задачи быстро и грубо. На уровне здравого смысла. На уровне примерного объема работы, который можно взять на спринт(2 недели).

Логическим выводом стало использование Planning Pocker, который оценивает задачи по сложности, а не по времени.
Проблема Planning Pocker в чистом виде в том, что полностью абстрагироваться от времени все равно не получается. Да и конечному заказчику продукта наплевать на то, насколько сложно его сделать. В первую очередь важно, когда будет готово, верно?

Другой прикол Planning Pocker методики заключается в том, что оценивается производительность команды, а не индивидуальных членов. Видимо, там, откуда она пришла никто никогда не ходит в отпуск. В нашей реалии, к сожалению, разработчики уходят в отпуска, болеют, берут отгулы и т.п. Для команды из 5 человек минус один член на спринт — это минус 20% ресурсов(а то и минус 30% в случае матерых производителей). Т.к. мы живем в реальном мире, мы решили мерять индивидуальную производительность и учитывать ее при отсутствии членов команды.

В итоге, извилистыми дорожками мы пришли к простой методике, которая описана ниже.

Методика

Вся методика заключается в оценке задач в баллах(Story Point) из этой таблички:

Задач сложнее 8 баллов в нашей вселенной не существует, если такой астероид невзначай залетает — он дробится лазерной пушкой на мелкие куски. Традиционно для Planning Pocker мы оцениваем задачи всей командой и дискутируем, если что-то непонятно или оценки слишком сильно отличаются друг от друга.

Баги и задачи, не вносящие явного профита в продукт(системное администрирование и т.п.), не оцениваются.

На оценку 2х-недельного спринта уходит порядка 2-3 часов.

Первые два-три двухнедельных спринта мы просто сделали столько, сколько смогли, а потом начали ориентироваться на среднестатистические данные.

На выходе каждого спринта в простую табличку добавляется строка:

Вот так и живем =)

Поддерживающие требования

Никакая методика не будет работать, если нечего оценивать или нет понимания задачи, которую нужно оценить. Это означает, что перед оценкой должны быть заготовлены требования и сами задачи(ну или User Story).
За подготовку требований обязательно кто-то должен отвечать, и этого ответчика нужно ставить в позицию гориллы, если перед оценкой требования сформулированы недостаточно четко. Но это тема для отдельной статьи.

Естественное снижение производительности

По мере развития проекта мы заметили заметное снижение производительности, до 30-40% в отдельно взятых спринтах. А недавно вдруг опять подскочила. Ларчик, как оказалось, ломом открывался: производительность была хорошая в тех спринтах, в которых мы практически не исправляли баги.

Наша стратегия относительно исправления ошибок очень проста и отображена в этой табличке:

Таким образом, если при планировании спринта мы видим большое количество ошибок, подлежащих исправлению — в спринт берется на 20-30% меньше задач.

Заключение

Эта методика подойдет далеко не всем командам. Все зависит от целей и задача. Наша основная цель заключается в понимании того, сколько примерно задач можно взять на спринт, чтобы не было недобора или перенасыщения. У нас нет гонки вооружения или супер зажатых сроков — все идет размеренно.
Тем не менее, наличие подобных процедур поддерживает команду в веселом тонусе и дает хорошие возможности для планирования.

Автор: Irbiz

Источник