Как мы пришли к сторипоинтам

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

В Space307 есть команда Core. Мы занимаемся задачами, которые облегчают и ускоряют процесс разработки в продуктовых командах. Раньше работа в команде велась в рамках псевдоспринтов: каждый разработчик набирал себе пул задач на неделю. Иногда удавалось следовать плану, но чаще всё шло не так, как планировалось.

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

Расскажем подробнее о самой команде. Core состоит из бэкенд-разработчиков и QA-инженеров. В разработке и сопровождении находится около 70 микросервисов. Задачи очень разные. Команда почти не зависит от долгосрочных продуктовых эпиков, но занимается своими объёмными техническими задачами по рефакторингу и проектированию и внедрению новых решений.

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

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

К сожалению, таблица не дала того эффекта, которого мы ждали. Разные специалисты оценивали одну задачу по-разному, из-за чего не получалось грамотно выстраивать недельные планы.

На помощь пришли стори поинты (SP). Все в команде слышали, что это круто и эффективно, но никто не знал, как это работает.

И всё-таки мы решили попробовать: завели честные спринты в Jira, установили приложения, даже сделали карты для покера планирования! А что дальше?

А дальше нужно было решить, как оценивать задачи.

Что же такое стори поинты?

Джефф Сазерленд в своей книге «Революционный метод управления проектами» писал так: «Теперь нужно разобраться, сколько потребуется усилий, времени и денег на этот проект. Как я уже говорил, люди довольно плохо справляются с такого рода расчётами, но мы хорошо умеем делать другое — сравнивать один размер с другим, то есть определять относительную оценку».

Важно не просто оценить саму задачу, но дать ей оценку в сравнении с другими. Например, значение «2» больше значения «1» в два раза.

В основе такой оценки — четыре фактора:

Объём работы (Volume)

Показатель отражает количество действий, необходимых для реализации задачи. Например, нужно сделать экран с одним полем ввода и лейблом к нему. Мы оценили такую задачу в 1 SP. И есть вторая задача — сделать 50 точно таких же полей. Значит, и оценка должна увеличиться в 50 раз? Нет. Возможно, понадобится только один раз написать реализацию такого поля и переиспользовать её 49 раз, если между этими полями нет зависимостей и их поведение прозрачно и однотипно. Тогда объём работы будет не в 50 раз больше, а в два-три раза (только из-за количества полей).

Сложность (Complexity)

А теперь представим, что нам нужно реализовать экран, на котором располагаются те же 50 полей. При этом они могут принимать разную информацию (где-то только цифры, где-то только буквы). Некоторые поля могут скрываться в зависимости от значения другого поля. По этой же причине могут меняться правила валидации в пяти полях (так работают поля для ввода БИК: поле может содержать разный набор символов в зависимости от информации о стране). Также нужно протестировать все комбинации. Задача сложная, согласитесь?

Риски (Risks)

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

Неопределённость (Uncertainty)

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

Оценку в стори поинтах можно выразить формулой:

Story points = f(Volume, Complexity, Risks, Uncertainty)

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

Это упрощённая схема, но она хорошо объясняет суть.

Как сравнивать задачи?

Чтобы начать оценивать задачи в SP, необходимо выбрать метод оценки требуемых усилий. В agile-разработке их много, например, шкала Фибоначчи, размеры футболок или покер планирования.

Шкала Фибоначчи. Популярный метод оценки в SP. Это шкала со значениями 1, 2, 3, 5, 8, 13, 21 и так далее. Она основана на последовательности Фибоначчи — сложении двух чисел для получения следующего числа. Её используют, чтобы показать, что объём усилий, необходимый для выполнения задач, увеличивается экспоненциально, а не линейно.

Размеры футболок. Ещё одна популярная шкала для оценки пользовательских историй. Помните, как выглядит американская линейка размеров? В ней есть показатели XS, S, M, L и XL. Метод используется, если тяжело понять, сколько усилий потребуется для выполнения задачи. Размеры футболок позволяют быстро и легко оценить уровень усилий, не привязываясь к деталям.

Покер планирования (Planning poker). Участники команды обсуждают и определяют количество усилий, необходимых для реализации той или иной задачи. Каждый член команды получает колоду карт с разным количеством SP и выбирает карту, отражающую его оценку. Затем оценки обсуждаются, и команда вместе выбирает одну финальную оценку.

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

В начале мы выбрали шкалу, основанную на последовательности Фибоначчи:

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

1. Как выбирать оценку, если мнения разнятся

Мы пробовали разные подходы:

1. Берём максимальную оценку

Эффект: ПЕРЕоценка сложности, задачи в спринте быстро заканчиваются

2. Берём минимальную оценку

Эффект: НЕДОоценка сложности, слишком много задач в спринте

3. Берём среднюю оценку и округляем в большую сторону

Эффект как первом случае

4. Берём среднюю оценку и округляем в меньшую сторону

Эффект как во втором случае, но не такой выраженный

5. Берём оценку, которую поставило большинство участников команды

Такой подход оказался оптимальным для нас

Мы рекомендуем протестировать разные методы: для вас может сработать подход, который не подошёл нам.

2. Как считать capacity команды, чтобы набрать в спринт необходимое количество SP

Единственное решение — проявить терпение. Со временем вы поймёте, сколько SP команда готова взять в спринт. Соберите статистику после нескольких спринтов, не забудьте включить в неё состав команды (помните про больничные и отпуска?), посчитайте capacity при идеальных условиях и скорректируйте значение с поправкой на реальность.

3. 5 и 8 SP — это слишком, а 11 SP — вообще запредельщина!

В процессе мы поняли, что задача в 5 SP слишком сложная, чтобы её мог выполнить один разработчик за спринт. Задачу в 8 SP точно не выполнить за неделю, а в 11 SP тем более. В итоге мы отказались от оценки 11 SP: если задачу оценили в 8 SP, значит, она не была должным образом декомпозирована.

Так появились два дисклеймера.

4. Взяли много задач в 1 SP и выполнили план к середине недели

Мы набрали много задач в 1 SP на один спринт. Такой план на бумаге соотносился с показателем capacity, но в реальности задачи закончились в среду. Инсайт: есть очень простые задачи, на которые нужно минимальное количество времени (5–10 минут), но их тоже нужно включить в план спринта, чтобы правильно подвести итоги. Для таких задач в нашей шкале появилась оценка 0 SP.

Текущая шкала

Сейчас наша шкала оценки выглядит так:

Применение стори поинтов для оценки задач позволило снизить влияние фактора автобуса, научиться оценивать возможности команды на спринт, лучше планировать работу и повысить прозрачность. Теперь наши коллеги из других команд получают чёткий ответ на главный вопрос в мире разработки — «Когда будет готово?». Стори поинты — это коллаборативный и объективный подход к оценке усилий. Члены команды обсуждают задачи и принимают решение об оценке коллективно, что, в свою очередь, улучшает коммуникацию и микроклимат в команде.

Кроме того, сейчас технические команды начали использовать практику квартального планирования. Зная velocity команды, мы можем понять, какой объём работы реально выполнить за квартал (принимая во внимание отпуска, больничные, операционку и прочие риски). Потратив на декомпозирование, обсуждение и планирование некоторое количество времени, мы можем составить план задач на квартал с учётом текущих реалий, а значит, быстрее устранить зависимости от других команд и продумать общие активности.