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

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

Немного о Story Points

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

• линейная последовательность (1, 2, 3, 4, 5, 6, 7),
• последовательность удвоения (1, 2, 4, 8, 16),
• последовательность Фибоначчи (1, 2, 3, 5, 8, 13).

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

Недостатки оценки в часах

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

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

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

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

Преимущества Story Points

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

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

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

Методы оценки в Story Points

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

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

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

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

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

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

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

SP	Условие	Пример задачи
1	Тривиальная задача, которая не должна занимать много времени и не связана с изменением логики. Чаще связана с небольшими визуальными элементами/ стилями/ текстом.	Поправить текст, стили. Изменить название переменных, условие в коде. Поменять/добавить ссылку, кнопку.
2	Правки или небольшое дополнение существующей функциональности, в которой все понятно. Реализация не должна вносить большие изменения.	Добавить в существующие настройки возможность запоминать выбранную тему. Добавить настройку включения/отключения появления модального окна. Поправить комбинации горячих клавиш.
3	Правки или добавление функциональности, для которой уже подготовлены необходимые элементы, но потребуется больше времени на реализацию. Реализация вносит более объемные изменения в коде, но при этом не должна быть сложной и требовать больших временных затрат на вникание в логику.	Добавить типовое модальное окно с формой отправки. Найти причину неверной работы фильтрации. Подключить небольшое API.
5	Реализация новой функциональности. Возможно, для нее уже существует часть элементов или подготовлена минимальная среда. Чаще необходим поиск решений, создание прототипов макетов элементов или функционала.	Реализовать фильтр. Разобраться с неизвестным багом и исправить. Подключить большой API/переделать старый на новый.
8	Задача повышенной сложности, для реализации которой нужна совместная работа с другим отделом. Большой объем работы, чаще с выяснением непонятных моментов, проверкой гипотез и поиском решений. Возможно для функциональности ничего нет и все нужно писать с нуля.	Переписать существующие методы получения данных и изменить их отрисовку на клиенте. Подключить новые методы с новой структурой и отобразить на клиенте. Оптимизировать работу приложения с тестированием. Перенести часть ресурсоемкого функционала с клиента на бекенд.
13	Реализация отдельного раздела/сервиса с добавлением ранее не используемых инструментов. Задача на правки или расширение функционала глобально для всего сервиса с большим объемом написания кода. Необходимо проектирование, дизайн, работа с другим отделом и поиск решений. Ожидается наличие подводных камней, реализация в несколько подходов и вероятная декомпозиция задачи.	Создать отдельный раздел/ страницу с функционалом. Добавить темную тему для всего сервиса.
21	Задача, которую на данном этапе невозможно выполнить.Подготовка к реализации сервиса/ раздела. Чаще такие задачи следует сразу разбить на подзадачи и продумать план их реализации.	Перевести сервис c SPA на SSR. Перевести проект на новую архитектуру.

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

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

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

Планирование и игра в покер

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

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

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

Чек-лист по ошибкам 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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