Как оценить свои задачи с помощью игры в «покер»? Методология Story Points

Привет! Я — Игорь, фронтенд-разработчик в Selectel. В тексте расскажу, как переход на Scrum помог гибко управлять задачами и почему оценка в часах — не всегда оптимальное решение для этого.

Когда-то давно я был проектным менеджером в небольшой компании, где было принято работать по модели Waterfall. Все этапы разработки были определены заранее, а на каждый этап отводилось определенное время.

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

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

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

Однако вовсе необязательно привязываться в числовым значениям. В качестве единицы измерения вы можете выбрать любой параметр, который отражает сложность задачи. Например, некоторые команды используют альтернативные шкалы оценки с попугаями или размерами маек (S, M, L, XL). В целом, это не так важно, вы можете дать волю своему креативному мышлению. Главное — разобраться в сути Story Points и недостатках использования абсолютных единиц измерения.

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

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

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

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

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

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

SP с оценкой по эталонной задаче

Из списка задач в спринте выбирается самая маленькая, которой ставится наиболее низкая оценка, например 1SP. Эта задача является эталонной. С ней сравниваются следующие.

Мы спрашиваем себя, насколько вторая задача требует больше усилий по сравнению с эталонной. Далее — присваиваем ей оценку. Здесь есть нюанс: от спринта к спринту веса эталонных задач должны быть примерно одинаковыми. Советую придумать правила для оценивания.

SP с относительной оценкой

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

Каждая команда выбирает последовательность, исходя из собственной специфики работы и задач. Мы в отделе используем последовательность Фибоначчи (1, 2, 3, 5, 8, 13, 21). В ней для каждого значения есть свое описание условия/критерия, которому должна соответствовать задача для получения Story Point.

Приведу пример таблицы для сопоставления значения Story Point и критерия соответствия.

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

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

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

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

Задачи в новом спринте оцениваем с помощью Scrum Poker. Это необязательный инструмент, но многие команды используют именно его. «Играя в покер», команда берет задачу из списка и кратко обсуждает ее. Далее — каждый участник выставляет оценку на доске. Значения вскрываются после того, как все участники поставили оценку.

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

Расскажу о наиболее распространенных ошибках, с которыми можно столкнуться при использовании Story Points. Используйте и делитесь своими советами в комментариях!

1. Оценка в Story Points на основе времени и игнорирование воркфлоу

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

Не забывайте про время на проверку, исправление багов, тестирование и внедрение!

2. Оценка без учета технического долга

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

3. Оценка без учета зависимости от других команд

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

4. Недостаточное описание задачи

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

5. Игнорирование неопределенности и рисков при оценке

Детальное описание есть, все супер. Вы начали работать — и тут пишет заказчик, что все нужно переделать. Как следствие — сроки сдвинулись, а другие задачи пострадали.

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

6. Отсутствие четких критериев для оценки

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

7. Оценка задач без учета предыдущего опыта

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

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

Независимо от используемого подхода оценки задач, без анализа сами по себе оценки бесполезны. Раньше мы использовали линейную последовательность от 1 до 10, где 1 — самая тривиальная задача, 2 — чуть сложнее и т. д. С ней было просто работать, но в итоге не хватило гибкости для оценки объемных задач. Последовательность не учитывала значительные различия в сложности между ними.

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

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

#selectel #менеджмент #софтскиллы #storypoints #разработка