Приветствую всех читателей! Меня зовут Игорь Конев и я техлид команды STaaS (Storage As A Service) в Авито. Сегодня я хотел бы в очередной раз поднять тему оценки задач, а конкретно оценки при помощи Story Points. Хотя мы давно применяем их в работе, оказалось, что команда по-разному трактует детали. Поэтому мы решили систематизировать и выровнять наши знания, собрать хорошие практики по работе со Story Points и попробовать улучшить процедуру оценки задач у нас.
Результатом работы стал этот материал, которым я с радостью делюсь с вами. Он не претендует на откровения, но удобно собирает терминологию, практические советы и наш опыт — возможно, это сэкономит вам пару-тройку Story Points.
Содержание:
Краткий экскурс в историю
Инженерам, а чаще — их менеджменту всегда требовался какой-либо механизм для измерения объема работы, чтобы предсказывать сроки, осознанно ограничивать объем взятых в работу задач, отдавая приоритет наиболее важным. Самая простая метрика, которая приходит в голову — человеко-часы. Берем экспертного инженера из команды и, например, спрашиваем: «А сколько часов примерно нужно, чтобы переписать легаси на Rust?» . Он отвечает, что справится за N часов и десяток кружек кофе.
Однако при планировании по такому подходу быстро выяснилось, что в реальный рабочий день программист, помимо решения задач из бэклога, занимается еще кучей вспомогательных задач: отсматривает Pull Request, ходит на встречи, отвечает на вопросы коллег и т.д. Если при планировании в человеко-часах это не учитывать, то точность, мягко говоря, хромает. Для решения этой проблемы придумали концепцию «идеальных» часов.
«Идеальные» часы — это те же человеко-часы на задачу, если от ее исполнения ничего не отвлекает. Но далее к этим часам применяется коэффициент отвлечения, и мы получаем примерное реальное время, которое потратится на решение задачи:
где Коэф.отвлечения > 1.
Очевидно, что этот коэффициент волатилен. Он зависит от этапа проекта, степени автоматизации и платформизации, зрелости инженерных процессов и многого другого. Достаточно опросить команду, посмотреть на текущие метрики проекта и эмпирически предположить, что, например, «на задачу мы тратим в среднем в два раза больше времени, чем она занимает». Применив подобный механизм, мы можем улучшить точность планирования.
Основная проблема идеальных часов
Однако при применении идеальных часов есть один большой недостаток. Помните, выше мы спрашивали экспертного инженера, сколько часов нужно на выполнение задачи? Так вот, в реальном мире команды обычно неоднородные, и неясно, кого считать экспертом. Более опытный инженер скажет, что на задачу нужно мало времени. Погруженный в домен этой задачи инженер скажет, что нужно еще меньше времени. А исполнителем потом назначат джуна, потому что первый инженер уйдет в отпуск, а второму инженеру внезапно поручат критически важный баг. Временнáя оценка неизбежно тянет за собой ожидание, что у задачи будет конкретный исполнитель.
Но что если отказаться от абсолютных и временных оценок? Внезапно выяснится, что инженерам гораздо проще договориться, сравнивая задачи между собой. Согласиться, что одна задача примерно в три раза сложнее другой, — проще и естественнее, чем точно прикидывать, сколько часов уйдет на каждую. Именно эта простая идея использования относительных оценок для планирования лежит в основе механизма Story Points.
Что такое Story Points
Story Points (SP) — это относительная единица измерения, используемая для оценки общего объема усилий, необходимых для полной реализации элемента продуктового бэклога.
Уйдем от формального определения и разберемся, как же это работает. Story Points предполагают, что для оценки задач команда вводит какую-либо шкалу. Различные значения в этой шкале должны заметно отличаться друг от друга по весу, и эти отличия должны быть очевидны для всех членов команды. Это могут быть:
размеры футболок (XS, S, M, L, XL);
животные, отличающиеся по габаритам (мышь, кошка, тигр, слон, кит);
транспортные средства (самокат, велосипед, мотоцикл, автомобиль, автобус);
пресловутые числа Фибоначчи (1, 2, 3, 5, 8) и т.д.
Идея лишь в том, чтобы можно было легко сравнить значения и сказать, что кошка больше мыши, а тигр больше их обоих.
Далее для каждого из значений шкалы команда выбирает эталонные задачи из уже выполненных. Они должны быть сопоставимы по величине со значениями шкалы. Например, очевидно, что добавить отправку одной метрики при успешной операции значительно проще, чем внедрить структурированные логи для всей операции и всех ее стадий. Тогда первая задача будет «мышью», а вторая — «кошкой».
Ниже мы подробнее разберем, как можно внедрить шкалу и выбрать эталонные задачи для нее. А сейчас посмотрим на то, из чего складывается оценка в Story Points и какие факторы на нее влияют.
Из чего складывается оценка в SP
Количество работы
Чем больше работы необходимо сделать, тем больше должна быть оценка в Story Points. Но важно понимать, что зависимость здесь нелинейная. Особой разницы между «добавить один TextBox» в интерфейс или «добавить два TextBox» — нет. А вот если таких полей сто, это уже значительно увеличивает объем механической работы, хоть и не добавляет сложности. В таких случаях команда справедливо даст более высокую оценку в Story Points — не за сложность, а из-за количества работы.
Сложность
Возьмем тот же пример с TextBox, но теперь усложним задачу. Вместо сотни одинаковых полей нам необходимо добавить различные элементы ввода: выбор дат, элементы множественного выбора, текстовые поля. Кроме того, нужно добавить валидацию. Например, при выборе города, где находится представительство международной компании, формат почтового индекса должен автоматически подстраиваться под страну. Такая задача требует больше обсуждений, больше условий и потенциальных ошибок — и, очевидно, должна оцениваться выше в Story Points.
Неопределенность и риск
Бывало ли у вас такое, что нужно добавь фичу в legacy-компонент, который редеплоился последний раз два года назад и не покрыт тестами? А какой объем работы нужно заложить на подобный случай? Безопасно будет «перезаложиться» и выбрать для такой задачи больше Story Points. Ведь чем выше неопределенность, тем выше вероятность, что что-то пойдет не так. Не раз за свою карьеру я видел ситуацию, когда бравый инженер склонял команду к меньшей оценке, а потом задача переезжала из спринта в спринт. Подобное хорошо описывает уже «бородатый» мем из Рика и Морти про приключение на 20 минут.
Из чего же складывается неопределенность? Выделим некоторые факторы:
отсутствие экспертизы команды в конкретном домене или технологии;
legacy-компоненты без документации;
проекты, не покрытые тестами;
плавающие баги, которые нетривиально воспроизвести;
размытые требования, которые нуждаются в уточнениях.
Сюда же можно отнести и риск. Обычно мы рискуем, если у нас недостаточно знаний о системе, но решение требуется принять здесь и сейчас. Например, нет возможности провести полномасштабное перформанс тестирование, а нагруженную фичу нужно катить (не является практической рекомендацией). Если из-за этого возникнут проблемы, то понадобится дополнительный ресурс на разгребание последствий.
Как внедрить Story Points в команду
Перейдем от теории к практике. Давайте рассмотрим, какие шаги необходимо предпринять, чтобы внедрить Story Points к себе в команду.
1. Определиться со шкалой
Как я описывал выше, нужно выбрать удобную и понятную для команды шкалу — именно по ней вы будете оценивать задачи в Story Points. Многие команды выбирают числа Фибоначчи. Почему? Потому что эта шкала нелинейная: чем больше значение, тем больше разрыв между соседними числами. Это хорошо отражает реальность — чем больше задача, тем выше неопределенность и тем труднее оценить её точно. Числа Фибоначчи заставляют нас отказаться от ложной точности и признать: у больших задач границы размыты.
Возникает закономерный вопрос: сколько значений должно быть на шкале? К сожалению, на него нет однозначного ответа, ведь это зависит от специфики конкретной команды. Но я постараюсь дать базовые рекомендации:
Значений на шкале не должно быть слишком много. Чем их больше, тем труднее принять решение — особенно в условиях неопределенности. Гораздо проще выбрать оценку для задачи между «кошкой» и «слоном», чем между «леопардом» и «гепардом».
В то же время значений не должно быть слишком мало. Нехватка промежуточных значений на шкале будет приводить к недооценке или переоценке задач.
Максимальное значение должно отражать задачу, которую реально может решить один разработчик за разумное время. В случае Scrum — это спринт. Если очередная задача не будет укладываться в выбранное число, то это хороший признак, что ее стоит разбить.
Таким образом, моя рекомендация — брать шкалу, содержащую 4-6 значений. Наиболее универсальной, на мой взгляд, является шкала из чисел Фибоначчи от 1 до 8: {1, 2, 3, 5, 8}.
2. Выбрать эталонные задачи
После выбора шкалы, необходимо соотнести с ней некоторые из уже выполненных задач, чтобы составить эталонный список. Команда должна определить примеры задач для каждого из значений шкалы. Это позволит откалибровать шкалу и далее использовать сформированные эталоны при оценке новых задач. Можно провести аналогию с простейшими рычажными весами, на которые с одной стороны кладется взвешиваемый предмет, а с другой он уравновешивается стандартными грузами. Вот их вам и нужно сформировать.
Можно обойтись простым голосованием. Тимлид или другой ответственный подготовит список из выполненных ранее задач. По хорошему они должны быть разного типа (исследования, новые фичи из разных компонентов и т.д.) и не слишком старыми, чтобы команда была в контексте. И далее члены команды голосуют, во сколько Story Points они бы оценили ту или иную задачу. Оценка активно обсуждается, мнения подкрепляются аргументами.
Можно подойти к процессу более творчески. На интересный метод я наткнулся, пока листал блог на scrum.org. Автор предлагает раздать участникам голосования карточки разного размера для оценки референсных задач по критериям: сложности, затраченным усилиям и неопределенности. Для каждого из критериев голосующий выбирает маленькую, среднюю или большую карточку. Далее задачи группируются по набранным «очкам» и соотносятся с выбранной шкалой Story Points.
Конечно, при формировании референсного списка можно также использовать покер планирования или Scrum Poker. Рассмотрим этот механизм в следующей секции.
3. Внедрить практику регулярной оценки задач
В рамках данной статьи я стараюсь не углубляться в конкретную методологию разработки. Story Points — это метод оценки, а применять его можно в разных ситуациях. Но независимо от методологии, у вас наверняка есть командная встреча, на которой вы детализируете задачи, определяете критерии приемки и выявляете блокеры. В рамках Scrum такую встречу обычно называют грумингом. Применение Story Points подразумевает, что вы командно выбираете оценки для задач в рамках такой встречи. И регулярность здесь очень важна. Большой объем неоцененных задач сводит на нет возможность нормального планирования.
Самым известным механизмом для оценки задач во время груминга является покер планирования. Читатели, которые ничего не понимают в обычном покере, — не пугайтесь. Я отношусь к вашему числу. Суть метода предельно проста. Сначала ведущий встречи кратко описывает контекст задачи, отвечает на вопросы и стартует таймер. Далее члены команды тайно выбирают свои оценки в Story Points и затем одновременно «вскрываются»
(не буквально). При расхождениях команда обсуждает оценку до тех пор, пока не достигнет консенсуса. Особенно интересно выслушать аргументацию тех, кто выбрал наименьшее и наибольшее число Story Points. А в спорных ситуациях как раз используются эталонные задачи и сравнение с ними.
Для проведения покера планирования в древние времена у Scrum Master были настоящие колоды карт с напечатанными Story Points. Сейчас существует много онлайн-инструментов, все они без труда гуглятся. В Авито мы используем внутренний инструмент, который выглядит так:
Самым важным преимуществом покера планирования является независимость выставления оценки. Это позволяет учесть мнение всех инженеров, а также оценить задачу с поправкой на мнимого «усредненного» члена команды, так как исполнитель заранее не известен. Хотя мне приходилось работать в командах, где Story Points выбирали обычным открытым голосованием и это успешно работало. Но нужно понимать, что для этого члены команды должны быть активными и сработавшимися на конкретном проекте.
4. Применять Story Points при планировании
После того, как команда какое-то время использовала Story Points, можно оценить, сколько из них обычно закрывается за определенный промежуток времени. Например, в рамках Scrum — за спринт. Можно выделить несколько таких значений и вычислить среднее (или примерный диапазон с учетом рисков, если данных недостаточно). Полученное число называют Velocity или скорость, с которой команда закрывает задачи.
Планируя очередную итерацию проекта, используйте Velocity для того, чтобы понимать, на сколько Story Points можно укомплектовать команду. Естественно, чем дольше команда работает над определенным проектом, тем больше данных у нас для того, чтобы измерить Velocity. Со временем Velocity может расти, поскольку команда осваивается в проекте, понимает домен и инструменты. Верно и обратное: если команда переключается на другой проект или изменяется ее состав, то историческое значение Velocity становится неактуальным (как и ранее выбранные эталонные задачи).
В идеале команда закрывает за итерацию столько Story Points, сколько запланировала. Это позволяет более точно управлять ожиданиями стейкхолдеров. Но мы живем в реальном мире, где существует неопределенность, внешние факторы, шероховатости процессов. Поэтому иногда не попадать в оценку — это нормально. Но важно не допускать систематических провалов за счет регулярного анализа и калибровки процессов планирования и оценки задач.
Также с долей осторожности Velocity можно применять и для более долгосрочного планирования. Если ваш бэклог задач оценен по Story Points, то зная Velocity можно предположить, сколько итераций вашей команде потребуется для завершения проекта. Например, у вас в бэклоге задач на 200 Story Points, а Velocity команды 15. Тогда примерно за 14 итераций можно завершить проект. Конечно, это очень грубая оценка и можно еще учитывать отпуска в команде, возможность блокировок об внешние команды и много-много всего. Но не будем вдаваться в подробности, долгосрочное планирование — не тема этой статьи. Важно лишь понимать, что подобная оценка дает неплохое начальное приближение, которое можно использовать при более детальном планировании.
Лучшие хорошие практики при применении Story Points
Гарантировать идеальную работу таких механизмов, как Story Points, для любых проектов и команд — невозможно. Даже при условии стабильной и осознанной команды, которая активно вовлечена в процесс оценки задач. Мы все еще пытаемся предсказывать будущее в изменяющихся условиях с кучей параметров. По этой же причине не существует универсального набора лучших практик. То, что работает в одной команде, может совершенно не работать в другой. И наоборот.
Хорошая новость: нам не нужен идеал, а нужен рабочий инструмент. И в этом разделе я собрал советы, которые показали себя рабочими в моей практике — возможно, они окажутся полезными и для вас. И возможно, что за некоторые вы наградите меня званием «Капитан-Очевидность».
Не оценивайте заблокированные задачи
Заблокированные задачи зависят от выполнения других задач, поэтому входные условия для них могут измениться. Преждевременная оценка рискует быть не точной, да и имеет мало смысла. Вы все равно не сможете взять такую задачу в работу.
Сравнивайте задачи между собой и ссылайтесь на список эталонных задач
При трудностях в оценке или спорах ссылайтесь на список эталонных задач. Подвергайте оценку сомнению, сравнивая задачу с текущими рядом оцененными. На то Story Points и относительная величина, поэтому сравнение с другими задачами — основа механизма. Иногда удобно применить метод «триангуляции»: сравните новую задачу с уже оцененными меньшей и большей сложности. Если задача ближе к меньшей — дайте ей меньше SP, если к большей — больше.
Не бойтесь закладывать больше Story Points на неопределенность
Выше я уже писал, что влияет на неопределенность и как переоценка собственных сил может привести к сдвижению сроков. Наибольшую точность в оценке можно достичь, дробя задачи на более мелкие, но это не всегда целесообразно: иногда задачи включают ресерч, опираются на недоступные сейчас дизайны, или при дроблении теряется целостная картина. Поэтому не стесняйтесь при планировании неопределенной задачи закладывать больше Story Points (конечно, в разумных пределах). При сомнениях в оценке применяйте пессимистичный подход и округляйте в большую сторону. Сопротивляйтесь соблазну оценить ниже, чтобы взять больше задач. В конечном итоге лучше сделать больше, чем обещали, чем не сделать обещанного.
Детализируйте задачи перед оценкой
Невозможно оценить задачу, если у команды нет четкого образа результата. Идеально, чтобы автор задачи сразу, не отрываясь от контекста, заполнил ее описание и критерии приемки. Для большой задачи полезно разбить ее на предполагаемые шаги, которые потребуется пройти исполнителю. Во время покера планирования это позволит сосредоточиться на самом главном — командой оценке.
Не углубляйтесь слишком сильно при оценке задачи
В своей книге Agile Estimating and Planning Майк Кон приводит следующий график примерной зависимости точности оценки задачи от усилий, приложенных для вычисления этой оценки:
И хотя график основан не на данных, а на субъективном опыте автора, я с ним согласен. Чем больше вы «закапываетесь» в деталях конкретной задачи, тем выше риск дать неточную оценку. Чаще всего это работает в сторону занижения оценки. После бурного обсуждения, у вас возникает ложное чувство разрешения неопределенности. Задача начинает казаться не такой уж и сложной, и в результате вы ставите меньшую оценку. По мне, на обсуждение оценки одной хорошо описанной задачи оптимально тратить ~2 мин командного времени.
Реагируйте с умом на провалы планирования
Если это разовая история, то самой правильной реакцией будет ничего не делать. В условиях постоянной неопределенности мы не можем гарантировать 100% точность планирования.
Иногда возникает соблазн «подогнать цифры» и задним числом добавить несколько Story Points к задачам, которые оказались сложнее. Так Velocity вроде бы совпадает с планом. Но это искажает систему: все остальные задачи в бэклоге были оценены относительно этих же задач и их никто не переоценивает. В итоге при следующем планировании под прежний Velocity команда снова столкнётся с ошибкой.
Единственное исключение — когда мы понимаем, что целый класс задач систематически оказывается сложнее, чем ожидалось. Например, отрисовка интерфейса может требовать больше усилий из-за нехватки экспертизы во фронтенде. Или задачи, требующие коммуникации с внешними командами. В таком случае корректно переоценить все подобные задачи в бэклоге.
Если провалы в планировании становятся регулярными, стоит пересмотреть целевую Velocity на основе последних итераций и снизить ее. Повышать ее имеет смысл только после того, как ситуация стабилизируется. Если же фактическая Velocity заметно колеблется — команда то перевыполняет, то недовыполняет план — скорее всего имеются проблемы с оценкой задач. Обратите внимание на следующий пункт.
Периодически обновляйте эталонные задачи, ведь видение, скилл, контекст и память команды изменяются
С течением времени может изменяться домен или этап проекта, навыки команды, ее состав и т.д. При любых серьезных изменениях рекомендую командно актуализировать эталонные задачи, выбрать туда более новые. Так как эталоны приносят пользу только тогда, когда их можно сравнивать с текущими задачами, и все коллеги понимают их вес.
Как переоценивать частично завершенные задачи
Первый и самый прозрачный способ — не засчитывать никаких Story Points для частично выполненных задач. Тем самым мы подчеркиваем, что для нас главное — результат и ценность, которую приносит задача. В этом случае Velocity в текущей итерации просядет, а в следующей ожидаемо вырастет: команда завершит оставшуюся работу, получит Story Points за полную задачу, и часть ресурсов освободится. Такие колебания Velocity незначительны, ведь мы ориентируемся на стабильность в долгосрочной перспективе.
Второй способ — засчитать выполненную часть работы в Story Points, а для оставшейся создать отдельную задачу и оценить её заново. Такой подход более гибкий: он позволяет вернуться к «хвосту» значительно позже, если приоритеты команды изменились.
Какой из способов выбрать — зависит от контекста и удобства именно для вашей команды.
Изменяйте шкалу в крайнем случае, это аннулирует ранее выставленные оценки
Если вы хотите изменить шкалу Story Points, например, добавить больше промежуточных значений, вы должны понимать, что это аннулирует ранее оцененные задачи. И в таком случае вам необходимо снова выбрать эталоны и произвести переоценку бэклога. Поэтому изменяйте шкалу осознанно, только когда это действительно необходимо.
Заключение
Story Points — всего лишь еще один инструмент, который хорошо работает, когда его применяют по назначению. «Забивать шуруп молотком» можно, но только зачем? Индустрия знает о попытках использовать Story Points для сравнения производительности команд, об подгонке для красивых цифр в отчетах. Но это лишь внутренний помощник команды для планирования в условиях высокой неопределенности.
Закончить свой материал мне хотелось бы цитатой Рона Джеффриса, создателя Story Points (в моем вольном переводе):
Ну, если я и правда изобрёл Story Points, то, пожалуй, я сейчас немного сожалею об этом, но не слишком сильно. Я действительно считаю, что оценки часто используют неправильно и что многих проблем можно избежать, если вовсе отказаться от оценок в Story Points. Если они не приносят вашей команде или компании ощутимой пользы, я бы посоветовал от них отказаться, как от лишних затрат. С другой стороны, если вы их просто обожаете — что ж, продолжайте!
Источники
Майк Кон. Agile Estimating and Planning, 2005
Кен Швабер и Джефф Сазерленд. Руководство по Scrum, 2020
Рон Джеффрис. Story Points Revisited (оригинал статьи недоступен, прикрепляю ссылку из веб-архива)
Знакома ли вам оценка задач по методике Story Points? Пишите в комментариях.
А если хотите вместе с нами помогать людям и бизнесу через технологии — присоединяйтесь к командам. Свежие вакансии есть на нашем карьерном сайте.