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