Comments 14
Был продакт-оунером, все свои грабли прочитал в статье - спасибо :)
Как можно было бы скорректировать алгоритм под разработку нового продукта, а не поддержку старого?
P.s. Думаю, график точности неправильный. Возможно, следует переименовать усилия на горизонт, потому что точность (погрешность) не может снижаться.
Спасибо за вопрос!
Scrum требует, чтобы бизнес-ценность поставлялась стейкхолдерам после каждого спринта, даже самого первого. Отдельного этапа сбора требований и проектирования у нас нет. Скорее всего будет сессия по наполнению бэклога верхнеуровневыми требованиями, оценки их сложности и приоритизации. Но это занимает не более 1-2 дней. Поэтому для нового продукта алгоритмы и рекомендации остаются теми же, за исключением определения средней скорости для долгосрочного планирования. Лучший вариант - это поработать два спринта для нового продукта, получить значения фактической скорости и на основании нее строить долгосрочные планы. Значения фактической скорости команды всегда будут точнее любых прогнозов. Если возможности поработать два спринта нет, то в этом случае можно попробовать один из следующих вариантов:
Использовать исторические значения скорости команды с предыдущего проекта. Вариант применим, если команда с предыдущего проекта не менялась.
Сделать прогноз. Для этого можно провести “виртуальное” планирование спринта: мы примерно прикидываем, какой у нас будет состав команды и зовем этих людей на встречу. Вместе определяем предполагаемое капасити команды на спринт в идеальных часах. Далее берем элемент бэклога, бьем его на подзадачи, оцениваем в идеальных часах. Если команда считает, что у нее еще осталось капасити, берем следующий элемент бэклога и проводим те же самые операции. Так повторяем до тех пор, пока капасити по ощущениям команды не закончатся. После этого считаем сумму сторипоинтов для элементов бэклога, которые команда взяла в “виртуальный” спринт. Это и будет прогнозным значением средней скорости. Степень неопределенности в этом прогнозе очень высока. Майк Кон в этом случае рекомендует умножать прогнозную среднюю скорость на коэффициенты 0,6 - 1,6, чтобы получить достоверную оценку.
Насчет графика. Под точностью прогноза понимается расхождение прогноза со значениями, которые были получены в реальности. Рассмотрим две ситуации. В первой ситуации команда вкладывает меньше усилий на планировании и понимает, что не может назвать точную дату релиза. Поэтому вместо точной даты называет диапазон. В ходе работ команда сталкивается с непредвиденными ситуациями, которые увеличивают сроки работ. Но поскольку они назвали диапазон, то они попадают в него под самую верхнюю границу. Во второй ситуации команда вложила столько усилий на планировании, что считает, что предусмотрела все-все ситуации, которые могут случиться. И поэтому с уверенностью называет точную дату релиза. В ходе работы они сталкиваются с ситуациями, которые они не смогли предусмотреть не смотря на все усилия. В результате дата релиза значительно отличается от того, что они называли в момент планирования. Точность прогноза во второй ситуации упала, по сравнению с первой ситуацией не смотря на большее количество приложенных усилий на планировании.
во всех таких статьях рассказывается как за спринт сделать работающую фичу.
а как быть, если эту фичу нельзя за спринт осилить?
Например, нужно сделать большой кусок системы, или новую систему.
за 2 недели ничего не появится, а если появится, то потом можно будет выкинуть все и делать заново.
Это хороший вопрос. И частая ситуация в наших командах. Например, в этом спринте ребята хотели начать делать задачу, по которой бизнес-ценность пользователи смогли бы ощутить только через 3 спринта, то есть, через 9 (!!!) недель (у нас спринты по 3 недели). После того, как мы с ребятами провели встречу по разбиению задачи, оказалось, что бизнес-ценность можно начать поставлять уже после первого спринта.
Как этого добиться? Обратите внимание на 3 момента:
Во-первых. Если вы пишете требования в формате User Story, то посмотрите на сonditions of satisfaciton. Это условия, которые позволяют определить, что User Story выполнена. Например, у пользовательской истории “Как пользователь, я хочу авторизоваться на сайте, чтобы продолжить работу” могут быть следующие условия удовлетворенности:
Пользователь входит на сайт, если он указал верный логин-пароль
Пользователь может сохранить логин-пароль
Пользователь может запросить сброс пароля
Пользователь блокируется после трех неудачных попыток
Если команда понимает, что всю пользовательскую историю за спринт они сделать не могут, то они могут взять несколько conditions of satisfaction и выделить их в отдельную историю. Любое из условий удовлетворенности принесет пользователям бизнес-ценность. Если вы не используете User Story, то conditions of satisfaction все равно достаточно легко сформулировать.
Во-вторых. У команды и владельца продукта обычно слишком идеальное представление о “бизнес-ценности”. Хочется сделать все-все и только потом отдать это пользователям. Из примера выше, команда может подумать, что пока они все условия удовлетворенности не сделали, на бой авторизацию выкатывать они не могут. Но возможно, пользователи готовы начать пользоваться системой без сохранения логина-пароля, а сброс пароля пока можно запросить письмом через техподдержку. Да, системы большие и требования бывают большими и их не получится сделать “идеально” за один спринт. Но какой-то кусочек можно.
В-третьих. Есть еще другие техники разбиения задач, известных под акронимом SPIDR. У Майка Кона есть хороший постер.
PS. Да, в Scrum часто приходится переделывать. Это нормально. Потому что Scrum основан на эмпиризме. Мы пробуем, получаем обратную связь и корректируем наши действия. Это все равно получается эффективнее, чем пытаться изначально собрать все требования, спроектировать и сделать идеальную систему. Вспомните про результаты исследований, которые я приводил в начале статьи.
В результатах у вас очень интересные выводы (я прям скопирую формулировки):
в начале февраля 2022 года
средний объем взятых на спринт обязательств составлял 213 часов
средний объем невыполненных элементов бэклога к концу этих спринтов был 113 часов
год спустя (очевидно уже в 2023 году)
средний объем взятых на спринт обязательств составляет 114 часов
Проведём вычисления: 213 (обязательства февраль 2022) - 113 (объем не выполненных обязательств февраль 2022) = 100
Через 1 год (очевидно уже в 2023 году) средний объем 114 часов
Рост часов есть, неоспоримо, но и команда могла измениться.
Вопросы:
Если выгода 14 часов, то стоит ли игра свеч? (И мы не знаем изменился ли качественный состав команды)
Наблюдается ли у вас эффект по примерно одинаковой оценке задач в Story Point?
Да, вы все правильно отметили. Цель состояла не в увеличении производительности, а в повышении уверенности в прогнозах команды. В начале команда постоянно брала в спринт больше, чем они могли сделать. Не было уверенности в том, сколько из того, что ни взяли, они реально сделают. Сейчас стейкхолдеры могут быть уверены в том, что если команда обещает что-то сделать за спринт - они это сделают.
Инфляции Story Point не наблюдается. Для этого мы в ходе оценки всегда стараемся сравнить новые задачи с уже оцененными старыми, чтобы было от чего оттолкнуться. Во-вторых, мы не используем скорость команды в качестве метрики производительности команды. Поэтому мотивов увеличивать оценку у команды нет.
Я просто всегда предполагал, что одно из следствий качественного планирования - это повышения производительности и качества работ, а для ИТ ещё и переиспользование уже реализованного функционала (на моей практике переиспользование это прямо боль и как раз решается данная проблема путём качественного планирования)
А в больших компаниях, где команд много, и есть единоначалие (у вас 9 команд, это прям высокий показатель) эффект прям очень ожидаем.
Стремление повысить производительность понятно и важно. Вместе с тем, на мой взгляд, еще важнее - это формирование доверия к командам и возможности них положиться. У нас действительно много команд и при этом нет контролирующих и координирующих ролей, типа руководителей проектов или тимлидов. Команды планируются самостоятельно и сами отвечают за результат и коммуникацию. Поэтому важно им привить ощущение ответственности за свои прогнозы и планы. После этого можно думать о повышении производительности, потому что к нему команды тоже будут подходить ответственно.
На мой взгляд, переиспользование кода решается не только на планировании. Если говорить про фреймворк LeSS, который мы используем, то переиспользование кода происходит благодаря:
Отказу от специализации команд. От 4 до 8 команд должны иметь один бэклог и быть способными сделать любую задачу из этого бэклога. Благодаря этому команды хорошо знают всю кодовую базу, а не только свой кусок. Это повышает вероятность переиспользования кода.
Общей части планированию спринта. Когда встречаются все команды договариваются о распределении задач. И если они видят, что будут работать над одной частью, то могут продолжить планирование работ вместе, чтобы избежать дублирования.
Коммуникации через код. Когда кодовая база одна и разработчики видят коммиты друг друга. Если они видят, что начали работать над одним местом в коде, то могут созвониться и обсудить взаимодействие.
Комьюнити разработчиков (бэки, фронты, тестеры и тп), где они могут обсудить вопросы синхронизации и переиспользования кода.
Архитектурным воркшопам, куда приглашаются все команды и можно верхнеуровнево обсудить большие доработки.
Мне почему-то кажется не "эта статья помогает понять, как команды в Scrum и agile могут давать гарантии и сроки, сохраняя гибкость в планировани", а "как мы за год научились давать реальные обещания, постоянно выполняя план-фактный анализ". Если команды менялись мало - то это называется "сработались/притерлись". За постер спасибо.
Вообще, конечно,будучи обеими руками за гибкость, я считаю, что ТАК работать позволяет исключительно необходимость пользователей. С костылями, плохо допиленный, но пользователи часто вынуждены пользоваться (ну да, повторение слов).
В ресторане скорость и "обещаемость" выполнения заказов обеспечивается другими способами. лол.
Полный энергии и уверенности, он начинает работать над задачей… и вдруг его зовут на несколько важных встреч, где без него не могут принять решение. Потом внезапно оказывается, что у него нет необходимых доступов, чтобы сделать доработку. Потом падает среда разработки и не получается выкатить доработку, чтобы протестировать ее. Потом приходит коллега из другой команды и просит нашего участника команды помочь решить одну проблему… К концу дня наш герой обнаруживает, что ему удалось поработать над задачей всего 4 из 8 часов рабочего дня.
Хочется спросить Scrum-мастера этой команды о том, почему он не выполняет свою работу и не "защищает" разработчиков от этих "неожиданностей", как ему и положено? Это все классические вещи, с которыми Scrum-мастер должен работать.
С устранением препятствий интересно. Скрам Гайд говорит, что Скрам мастер должен способствовать устранению препятствий, но не дает их четкого определения. То есть, каждый трактует “препятствия”, как считает нужным. И вы имеете полное право рассматривать все перечисленные выше вещи как препятствия.
Если же появляются сомнения, стоит ли какую-то ситуацию рассматривать как препятствие или нет, то можно обратиться к популярной статье The 8 Stances of a Scrum Master на Scrum.org. Автор предлагает задавать 3 вопроса:
Является ли это препятствием или это что-то, что команда может решить самостоятельно?
Точно необходимо устранять это препятствие?
Какая здесь настоящая проблема?
Задавая себе эти вопросы, я прихожу к выводу, что эти проблемы вполне могут решить сами члены команды. И если у них получается тратить на свои основные задачи не менее 4 часов за день, то это нормальный результат и моего подключения не требуется. Если пытаться повысить этот показатель, то можно закончить тем, что Скрам мастер будет тратить все свое рабочее время решая за ребят, нужно ли было им встречаться или как поднять среду разработки.
Думаю, вы перегибаете палку в одну сторону.
Верно то, что самоуправляемые ("self-organizing") команды должны стремиться решать свои проблемы самостоятельно. Но неверно утверждать, что участие Scrum-мастера в устранении препятствий не требуется. Scrum-мастер играет важную роль в выявлении и устранении проблем, возникающих в команде. Если Scrum-мастер игнорирует эти проблемы под предлогом предоставления команде "самостоятельного управления", это может привести к дальнейшим проблемам. Аналогично, например, стейкхолдеры не могут пренебрегать своими обязанностями, такими как предоставление видения по "высокоуровневым" целям или предоставление обратной связи по очередному инкременту (на ревью) и оправдывать это тем, что они предоставляют команде возможность "самоуправляться". Такие действия никак не способствуют самоуправлению команды, а представляют собой отказ от своих обязанностей перед командой.
Краткосрочное и долгосрочное планирование в Scrum и agile