Все о SCRUM. Изучение, разработка, интеграция

На это можно ответить: это не просто собрания, и в Kanban команду ждет то же самое. Фактически, много времени занимает процесс оценки, и в целом можно продолжать Scrum без него.

Давление на команду часто возникает из-за неправильно понятых обязательств. Но эту проблему тоже можно решить.

Частый ввод в эксплуатацию – это хорошо и вполне возможно в рамках Scrum. Иногда команды придерживаются неправильной идеи, что ввод в эксплуатацию должен совпадать с концом спринта или сезона. Нет, вводить продукт в эксплуатацию можно в любой момент, и желательно как можно скорее.

Можно также установить особый ритм, чтобы, например, договориться о регулярных встречах с заинтересованными сторонами.

Кроме того, на мой взгляд, применять Kanban труднее, чем Scrum. Он требует статистических знаний, которыми обладают очень немногие разработчики.

20.6.3 Правильные причины для остановки Scrum в пользу Kanban

• Слишком много срочных задач

Как уже было сказано в первой главе, Scrum подходит не для всех ситуаций, особенно если команда постоянно сталкивается с изменениями.

Как понять, подходит контекст команды или нет?

Проведите несколько спринтов в Scrum-формате.

После этого подсчитайте уровень срочности: необходимо вычислить процентное соотношение того, что появилось в процессе спринта, к тому, что команде удалось завершить. Если результат не уменьшается и остается выше 40 % (выяснено опытным путем), лучше остановить спринты и вообще работу в Scrum-фреймворке.

• Ритм спринта больше не нужен

Scrum-команда, успешно внедрившая в свою работу Kanban, может задаться вопросом об остановке спринтов.

Она овладела принципом ограничений и ловко управляет потоком историй.

Она чувствует себя достаточно опытной, чтобы рассинхронизировать планирование, обзор и ретроспективу. Она проводит их по требованию, то есть, в случае необходимости, а не ориентируясь на ритм спринта.

Если команда останавливает спринты, можно утверждать, что это больше не Scrum. Главное – оставаться Agile.

Рисунок 20.9 – Можно быть Agile, не отвлекаясь на события

21 Разработка продукта несколькими командами

Во втором издании этой книги (2010 год) появилась глава «Scrum в больших масштабах». С тех пор эта тема расширилась, разные структуры были предложены и проданы, то есть прошли сертификацию и стали предметом обсуждения на конференциях.

Я неоднократно участвовал в переходе проектов на более крупные масштабы. Я также много читал и наблюдал. И моя позиция изменилась: я вернулся к простоте – я бы сказал, вернулся к Scrum. На мой взгляд, Scrum в большом масштабе имеет право на существование, но только в том случае, если для него не создаются новые роли.

Я переименовал главу, так ее основная цель стала яснее. Действительно, scaling Scrum (или, в более широком смысле, Agility в крупном масштабе) стал темой, о которой все говорят и задают много вопросов. В этой книге я решил отдельно рассмотреть Scrum для разработки продукта несколькими командами (что является предметом данной главы) и Agility для трансформации организаций (о чем мы узнаем в следующей).

21.1 Фрактальный и минимальный подход

21.1.1 Сперва небольшой масштаб

Scrum создан для разработки сложных продуктов. Срок их службы может быть продолжительным, и в Scrum-фреймворке он регулируется последовательностью сезонов и командой, о которой мы узнали в предыдущих главах.

В фокусе этой главы Scrum на несколько команд. Интуитивно понятно, что необходимость в нескольких командах коррелирует с разработкой масштабных продуктов – настолько крупных, что для них требуется нечто большее, чем одна Scrum-команда. Но о каких ситуациях идет речь?

И хотя мы будем стараться все упростить, применять Scrum в больших масштабах сложнее, чем с одной командой.

Рисунок 21.1 – Scrum и масштабы

Лучше по возможности избегать больших масштабов, ну или хотя бы не запускать проект на несколько команд с самого начала.

В большинстве случаев этого и не требуется. Продукт часто не такой уж и большой, и одна команда может сделать многое.

Но если продукт слишком объемный, иногда можно разбить его на независимые части (подсистемы) и сформировать Scrum-команду для каждой из них. Крупномасштабный Scrum не нужен, по крайней мере, на первых порах.