Сам по себе фреймворк Scrum уже давно перестал быть инновацией. Появившись задолго до подписания Agile-манифеста, Scrum сегодня неразрывно связан с миром гибких подходов. Основой фреймворка уже довольно давно является «Руководство по Scrum» (Scrum Guide). С момента своего появления этот документ довольно сильно изменился. В своей статье голландский специалист Вилем-Ян Агелинг рассказывает о пяти спорных моментах, выпавших из руководства по Scrum за эти годы.
Если вы перешли на Scrum пять или более лет назад, то ваше понимание Scrum отличается от того, которое существует сегодня. Есть много вещей, которые когда-то определялись как Scrum, даже упоминались в руководстве по Scrum, но в какой-то момент были убраны. Какие-то понятия ушли навсегда, некоторые заменили на что-то другое. Логично, что многие до сих пор связывают эти темы со Scrum, но Scrum эволюционировал, и они больше не актуальны.
Вот 5 спорных моментов, которые были либо удалены, либо заменены. Если раньше эти вещи вызывали у вас беспокойство, то, возможно, сейчас вы захотите еще раз подумать, полезен ли для вас Scrum.
1. Куры и свиньи
В руководстве по Scrum была следующая история:
Курица говорит свинье: «Давай откроем ресторан!»
Свинья обдумала это предложение и спрашивает: «Как мы назовем этот ресторан?»
Курица отвечает: «Ветчина и яйца!»
Свинья говорит: «Нет, спасибо, с тебя тут требуется только рядом постоять, а для меня это станет серьезным обязательством!»
Scrum-команда — это свиньи, все остальные — куры. Курица не может указывать свиньям, как делать их работу. Такая история не всегда приводила к желаемым результатам. Часто дело доходило до раскола между Скрам-командой и «посторонними».
Эта история была удалена из версии руководства по Scrum 2011 года.
2. Принятие обязательств в отношении задач, запланированных в спринте
С 2011 года команда разработки больше не принимает на себя обязательств выполнить работу, запланированную в спринте. Вместо этого команда создает прогноз.
Это серьезное изменение.
Обязательство подразумевает, что во время спринта не будет новых идей. Прогноз создается эмпирическим путем: прозрачность, инспекция, адаптация.
3. Груминг бэклога — сначала добавить, потом убрать
В руководстве по Scrum версии 2010 года груминг бэклога продукта является всего лишь подсказкой. Таким образом, это не было частью руководства по Scrum, но было сказано, что эта практика хорошо работает в Scrum. В версии руководства по Scrum от июля 2011 года в Scrum уже добавлена обработка бэклога продукта. В версии от июля 2013 года слово «груминг» заменено на PBR (Product Backlog Refinement), поскольку слово «груминг» имеет некоторый негативный оттенок.
4. Три вопроса во время ежедневного митинга
В руководстве по Scrum ранее требовалось, чтобы каждый член команды отвечал на следующие три вопроса:
Чего он достиг с момента последней встречи;
Что он собирается сделать к следующей встрече;
Какие препятствия стоят на его пути.
В результате ежедневный митинг стал не более чем проверкой статусов задач. Часто команда не учитывала цель спринта и то, как обстоят дела с достижением этой цели. У команд, которые просто проводят проверку статусов задач, нет эффективных ежедневных собраний. Это обеспечило Daily Scrum плохую репутацию.
Вот почему в 2013 году эти три вопроса были изменены на следующие:
Что я сделал вчера, что помогло команде разработчиков достичь цели спринта?
Что я сделаю сегодня, чтобы помочь команде разработчиков достичь цели спринта?
Вижу ли я какое-либо препятствие, которое мешает мне или команде разработчиков достичь цели спринта?
Это огромный шаг вперед. Однако, когда команда самоорганизуется, она может прийти к выводу, что есть другой способ добиться наилучших результатов от ежедневных митингов. Поэтому в 2017 году руководство по Scrum упоминает эти три вопроса в качестве одной из альтернатив Daily Scrum, поясняя, что его можно проводить по-разному, если основное внимание уделяется цели спринта.
5. Скрам-мастер ведет Daily Scrum
Вот что говорится в книге Кена Швабера и Майка Бидла «Гибкая разработка программного обеспечения с использованием Scrum» (2002 г.):
«Скрам-мастер отвечает за успешное проведение Daily Scrum».
Затем в книге подробно рассказывается, как Скрам-мастер организует и проводит Daily Scrum.
Руководство Scrum от 2010 года изменило это:
«Скрам-мастер обеспечивает встречу команды. Команда отвечает за проведение Daily Scrum».
Начиная с версии руководства по Scrum 2010 года, этот абзац остается неизменным. Команда разработчиков отвечает за Daily Scrum, поскольку это самоорганизующаяся команда, оценивающая прогресс в достижении цели спринта. Скрам-мастер обучает команду проводить ежедневные митинги, не выходя за рамки 15 минут и отстаивает в рамках компании позицию, что Daily Scrum предназначен для команды разработки. Скрам-мастеру на самом деле совсем не обязательно посещать Daily Scrum.
Также по теме:
- Самоорганизованная команда. Направлять или управлять?
- От измерений к действиям. Системная динамика в управлении ИТ
- Такой же, но совсем другой (как мы сделали учебный курс по DevOps)
- Волшебство коротких пользовательских историй
- Потоки создания ценности и их природные аналоги
