В полдень он устраивает пробежку вдоль канала.
Рисунок 5.4 – Полуденный канал
Немножко времени на душ, быстрый перекус (сегодня нет времени обедать с командой) – и вот уже совещание. Команда пригласила Лорана, специалиста по картографированию: есть истории по этой теме, их надо доработать. Но похоже, Лоран забыл о совещании, его нет! Николя звонит ему: у Лорана ЧП, но он уже едет и будет через пятнадцать минут. Чтобы не тратить времени, команда обсуждает другие вопросы. Доработка проходит хорошо, много готовых историй, Николя насчитывает аж десять штук.
После совещания он остается с Владельцем продукта Селиной, чтобы по итогам доработки обновить план на сезон. Но ему звонит Себастьян и сообщает, что сервер разработки упал. Николя оставляет план Селине и спешит к Себастьяну. К счастью, достаточно перезагрузки сервера.
Он пытается объяснить Себастьяну, что тот вполне мог бы справиться с проблемой в одиночку.
У Николя есть немного времени до собрания, чтобы проанализировать причины крупного бага на прошлой неделе. Он идет к участникам команды, которые занимаются историей «Отредактировать раздел с фотографиями собак». Помогает им пройти две проверки, связанные с этой историей. Она будет закончена сегодня вечером!
Он ведет обсуждение крупного бага, стремясь обеспечить согласованность в работе над улучшением. Хмм, похоже, следует добавить еще одно правило в написании кода.
Во время утренней схватки Николя заметил, что Эмилия расстроена. Оказалось, поссорились с Дэвидом. Надо будет поговорить с ним завтра. Николя раздумывает над тем, чтобы во время следующей ретроспективы предложить паттерн Niko-Niko и избежать таких ситуаций в дальнейшем.
Перед уходом просматривает сообщения и видит запрос от Кевина: тот хочет забрать Жюльена, пока идет демо для клиентов. Посоветовавшись с участниками команды, Николя вынужден честно сказать Кевину нет, потому что это подорвало бы цель спринта.
5.7 Антипаттерны
Ситуация. Участники команды отмечают: планирование занимает слишком много времени. Scrum-мастер решает, что сделать, чтобы ускорить процесс.
Последствия. Команда демотивирована. Самоорганизация отсутствует.
Как сделать лучше? Заменить Scrum-мастера в соответствии с паттерном вращающегося Scrum-мастера.
Например, в опытной команде роль Scrum-мастера может переходить от человека к человеку и меняться каждый спринт или после нескольких спринтов.
Таким образом, роль Scrum-мастера динамична. Она не достается тому, кто превращает работу в рутину или беспрекословное подчинение указаниям. Этот паттерн позволяет увидеть отношения участников и понять, какое поведение наиболее приемлемо на роли SM для конкретной команды.
Рисунок 5.5 – Вращающийся SM
Ситуация. При внедрении Scrum руководитель проекта стал Владельцем продукта, а на роль SM пригласили человека извне – буквально навязали его команде.
Последствия. Его легитимность не признана. Человек не способен устранять препятствия. Ко всему прочему, он не понимает проблем технического характера.
Как сделать лучше? Устраивать выборы без кандидатов.
Ситуация. Команда достигла значительных успехов, и в какой-то момент SM, бывший разработчик, решил развиваться дальше. Он покинул пост SM команды.
Последствия. Scrum не применяется, работа команды встала.
Как сделать лучше? Научиться менять положение в команде.
Роль Scrum-мастера развивается вместе с командой: сначала он уделяет много времени обучению команды принципам Scrum, затем становится советчиком (экспертом, ментором, коучем).
Ситуация. SM делает все, что связано с логистикой. Он убирается, закупает необходимое. Единственный из команды пишет Post-it®.
Последствия. Остальные во всем на него полагаются и не участвуют в жизни команды. Scrum-мастера все достало.
Рисунок 5.6 – Scrum-мастер проверяет, все ли готово
Как сделать лучше? Коллективно обсудить правила жизни команды.
Чтобы идти дальше
Книги
‣ Rachel Davies, Liz Sedley, «Coaching Agile», Lulu, 2009. Эта книга дает очень хорошие советы Scrum-мастеру, хотя даже не упоминает эту роль
6Структура бэклога
После решения о начале разработки продукта самая большая трудность – трансформировать первоначальное видение в нечто, что может использовать команда разработчиков.
В традиционных проектах стадия спецификации выполняется полностью в начале проекта и принимает форму документа. Он описывает, что будет делать продукт, какие функции от него ожидаются. Документ довольно громоздкий: детально расписано, что требуется от разработчиков – чтобы ничего не упустить, чтобы все четко знали свои задачи.
Позднее становится ясно, что этот внушительный и неповоротливый документ так и не послужил своей цели. Он даже не пригодился команде, занимающейся тестированием: прошерстить две сотни страниц тому, кто не особо ориентируется в конкретной области – непосильная задача. И само собой, после двух недель разработки документ так и не обновлялся.
В Scrum этот подход в корне отличается: задачи, которые необходимо выполнить, появляются в связи и благодаря постоянному сотрудничеству участников команды и Владельца продукта, регулярной обратной связи от заинтересованных сторон.
Бэклог – это инструмент сбора и распределения задач.
6.1 Бэк что?
Неужели нет французского слова для бэклога?
Когда в 2006 году я впервые участвовал в проекте и сопровождал переход команды к Scrum, использовал термин хранилище требований. Но если бэклог рассматривать как хранилище, найдем мы там не совсем требования. В Agile-подходе никто ничего не требует друг от друга, все общаются на тему историй, чтобы прийти к взаимопониманию. Никаких требований.
Наши братья из Квебека, которые являются ревностными последователями офранцуживания английских слов, переводят бэклог как carnet (блокнот), но блокнот продукта не укоренился в нашем лексиконе. В конце концов, все привыкли к использованию термина бэклог.
Хотя и не без путаницы: кое-кто упорно произносит блэклог. Я даже как-то раз слышал блэкдог.
Рисунок 6.1 – «Я сказал дополнить бэклог, а не исполнить «Black dog»
Scrum-мастер – разработчику и фанату группы «Led Zeppelin»
В литературе о Scrum различают бэклог продукта и бэклог спринта.
✓ В 2008 я решил более не использовать термин бэклог спринта для обозначения плана на спринт. Я объясню свое решение в главе 9.
✓ Начиная с третьего издания этой книги, сокращаю бэклог продукта до бэклога.
Этому есть несколько причин: во-первых, так проще, во-вторых, мы говорим о продукте и, наконец, – это больше соотносится с командой. К слову, в Scrum 3.0 термин продукт почти не встречается.
Остается только прояснить грамматический род этого слова. Я слышал, кто-то считает, что бэклог женского рода. Но я буду, как большинство, думать, что это слово мужского рода.
6.2 Необходимый инструмент экосистемы
На первый взгляд, бэклог – это список задач для команды, обладающий некоторыми отличительными особенностями.
Рисунок 6.2 – Свойства бэклога
Владелец продукта – главный в процессе разработки и поддержания бэклога. В то же время, бэклог является инструментом обмена в экосистеме: он легко доступен как для команды, так и для заинтересованных сторон. Любой может его просмотреть и предложить идеи.
Бэклог находится в общем доступе, поддерживая прозрачность процесса и упрощая обратную связь.
Часто бывает, что бэклог команды, начинающей работать в формате Scrum, – огромный и неприступный. Особенно у команд, которые используют электронные таблицы, бэклог выглядит как мешанина из десятков и сотен элементов.
Это нецелесообразно. Список невероятно длинный. Распределить задачи невозможно. Хотя бэклог и является, по сути, списком задач, это не значит, что с самого начала работы надо детально описывать, к чему команда подойдет не завтра и даже не послезавтра.
Конструктивный подход к созданию бэклога и его дальнейшая структуризация позволят ограничить количество элементов в списке.
Конструктивное сокращение бэклога делает его понятным и упрощает его использование.
Элементы бэклога расставлены в предположительном порядке их реализации. У задач должна быть четкая последовательность.
Приоритетный порядок, нетипичный для документов спецификации, адаптирован для итеративной разработки: последовательность элементов соответствует последовательности, в которой они будут реализованы.
Если А приоритетнее, чем Б, то А будет выполнено до Б.
Владелец продукта стремится максимизировать ценность, минимизируя затраченные ресурсы. Он использует критерии, чтобы определить порядок.
В бэклоге находится все, что при традиционном подходе рассредоточено по разным документам и инструментам. Уникальность бэклога упрощает распределение задач и его поддержание в рабочем состоянии. Но самое важное – это единственный список задач для команды.