Процессы
June 21, 2024

Оценка спринта как способ работать работу

Планирование — друг человека

Планирование — это 50% успеха, сказал бы како-нибудь душный умник.

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

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

Этап 1 — заполнять спринт до упора. Это плохо.

По началу кажется, что так и должно быть. Мы приняли оценку по методу Фибоначчи. И довольно долго жили с тем, что для классной работы надо упихать все 21 story point, выделенные на спринт.

Фатальная ошибка.

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

Заполняя полностью спринт под завязку, мы перегружали дискавери команду. Казалось, что с недозабитым спринтом в 21SP, дизайнер не дорабатывает или ещё хуже — не знает, чё ему делать. Но по факту, когда начинаешь анализировать закрытые таски, выходит, что спринт закрывался с реальынми 25-30-40SP.

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

— я буду это делать 2 дня. Но по факту там на полдня работы вышло

С другой стороны, у недооценки нет никакого лимита:

— я будут делать это 2 дня. Но выходит на пару спринтов.

Почему? Потому что:

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

В конце спринта команда понимает, что еле-еле выполнила, что планировала. Почему? Потому что на самом деле задачи были перевыполнены. Просто оценены неправильно.

Что можно сделать после этого? Как выход — брать на 30-20% меньше, чтобы был запас для манёвра.

И вот мы начинаем заполнять спринт на 70%.

Начинаем брать в спринт поменьше. Вместо 21SP - берём 14-17SP

Этап 2 — не дробить сложные стори. Это плохо.

Мы по-прежнему ошибаемся в оценке, но уже попадаем в нагрузку спринта. Вместо 21 берём 14-17 SP, но после переоценки на ретро видим, что мы попали по нагрузке в 21. Супер? Да, но нет.

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

Мы решили — любая сложная и непонятная задача в 8SP и больше превращается в Сторю. А в этой Стори уже будут наши любимые Таски.

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

Стори: пользователь хочет получать новый промокод и мгновенно его активировать.

  • Оцениваем задачу как 8 SP и попытаемся раздробить на более мелкие, понятные подзадачи для всех участников:
    • 1 SP Понять откуда приходят данные и в каком виде
    • 2 SP Согласовать требования и результат, который всех устроит. Нас как команду и заказчиков.
    • 2 SP Какие могут быть ошибки, корнер кейсы
    • 1 SP Описание состояний для QA 
    • 2 SP Адаптивы для разных экранов
    • 1 SP Правка текстов и визуал
  • Мы примерно попали в оценку. Но заложим еще 30% на ожидания ответов и согласование с Деливери командой и процесс правок после Дизайн-ревью.
  • Сама задача выросла до 12 SP, хотя казалось, что можно управится за пару дней. В действительности, сторя может занять больше 1 недели.

Более мелкими задачками управлять куда проще и всегда проще приоритизировать. Чем большую, непонятную Стори в 12 SP.

Но есть некоторая проблема дробления: из-за того, что мы просто начнём втупую брать меньший объём задач, скорость до прода начнёт падать. А это неинтересно ни команде, ни бизнесу.

Ещё ж и адхоки могут прилететь в любой момент. И никто не отменял обязательства по закрытию спринта, верно?

Разберем в следующем этапе — обязательства.

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

Перед самым стартом спринта мы находимся в двух состояниях сразу:

  • состояние наименьшего погружения в суть задачи и всех возможных рисков
  • состояние принятия обязательств по закрытию спринта

Что нам помогло?

Нужно научиться делать гибким сам объём задач, вместо суммирования сторипонтов до начала спринта.

Для этого нужна оценка важности по всем типам задач. По-простому – приоритет.

Так будет проще взять в работу во время спринта ещё какую-то пачку на основе их оценки. Оценки типа Low, Middle, High, Blocker теперь наши друзья.

2 задачи High приоритета, 1 Low, 9 Middle

Мы видим, что в спринте есть 2 задачи High приоритета. То есть для нас это принятие обязательств, что эти 2 задачки заедут за две недели, т.к. они важны. А одна Low приоритет, так что ничего страшного, если эта 1 задачка не задет.

Этап 4 — идти в спринт без целей. Это плохо.

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

Например, цель спринта:

  1. вылить в прод часть админки
  2. описать сценарии подключения программы лояльности
  3. зафиналить логику выбора торговых точек для отображения каталога
  4. улучшить процесс авторизации на андроид телефонах

Это главные цели на спринт. Не стоит подписываться жёстко под весь список. Лучше выделить основное и второстепенное. Если основная часть закончится раньше, то можно спокойно доделывать остальное, при этом особо не парясь, будут ли остальные задачи выполненные точно в спринт или нет. Ведь цели уже были закрыты. Это ли не успех? ~^^

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

Поверьте, вселенная не схлопнется из-за этого, вас не растворят в кислоте, а вы научитесь чуть проще и реалистичнее относится к планированию.

Этап 5 — фиксировать гвоздями цели спринта. Это плохо.

Спринт это просто отрезок времени, за который что-то должно произойти. И если цель была «поставить на прод 3 фичи», но в процессе выполнения вдруг поняли, что это нереально сделать — вы спокойно можете переписать цели спринта на «задокументировать 2 фичи, выпустить на прод 1».

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

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

В итоге мы стали лучше? Это хорошо.

Да, но и это не предел. Всегда есть что улучшать и развивать. А пока мы смогли:

  1. автоматизировать процесс заведения сторей
  2. научились дробить большие стори
  3. стали приоритизировать задачи по ходу работы
  4. гибко выставлять цели на спринт