Стоит ли оценивать задачи Scrum команд в часах?

Много статей и книг написано про преимущества оценки задач в Story Points. Они содержат меньшую погрешность и позволяют более точно прогнозировать сроки реализации проекта текущей командой разработки. Но что делать, если команда очень мала, если приоритеты заказчик меняет слишком часто, задачи сильно различаются по объему и сложности реализации и содержат высокую долю неопределенности? Может ли оценка задач в часах дать преимущества в планировании в некоторых ситуациях? Мы говорим, да, может, и ниже расскажем, когда и почему и как мы делаем это в одном из своих проектов.

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

Поговорим про оценку в Story Points

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

Нет смысла пересказывать статьи и книги про преимущества оценок в Story Points. Кратко особенности способа и его преимущества выглядят так:

• Задачи сравниваются друг с другом. Оценка в Story Points носит относительный характер.
• Подход учитывает возможные риски и неопределенность в требованиях.
• Оценивает вся команда(а не только тимлид или PM). Оценка лишена субъективности и не зависит от конкретного исполнителя, который будет делать задачу.
• Прогноз сроков реализации сделанный на основе Story Points корректируется с учетом средней “скорости” переваривания Story Points командой разработки. Корректировка происходит относительно просто — все задачи оценены относительно друг-друга. Если меняется средняя velocity команды (количество Story Points которые команда закрывает в течение 1 спринта), достаточно общую оценку проекта поделить на новое значение velosity и получим новые сроки реализации проекта.

Звучит как будто у этого способа одни плюсы, но не слишком обольщайтесь. Если говорить в общем, то модель довольно сложна в использовании. Чтобы успешно использовать Story Points должны сложиться определенные условия.

Без чего Story Points не будут работать как следует

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

Второе — состав команды должен быть стабильным на протяжении длительного промежутка времени. Когда уходит разработчик, velosity очевидным образом падает (но неизвестно на сколько), когда ему на замену приходит новый(скорее всего не сразу а спустя время), ему требуется время на онбординг. Тогда оценки новичка привносят ошибку, velocity команды также непредсказуемо меняется.

Третье — сама команда должна состоять больше чем из 2–3 человек. Если у вас 2 разработчика, особых преимуществ при такой оценке вы не получите.

Четвертое — уровень разработчиков должен быть довольно высоким (несколько middle и senior). Все дело в том, что Junior Developer будет сложно без подготовки и знакомства с кодовой базой давать какие-либо оценки фичам или задачам, которые на начальном этапе в основном сформулированы абстрактно. Команда, состоящая из тимлида и джунов не сможет использовать Story Points от слова совсем.

Пятое — скоуп проекта стабилен и просматривается на несколько месяцев вперед. Приоритеты по разработке фичей также стабильны. Если это не так, вам будет сложно работать относительно “длинными спринтами” (3–4 недели) и накладные расходы на проведение планирования и оценки задач могут превысить выгоды от точности оценок.

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

Не вполне понятно, как быть с оценками задач, которые команда не успела сделать в течение спринта. Стоит ли их корректировать в новом или нет? Если стоит, то как? Если нет, то как оценить среднюю velocity (например по этой паре спринтов)?

Добавим сюда требование к общей зрелости команды. Процесс оценки в Story Points в целом сложнее для понимания и работы с ним (на покер планирования нужно оценить абстрактные задачи, высказать мнение и аргументировать его). Далеко не все команды “дозрели” до понимания концепции и преимуществ Story Points. Повышаются требования к кооперации, ведь задачи, как и оценки, теперь общие для всей команды — успех или неудача закрытия спринта зависит от общих усилий команды в целом. Если спринт не был закрыт, не имеет значения, что отдельные разработчики выполнили свою работу вовремя. Ритуалы становятся более продолжительными, покер планирования подразумевает дискуссию, аргументированный спор и т.д. Если подвести итог, то у этого подхода есть как плюсы так и минусы. Но, мировой опыт говорит о том, что минусов у оценки задач в часах все же больше.

Когда выгодно использовать оценку в часах

Оценка задач в человеко-часах (или просто в часах) — способ оценить трудоемкость задачи. Здесь и далее мы будем подразумевать под оценкой в часах общее количество времени, которое требуется разработчику для того, чтобы реализовать требуемый функционал, написать тесты (если требуется), пройти ревью, исправить замечания и выполнить другие требования DoD (Definition of done). Время QA на тестирование учитывается в отдельной задаче.

Получается, что в некоторых случаях сложность оценки задач в Story Points может сделать их использование невозможным или нецелесообразным. Как тогда поступить? Мы предлагаем взять более простой инструмент и, понимая его ограничения, попытаться повысить точность. Ранее мы говорили об оценках задач только как о способе узнать срок окончания реализации проекта. На самом деле оценка задач преследует несколько целей:

• позволяет оценить срок реализации всего проекта или крупных фичей;
• определяет каждому разработчику цели на спринт и позволяет отследить прогресс (мотивирует);
• позволяет запланировать работу на спринт;
• позволяет распределять нагрузку внутри команды;
• задает метрику;
• позволяет провести ревью спринта и сделать выводы.

Сразу оговоримся, что, возможно, главную задачу оценка в часах решает недостаточно хорошо. Оценки всего проекта получаются неточными. Однако, в определенных условиях она полезна для структурирования процесса работы команды.

