Что такое story points в agile
Story Points — оценка задач и планирование разработки продуктов
Что такое Story Points? Как оценить задачи для разработчиков? Как спланировать дорожную карту?
Story Points или сторипоинты — это бальная система оценки задач и планирования проектов в разработке.
У меня ушло около 10 лет практики руководства командами разработки на то чтобы понять что это и почему это важно.
Вводные
Первое что стоит понять, что сторипониты это не совсем оценка времени. Это скорее бальная оценка задач.
Она частично связана с трудоемкостью, но лишь отчасти.
Если проводить аналогию, то можно взять Шкалу Бофорта из метеорологии.
Там скорость ветра привязывается к баллам. Тоже самое следует делать в разработке — привязать оценку трудоемкости в идеальных днях к баллам или сторипоинтам.
Почему так надо делать? Чтобы что? Это сложные вопросы, на которые попробуем ответить ближе к концу статьи.
Почему проектные подходы ломаются в разработке?
Многие начинающие руководители в разработке пытаются оценивать сроки по задачам или разработчикам. Как это принято делать в старых проектных подходах.
Они просят разработчика оценить сроки по задаче. Это последствия слабого опыта в управлении разработкой.
Важно понять что оценка сроков по задачам и разработчикам — не работает, если вы разрабатываете что то более менее сложное или менее предсказуемое чем сложное.
Что значит менее предсказуемое чем сложное? Ответ на этот вопрос можно узнать если ознакомиться с моделью Киневина.
Сложные системы — это не так уж сложно 🙂 Большинство разработок с кодом — заметно отличаются в методах планирования. Системы типа Хаос или Запутанные — управляются иначе чем Сложные системы. Важно это понять. Модель Киневина — хорошо помогает понять в чем отличие.
Ключевые отличия планирования сроков по задачам и по итерациям
В старых проектных подходах было принято оценивать сроки так:
В подходах на основе Agile, Scrum, Kanban, оценка происходит иначе. Сильно иначе.
Там оценка идет по другим аспектам:
Важно понять что оценка сроков в Agile требует иных навыков и понятий:
Как быть? Что нужно уяснить?
Что такое баллы или сторипоинты?
Вот мы и подбираемся к ключевой идее. Почему нужно использовать баллы вместо трудоемкости или сроков по задачам?
Во первых стоит понять что такое баллы (сторипоинты) и как они связаны с идеальными днями?
В таблице ниже можно понять соотношение идеальных дней и баллов:
Эта таблица похожа на Шкалу Бофорта, только вместо скорости ветра тут идеальные дни, а вместо баллов Бофорта тут баллы истории или сторипоинты.
Важно оценить каждую историю по баллам. Сколько баллов у истории?
Если история слишком крупная — ее надо разбить на более мелкие истории.
Истории могут объединяться в темы (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 баллов.
Почему идеальная скорость отличается от реальной?
Тут играет куча факторов, которые снижают эффективность команды:
Почему сторипониты это не про идеальные дни?
Причина очень простая. Если слабому менеджеру сказать что сторипоинты это про идеальные дни, то он попытается оценить всех кто в команде. Он будет оценивать тестировщиков, аналитиков и всех кто есть в команде. А это тупиковый путь.
Суть в том что ключевое отличие в принципе оценки по бутылочному горлышку.
Что есть бутылочное горлышко чаще всего? Это программисты. Потому оценка сторипоинтов идет по программистам. Идеальные дни с точки зрения программистов. Сколько там займется времени по задачам у тестировщиков или аналитиков в большинстве случаев не имеет значения.
Хотя я видел ситуации когда мы упирались в тестировщиках. В этом случае было бы лучше оценивать задачи с точки зрения идеальных дней у тестировщиков. Но объяснить это команде было очень сложно. Потому продолжали оценивать как получится. Но это исключительные и очень редкие ситуации.
Потому в большинстве случаев мы просто оцениваем идеальные дни с точки зрения программистов, потому что именно они обычно бывают узким горлышком.
Это еще добавляет сюрпризов с точки зрения подсчета скорости и вместимости.
Но если все сделать правильно, то в конечном итоге скорость и вместимость становятся достаточно понятными, предсказуемыми и позволяют оценивать реальные сроки.
Что такое дорожная карта и Kanban доска?
Важно отличать Канбан доску от Дорожной карты.
Важно еще уметь применять оба инструмента. Это не так просто.
Подробнее про эти понятия можно почитать тут:
А можно без сторипоинтов?
А оно нам надо? Хороший вопрос 🙂 Этот подход далеко не единственный и далеко не всем командам он подходит.
Этот подход хорошо работает в следующих ситуациях:
Когда это все нафиг не надо?
Например если вы работаете над b2c продуктом, у вас 1 000 000 пользователей и все хорошо. Вы просто выкатываете то что выкатываете когда получится. Обычно там лучше применять Agile, Kanban & OKR.
Сторипоинты, короткие итерации, капасити и велосити в этом случае будут излишним усложнением. Конечно могут быть исключения.
Про карго-культ
Многие команды заявляют что используют Scrum или Agile. Но на деле там Срам, Ад-айл и Карго-культ )
Как отличить карго-культ? Какие ошибки часто встречаются?
Сроки спрашиваются по задачам и разработчикам
Руководство говорит о том что мы про Agile & Scrum, но сроки просит называть по разработчика и по задачам 🙂 Также пытаются оценивать метрики эффективности по каждому разработчику — это не про Agile и не про Scrum.
Путают итерацию (спринт) и этап проекта
Вот мы запланировали в итерацию 7 историй, но не успели сделать 2 истории. Давайте продлим срок итерации )) Это тоже карго культ. Итерация — это не этап проекта. У итерации срок не может сдвигаться. Итерация кончилась — посчитали скорость. Если надо — перепланировали следующую итерацию — пляшем дальше.
Отсутствует подсчет скорости
Итерации заканчиваются, а какая скорость получилась — никто не считает. В этом случае итерации бесполезны. Но кого это волнует в карго-культе? )
Ретроспектива не делается или делается в стиле “что было прикольно? а что плохо?”
Типа вот мы кофемашину в офисе поставили — это прикольно. А работы было много — это фигово.
Ретроспектива должна делаться на основе плана историй и итераций. Вот запланировали на итерацию 10 историй, 8 успели, а 2 нет. 8 успели — это круто. А 2 не успели — почему?
Может быть планирование было сделано плохо, или реальную скорость не учли? Или просто эффективный менеджер занимается очковтирательством, пытается показать свою амбициозность перед старшими и загоняет команду в не реальные планы?
В общем есть много различных признаков карго-культа, когда говорят правильные слова, но по факту занимаются имитацией бурной деятельности. Не дай бог попасть в такую команду )
Итого
Давайте подобьем итоги:
Если чего то не поняли — пишите вопросы в комментах. Разберемся)
Оценка задач в Story Points
Практически каждый человек, который сталкивался с разработкой ПО знает что такое оценка задач в Story Points (SP), тем не менее периодически мне доводится рассказывать коллегам из других отделов или новичкам в команде, которые ни разу не сталкивались с таким подходом, зачем мы используем SP и почему это удобно для команды и эффективно для компании.
Цель этого текста – рассказать, что такое SP, как их использовать для оценки задач и почему эта методика получила такое широкое распространение.
Проблема
Расчет времени, необходимого на выполнение задачи одновременно и очень простая и очень рискованная задача, с которой сталкиваются команды разработки.
Неверная оценка становится одной из первых причин срыва графиков или даже провала проекта.
Проблема в том, что бизнес рассматривает оценки как обязательства. Разработчики рассматривают оценки как предположения.
Для иллюстрации я приведу в пример вымышленный диалог из книги Роберта Мартина «Идеальный программист».
Майк (Менеджер): Какова вероятность того, что ты справишься за три дня?
Питер (Разработчик): Пожалуй, справлюсь.
Майк: Можешь назвать число?
Питер: Пятьдесят или шестьдесят процентов.
Майк: Значит, есть довольно высокая вероятность, что тебе понадобится четыре дня?
Питер: Да. может понадобиться даже пять или шесть, хотя я в этом сомневаюсь.
Майк: До какой степени сомневаешься?
Питер: О, я не знаю… Я на девяносто пять процентов уверен, что работа будет сделана менее чем за шесть дней.
Майк: То есть может быть и семь?
Питер: Ну, если все пойдет наперекосяк… Черт, если ВСЕ пойдет наперекосяк, может быть десять и даже одиннадцать дней. Но ведь вероятность такого совпадения очень мала, верно?
Я думаю, что диалог выше звучит довольно знакомо для любого разработчика или менеджера проекта.
К сожалению, проблемы с оценками на этом не заканчиваются. Следует так же учитывать и другие подводные камни:
Корреляция оценки и оценивающего
Выставленная оценка справедлива только в том случае, если реализовывать задачу будет автор оценки. Ведь очевидно, что время, затраченное на задачу старшим разработчиком и интерном будет отличаться.
Идеальная оценка в неидеальном мире
Срочные встречи, рабочие письма, мессенджеры и упавший таск-менеджер еще больше запутывают и без того сложный процесс разработки, что делает идеальные часы, которые мы воображаем во время выставления оценок слабо полезными для менеджера проекта, пытающего собрать стремительно устаревающую диаграмму Ганта.
Далее мы рассмотрим подход к оценке задач в SP и то, каким образом он адресует все описанные выше сложности.
Альтернативные решения
Естественно, подход с использованием SP не первая попытка решить озвученные проблемы, хотя и, вероятно, самый популярный.
В этом блоке я расскажу еще об одной программе, включающей в себя схему оценки задач. Программы называется PERT и знакомство с ней не обязательно для достижения цели тексты, поэтому можно смело перейти к следующему блоку.
PERT или Program Evaluation and Review Technique была разработана в 50-е годы XX века в ВМС США.
Для оценки задачи по схеме представляются три числа:
O: предельно оптимистическая оценка. Задача может быть выполнена в эти сроки только если все без исключения пройдет как задумано.
N: номинальная и наиболее вероятная оценка.
P: крайне пессимистическая оценка, в которую заложены все неприятности, которые могут произойти во время выполнения задачи.
По этим трем оценкам ожидаемая продолжительность задачи описывается следующей формулой:
А среднеквадратическое отклонение, фактически являющееся мерой неопределенности задачи вычисляется по формуле:
Таким образом задачу, которую обсуждали Питер и Майк можно оценить в:
Как видим данный метод заставляет оценивающего задумываться не только о позитивных, но и негативных сценариях и даже использует элемент статистики. Но, к сожалению, не отвечает на все поставленные вопросы и к тому же весьма усложняет сам процесс оценки.
Story Points
Что же такое Story Points и как они помогают оценивать задачи? Весьма коротко и понятно об этой технике рассказывает в своем видео Майк Кон евангелист Agile и CEO компании Mountain Goat Software.
Что если вместо оценки времени, которое потребуется для выполнение задачи мы будем оценивать усилия, необходимые на решение этой задачи? Для этого мы примем шкалу оценки и расставим на ней задачи, требующие оценки.
При этом в оценку усилий следует заложить все факторы, которые могут повлиять на нее:
Хочется подчеркнуть два важных аспекта метода Story Points, которые позволяют ему решать проблемы, которые мы обсудили на предыдущей странице:
Относительность оценки
Задачи оцениваются относительно друг друга, таким образом возникает универсальная шкала оценки, не зависящая от опыта оценивающего. Даже если у задачи сменится ответственный — ее оценка останется неизменной, достаточно новые задачи оценивать относительно этой шкалы.
Замена часов на абстрактные баллы
Так мы снимаем с оценивающего необходимость оценивать задачу в часах. Вместо этого он оценивает ее в баллах, таким образом мы убираем противоречия в восприятии оценки разработчиком и менеджером. Более того, теперь отвлекающие факторы и форс-мажорные обстоятельства никак не повлияют на оценку, ведь они не меняют усилия, требующиеся для решения задачи!
Числа Фибоначчи, майки и собаки
Да, да майки и собаки. Для оценки задач можно использовать любую шкалу. Самой распространенной являются числа Фибоначчи, это понятные числовые значения к тому же с приятным бонусом: элементы этой последовательности хорошо отражают рост неопределенности, который возникает с ростом сложности оцениваемой задачи.
Тем не менее некоторые команды используют альтернативную шкалу оценки. Самые распространенные это оценка в майках и собаках, когда сложность задачи указывается в размере майки (S, M, L, XL) или в породе собаки (Чихуахуа, Мопс, Дог). Таким образом команды еще больше абстрагируются от численного представления оценки, которое в некоторых случаях так и подмывает перевести в оценку временную.
 | |
