Вступление
Вне зависимости от методологии разработки ПО, каждая команда сталкивается с этапом планирования и оценки задач. Есть те, кто привык оперировать человекочасами и человекоднями, есть те, кто уверовал в мощь и эффективность оценок в абстрактных величинах, таких как Story Points (далее SP). У этой статьи нет цели доказать превосходство одного подхода к оценке над другим. В ней речь пойдет об истории одной команды, которая пожила четыре спринта с оценками в часах, перешла на SP, а спустя девять спринтов подумывает о том, не вернуться ли к первому подходу.
На каждом из этапов казалось, что сделанный выбор логичен и обоснован. На самом деле, это был один большой эксперимент по поиску способа, как команде попадать в оценки и цели спринта. Набитыми шишками и выводами делимся с вами.
Начало пути: оценки в часах
В девяносто втором спринте образовалась новая команда. По большей части команда состояла из новых сотрудников, которые только-только знакомились с процессами и продуктом компании. Соответственно, в самом начале решили обойтись без креатива. Другие команды оценивают в часах? Ок, мы тоже. Тем не менее с самого начала у каждой команды была свобода организовывать и совершенствовать процессы внутри команды. По этой причине, хоть и была общая канва, как мы делаем разработку, в мелочах команды жили по-своему.
Методология оценки в часах на тот период:
Аналитик приносит в команду бизнес-фичу.
Команда декомпозирует бизнес-фичу на истории, которые можно было бы поставлять по отдельности. При этом каждая история должна нести бизнес ценность. Для команды этот критерий был важнее, чем «история должна помещаться в один спринт».
По каждой истории команда дает оценку в часах на объем работ по backend, fronted разработке и по тестированию.
Оценки в часах по каждой истории суммируются.
Оценка на бизнес фичу — сумма оценок по всем историям, входящим в фичу.
Некоторые команды при оценке сразу разбивали истории на подзадачи и оценивали по подзадачам, но эта практика у нас не использовалась, чтобы не затягивать оценку.
При этом подходе возникали следующие проблемы:
Команда знакомилась с требованиями на встрече по оценке. Никто не уделял заранее время на изучение той части системы, в которую вносятся изменения по требованиям. Другими словами, при оценке команде было сложно предвидеть риски из-за зависимостей и накопившегося за девяноста два спринта техдолга.
Обычно оценку давал кто-то один от каждого направления, а остальные просто соглашались. Неформальные лидеры в команде оказывали на остальных сильное влияние, что влекло за собой следующие две проблемы:
Записывалась оценка от неформального лидера, а не оценка от исполнителя.
Оценки мало обсуждались. Вопросы в стиле «а почему столько часов?» не задавались.
При оценках по ролям (бэк, фронт, QA) часто забывали закладывать время на исправление замечаний после код-ревью, исправление дефектов, перетестирование.
При оценках в часах возникал соблазн трудоемкость конвертировать в длительность. Условно, если история оценена в девяносто часов, то с допущением, что один день разработчика равен шести часам, формировалось ожидание, что эту историю можно закрыть за пятнадцать дней, т.е. она должна поместиться в спринт. По факту, у нас история с такой оценкой растягивалась на два-три спринта.
Почти не учитывались зависимости между фичами как из бэклога команды, так и из бэклога других команд.
У команды был низкий процент закрытия целей спринта.
Переход на оценку в SP
Шли спринты, команда успешно проходила стадии от формирования до нормализации по модели Такмена и Дженсена, но процент выполнения целей спринта снижался. В четвертом спринте команда обнаружила, что смогла выполнить цели всего лишь на двадцать процентов. Несмотря на то, что за непопадание в цели спринта никаких штрафных санкций к команде не применялось, ощущение неудовлетворенности от слабых результатов росло. Тогда на ретро команда выдвинула ряд гипотез.
"Мы не попадаем в цели спринта потому что:
в спринт влетают задачи более высокого приоритета, которые надо делать в текущем спринте. Объем этих задач на спринт заранее неизвестен.
т.к. система не с нуля пишется и есть связанность кода, то при реализации простая задача может резко увеличить свою сложность, а времени на исследование перед оценкой нет.
реализация может быть простая, но есть риски с окружением и с зависимостями по другим задачам — неизвестно сколько в часах уйдет времени на исследования, общение со смежной командой, на ребейзы и т.д.
Не проверяя эти гипотезы, команда решила, что оценка в SP поможет решить эти проблемы. Ведь SP отвязана от конкретных исполнителей и ролей в команде, вмещает в себя и объем и сложность истории, отображает степень неопределенности, с которой столкнется исполнитель при реализации.
Как перешли на шкалу в SP:
Из всех историй, которые были реализованы в команде за предыдущие четыре спринта, взяли самую маленькую и простую и сказали, что истории аналогичной сложности — это 1 SP. А дальше при оценке историй в SP мы задавались вопросом, во сколько эта история сложнее той, что мы взяли за единичку. При этом в исходной истории, от которой мы простраивали шкалу SP, были подзадачи и на бэк, и на фронт и на QA.
Методология оценки в SP на тот период:
Аналитик приносит в команду бизнес-фичу.
Команда декомпозирует бизнес-фичу на истории.
Каждая история оценивается всей командой через голосование. Для голосования использовали http://pockergram.ru/ После вскрытия карточек с оценками, оценки обсуждались. Голосование по истории проходило столько раз, сколько потребуется для консенсуса.
Оценка фичи в SP не проводилась и мы не суммировали оценки в SP.
Проблемы с оценкой в SP:
Команда по-прежнему не попадала в цели спринта. Средний процент закрытия целей спринта за весь период оценки в SP - 57%. Для сравнения средний процент закрытия целей спринта за весь период оценки в часах - 54%. Т.е. ситуация улучшилась, но незначительно.
Команда ничего не знала о договорных обязательствах и сроках. Незакрытые истории просто переносились на следующий спринт.
Состав задач и историй мог меняться в течение спринта.
Потребовалось время, чтобы команда привыкла к подходу и каждый член команды давал оценки истории не с позиции своей роли, а в целом за всю команду.
Команде удобно, а Product Manager, Product Owner страдают, ведь им надо абстрактные оценки перевести в конкретные сроки и деньги. Тут то и начинается веселье с попыткой сопоставить SP с часами, а потом эти цифры еще как-то в план-график работ перевести и разобраться с нагрузкой членов команды.
Предпосылки к возврату оценок в часах
Сильно повысился приоритет цели попадать в сроки по договорным обязательствам. Теперь команда не живет в вакууме и знает о своих дедлайнах, а не сообщает постфактум о том, когда что будет готово или переносится на следующий спринт.
Вновь изменился состав команды, т.е. предыдущие результаты по Velocity и Capacity команды уже не могут быть применены к новому спринту. Нужно заново накапливать эмпирический опыт оценок, а времени на это нет.
В компании увеличен горизонт планирования со спринта до квартала.
Появилась практика по выявлению и учету зависимостей между историями и фичами не только внутри команды, но и внутри стрима из нескольких команд, а также между стримами и разными продуктами. Соответственно, нужна более универсальная шкала оценок для всех команд, т.к. «стоимость» 1 SP в разных командах разная и оценки в SP из разных команд просто нельзя сравнивать между собой.
Заключение
В заключение хочется поделиться извлеченными уроками:
Оценки необходимы для планирования и управления объемом работ, следовательно, подход к оценкам должен быть удобен исполнителям и тем, кто отвечает за сроки, бюджет. Если не хотите городить огород или удивляться, откуда взялись такие deadlines, не заставляйте менеджеров придумывать свои «курсы конвертации» одних оценок в другие. Также плохая идея давать верхнеуровневые оценки в одном формате (например в неделях), а детальные оценки в SP. Как их потом сопоставлять?
Если несколько команд работают над одной системой, у всех команд должен быть одинаковый подход к оценкам, иначе сложно управлять кросскомандными зависимостями и прогнозировать сроки поставки историй и фичей.
Прежде чем менять подход к оценке нужно убедиться, что проблема именно в подходе и в точности оценок. Возможно, ту проблему, которую вы хотите устранить переходом на SP или на часы нужно решать совсем другими методами, и она не касается оценок.
Избегайте подмены понятий. Непопадание в оценку не то же самое, что не попадание в сроки. Правильное целеполагание и правильные методы анализа отклонений — наше все. Непопадание в оценки, это когда оценивали задачу на X часов/SP, а сделали за Y. А когда вопрос стоит, почему вы задачу на X часов/SP не успели за спринт, то тут проблема не в оценке, а в скорости поставки, которая складывается из многих факторов.
Каким бы подходом в оценках вы не пользовались, без анализа причин отклонений сами по себе оценки мало чем помогут.