Оценка трудоемкости задач в часах — знакома и интуитивно понятна. Ее не нужно объяснять начинающим разработчикам и можно использовать сразу без долгих прелюдий и пробуксовок. Такую оценку проще будет использовать в команде, которая только начинает работать вместе и люди еще не “притерлись” друг к другу (на притирку может уйти до полугода).

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

Если стейкхолдеры или продукт оунеры помешены на тотальном контроле проекта, оценки в часах им более понятны. Тогда у команды меньше времени уходит на объяснения и согласование приоритетов и реализации, а ситуация для стейхолдера становится более прозрачной. В таком случае практически отпадает необходимость в отчетности, стейкхолдеру достаточно изучить события в Jira.

Оценку в часах можно использовать при любом грейде и количестве разработчиков.
Кроме того, оценка в часах выгоднее на коротких спринтах продолжительностью 1–2 недели. Ведь нет необходимости использовать покер планирования. Грумминг задач можно делать асинхронно, а сам митинг по планированию занимает не многим больше стендапов (30–60 минут). В свою очередь необходимость использовать короткие спринты может быть вызвана высокой неопределенностью в проекте и частой сменой приоритетов. В этом случае мы не тратим время на проработку тех задач, которые могут быть впоследствии отменены или отложены.

Наконец, на коротких проектах протяженностью 2–3 месяца оценка в часах позволит точнее оценить сроки проекта перед его началом, а также получить оценку быстрее. Ведь если мы будем оценивать задачи в Story Points в начале мы не будем знать, сколько Story Points команда сможет закрыть за 1 спринт, а сделав 1–2 итерации оценку придется корректировать. Так мы получим что-то более менее точное только к окончанию проекта.

Как наша команда работает с оценками задач

Теперь перейдем к практике и расскажем, как именно мы используем оценку задач в часах в одном из проектов Mad Devs.

Команда состоит из 4-х backend разработчиков(2 junior разработчика, 1 middle и 1 техлид), 1-го frontend middle разработчика, 1-го QA- инженера и 1-го PMа. Длина спринта — 1 неделя. В проекте присутствует частая смена приоритетов из-за внешних факторов, связанных с изменениями требований законодательства страны нашего заказчика.

Проект, несмотря на то, что находится в production, содержит очень высокую неопределенность. Пивоты случаются в среднем один раз в два месяца. Срочные и горящие задачи могут появляться каждую неделю. Были случаи, когда проектирование и разработку в течение 1,5 месяцев пришлось останавливать и выбрасывать код. Для прогнозирования завершения проекта или крупных этапов мы используем оценки крупных блоков функционала, которые были сделаны при проектировании. Они делаются с запасом и существенно пересматриваются далее при планировании спринтов (об этом ниже).

Цикл планирования и оценки задач в проекте

Для коротких спринтов (длина — 1 неделя) планирование приходится проводить еженедельно (по пятницам). Чтобы сократить и максимально эффективно использовать время команды, к митингу по планированию мы начинаем готовиться с понедельника. PM планирует следующий спринт, техлид асинхронно смотрит распределение и корректирует при необходимости. При планировании мы сразу назначаем исполнителей задач, оценки трудоемкости выставляет техлид на свое усмотрение.

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

Мы не планируем полностью 100% рабочего времени ребят. Обычно суммарная оценка чистого времени выполнения задач для одного разработчика составляет от 2,5 до 3,5 рабочих человеко-дней (из 5). Мы вычитаем из рабочей недели время которое точно потратим на ретроспективы, тимсинки, код ревью (у нас минимум 2 человека в backend команде ревьюит код друг друга) и другие командные коммуникации. Для Junior разработчиков мы планируем меньшую загрузку, подразумевая, что значимая часть времени будет потрачена на устранение замечаний.

Когда спринт запланирован и получен апрув от техлида (например, к вечеру понедельника), каждый разработчик тогда, когда ему удобно, изучает задачи, задает вопросы, при необходимости знакомится с кодом и до митинга планирования (пятница) предварительно декомпозирует и оценивает задачи. Для этого остается большая часть спринта. За это время разработчики, на которых были распределены задачи, знакомятся с требованиями, уточняют их и делают декомпозицию. Чем более гранулярной будет декомпозиция, тем точнее будет итоговая оценка по задаче. Так первоначальные оценки уточняются и меняются, но на основе проделанного рисерча с учетом сил тех, кто будет реализовывать задачу.

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

Немного выводов или последние нюансы

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

Мы используем часы при планировании работы на короткой дистанции (1–2 спринта). Такие оценки позволяют сделать краткосрочное планирование предсказуемым и качественно анализировать итоги.

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

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

Бонусом мы получаем еще кое что. При описанном подходе мы видим наглядно насколько оценка отличается от фактического времени выполнения задачи. Факторов как правило два. Во-первых, становится явным, если разработчик при планировании работы уделил недостаточно времени на изучение контекста и уточнение требований. Во-вторых, отклонения от оценок при декомпозии наглядно показывают, насколько хорошо тот или иной девелопер декомпозирует задачу. Чем выше отклонение от оценки, тем больше внимания нужно уделить росту навыков. Кроме того это наглядно демонстрирует команде пользу от декомпозиции (которая не всегда и не всем очевидна).
В любом случае, на ревью спринта практика помогает PM анализировать и работать над решением проблем (которые, к слову, достаточно распространены).