Необходимо просчитать время между готовностью элемента и завершением работы над ним.
Одним из индикаторов в Kanban является накопительная диаграмма потока. Она показывает количество элементов по вертикали. Если речь об историях, то считается количество элементов в лотках. Получается накопительная диаграмма лотков.
Рисунок 20.8 – Накопительная диаграмма лотков
Я рекомендую подсчитывать данные для этого индикатора еженедельно, а не в конце каждого спринта, чтобы было больше точек на диаграмме.
Им действительно сложно пользоваться, признаю, это потребует усилий. Но не таких больших, если команда использует паттерн лотков. Этот индикатор трудно интерпретировать. По сути, это комплексный инструмент анализа, для которого нужно иметь достаточно данных. Но усилия, приложенные для его создания, вознаграждаются огромным объемом получаемой при его помощи информации.
20.6 Остановить Scrum в пользу Kanban?
Анализ ситуаций, когда следует остановить Scrum, не является основной целью этой главы: в ней мы больше фокусируемся на применении Kanban в дополнение к Scrum. Но существует риск их неправильного использования. Иногда все же встает вопрос об остановке Scrum и применении одного Kanban. Для этого действительно могут быть веские причины. А могут и не быть.
Один из рисков – внесение ограничения только на задачи. Мы также говорили об основном риске в преамбуле: команде, еще не овладевшей Scrum, не стоит соединять его с Kanban. В ином случае у нее, вероятно, не получится ни то, ни другое.
Kanban – это не просто столбцы с накленными Post-it®.
Среди доводов тех, кто говорит: «Мы останавливаем Scrum, чтобы перейти на Kanban», некоторые мне кажутся очень сомнительными:
✓ собрания занимают слишком много времени,
✓ спринт – это смирительная рубашка, ограничивающая команду,
✓ зачем сохранять спринт, если развертывание проходит вне установленного ритма?
На это можно ответить: это не просто собрания, и в Kanban команду ждет то же самое. Фактически, много времени занимает процесс оценки, и в целом можно продолжать Scrum без него.
Давление на команду часто возникает из-за неправильно понятых обязательств. Но эту проблему тоже можно решить.
Частый ввод в эксплуатацию – это хорошо и вполне возможно в рамках Scrum. Иногда команды придерживаются неправильной идеи, что ввод в эксплуатацию должен совпадать с концом спринта или сезона. Нет, вводить продукт в эксплуатацию можно в любой момент, и желательно как можно скорее.
Можно также установить особый ритм, чтобы, например, договориться о регулярных встречах с заинтересованными сторонами.
Кроме того, на мой взгляд, применять Kanban труднее, чем Scrum. Он требует статистических знаний, которыми обладают очень немногие разработчики.
• Слишком много срочных задач
Как уже было сказано в первой главе, Scrum подходит не для всех ситуаций, особенно если команда постоянно сталкивается с изменениями.
Как понять, подходит контекст команды или нет?
Проведите несколько спринтов в Scrum-формате.
После этого подсчитайте уровень срочности: необходимо вычислить процентное соотношение того, что появилось в процессе спринта, к тому, что команде удалось завершить. Если результат не уменьшается и остается выше 40 % (выяснено опытным путем), лучше остановить спринты и вообще работу в Scrum-фреймворке.
• Ритм спринта больше не нужен
Scrum-команда, успешно внедрившая в свою работу Kanban, может задаться вопросом об остановке спринтов.
Она овладела принципом ограничений и ловко управляет потоком историй.
Она чувствует себя достаточно опытной, чтобы рассинхронизировать планирование, обзор и ретроспективу. Она проводит их по требованию, то есть, в случае необходимости, а не ориентируясь на ритм спринта.
Если команда останавливает спринты, можно утверждать, что это больше не Scrum. Главное – оставаться Agile.
Рисунок 20.9 – Можно быть Agile, не отвлекаясь на события
21Разработка продукта несколькими командами
Во втором издании этой книги (2010 год) появилась глава «Scrum в больших масштабах». С тех пор эта тема расширилась, разные структуры были предложены и проданы, то есть прошли сертификацию и стали предметом обсуждения на конференциях.
Я неоднократно участвовал в переходе проектов на более крупные масштабы. Я также много читал и наблюдал. И моя позиция изменилась: я вернулся к простоте – я бы сказал, вернулся к Scrum. На мой взгляд, Scrum в большом масштабе имеет право на существование, но только в том случае, если для него не создаются новые роли.
Я переименовал главу, так ее основная цель стала яснее. Действительно, scaling Scrum (или, в более широком смысле, Agility в крупном масштабе) стал темой, о которой все говорят и задают много вопросов. В этой книге я решил отдельно рассмотреть Scrum для разработки продукта несколькими командами (что является предметом данной главы) и Agility для трансформации организаций (о чем мы узнаем в следующей).
21.1 Фрактальный и минимальный подход
Scrum создан для разработки сложных продуктов. Срок их службы может быть продолжительным, и в Scrum-фреймворке он регулируется последовательностью сезонов и командой, о которой мы узнали в предыдущих главах.
В фокусе этой главы Scrum на несколько команд. Интуитивно понятно, что необходимость в нескольких командах коррелирует с разработкой масштабных продуктов – настолько крупных, что для них требуется нечто большее, чем одна Scrum-команда. Но о каких ситуациях идет речь?
И хотя мы будем стараться все упростить, применять Scrum в больших масштабах сложнее, чем с одной командой.
Рисунок 21.1 – Scrum и масштабы
Лучше по возможности избегать больших масштабов, ну или хотя бы не запускать проект на несколько команд с самого начала.
В большинстве случаев этого и не требуется. Продукт часто не такой уж и большой, и одна команда может сделать многое.
Но если продукт слишком объемный, иногда можно разбить его на независимые части (подсистемы) и сформировать Scrum-команду для каждой из них. Крупномасштабный Scrum не нужен, по крайней мере, на первых порах.
Если в нем действительно возникнет необходимость, переходить к нему стоит постепенно: начать с одной команды, затем создать еще одну и т. д.
Чтобы организовать переход к Scrum на несколько команд, надо сперва овладеть Scrum на уровне одной команды. Поэтому я рекомендую начинать с небольших масштабов.
Когда я только начинал работать в Scrum-фреймворке, ответ на вопрос о масштабах процесса был прост: мета-Scrum! И в качестве примера практики это был Scrum of Scrums, схватка схваток. Помимо ежедневных схваток каждой команды была еще одна с представителями от каждой команды!
Я не сразу осознал, что за этой, казалось бы, упрощенной схемой скрывается фрактальный аспект подхода.
Суть фрактального подхода в том, что одни и те же концепции применимы на разных уровнях. То, что допустимо на уровне одной команды, применимо и к другим.
Это важнейшний пункт: крупномасштабный Scrum остается Scrum. Это классический Scrum, но в широком контексте, где могут быть полезны новые организационные паттерны. Вот почему, если бы нужно было выбрать один Agile-фреймворк, это был бы LeSS. LeSS предлагает именно такой формат: Scrum плюс несколько паттернов для широкого контекста.
Большинство паттернов, которые будут представлены в этой главе, являются частью LeSS [62].
Важно не забывать о том, что в этом фрактальном подходе сохраняются традиционные роли Scrum. Новые роли не создаются.
Как сохранить силу Scrum при работе в больших масштабах? Как избежать возврата к подходу командование и контроль, когда координируешь сразу несколько команд?
В книге «Lean Enterprise» в качестве ответа на эти вопросы автор предлагает принцип миссии.
Речь идет об определении миссии организации, ее четкой формулировке, объяснении, почему она важна, – и наконец, о том, чтобы позволить людям, отвечающим за выполнение, достичь ее. При этом не нужно составлять подробных планов и следить за их исполнением.
Этот принцип направлен на согласование – ту же цель, что и у подхода для создания первоначального бэклога (см. главу 15). При работе нескольких команд этот принцип гарантирует их самоорганизацию и автономность, что важно для реализации Scrum в хороших условиях.
Принцип миссии, применяемый несколькими Scrum-командами, работающими над одним продуктом, воплощен в общей цели сезона. Она усилена воздействиями, на которые ориентирована каждая команда. От участников зависит, как они будут идти к этой цели. Согласование – это цель спринта в условиях большой неопределенности.
21.2 Состав команд
Для лучшего понимания этого раздела рекомендую сперва ознакомиться с главами 3, 4 и 5.
Экосистема одной команды состоит из ее участников и заинтересованных сторон. Для нескольких команд заинтересованные стороны одни и те же. Экосистемы в большом масштабе отличаются взаимоотношениями команд.