Хороший Скрам Мастер ежедневно обновляет Спринт Burndown, чтобы освободить команду от лишней работы. Отличный же Скрам Мастер помогает команде самоорганизовываться при помощи визуальных инструментов (Geodoff Watts, Scrum Mastery).
Burndown и Burnup – хорошо знакомые нам инструменты, которыми пользуются многие Скрам команды. Но, не смотря простоту, я сталкиваюсь с большим количеством недопониманий. Давайте рассмотрим некоторые из них, а затем я расскажу о том, каким образом можно увеличить эффективность использования этих инструментов.
Миф №1. Каждая Скрам Команда обязана строить Burndown. Действительно, еще десять лет назад Burndown был неотъемлемой частью Скрама, обязательным его артефактом (некоторые до сих пор считают так). Но сейчас это не так. В Скрам Гайде четко написано, что:
Возможно использование различных практик для прогнозирования прогресса, как, например, берндаун, бернап чарты или коммулятивные диаграммы. Эти техники полезны (Scrum Guide, july 2013).
Итак, современному Скраму безразлично, используете ли вы Burndown, Burnup, или же коммулятивные диаграммы для отображения прогресса. Существует большое количество различных практик и подходов. Скрам не навязывает конкретные решения. Скрам – фреймворк, внутри которого у команд возникают собственные практики, процессы и инструменты. Важно другое:
В любое время можно суммировать оставшуюся работу в Спринте. Команда Разработки отслеживает ее, по меньшей мере, на каждом Ежедневном Скраме, чтобы понять вероятность достижения Цели Спринта. Отслеживая оставшуюся работу, Команда Разработки видит и управляет прогрессом (Scrum Guide, july 2013)
Вы можете использовать Burndown, а можете «зарядить» Burndown. А, возможно, ни один из этих графиков вам не приглянулся, и вы решили, что визуальная Скрам доска прекрасно отображает прогресс к Цели Спринта. И знаете что? Скрам ОК с этим.
Миф №2. Скрам Мастер должен обновлять Burndown/Burnup. Часто, когда я говорю командам о том, что они сами должны обновлять свои графики, я ловлю на себе недоумленные взгляды, а затем обычно кто-то спрашивает: «а Скрам Мастер тогда нам зачем?». У меня есть встречные вопросы:
Burndown/Burnup существуют для того, чтобы давать обратную визуальную связь тем, кто отвечает за достижение Цели Спринта, и заставлять их рефлексировать, корректировать свои действия в зависимости от видимого прогресса. Так как именно Команда Разработки отвечает за достижение Цели Спринта (а НЕ Скрам Мастер), то она и должна отслеживать свой процесс сама. Частый негативный паттерн, который я вижу в Скрам командах, где Скрам Мастер ведет графики – команде глубоко побоку вся эта информация. Ну, меняются какие то циферки, и что дальше? Поверьте, если вы введете правило, что каждый по очереди должен обновлять график на стене во время или после Ежедневного Скрама, команда начнет реагировать на прогресс лучше.
Поведение людей является функцией от человека (Person) и его окружения (Environment). Вывел эту знаменитую формулу психолог Курт Левин:
B=f(P,E)
Для того, чтобы воздействовать на поведение людей, вместо того, чтобы менять самих людей (что очень тяжело), можно просто изменить окружение и тем самым заставить их самоорганизоваться внутри границ (How to Change the World, Yurgen Apello).
Какая же роль в этом случае отводится Скрам Мастеру? Объяснить команде, зачем нужен Burndown, научить его строить, задавать открытые вопросы и фасилитировать процесс, добиваясь самоорганизации.
Миф №3. Нужно стремиться к тому, чтобы фактическая линия на графике совпадала с идеальной.
Иногда менеджеры с гордостью демонстрируют идеальный Burndown, где зеленая линия (идеальная) совпадает с красной (фактической). У меня в голове возникают сразу две мысли:
Чаще всего оказывается верным первое. В запутанной среде разработки ПО нельзя запланировать задачи на Спринт вперед так, чтобы исключить непредсказуемость. Беклог Спринта динамически меняется. Цветные стикеры двигаются по доске, оценки на задачи меняются, разработчики тратят на задачи больше или меньше времени, чем они изначально рассчитывали. В Запутанной среде (читаем
Путешествие по Кеневину, часть 1) невозможно в конце получить то, что было запланировано в начале. А если ваша команда, все таки, занимается разработкой ПО и имеет подобные графики, то, скорее всего, отсутствует доверие. Разработчики завышают свои оценки, чтобы обезопасить себя.
Если же в команде доверительные отношения и мы не страхуемся завышенными оценками, а графики выходят идеальными, то я бы рекомендовал задуматься – а зачем здесь нужен Скрам вообще? Скорее всего, вы находитесь в Очевидном или Сложном доменах. Скрам – не серебряная пуля, возможно, вам подойдет «старый добрый Водопад».
Теперь я хочу поделиться своим собственным опытом в использовании Burndown и Burnup. Я приведу примеры конкретных практик, которые работали в моих командах.
Практика 1. Использование Burndown (часы) и Burnup (story points) одновременно. Долгое время я довольствовался лишь одним Burndown-ом, построенным на часах, но потом мне его стало не хватать. И вот почему. Он не отображает реальную бизнес ценность, доставленную командой. Если команда одновременно работает над большим количеством Историй (это плохая практиа, нужно ограничивать WIP), то, несмотря на то, что работа кипит – Истории не закрываются. В итоге можем придти к парадоксальной ситуации – Burndown почти «сгорел», а ничего, по сути, не сделано. Я начал пользоваться Burnup-ом, построенном на Стори Поинтах, который отображал доставленную ценность, но столкнулся с другой проблемой – иногда этот график сильно демотивировал некоторые команды. Представьте себе, что работа кипит, люди закрывают таски, а на графике унылая горизонтальная черта. И тогда я решил пользоваться двумя графиками одновременно.
Подобная практика убивает сразу двух зайцев:
Показывает, насколько здоров ваш процесс и как быстро вы можете доставлять бизнес ценность на уровне Стори Поинтов (Burnup).
Отображает общий прогресс на уровне часов (Burndown).
Не забывайте использовать визуальную Канбан доску и ограничивать работу в прогрессе (WIP), иначе можно остаться у разбитого корыта к концу Спринта (см. фото ниже):
Практика 2. Сделайте так, чтобы графики обновляла сама команда. Возможно, каждый день это будет новый человек. Поймите, что работает для вас и пользуйтесь этим.
Практика 3. Сделайте ваши графики визуальными и составной частью информационного радиатора. Каждый должен иметь возможность увидеть их и почесать голову в задумчивости, если там не все ОК. В отличии от информационных холодильников, дверцу которых нужно специально открывать (к примеру, электронные инструменты вроде Jira, Greenhopper), радиаторы излучают информацию и служат прекрасным источником коммуникации. И когда менеджер в очередной раз зайдет в комнату , возможно, все, что вам нужно будет сделать – проводить его к радиатору.
Практика 4. Меняйте время от времени расположение ваших графиков. Человеческий глаз быстро привыкает к новому и скоро команда может перестать обращать на них внимание. Они станут просто обоями. А обои время от времени следует переклеивать.
Практика 5. Обновляйте графики во время Ежедневного Скрама, чтобы вся команда видела их актуальное состояние и рефлексировала. После Ежедневного Скрама можно спросить: «ОК, кажется, мы не успеваем. Что мы можем сделать?»
Практика 6. Используйте геймификацию. Подкиньте команде идею добавить что-то новенькое в Burndown. Ведь скучно же каждый Спринт наблюдать за однообразными осями и цифрами. Удобно сделать это на Ретроспективе. И вот к чему можно придти:
Одна команда, состоящая из большого количества любителей пива, решила сделать свой Burnup чарт, используя пивные наклейки. Каждый пивной бокал равнялся 3 S.P.
В другой команде много ребят занимались зимними видами спорта. Burndown напомнил им лыжную горку, которой спускается лыжник, минуя препятствия.
А бывает просто вот так:
Практика 7. Никогда не стойте на месте и старайтесь разнообразить практики, пробуйте что-то новое. Начинайте, ошибайтесь и вновь пробуйте.
А как вы помогаете командам отслеживать прогресс к Целям? Делимся своим опытом в комментариях.
