Научитесь использовать Story Points для оценки сложности задач в методологиях Agile и Scrum, что поможет улучшить планирование и управление проектами.

Story Point — это единица измерения, используемая в Agile управлении и разработке проектов для оценки сложности реализации User Story и других задач. Оценка в Story Points обычно противопоставляется оценке в «идеальных инженерных днях» — методу, когда время разработки оценивается в конкретном количестве дней и часов, которое (предположительно) потребуется на решение задачи.

Оценка через Story Points (Стори Поинты) — это оценка в условных единицах. Такие условные единицы нельзя «перевести» в конкретные часы или дни. Другими словами, нельзя будет сказать точное время, сколько займет разработка. Однако, можно определить разницу того, что будет выполнено быстрее, а что займет больше времени.

Оценить задачу или требование через Story Points довольно просто. Чаще всего для оценки используется так называемый Planning Poker — покер планирования. Суть этого метода сводится к тому, что каждый член команды делает свою оценку в Story Points независимо, а после разбираются результаты.

Ключевая особенность «Стори Поинтов» состоит в том, что эта метрика не привязывается к конкретному времени, такому как дни или часы разработки.

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

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

Идеальный инженерный день — это оценка задачи в количестве дней, требуемых на выполнение задачи «средним разработчиком».

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

В чем тут проблема?

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

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

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

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

Попытка что–то предсказать в таких условиях приводит к тому, что мы либо нарушаем установленные дедлайны, либо перерабатываем, чтобы втиснуться в них.

Обе эти проблемы решаются в другом подходе к оценке — относительной оценке в Story Points.

Оценка через Story Points (Стори Поинты) — это принципиально другой подход к оценке. Это относительная оценка, то есть оценка в условных единицах. Такие условные единицы нельзя «перевести» в конкретные часы или дни.

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

Такой подход к оценке имеет ряд преимуществ.

• Скорость планирования значительно быстрее, чем в случае попыток «точной» оценки в днях и часах [мы это обсудим далее]

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

• Оценка в времени имеет эмоциональную нагруженность, и из–за этого часто становится необъективной. Сказать «Это будет сделано до завтра включительно» значительно сложнее, чем сказать «Это займет X очков Story Points»

• И, пожалуй, наиболее важное — Story Points фокусируют команду на ценности поставляемого продукта, вместо того, сколько времени будет потрачено на эту поставку.

Конкретная реализация такой относительной оценки может быть выполнена по–разному.

Метод первый — оценка по эталону

Этот метод похож на оценку в «попугаях» в знаменитом мультике 38 попугаев — когда мы берем в качестве меры оценки конкретный объект.

В данном случае за основную условную единицу можно брать какую–то одну User Story, которая будет своего рода «эталоном» — её значение будет равно единице. Остальные User Story можно оценивать в соотношении с этим эталоном.

Например, вы можете оценить одну из User Story как 2 единицы, другую как 3. Это будет значить, что для них нужно в 2 или в 3 раза больше времени соответственно, по сравнению с эталоном.

Этот метод хорош тем, что здесь мы можем лучше оценить то, насколько быстро будет выполнена задача, примерно понимая «вес» эталонной User Story.

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

Метод второй — относительная оценка

Во втором методе оценки по Story Points используется последовательность Фибоначчи — 0, 1, 2, 3, 5, 8, 13, 21 и т.д.

!story points scrum что это

В этом варианте оценки разница между задачами еще менее конкретна. Здесь разница между 1 и 2 это то же самое, что разница, например, между 13 и 21 — то есть здесь нельзя сказать, это разница в два, три или сколько–то еще раз. Здесь мы можем констатировать только одно — больше, меньше или равно.

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

Это значительно упрощает задачу для Product Owner, когда он приоритезирует бэклог. Ведь теперь он может взять разные задачи, и увидеть, что их разработка занимает разное время. Одну команда может сделать быстрее, разработка другой займет больше времени. Если при этом ценность этих задач равнозначна, логично начать с более легковесной, чтобы бизнес быстрее получил ценность.

То же самое можно делать и в случае оценки через идеальные инженерные дни, но здесь у оценки в Story Points есть ряд преимуществ.

Оценка методом «T-shirt sizes»

