Всем привет! Я достаточно давно в разработке и мне приходилось видеть разные вариации гибких методологий управления проектами. Чаще всего я встречал такую картину: вроде есть спринты, дейли, иногда даже демо, отчеты, ретро, но все равно, получив набор фичей от бизнеса, команда не могла достаточно быстро сказать, сколько времени ей потребуется на реализацию. Со временем я пришел к своей спринтовой модели, которая позволяет моей команде довольно точно и быстро давать оценку трудозатрат, что в итоге приводит к успешному попаданию в дату релиза.
Дисклеймер
Я намеренно называю свою модель “спринтовая модель”, чтобы избежать лишних споров по поводу того, каким должен или не должен быть скрам, аджайл и т.д. Я просто описываю получившуюся опытным путем модель в своей команде, которая работает, и абсолютно не претендую на какую-либо истину в методологиях разработки.
Некоторые определения
Команда - это все участники, которые работают над продуктом (менеджер проекта, владелец продукта, аналитики, дизайнеры, разработчики, тестировщики, технические писатели и другие).
Подкоманда - группа, которая сформирована по определенной специфике задач (Android, iOS платформы или продуктовая вертикаль).
Фича - большая задача от бизнеса. Как правило, результатом выполнения фичи является новый функционал.
Задача - часть фичи, техническая задача или баг, которые выполняются определенной подкомандой.
Зачем переходить на спринты?
Спринты помогли мне решить две важные проблемы:
Синхронизация всей команды и совместное планирование задач на спринт. Работа над фичей может занимать 2 недели по абсолютной величине, но в виду ряда ограничений, фича может быть в работе 2 месяца и это нормально. Такие фичи делятся на задачи, которые могут выполняться параллельно, т.к. выполняются разными участниками команды. И как раз на планировании команда получает информацию о текущем состоянии фичей (какие задачи уже выполнены, какие возникли проблемы, как изменились приоритеты, какой получили фидбэк), а уже исходя из этого состояния, команда принимает решение, какие задачи следует взять в следующий спринт.
Предоставление бизнесу информации о том, какой объем работы может выполнить эта команда (именно эта, а не какая-то абстрактная команда!) за спринт. Без понимания какой объем работы может выполнить команда, невозможно что-либо планировать в долгосрочной перспективе. Бизнес обычно дает задачи на полгода или год вперед, и без понимания скорости работы команды практически нереально выйти в намеченные даты без переработок и/или недоработок (имею ввиду сырые недоделки, а не ограниченные функционалом фичи).
Также спринты позволяют проводить регулярные выпуски продукта с новым функционалом. Но я решил отвязать выпуски от спринтов: релиз и спринт - это две независимые сущности. Я пришел к такому выводу после попыток успеть за спринт подготовить релиз, которые в большинстве случаев проваливались или были ненадлежащего качества. Наверняка вы слышали о таких вещах как: фича-фриз, фиксированное время тестирования и исправления ошибок. У меня это все никогда не работало: разработчики залезают за фича-фриз, QA не успевает, время на баги и тех долг постоянно забирается на фичи. Поэтому для меня спринты - это про планирование и оценку объема работ, а релиз - это релиз. Мне нравится концепция релизного поезда (где-то на Хабре была хорошая статья про релизный поезд от ребят из Яндекса). Если сказать в двух словах, то релизный поезд - это регулярное фиксированное время выпуска новой версии продукта. Все, что успели разработать, протестировать и добавить в релизную ветку до отправления поезда, - попадает в релиз. Рекомендую автоматизировать отправку поезда, чтобы не было соблазна “задержать” его. И т.к. релиз больше не зависит от спринтов и планирования, становится очень просто регулировать TTM (time to market), хоть два раза в день. Ладно, вернемся к планированию и спринтам.
Описание модели
Для меня спринт - это просто итерация, которая имеет дату начала и окончания, т.е. единственным неотъемлемым атрибутом спринта является планирование. Все остальное: дейли, демо и т.д. - это, скажем так, “обвесы” спринта, которые могут быть, а могут и не быть, или присутствовать в измененном виде. Спринты идут сами по себе один за другим, тут все просто. А вот за кулисами спринтов постоянно ведется большая работа по подготовке фичи для взятия в спринт. Каждая фича проходит несколько этапов, периодически попадая в спринт.
Этапы такие:
Работа над бэклогом (формирование и приоритезация). Сюда входят бизнес фичи, баги и технические задачи (тех долг, развитие продукта).
Обсуждение фичей (грумминги). На таких встречах бизнес рассказывает, чего он хочет.
Оценка сложности фичей в story points.
Оценка времени на системный анализ и составление тест-кейсов в человеко-часах.
Декомпозиция фичей на задачи и оценка задач в человеко-часах.
На схеме ниже я попытался отобразить эту идею. По мере прохождения подготовительных этапов фича попадает в спринты 3 и 5. А в других спринтах ведется работа над другими фичами, которые уже были подготовлены.
Этап 1 - Работа над бэклогом
Четкий приоритезированный бэклог - это залог постоянной, предсказуемой и автономной работы команды без простоев. Над бэклогом нужно регулярно работать: удалять ненужное, актуализировать, приоритезировать. Бэклог должен состоять из фичей, технических задач и багов.
Если ваш бэклог - это куча, в которую сваливают всё подряд всем, кому не лень. То нужно сесть с руководителем проекта или владельцем продукта и приоритезировать часть бэклога, чтобы задачи, которые нужно сделать в следующие 1-2 спринта, “всплыли” наверх бэклога. В дальнейшем вам потребуется организовать работу с бэклогом: кто, какие и с каким приоритетом может заводить задачи в бэклог, чтобы, например, завхоз не мог завести задачу с приоритетом critical на тот функционал, который, как ему кажется, был бы killer-фичей.
Этап 2 - Обсуждение фичей
Провести несколько этапов обсуждения, пока не станет понятно, что нужно сделать. В подобных обсуждениях участвует вся команда, у всех должно появиться понимание объема работы в фиче. Результатом этих обсуждений должна стать возможность провести оценку сложности фичи. Обычно для оценки сложности достаточно иметь общее представление о требуемом бизнес-процессе, системах, которые будут задействованы в фиче, участниках, которые будут работать над фичей. Не нужно сильно углубляться - все детали будут выясняться позже, пока нам нужна только общая картина.
Этап 3 - Оценка сложности фичей в story points
Оценивать с точки зрения сложности нужно только бизнес-фичи. Каждая подкоманда должна оценить, насколько сложно будет сделать эту фичу. Существуют разные способы оценки в Story Points, я использую эталонный способ: выбирается любая довольно простая фича в качестве эталонной, где требуется участие всей команды (!), этой фиче назначается оценка, например 3 SP (это может быть и 5, и 10 SP, неважно). И относительно этой эталонной фичи оценивается сложность других фичей. Я оцениваю все фичи относительно этой первой эталонной (во всех последующих спринтах одна и та же эталонная фича).
В результате получается оценка сложности фичей в SP, например:
Самое главное то, что оценка сложности должна производиться достаточно быстро. Обычно, между появлением бизнес-требования и оценкой сложности должно пройти не больше недели. Зачем это нужно, а также о некоторых нюансах оценки сложности, расскажу ниже.
Этап 4 - Оценка времени на системный анализ и составление тест-кейсов в человеко-часах
Теперь нужно трансформировать бизнес-модель фичи в техническую модель. Для этого мы проводим системный анализ, результатом которого является техническая документация и набор тест-кейсов. Для меня наличие двух этих артефактов является критерием взятия задачи в разработку (definition of ready). Системный анализ требует времени, и пока он не выполнен, брать задачу в разработку не стоит. Поэтому на этом этапе необходимо оценить трудозатраты на системный анализ. Оценка производится уже в человеко-часах. Системный анализ может проводиться разработчиками, системными аналитиками, даже QA специалистами. Все зависит от того, какие роли представлены в команде, но в любом случае анализ сделать кто-то должен.
Мне приходилось работать в условиях, когда этот этап “опускали” и сразу брали задачу в разработку, а все детали прояснялись по ходу. Как правило, это ни к чему хорошему не приводило: сроки постоянно съезжали, обозримого предела разрабатываемой функциональности нет, много ценных деталей обсуждается в переписке, и по итогу у фичи нет документации. В общем, мое мнение такое, что лучше выделить время на анализ фичи до взятия её в работу. Оно, конечно, и при наличии системного анализа всего не предусмотришь, и будут доработки, но эти доработки, как правило, небольшие и “укладываются” в заложенные риски.
Это первый этап, на котором у фичи появляются задачи с оценкой в человеко-часах (задачи на анализ и составление тест-кейсов). С этого момента фича уже может быть запланирована в спринт (пока только на системный анализ).
Оценка в часах должна быть выполнена до (!) встречи планирования. Поэтому важно, чтобы все обсуждения и оценка сложности были выполнены заблаговременно. Обычно если за Х дней до планирования у фичи нет оценки сложности, то фича точно не будет взята в ближайший спринт.
Этап 5 - Декомпозиция фичей на задачи и оценка задач в человеко-часах.
На этом этапе каждая подкоманда погружается в документацию и тест-кейсы и оценивает свой объем работ. Я с командой провожу декомпозицию фичи на задачи и оценку каждой задачи в часах (тут используется коэффициент: скорость разработки).
Я пришел к выводу, что оценивать нужно только те задачи, которые относятся к фичам. Оценивать тех долг и баги особо не имеет смысла - это бизнесу не интересно. Если техническая задача или баг очень важны для бизнеса, и требуется спланировать работу над ними, то оценивать их тоже нужно. Как выделять время на тех долг и баги описано ниже.
Здесь тоже: оценка в часах должна быть выполнена до (!) встречи планирования. Поэтому важно, чтобы системный анализ и составление тест-кейсов были выполнены заблаговременно. Обычно если за Х дней до планирования у фичи нет тест-кейсов (не выполнен критерий definition of ready), то фича точно не будет взята в ближайший спринт.
Коэффициент разработки и риски
Разработчик (это применимо не только к разработчикам) не может разрабатывать 8 часов в день. Есть много отвлекающих факторов: консультации других участников команды, обсуждения, код-ревью, срочные дела и т.д. А бизнес имеет тенденцию запихивать в спринт задачи под завязку. Бизнес уверен, что если дать разработчику две задачи по 4 часа, то он сделает их за день. Поэтому лучше перед тем, как отдать оценку менеджеру проекта, разделить ее на этот коэффициент. Этот коэффициент прячет за собой эту закулисную работу по подготовке задачи в спринт. Коэффициент разработки может варьироваться от 0.3 до 0.8, в зависимости от сбалансированности и зрелости команды. Если команда имеет четкие зоны ответственности, роли, обкатанный процесс разработки, общие правила написания кода и т.д., то такая команда будет иметь высокий коэффициент разработки. По этому показателю я определяю, насколько оптимально настроен наш процесс разработки и не растрачивается ли драгоценное время разработчика.
Рекомендую начать с коэффициента в 0.5.
Следует учесть, что в этом коэффициенте не учитываются риски, например, что-то не предусмотрели и на задачу потребовалось больше времени. Для рисков нужен отдельный коэффициент. Обычно это 30-50% времени от всей фичи.
После данного этапа можно рассчитать суммарную оценку в часах. Для этого оценки подкоманд просто складываются и прибавляется время на риски и доработки. На самом планировании задачи можно будет распараллелить и сократить фактическое время работы над фичей.
Планирование спринта
На планировании команда должна принять во внимание задачи, которые не успели сделать за прошедший спринт, а также задачи из фичей, которые прошли подготовительные этапы и готовы к работе, и наполнить новый спринт согласно приоритетов и доступных ресурсов. Планирование - это не место для обсуждений реализации, споров и т.д. Здесь просто наполняются человеко-часы на всю команду на весь спринт.
Планировать спринт хорошо на диаграмме Ганта. На диаграмме сразу видно, какие задачи можно делать параллельно, а также увидеть недопустимые пересечения задач. У разработки почти всегда есть окна между фичами, например, пока идёт тестирование. Эти окна заполняются задачами из технического бэклога и багами. Если окон нет (слишком много фичей), то необходимо жестко зафиксировать время в спринте на баги и тех задачи. Например, 20% времени на баги, 10% на тех задачи и 70% на фичи. Такое время нужно выделять в каждом спринте, иначе проект скатится. Бизнес будет против, но вы отбивайте свои 30%, как только можете. Можно планировать рефакторинг внутри фичи, чтобы не было заметно выделения отдельного времени на тех задачи, если уж сильно приперли.
Я не трачу время на оценку тех задач и багов, если этого не требует бизнес. Главное, чтобы всегда был приоритезированный список таких задач, чтобы можно было взять оттуда задачу, как только появилось окно. А в спринте я просто заполняю окна или выделяю фиксированное количество времени для работы над этими задачами, если фичей много. Это как в буддизме: важно, не закончить, а просто всегда уделять этому время.
Например, спринт в 1 неделю может выглядеть так (я для примера заполнил окна разработки, а для остальных распланированы только работы над фичами).
Еще раз, главное правило планирования, которое поможет провести его конструктивно и уложиться в тайминг встречи:
В планировании могут участвовать только фичи, у которых есть задачи, оцененные в часах. Т.е. владелец продукта выбирает только те фичи, которые имеют оценку сложности, декомпозированы на задачи, которые оценены в часах. Если эти критерии не выполнены - не берите задачу в спринт. Вас будут упрашивать взять задачу без оценки, объяснять почему не успели передать фичу на оценку и т.д. - не берите этого кота в мешке, потом будете виноваты именно вы, что взяли в спринт задачу без предварительного анализа и оценки. У меня был прОдукт, который игнорировал обсуждения, не отвечал на вопросы, а потом считал своим долгом приходить на планирование и рассказывать команде, что он хотел сделать в своей фиче. Мы должны были с его слов оценить и взять в спринт на месте.
Итоги спринта
Например, в ходе спринта была выполнена фича на 3 SP, начали работу над второй фичей, также сделали ряд багов и задач из тех долга. Но в зачет спринта пойдет только выполненная фича: 3 SP. Это главный итог спринта: 3 SP. Не нужно как-то учитывать часть выполненной работы по второй фиче, она пойдет в зачет того спринта, в котором она будет выполнена.
Например, мы провели 6 спринтов:
Теперь можно посчитать среднее кол-во SP, которые реализуется за спринт. 4.5 SP за спринт в среднем. Это значит, что данная команда, при всех ее за и против, при отвлечении на консультации, обсуждения, при работе над багами, тех долгом и т.д. делает в среднем за спринт 4.5 SP бизнес-фич. Теперь, когда бизнес получит от этой же команды набор фичей с оценками в SP, бизнес довольно точно будет понимать, какие фичи ему можно взять, чтобы команда успела за спринт, или через сколько спринтов команда закончит работу над большой фичей. Для достаточно точного планирования это все, что нужно знать бизнесу: оценка фичей в SP и среднее кол-во SP, выполняемое за спринт.
У вас будут нулевые спринты или спринты с совсем маленьким количеством выполненных SP, вы будете ошибаться в оценках, например, задача средней сложности упрется в какую-то большую проблему, которую изначально не увидели, или наоборот, задача окажется слишком переоцененной, неважно, менять оценку в SP нельзя, а в зачет фича пойдет в тот спринт, в котором работа над ней будет закончена. Законы больших чисел все уравняют. Чем больше итераций, тем точнее средний объем выполняемых фичей за спринт.
Метрики спринта
1 Скорость разработки фичей - среднее количество Story Points за спринт.
Это главная метрика. С помощью нее можно быстро оценить фичу и сказать ориентировочный срок, когда фича будет готова, без глубокого погружения в фичу. Возвращаясь к нашему примеру, пусть вам пришла фича, вы оценили её в 18 SP. С учетом скорости 4.5 SP за спринт вам понадобится около пяти спринтов, чтобы сделать фичу. Таким образом у вас будет на что опереться при планировании работ, а выпустить фичу удастся в срок в большинстве случаев. Также, если вы понимаете, что фича не будет готова к желаемому бизнесом сроку, например, эту фичу с 18 SP надо сделать за 3 спринта, можно предложить альтернативные варианты, например, часть некритичного функционала фичи отложить до следующего релиза.
В книге “Чистый Agile” Роберт Мартин пишет, что цель спринта не выполнить все взятые задачи, а собрать метрику о ходе работ в спринте. И я с этим согласен. В долгосрочной перспективе эти метрики помогут прогнозировать сроки выполнения поставленных задач, а также уберегут вас от работы по ночам и выходным.
2 Наполнение спринта фичами
В моей схеме, если оценивать только фичи, посчитать наполнение спринта фичами очень просто.
Например, в недельный спринт мы взяли 20 часов задач фичей. Наполнение = 20/40 = 0.5. Это маловато. Надо разбираться, почему мы не можем взять больше фичей в спринт. А если взяли слишком много, то стоит не забывать про свои 20-30% от спринта для работы над тех долгом и фикса багов.
3 Коэффициент разработки
Показывает, насколько сбалансированная команда, как разработчик работает над фичей. Этот коэффициент будет изменяться со временем, в идеале он должен расти, что будет говорить о стабильности процесса и зрелости команды. В начале стоит начать с коэффициента 0.5. Т.е. разработчики оценили фичу в 10 часов, а заложили 20. Плановое время считается так:
Взяли в спринт. Разработчик справился за 15 часов, т.е. на 25% быстрее, чем запланировали, фактически после спринта коэффициент получился равен = 0,67. Фактический коэффициент считается так:
После спринта я считаю фактический коэффициент команды разработки. Если он растет, значит команда зреет, и мы можем брать в спринт больше фичей. А если коэффициент падает, значит в команде растет беспорядок (плохая проработка задач, отсутствие документации, отсутствие некоторых ролей, точек принятия решений и т.д.). Чтобы этот коэффициент удалось посчитать, мне было достаточно приучить команду следить за статусами задачи: в работе, завершено, вернули и т.д. Я не использую таймшиты или другие способы учета затраченного времени, чтобы не перегружать разработчиков ненужной и раздражающей работой. Я просто по отметкам времени изменения статуса задачи считаю фактическое время работы над задачей (в jira есть статус Time In, который считает время автоматически). В зачет идут только те задачи, которые выполнены за спринт. Если задача не выполнена, то, скорее всего, возникла какая-то проблема и оценка задачи уже не актуальна.
Основные правила подсчета:
Допустим:
Разработчик взял в работу задачу, которая относится к фиче и имеет оценку в часах.
Сценарий 1
Разработчик по ходу работы над фичей отвлекается на разные рабочие вопросы: код-ревью, совещания, консультации, участие в оценке других фичей и т.д. В таком случае задача все время висит в статусе "Идет работа", даже если в некоторые моменты разработчик не работает над ней по факту. После завершения работы над задачей она переходит в статус - готово к ревью. Это и есть сценарий, когда можно оценить коэффициент разработки. Даже если после ревью, тестирования или еще по каким-либо причинам задача вернулась в разработку - эти все последующие этапы отбрасываются и не оказывают влияния на расчет коэффициента. Я оцениваю первичную разработку.
Сценарий 2
Разработчику дали другую задачу или разработчик заболел. По текущей задаче работа приостановлена. Эта задача больше не участвует в расчете коэффициента, т.к. возвращение к приостановленной задаче потребует дополнительного времени на повторное погружение, таким образом, первичная оценка уже будет немного неточна, а коэффициент я считаю по первичной оценке.
Небольшой пример
Этап 1 - Бизнес принес две задачи: добавить in-app покупку и подписку, а также поменять лого.
Этап 2 - Обсуждаем задачи
Из описания ничего не понятно. Говорим бизнесу, что оценить не можем, нужно обсуждать. В принципе, оценить сложность можно прямо на обсуждении, если в ходе него все ключевые вопросы будут сняты.
В ходе обсуждения получили необходимые минимальные уточнения:
Этап 3 - Оценка сложности фичей
Теперь стало понятно, что хочет от нас бизнес. Можно оценить сложность фичей. Как я уже писал выше, я использую эталонный способ оценки.
Есть эталонная задача, которую мы приняли за 3 SP, все остальные задачи мы оцениваем относительно этой эталонной. Эталонная задача звучит так: экран обратной связи, на котором есть телефон и e-mail. Контакты приходят с бэкенда. По клику на телефон запускается dialer с введенным номером, по клику на e-mail - почтовое приложение с заполненным получателем. Работа всей команды (дизайнер должен нарисовать экран, бэкенд сделать endpoint, по которому возвращаются контакты, фронт должен все это собрать в мобильном приложении, QA составить тест-кейсы и протестировать) упакована в 3 SP. Эти 3 SP мы приняли произвольно, тут могло быть любое другое число, оно неважно. Важно оценивать другие задачи относительно этой. А сколько времени займет разработка этой фичи мы тоже не знаем - это тоже неважно.
Нужно поменять логотип в шапке приложения на главной странице. Формат 150 х 40. Монохромный. | Дизайн: 5 SP Фронт МП: 1 SP QA: 1 SP Итого: 5 SP В качестве итоговой оценки стоит взять максимальную из предложенных. Но, если оценки слишком сильно расходятся, возможно, появились дополнительные вопросы. Тогда нужно вернуться к бизнесу и уточнить все обнаруженные нюансы, а потом снова собраться на оценку. |
Нам нужно добавить оплату только через механизм Google Play. Необходимо добавить постоянную покупку "Убрать рекламу", и ежемесячную подписку, открывающая функционал синхронизации на разных устройствах. | Дизайн: 3 SP - один экран, где будут оба варианта покупки Бэкенд: 9 SP - 2 endpoint для фронта для отправки информации о покупке, 2 endpoint для фронта для валидации покупки. Плюс внутренняя логика проверки оплаты. Фронт МП: 7 SP - сверстать экран, прикрутить billing library, связать с нашим бэком. QA: 5 SP - ТК и тестирование фронта и бэка. Итого: 10 SP На общем обсуждении команда сошлась на 10 SP. Т.е. мы считаем, что эта задача в 3 раза сложнее (сложность должна быть линейной), чем эталонная задача. Но это не значит, что делать задачу с покупками мы будем в 3 раза дольше. |
Этап 4 - Оценка времени на системный анализ и составление тест-кейсов в человеко-часах.
Теперь можно оценить время на системный анализ и составление тест-кейсов.
Новый логотип | 4 часа - описывать особо нечего, кроме перечисления экранов, где должен появиться новый логотип. |
Покупки | 40 часов - нужно описать схему взаимодействия фронта и бэка, логику проверки на бэке, UI логику фронта. |
В следующий спринт можно взять 44 часа на проработку этих двух задач. По завершению системного анализа и написанию тест-кейсов можно провести декомпозицию и оценку на реализацию.
Спринт 1
В этом спринте мы успеем выполнить анализ обеих фич, но проработать и подготовить к следующему спринту сможем только фичу про логотип. Т.е. в спринт 2 возьмём в работу фичу с логотипом, а также выполним декомпозицию и оценку фичи с покупками, которую возьмём в спринте 3. Остальное время заполняли другими фичами, багами и тех долгом. Хочу отметить, что фичу с лого мы не стали делать в этом спринте, мы только провели необходимую подготовку этой фичи к следующему планированию. Итог спринта: 0 SP.
Пусть оценили фичи следующим образом:
Спринт 2
За второй спринт выполнили фичу с логотипом, а также подготовили фичу покупок для следующего планирования. Итог спринта: 5 SP.
Спринт 3
В спринте 3 закончили всю разработку по фиче покупок, но не успели протестировать. Итог спринта: 0 SP.
Спринт 4
В этом спринте проверили тестирование, исправили некоторые замечания, в общем, уложились и сделали фичу. Итог спринта: 10 SP.
7 Итоги.
В среднем получилось 3.75 SP за спринт. Такая маленькая скорость получилась из-за того, что у нас было всего 2 фичи, и команда занималась не бизнесовыми задачами, при адекватной нагрузке фичами скорость будет не такая маленькая. Кстати, если у вас маленькая скорость, то, возможно, вам дают мало фичей, тогда смотрите метрику “наполнение спринта фичами”.
Декомпозиция фичи
Почти любую фичу можно декомпозировать, но с одним условием: декомпозиция должна строиться по функционалу, а не подкоманде.
Например, рассмотрим, как декомпозировать фичу с покупками из предыдущего примера.
Есть соблазн декомпозировать фичу по подкомандам. Например, взять в спринт разработку бэкенда, успеть закончить разработку за спринт и с чистой совестью записать 9 SP за проделанную работу. Но в результате вы получите ошибочную среднюю скорость команды, которая была получена без учета совместных усилий на получение работоспособной фичи. Фичу можно делить на полноценные мини фичи, над которыми работает вся команда, и которые можно выпускать в продакшн. В этом примере декомпозировать по функционалу можно следующим образом: сначала реализовать только одноразовую покупку, а потом подписку. Эти мини фичи нужно оценивать как самостоятельные фичи, и, скорее всего, суммарная оценка будет немного больше, чем у целой фичи. Например, мини фичи мы оценили в 7 SP и 5 SP. Первая мини фича подготовит почву для второй, поэтому вторая фича будет "легче". При такой декомпозиции есть шанс успеть сделать первую мини фичу за спринт.
Выводы
Оценка в Story Points должна производиться быстро и только для фичей.
Оценка в Story Points тесно связана с командой и процессом, который выстроен в этой команде. В эту относительную оценку сложности упаковано все, что необходимо сделать для выпуска фичи.
Скорость команды, полученная из оценки в Story Points, помогает прогнозировать сроки реализации фичей.
Системный анализ и тест-кейсы - минимальные артефакты, необходимые для взятия фичи в работу.
Декомпозиция фичей на задачи и их оценка в часах необходимы для наполнения команды адекватным объемом работ, выстраивания параллельной работы и планирования хода работ.
Спринты нужны лишь для того, чтобы синхронизировать команду и собирать метрику.
Еще пара слов в заключении
Такая спринтовая модель сложилась лично у меня, у вас она тоже получится “своя”, потому что модель всегда должна адаптироваться под команду.
На этом все, спасибо.
Мой канал: https://t.me/ar2code