Оценка в команде
Чем отличается оценка в команде от индивидуальной оценки?
Почему важно привлекать всю команду к выставлению оценок?
Одна из самых больших ошибок, которые можно допустить при оценке задач — сделать ее самостоятельно и не спросить мнения членов команды. Может быть у них есть свое мнение по этому поводу? Хотите добавить поддержку нового браузера? А что по этому поводу думают QA?
Люди — самый важный ресурс оценки. Они могут увидеть то, что не видите Вы.
Но как проводить оценку командой? Просто выкрикивать оценки не очень эффективно, к тому же услышав вашу оценку другой член команды может передумать и не станет озвучивать свою.
Покер планирования
В 2002 году Джеймс Греннинг описал метод, который впоследствии стал настолько популярным, что теперь Вы даже можете купить настоящие колоды карт для покера планирования. Или воспользоваться одним из онлайн сервисов для проведения сеанса;
Суть метода заключается в следующем: всем участникам команды раздаются карты с числами из шкалы оценки. Затем выбирается задача и обсуждаются требования к ней. После обсуждения модератор просит всех членов команды выбрать карту и положить ее «рубашкой» вверх. Затем модератор дает сигнал показать карты.
Если оценки участников согласуются – оценка фиксируется, в противном случае карты возвращаются в руку, а члены команды продолжают обсуждение задачи. Хорошая идея — спросить у выставивших разные оценки: «Какие сложности ты видишь в этой задаче?» или «Почему ты считаешь, что во время реализации не возникнет никаких проблем?».
Стоит отметить, что согласие не должно быть абсолютным. Вы можете условиться, что набор соседних оценок так же считается согласием.
Альтернативы
Как и самого метода оценки, так и у покера планирования есть альтернативы. Я вкратце расскажу о одной из них.
Этот блок можно пропустить и перейти сразу к следующей странице.
Об этом методе я узнал все из той же книги Роберта Мартина «Идеальный программист. Суть метода заключается в том, что все задачи записываются на картах без каких либо оценок. Экспертная группа стоит возле окна или стены, на которой карты распределены случайным образом. Участники не говорят между собой — они просто сортируют карты. Карты задач, требующих больше усилий, перемещаются вниз, требующих меньше усилий смещаются наверх.
Любой участник группы может в любой момент переместить любую карту, даже если она уже была перемещена другим участником. Карты перемещенные несколько раз, откладываются в сторону для обсуждения. Со временем безмолвная сортировка завершается и начинается обсуждение.
На следующем этапе между картами рисуются линии, представляющие усилия, требующиеся для реализации задач.
Стоит отметить, что подход с использованием таких категорий или „корзин“ можно использовать и в классическом покере планирования.
Планирование проекта
Сколько часов в Story Point’e и как мне построить диаграмму Ганта?
Итак, мы оценили наш бэклог задач, но на Story Point’ах план проекта не построишь. Часто у руководителя проекта возникает вопрос: „Как перевести SP в часы?“.
Короткий ответ на этот вопрос: „Никак“.
Конечно, можно с секундомером ходить за разработчиками и записывать время, которое им понадобилось на решение задачи, а затем вывести эту информация в виде графика. Тогда у вас получится классический „колокол“, как на примере в блоке ниже. Как мы видим на первом рисунке – некоторые задачи занимают чуть больше времени, некоторые чуть меньше, но в целом все значение будут соответствовать некоторому нормальному распределению.
То же самое справедливо и для задач в 2 SP и это показано на втором рисунке. Заметили, что „хвосты“ графиков пересекаются? Да, некоторые задачи оцененные в 1 SP могут потребовать больше усилие чем самые простые из оцененных в 2 SP. В конце концов ни одна команда еще не научилась оценивать идеально. Кроме того переводя SP в часы мы возвращаемся к старым граблям, то, сколько времени понадобится разработчику для решения конкретной задачи сильно зависит от самого разработчика.
| |
Но что же делать, мы не можем полностью отказаться от планирования. К счастью, для этого нам не нужно переводить каждый Story Point в часы. Что действительно важно, так это сколько SP команда разработки может „закрыть“ за спринт (итерацию, релиз).
Собирая данные о скорости команды можно получить достаточно точные данные для долгосрочного планирования проекта. К тому же не забывайте про закон больших чисел, погрешности оценок взаимно компенсируются, это касается как задач, так и итераций. Стоит отметить, что это немного оптимистично, т.к. погрешности обычно связаны с недооценкой, а не переоценкой. Но ничто не идеально.
Скорость (или Velocity) это мощный инструмент планирования и главная метрика команды разработки. Команда должна работать над постоянным улучшением, чтобы повысить свою скорость. Не стоит так же забывать, что скорость это производная величина от SP и поэтому тоже относительна. Нельзя сравнивать две команды друг с другом, команда соревнуется сама с собой.
Практика
Какие нюансы нужно знать?
Каких ошибок можно избежать?
В заключении хочется собрать несколько советов для тех, кто в первый раз решил попробовать описанные методики в своей работе.
Это ваш первый покер планирования и команда не понимает относительно чего оценивать новые задачи. Соберите несколько уже реализованных задач, в идеале хорошо всем знакомых или типовых и оцените их сложность относительно друг друга. Используйте эти задачи для оценки новых.
У вас новый проект и нет реализованных задач? Попробуйте воспользоваться афинной оценкой, которая описана выше, и распределите задачи по шкале оценок.
Не усредняйте оценки
Но, как и говорилось выше, вы всегда можете договориться о том, что близкие друг к другу оценки не будут являться поводом для дальнейшего обсуждения.
Даже если в ходе реализации вы поняли, что ошиблись при планировании, оставьте оценку неизменной. Вы будете ошибаться и в будущем, причем в обе стороны. Дайте этим ошибкам компенсировать друг друга, не вмешивайтесь в процесс.
Я сталкивался с разными подходами к оценке багов. Некоторые команды оценивают все баги, кроме тех, что возникли в ходе реализации новых задач в итерации. Некоторые не оценивают баги, обосновывая это тем, что скорость команды должна показывать новую ценность, которая добавляется в продукт, и исправление багов не должно влиять на рост этого показателя.
Какой бы подход вы выбрали оставайтесь последовательными. Информация об исторический скорости команды не должна пострадать от применения разных подходов к оценке.
Еще один вопрос, который не имеет однозначного ответа. Кто-то считает, что не бывает задач, не требующих усилий. Другие отвечают им, что назначение баллов простейшим задачкам ведет к необоснованному росту графика скорости команды.
Вы можете ввести оценку в 1/2 балла для таких задач и ретроспективно отслеживать не превышает ли доля таких задач разумные пределы. Но главный совет все тот же, оставайтесь последовательными в своих решениях.
Переоценка незаконченных задач между итерациями
Не всегда удается закончить задачу в одну итерацию, даже если это планировалось изначально. Тем не менее не стоит изменять ее оценку при планировании следующей итерации исходя из количества оставшейся работы. Учитывайте это при планировании, но оставьте оценку неизменной для истории.
Если вы еще не проводите ретроспективы – пора начать! Это отличный командный инструмент повышения скорости и слаженности команды. Впрочем это отдельная тема.
В ходе ваших ретроспектив пройдитесь по оценкам, которые были сделаны при планировании итерации и обсудите не случилось ли больших отклонений между ожиданиями и реальностью.
Можно так же достать из истории несколько задач с одинаковыми оценками и обсудить действительно ли все эти истории потребовали одинакового количества усилий.
Если ваша система управления задачами не поддерживает оценки и не считает скорость команды автоматически, значит вам придется делать это вручную. Как Вы, наверняка, уже догадались исторические данные важный инструмент совершенствования ваших оценок.
Оценка задач в Story Points для больших и молодых команд разработки
У разработчиков, которые давно работают вместе, обычно нет проблем в оценке задач. В таких командах процессы настроены, а люди хорошо понимают друг друга, и любому новичку, попавшему в такую команду, быстро объяснят, научат и покажут, как работать в команде.
Но на старте проекта (или при реформировании бизнес юнита) часто собираются новые команды. И в таких новых командах жизненно необходимо быстро и правильно построить методологию оценки задач; в ином случае, процесс планирования будет бесполезным, и даже примерно предсказать, когда будет сделана фича, станет невозможно.
В этой статье я расскажу, к чему пришел за годы практической разработки и управления командами. Естественно, это не правда в последней инстанции, а лишь то, что успешно работало у меня.
Мой опыт управления командами разработки
Я в разработке уже более 10 лет, за это время поменял несколько ролей. Работал и без процессов совершенно, работал работником, которому объясняют, как работать, работал в команде, где помогал настраивать процессы, и, наконец, помогал настраивать процессы сразу нескольким десяткам команд. Сегодня я — Android-лид в Кошельке, где продолжаю настраивать процессы.
Очень редко получается, что команда несколько лет подряд успешно работает одинаковым составом по одинаковым процессам. Постоянно что-то меняется: люди, их роли, проекты и так далее.
Новая команда, старые трудности
Команда Кошелька сейчас активно расширяется, стало больше людей и больше задач. Много новеньких пришло за последние 4 месяца. Как следствие, люди плохо знают друг друга и проект. Поэтому задачи, которые изначально кажутся небольшими и лёгкими, выполняются долго. Возникает вопрос, как прогнозировать разработку в таких условиях?
Необходимая теория: Оценка задач и её точность
Самый ценный и расходуемый ресурс во время разработки — время. Точно сказать, сколько уйдет времени на одну задачу, невозможно, пока она не будет выполнена. Поэтому мы оцениваем задачу приблизительно.
Точность зависит от знаний оценивающего о задаче и контексте, в котором она должна выполняться. Такие знания можно получить в результате предварительного анализа. Чем глубже анализ, тем более точную оценку мы сможем дать.
Таким образом, оценка — это предсказание, сколько будет стоить решение задачи. А нужна она, чтобы сформировать ожидания, когда будет получен результат.
От чего зависит оценка?
От ответов на два главных вопроса:
Ответ на вопрос «что?» формулируется при составлении задачи. Это смысл задачи, проблема, которую она должна решить. Перед началом работы нужно убедиться, что основные требования необходимы, достаточны и понятны.
Ответ на второй вопрос сложнее. Он зависит как от проблемы, которую нужно решить, так и от контекста, в котором её нужно решать. Контекст — это текущее состояние проекта. И он меняется с каждым новым изменением в коде проекта.
Решение почти любой задачи можно разбить на такие этапы:
Очевидно, что чем дальше мы продвинулись в решении, тем более точную оценку мы можем дать. Также очевидно, что оценивать сложность выполнения задачи уже во время тестирования бесполезно. Обычно адекватно оценить задачу можно во время начала этапа проектирования.
Оценка по времени
Сначала кажется, что время это очевидная мера оценки, ведь мы тратим на разработку именно часы и дни.
Плюс такого способа в том, что такая оценка всем понятна. Если задачу оценили в 8 часов, то её решение ожидается через 1 рабочий день, а за спринт ожидается решение 10 задач такого размера.
Минус в том, что в этом варианте невозможно учесть увеличение погрешности оценки с увеличением размера задачи. Ожидается, что 10 задач по 8 часов будут сделаны за то же время, что и 1 задача на 80 часов. Но более объемная задача, как правило, имеет больше подводных камней, которые не видны на ранних этапах проектирования.
Также не стоит забывать про разный уровень разработчиков в команде. Например, Senior сможет оценить и сделать задачу за 8 часов, тогда как Junior ту же задачу может оценить и сделать за 40 часов. Как следствие, оценка во времени актуальна, только если задачу будет делать тот, кто оценивал. Это может сработать, если в команде был, есть и будет один разработчик. Если разработчиков хотя бы два, то рассчитать среднюю производительность команды в часах будет трудно.
Как правило при оценке все забывают учитывать время на рутинные задачи, создание задачи, создание пулл-реквеста, время на ревью и исправление замечаний. А так как в оценке указано конкретное время, то и выполнение задачи ожидается именно за это время.
На практике задача, оценённая в часах, крайне редко выполняется вовремя.
Оценка в Story Point
Вместо оценки в часах и днях хорошо подходит оценка объема задач в относительных величинах. Такие величины называются story point. Ниже я расскажу о двух подходах к восприятию story points и оценке в них.
SP с эталонной задачей
Чтобы вся команда одинаково понимала значение единицы SP, можно придумать и описать эталонную задачу в 1 story point. Каждый сравнивает свою задачу с этим эталоном и дает оценку в зависимости от того, насколько она больше или меньше эталона.
Какие проблемы?
Проблем у такого подхода несколько:
Изменения. Контекст постоянно меняется, поэтому эталонная задача может быстро потерять актуальность. Со временем команда перестанет понимать, почему эта задача была когда-то эталонной.
Кросс-платформенная разработка. Если в команде есть несколько платформ, например, iOS и Android, то каждая платформа выбирает себе свою эталонную задачу. Так оценка перестаёт быть единой для всех, а члены команды, относящиеся одновременно к нескольким платформам (например, QA или аналитики), могут запутаться в понимании значения 1 SP.
Не учитывается погрешность оценки. Эталонная задача не учитывает прогрессию возрастания сложности. Если хотим оценить задачу в 3SP, то это вроде бы значит, что оцениваемая задача в 3 раза объёмнее эталонной. Это то же самое, что сделать 3 задачи по 1SP? На практике — нет. Чем сложнее задача, тем менее вероятно, что мы её оценим правильно.
SP со временем
Чтобы учесть проблемы предыдущих способов оценки, можно использовать story points с оценкой по времени. Важно понимать, что мы используем не просто время, а восприятие времени. То есть оцениваем не сколько часов будет выполняться конкретная задача, а за сколько часов в идеальном мире её можно выполнить.
Чтобы понять, за какое время мы сделаем задачу или сколько SP мы сделаем за спринт, нужно посчитать, сколько в среднем SP-ов мы делали в предыдущих спринтах. Так, если в предыдущих спринтах мы делали по 7SP, а в спринте 10 рабочих дней, то 1 SP — это 1,4 дня, а если по 14 SP, то 1 SP — это 0,7 дня.
Чтобы с чего-то начать, можно использовать такую шкалу:
0.5 SP — менее, чем за день
1 SP — до 2 дней
2 SP — около недели
3 SP — около одного спринта
5 SP — можно сделать за спринт, если всё будет идеально и никто не будет отвлекать
8 SP — 2 спринта
Задачи 5 и 8 SP в спринт брать нельзя, их нужно декомпозировать на более мелкие, чтобы снизить погрешность оценки. Задачи на 2 и 3 SP достаточно большие, их сложно сделать на одном дыхании, их лучше тоже декомпозировать. Но это не всегда оправданно или возможно.
Задачи с оценкой в 0.5 и 1 SP должны занимать основную часть спринта. Это довольно точные оценки, по ним всегда будет, что сказать на стендапе. Задач меньше, чем 0.5 SP, просто не бывает: всегда требуется время на описание задачи, на мерж-реквест, на тестирование и т.д.
Важно помнить, что в приведенной выше шкале время используется только для того, чтобы оценить, сколько SP стоит задача, но не за сколько она реально будет сделана. Как следствие, чтобы понять, сколько задач будет сделано за спринт, нужно смотреть, сколько в среднем среднем SP делали в предыдущих спринтах.
Какие проблемы?
Минусы такого подхода в том, что при оценке учитывается время. А это значит, что Junior и Senior оценят задачу по-разному, так как им нужно разное время на её выполнение. Эта проблема решается усреднением оценки по команде — например, с помощью покер-планирования.
При оценке в SP с использованием времени важно не учитывать, кто именно будет делать задачу. Иначе возникает соблазн включить в оценку индивидуальные особенности разработчика: его “синьористость”, отпуск, вынужденные выходные. Это повлияет на среднюю ёмкость спринта, а SP превратятся из оценки объёма задачи в оценку работы разработчика.
Текущий курс — стабилизация процесса
Как я уже писал, моя команда в Кошельке — новая, кроссплатформенная и большая. У нас объёмные и сложные задачи, нам нужно их быстро решать.
Уже несколько месяцев мы используем подход с оценкой в SP с привязкой ко времени. А последние несколько спринтов нам удаётся сжигать SP практически в ноль.
Мы следим за статистикой, мы обсуждаем то, что мы делаем, мы пытаемся лучше понимать друг друга. И мы становимся лучше с каждой итерацией.