Есть еще один метод оценки, используемый в Agile. Его не относят к Story Point, хотя он также является относительным и неточным, не привязанным к конкретному времени выполнения

Метод оценки T-shirt sizes — по «размерам футболки». Здесь может быть всего три уровня сложности задачи — Small, Medium, Large. То есть маленькая, средняя или большая задача. Может быть больше, если это нужно, но их все равно ограниченное количество.

Можно также использовать другие «ярлыки» для обозначения различий (например, M, L, X, XL, XXL и т.д.).

Это неплохой метод, но обычно полезнее использовать последовательность Фибоначчи, потому что субъективно разница между, например, XL и XXL может восприниматься как «недостаточно значимая», в то время как в последовательности Фибоначчи такого эффекта не возникает (разница между, например, 1 и 2 или 8, 13 — достаточно очевидна).

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

Приоритизацию большого количества задач здесь сделать не получится, так как каждый столбец уровня сложности будет очень большим. Ситуацию.может исправить дополнительная оценка значимости (ценности) задачи, но общая логика остается — если у вас много задач, лучше использовать обычные методы оценки через Story Point (или с последовательностью Фибоначчи, либо с эталонным значением).

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

Почему это так?

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

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

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

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

Ценность экономии времени можно поставить под сомнение в некоторых проектах, однако для проектов с огромными бэклогами (где, например, может быть более 300 фич в разработке) эта ценность очевидна — ведь на подробный разбор и планирование десятков задач может уйти и целый день. А вот процедура оценки в Story Points редко занимает более трех часов.

Оценить задачу или требование через Story Points довольно просто. Конкретный способ будет отличаться о того, какой метод оценки вы выбираете.

Чаще всего для оценки используется так называемый Planning Poker — покер планирования. Суть этого метода сводится к тому, что каждый член команды делает свою оценку в Story Points независимо, «в закрытую», а после того как каждый определился с выбором — разбираются результаты.

Такую оценку можно сделать с любым из методов.

Например, если вы используете простую оценку «T-shirt sizes», можно просто «выбрасывать» одновременно (на «раз–два–три») свою оценку пальцами — где 1 означает что это легко, 2 что это средняя сложность, 3 это это достаточно сложно.

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

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

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

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

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

Еще один важный момент — оценка тех задач, которые уже взяты в работу, должны оставаться неизменными, даже если появляется новая информация (а она наверяка появится).

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

Итак, предположим, вы и ваша команда проранжировали все задачи по Story Points. У вас также есть понимание того, какую ценность несет каждая фича или пользовательская история.

Как это можно использовать?

Самое первое и самое важное — это планирование ближайшей итерации. Вам нужно взять в работу самые «дорогие» (ценные) задачи, которые при этом «стоят» минимальное количество Story Points.

По–сути Story Points выступают как очки, которые вы можете потратить на разработку проекта.

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

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

Это же помогает внести прозрачность в работу компании. Стэйкхолдеры будут понимать, когда они могут рассчитывать на поставку определенной ценности. И если их это не устраивает (классика) — то вы всегда можете обосновать, почему это так. Ведь если сделать что–то раньше, это будет значить, что более приоритетные задачи будут выполнены позже. При такой постановке вопроса только значительное изменение приоритета может изменить порядок выполнения задач.

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

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

Если какая–то индивидуальная задача требует более 16 часов — это повод к тому, чтобы её декомпозировать. Субъективно очень сложно выполнять такую работу. В случае работы со стори поинтами вы можете установить, например, что максимальный лимит — это 20 очков. Если задача требует больше, вы можете обсудить, как её можно уменьшить или разбить на подзадачи.

Для задач, которые находятся на низком приоритете (в «глубине» бэклога) есть смысл оставлять наиболее грубую и поверхностную оценку (достаточно оценки методом «T-shirt sizes») — потому что если вы не возьмете эти задачи в ближайшие итерации, нет смысла планировать работу по ним, ведь ситуация еще много раз может измениться.

Таким образом, вы можете начинать с быстрой и грубой оценки — просто чтобы ваш Product Owner или Product Manager могли приоритезировать бэклог — после чего задачам высокого приоритета давать более точную оценку, на основе которой вы уже будете планировать ближайшую итерацию.

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

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