Наш ежедневный Scrum очень похож на то, как это описывают в книгах. Каждый день он начинается в одно и то же время, в одном и том же месте. Вначале, мы предпочитали проводить его в отдельной комнате (это были дни, когда мы использовали sprint backlog'n в электронном формате), однако сейчас мы проводим ежедневный Scrum у доски задач в комнате команды. Нет ничего лучше!
Обычно мы проводим встречу стоя, поскольку это уменьшает вероятность того, что продолжительность нашей «планёрки» превысит 15 минут.
Как мы обновляем доску задач
Обычно мы обновляем доску задач во время ежедневного Scrum'a. По мере того, как каждый член команды рассказывает о том, что он сделал за вчерашний день и чем будет заниматься сегодня, он перемещает стикеры на доске задач. Как только рассказ касается какого-то незапланированного задания, то для него клеится новый стикер. При обновлении временных оценок, на стикере пишется новая оценка, а старая зачеркивается. Иногда стикерами занимается ScrumMaster, пока участники говорят.
В некоторых командах принято, что все члены команды обновляют доску задач перед каждой встречей. Это тоже хорошо работает. Просто решите, что вам ближе, и придерживайтесь этого.
Независимо от того, какой формат sprint backlog'a вы используете, пытайтесь вовлечь всю команду в поддержание sprint backlog'a в актуальном состоянии. Мы пробовали проводить спринты, в которых только ScrumMaster занимался поддержкой sprint backlog'a. Он должен был каждый день обходить всех членов команды и спрашивать об оценках оставшегося до окончания времени. Недостатки этого подхода в том, что:
• ScrumMaster тратит слишком много времени на «бумажную работу», вместо того, чтобы заниматься поддержкой команды и устранением преград.
• Члены команды не в курсе состояния спринта, поскольку им не нужно заботиться о sprint backlog'e. Эта нехватка обратной связи уменьшает общую гибкость и сконцентрированность команды.
Если sprint backlog имеет надлежащий вид то любой член команды может легко его обновить.
Сразу же после ежедневного Scrum'a, кто-то суммирует оценки всех задач на доске (конечно, кроме тех, которые находятся в колонке «Готово») и ставит новую точку на burndown-диаграмме.
Как быть с опоздавшими
Некоторые команды заводят специальную копилку. Если вы опоздали, даже на минуту, вы кидаете в копилку определённую сумму. Без вариантов. Даже если вы позвонили перед началом ежедневного Scrum'a и предупредили, заплатить всё равно придётся :о)
Отвертеться можно лишь в исключительных случаях. Например, визит к врачу, собственная свадьба или что-то не менее важное.
Деньги из копилки используются на общественные нужды. Например, на них можно заказать пиццу, когда мы решаем поиграть вечерком :o)
Этот подход работает неплохо. Но пользоваться им нужно лишь в том случае, когда люди часто опаздывают. Некоторым командам это просто не нужно.
Как мы поступаем с теми, кто не знает, чем себя занять
Иногда кто-то говорит: «Вчера я делал то-то и то-то, а сегодня нет четкого представления у меня, чем занять себя». Наши действия?
Допустим, Джо и Лиза не знают, чем сегодня заняться.
Если я выступаю в роли ScrumMaster'а, я просто передаю слово следующему. При этом беру на карандаш тех, кто не знает, чем ему заняться. После того, как все высказались, я пробегаюсь вместе с командой по доске задач и проверяю, что данные на доске задач актуальные и что все понимают смысл каждой истории. Далее я предлагаю каждому участнику команды приклеить новые стикеры. После этого возвращаюсь к тем, кто не знал, чем себя занять, с вопросом «после того, как мы прошлись по доске, не появилось ли у вас представление о том, чем заняться?» Надеюсь, к тому времени оно уже появится.
Если же нет, то я выясняю, есть ли возможность для парного программирования. Допустим, сегодня Никлас планирует реализовать интерфейс для админки. Вы можете предложить Джо или Лизе поработать в паре с Никласом над этой функциональностью. Обычно это работает.
Если нет, то вот вам следующий приём.
ScrumMaster: «Так, и кто хочет продемонстрировать нам готовую бета-версию?» (предполагая, что выпуск бета-версии - цель спринта) Команда: недоумевающая тишина ScrumMaster: «Мы что — не готовы?» Команда: «ммм… нет».
ScrumMaster: «Почему? Что ещё осталось незаконченным?»
Команда: «Так у нас даже нет тестового сервера. Кроме того нужно починить билд-скрипт». ScrumMaster: «Ага» (наклеивает два новых стикера). «Джо и Лиза, вам всё еще нечем заняться сегодня?»
Джо: «Хм… Думаю, что я попробую раздобыть тестовый сервер». Лиза: «… а я постараюсь починить билд-скрипт.»
Если повезёт, кто-то действительно сможет продемонстрировать готовый к выпуску бета-версии релиз. Отлично! Цель спринта достигнута. Но что делать, если прошла только половина времени, отведённая на спринт. Всё просто. Поздравьте команду за отличную работу, возьмите одну-две истории из стопки «Следующие» и поместите их в колонку «В планах». После этого повторно проведите ежедневный Scrum. Уведомите Product owner’а о том, что вы добавили несколько новых историй в спринт.
Что же делать, если команда не достигла цели спринта, а Джо с Лизой всё ещё не могут определиться с тем, какую пользу они могут принести? Я обычно пользуюсь одной из нижеперечисленных методик (все они не очень хорошие, но всё же это последнее средство):
Пристыдить: «Ладно, если не знаешь, как принести пользу команде, иди домой, почитай книгу и т.д. Или просто сиди здесь, пока кому-то не потребуется твоя помощь».
По старинке: Просто назначить им задачу.
Моральное давление: Скажите им: «Джо и Лиза! Не смею вас больше задерживать. А мы все просто постоим тут, пока у вас не появятся идеи, как помочь нам в достижении цели».
Закабалить: Скажите им: «Вы сможете помочь команде, исполняя роль прислуги сегодня. Готовьте кофе, делайте массаж, вынесите мусор, приготовьте обед: делайте всё, о чём вас может попросить команда». Вы будете удивлены, насколько быстро Джо и Лиза найдут для себя полезные технические задачи :o)
Если у вас есть человек, который часто заставляет вас заходить так далеко, возможно, вы должны отвести этого товарища в сторонку и культурно объяснить ему, что он не прав. Если и после этого проблема не решится, нужно понять, важен ли этот человек для команды или нет?
Если он не очень важен, постарайтесь исключить его из своей команды.
Если же он важен для команды, попробуйте найти ему напарника-«наставника». Джо может быть классным программистом и отличным архитектором, просто он предпочитает, чтобы ему другие люди говорили, что он должен делать. Отлично. Назначьте Никласа наставником Джо. Или будьте сами им. Если Джо действительно важен для команды, такой будет цена достижения цели. У нас были похожие ситуации, и этот подход более-менее срабатывал.