На написание данной статьи меня подтолкнули мои выпускники Школы Скрам-мастеров. На одном из занятий, я рассказывала им про относительную оценку и они попросили написать сказанное словами. В моей голове пронеслась лишь одна мысль: “Неужели ещё не всё написано по этой теме?”
Возможно, остались какие-то белые пятна или что-то написано иными словами и моя статья будет полезна.
Относительная оценка: почему Фибоначчи?
Перед тем, как перейти к тому как и зачем команда использует относительные оценки, остановлюсь на ответе на вопрос “Почему последовательность Фибоначчи?”
Довольно часто меня спрашивают, почему в Agile используется адаптированная последовательность Фибоначчи: 1, 2, 3, 5, 8, 13, 21, 40, 100. Всё дело в законе Вебера-Фехнера, суть которого заключается в том, что человек обычно замечает разницу между двумя объектами, если эта разница более 60%.
Вы можете легко это проверить сами, для этого сделайте такое упражнение:
Именно закону Вебера-Фехнера подчинается последовательность Фибоначчи, поэтому она и используется как линейка для относительной оценки. Так как 0 не используется, команды начинают с 1. Максимальное значение, указывающее, что элемент бэклога можно сделать за спринт обычно обозначается 8, а иногда 13. Команды, с которыми я работала, чаще всего останавливаются на 8, а 13 используют как показатель, что требуется декомпозиция. 21 и 40 команда может использовать как показатель, что есть белые пятна в самом элементе бэклога и надо что-то прояснить (spike), а 100 - когда вообще ничего не понятно…
Относительная оценка: зачем она вообще команде?
Существует разное мнение относительно того, надо ли оценивать или не тратить на это время и уже не оценивать, ведь есть хорошая практика noEstimate. Я сторонник оценки элементов бэклога, но также всегда прислушиваюсь к команде, чтобы понять почему команда не хочет или не готова, там всегда есть своя история.
Изначально и по сей день, оценка элементов бэклога продукта проводится с целью выровняться по пониманию, что необходимо сделать для реализации функционала.
Представьте, что у вас есть элемент бэклога продукта (US/JS), для реализации которого вам потребуется фронт (FE), бэк (BE) и тестирование (QC). В команде у вас 2FE, 3BE и 2QC. Все эти участники команды потенциально могут заняться данным элементом бэклога, поэтому их задача слушать друг друга и понять сложность, объемность, новизну, риски реализации.
Послушав друг друга, они сбрасывают карточки из последовательности Фибоначчи – Покер планирование – которые показывают общую оценку реализации, а не только в своей части.
Данные оценки, как лакмусовая бумажка, отражают насколько участники команды хорошо поняли друг друга. Задача Scrum-мастера/Agile-коуча (фасилитатора), задать вопросы тем, кто поставил минимальное значение, а также тем, кто поставил максимальное, что они в них вложили. В нашем примере, примечательно, что задачи разошлись и у одной специализации, что тоже необходимо прояснить. Бывает, когда кто-то вернулся из отпуска и не знает, что “выпилили” какой-то “костыль”, а бывает, что кто-то не занимался этим участком кода и не знает, что там есть “свои нюансы”, также бывает, что FE и BE не знают сколько сложностей может быть у тестировщиков, например, из-за того, что им надо поднимать стенды или ещё хуже, охранять их от других, так как кто-то может переписать данные…
Всё это проясняется в диалоге и участники команды выравниваются по пониманию сложности, объёмности, новизны и рисков в элементе бэклога продукта.
Какое ещё понимание даёт относительная оценка? Она помогает понять кому её взять. В ряде команд, с которыми я работала, мы выработали практику, что если элемент бэклога оценён в 8 и эта оценка продиктована, например, сложным BE, то этой задачей будет заниматься Senior, аналогично и для FE.
Как и в беге объём задачи одинаков, лимит - спринт, а вот успеете вы или нет зависит от навыков, поэтому какие-то задачи делают Senior, какие-то Middle, а какие-то Junior, а когда Senior или Middle наставляет Junior, то он бежит разрабатывает медленнее и это сказывается на общей скорости команды - поправка на инвестицию в развитие, так как без такой инвестиции со временем команде станет туго.
Подводя итог этого раздела, основная задача относительной оценки для команды - это выровняться по пониманию, что необходимо сделать для реализации, а также определиться кто будет заниматься реализацией с учетом сложности.
Относительная оценка: с чего начать?
Допустим, вы приняли для себя решение о том, что будете оценивать в story points, с чего же начать?
Первое, что необходимо сделать – это собрать фактуру, а точнее выполненные элементы бэклога . Собирается фактура обычно 3 спринта.
После этого команда, которая занималась delivery (реализацией), напоминаю, что мы не берём в расчёт работы связанные с подготовкой элемента бэклога продукта к стадии “готово к разработке” - эта часть часто называется discovery/анализ, и связана с подготовкой (“прожаркой”) элемента бэклога продукта до необходимого состояния, чтобы было понятно что будем реализовывать и будем ли.
Далее делается сетка с оценкой, на которой выкладываются выполненные элементы бэклога продукта. Я рекомендую найти элемент, который будет оценён на “3” и от него можно отталкивать в большую или меньшую сторону. Ничего страшного, если по какой-то причина команда не договориться по каким-то элементам бэклога, это откалибруется со временем. Также со временем у команды появятся свои паттерны, когда оценка будет проходить быстро, например, если задействованы все стеки - оценка 5 или 8, если только один стек и тестирование - 2 или 3.
Относительная оценка: переоценка
Отдельно хочу остановиться на переоценке элементов бэклога продукта. В этом вопросе мнения тоже разделились, я поделюсь своим, а брать его или нет, решение уже за вами.
Я рекомендую переоценивать элементы внутри спринта и не трогать по окончанию, остановлюсь подробнее, чтобы у вас сложилось правильное понимание.
Если вы не будете переоценивать внутри спринта, то может произойти ситуация, когда при сравнении элементов команда не будет понимать какую оценку ставить, да и статистика будет нарушена.
Относительная оценка: как довести до внешнего окружения
Я всегда с улыбкой слушаю рассказы о том, что пытались донести до менеджмента сколько будет стори поинтов и менеджмент ничего не понял. Дело в том, что стори поинты - это терминология внутри команды, а с внешним миром общение идет через время, для это Владелец продукта переводит стори поинты в недели или месяцы, даже не в спринты. Для этого используется следующая формула.
Надеюсь, в этой статье вы нашли для себя свежие мысли 💭 и у вас даже появились идеи 💡 по повышению эффективности относительных оценок. А если вы хотите узнать больше, то приглашаю вас к нам на обучение:
Тренинг “Основы Agile и командной работы”
Автор статьи: Анастасия Бутова-Никишина Основатель компании "Лаборатория ПроЛидеров", Agile-консультант
