Story Points — оценка задач и планирование разработки продуктов

Что такое Story Points? Как оценить задачи для разработчиков? Как спланировать дорожную карту?

Story Points или сторипоинты — это бальная система оценки задач и планирования проектов в разработке.

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

Давайте разбираться.

Вводные

Первое что стоит понять, что сторипониты это не совсем оценка времени. Это скорее бальная оценка задач.

Она частично связана с трудоемкостью, но лишь отчасти.

Если проводить аналогию, то можно взять Шкалу Бофорта из метеорологии.

Там скорость ветра привязывается к баллам. Тоже самое следует делать в разработке — привязать оценку трудоемкости в идеальных днях к баллам или сторипоинтам.

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

Почему проектные подходы ломаются в разработке?

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

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

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

Что значит менее предсказуемое чем сложное? Ответ на этот вопрос можно узнать если ознакомиться с моделью Киневина.

Сложные системы — это не так уж сложно :) Большинство разработок с кодом — заметно отличаются в методах планирования. Системы типа Хаос или Запутанные — управляются иначе чем Сложные системы. Важно это понять. Модель Киневина — хорошо помогает понять в чем отличие.

Ключевые отличия планирования сроков по задачам и по итерациям

В старых проектных подходах было принято оценивать сроки так:

• сроки по задачам
• сроки по разработчикам

В подходах на основе Agile, Scrum, Kanban, оценка происходит иначе. Сильно иначе.

Там оценка идет по другим аспектам:

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

Чуете сложность?

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

Важно понять что оценка сроков в Agile требует иных навыков и понятий:

• оценить срок можно только у итерации
• истории можно планировать только на 1–3 итерации вперед
• чем дальше итерация, тем меньше вероятность совпадения плана и прогноза
• важно отличать прогноз от плана

Как быть? Что нужно уяснить?

• важно понять что такое баллы или сторипоинты (баллы истории)?
• чем история отличается от задачи?
• что такое дорожная карта историй?
• что такое скорость команды на 1 итерацию (велосити, velocity)?
• что такое вместимость итерации (капасити, capacity)?
• как спрогнозировать сроки на 2–4 итерации вперед?
• почему бесполезно планировать работу на более чем 4 итерации вперед? а иногда даже на 2 итерации вперед план будет слабым.

Что такое баллы или сторипоинты?

Вот мы и подбираемся к ключевой идее. Почему нужно использовать баллы вместо трудоемкости или сроков по задачам?

Во первых стоит понять что такое баллы (сторипоинты) и как они связаны с идеальными днями?

В таблице ниже можно понять соотношение идеальных дней и баллов:

Эта таблица похожа на Шкалу Бофорта, только вместо скорости ветра тут идеальные дни, а вместо баллов Бофорта тут баллы истории или сторипоинты.

Важно оценить каждую историю по баллам. Сколько баллов у истории?

Если история слишком крупная — ее надо разбить на более мелкие истории.

Истории могут объединяться в темы (themes) или эпопеи (эпики, epics). Более подробно можно прочитать в книге “Agile: оценка и планирование проектов”.

Как планировать итерации?

Итерации Agile в Scrum принято называть спринтами (sprint).

Итерации обычно бывают на 1 месяц или на 2 недели.

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

Бывают применяют недельные итерации. Но обычно это про карго-культ, а не про разработку и agile. Могут быть исключения. Если речь идет про очень простые продукты и задачи.

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

Например сколько мы можем сделать историй в августе?

Ответ на этот вопрос не так прост и с ходу не дается.

Что такое скорость и вместимость?

Что такое скорость? Еще ее называют велосити (velocity).

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

Средняя скорость команды в баллах и есть вместимость 1 итерации.

Предположим что у вас в команде 3 разработчика. А итерация равна 1 месяцу. Идеальную скорость мы можем посчитать через идеальные дни — 20 идеальных дней в месяце, на 3 разработчика — это 60 идеальных дней или 60 баллов — вместимость итерации.

Беда в том что идеальная скорость и вместимость — не достижимы.

Через 2–4 итерации вы узнаете что ваша скорость или вместимость равна в лучшем случае 30–40 баллов. Если все плохо то может быть 20–30 баллов. Если совсем плохо то 10–20 баллов.

Почему идеальная скорость отличается от реальной?

Тут играет куча факторов, которые снижают эффективность команды:

• слабое описание задач (слишком детальное, слишком короткое, плохая структура)
• нарушение правила пиццы: в команде меньше 3 или больше 7 разработчиков.
• совещания и обсуждения
• частое переключение между задачами (потери времени и мыслетоплива на переключения)
• наличие новичков в команде которых надо обучать
• технические проблемы и ошибки в архитектуре
• слабые навыки в команде и траты на обучение

Почему сторипониты это не про идеальные дни?

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

Суть в том что ключевое отличие в принципе оценки по бутылочному горлышку.

Что есть бутылочное горлышко чаще всего? Это программисты. Потому оценка сторипоинтов идет по программистам. Идеальные дни с точки зрения программистов. Сколько там займется времени по задачам у тестировщиков или аналитиков в большинстве случаев не имеет значения.

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

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

Это еще добавляет сюрпризов с точки зрения подсчета скорости и вместимости.

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

Что такое дорожная карта и Kanban доска?

Важно отличать Канбан доску от Дорожной карты.

Канбан доска:

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

Дорожная карта:

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

Важно еще уметь применять оба инструмента. Это не так просто.

Подробнее про эти понятия можно почитать тут:

• Что такое канбан доска?
• Что такое дорожная карта?

А можно без сторипоинтов?

А оно нам надо? Хороший вопрос :) Этот подход далеко не единственный и далеко не всем командам он подходит.

Этот подход хорошо работает в следующих ситуациях:

• когда нужно иметь более менее реальный прогноз на срок завершения какой то важной вехи в разработке. Например успеем ли мы выкатить функционал X через 10 месяцев? А если не успеваем, то что можно выкинуть?
• когда у команды есть 3–4 стейкхолдера и надо балансировать их хотелки. Например вы делаете b2b продукт, у вас клиенты: Сбер, Ростелеком и РЖД. Каждый постоянно что-то хочет и им важно понимать когда они это получат.
• когда есть инвестор или 1 ключевой Клиент, которому надо понимать что делать в 1ю очередь, а что может подождать? Ему для принятия решений надо знать что и когда будет готово? Сможет ли он получить функционал X в следующем месяце, если пожертвовать функционалом Z и отодвинуть его на 2 итерации вперед?

Когда это все нафиг не надо?

Например если вы работаете над b2c продуктом, у вас 1 000 000 пользователей и все хорошо. Вы просто выкатываете то что выкатываете когда получится. Обычно там лучше применять Agile, Kanban & OKR.

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

Про карго-культ

Многие команды заявляют что используют Scrum или Agile. Но на деле там Срам, Ад-айл и Карго-культ )

Как отличить карго-культ? Какие ошибки часто встречаются?

Сроки спрашиваются по задачам и разработчикам

Руководство говорит о том что мы про Agile & Scrum, но сроки просит называть по разработчика и по задачам :) Также пытаются оценивать метрики эффективности по каждому разработчику — это не про Agile и не про Scrum.

Путают итерацию (спринт) и этап проекта

Вот мы запланировали в итерацию 7 историй, но не успели сделать 2 истории. Давайте продлим срок итерации )) Это тоже карго культ. Итерация — это не этап проекта. У итерации срок не может сдвигаться. Итерация кончилась — посчитали скорость. Если надо — перепланировали следующую итерацию — пляшем дальше.

Отсутствует подсчет скорости

Итерации заканчиваются, а какая скорость получилась — никто не считает. В этом случае итерации бесполезны. Но кого это волнует в карго-культе? )

Ретроспектива не делается или делается в стиле “что было прикольно? а что плохо?”

Типа вот мы кофемашину в офисе поставили — это прикольно. А работы было много — это фигово.

Ретроспектива должна делаться на основе плана историй и итераций. Вот запланировали на итерацию 10 историй, 8 успели, а 2 нет. 8 успели — это круто. А 2 не успели — почему?

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

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

Итого

Давайте подобьем итоги:

• нужно понять что сроки по задачам или разработчикам не работают
• нужно понять что такое баллы истории или сторипоинты
• далее понять что сроки можно ставить только по итерациям
• выяснить как понять скорость команды и вместимость итерации
• после этого вы сможете планировать сроки по итерациям на 2–4 итерации вперед (2–4 месяца вперед)
• если у вас очень сильная команда и очень сильное руководство, то планировать можно на 1–2 года вперед, но такое бывает редко.

Если чего то не поняли — пишите вопросы в комментах. Разберемся)