Если компания ценит программное обеспечение и время создающей его команды гораздо меньше, чем усилия бизнес-подразделений и продавцов, то несложно сделать анализ затрат и выгод – и тогда BRUF оказывается логичным способом построения программного обеспечения. Если вы работаете в компании именно такого типа, то успешная попытка использования Scrum поможет вашим менеджерам и остальным сотрудникам понять ценности Scrum и Agile. Но если это не сработает, вы, по крайней мере, сможете попрактиковаться в Scrum и пополнить свой послужной список неплохими (хотя и не выдающимися) результатами.
Я могу понять, как планирование спринта работает после того, как команда придумала свои оценки, но мне неясно, из чего эти оценки исходят. Как команды оценивают задачи?
Есть много различных способов оценки задач. Наиболее популярный из числа используемых scrum-командами – это покерное планирование, одна из общепринятых практик Scrum (GASPs)[46]. Такое планирование изобрел Джеймс Греннинг, соавтор Agile-манифеста. Метод стал популярным благодаря книге Майка Кона Agile Estimating and Planning. Вот как он работает.
В начале покерного планирования все оценщики получают по колоде карт. На каждой карточке написана одна из допустимых оценок. Оценщикам может быть, например, дана колода карт, которая включает 0, 1, 2, 3, 5, 8, 13, 20, 40 и 100. Карты должны быть подготовлены до проведения собрания по планированию, и цифры следует написать достаточно крупно, чтобы можно было видеть их на расстоянии. Карты можно использовать для повторных сессий покерного планирования.
Модератор поочередно читает описание каждой пользовательской истории или темы, которые должны быть оценены. Эту роль обычно поручают владельцу продукта или аналитику. Однако можно назначить на эту роль и любого другого человека, поскольку она не дает никаких особых привилегий. Владелец продукта отвечает на любые вопросы, которые задают оценщики.
После того как все вопросы заданы и все ответы получены, каждый оценщик выбирает из своей колоды карту, которая отражает его мнение. Карты не открывают, пока каждый оценщик не сделает свой выбор. Затем все карты одновременно переворачиваются, чтобы все участники могли увидеть оценки, данные другими.
Очень может быть, что разброс оценок будет велик. Это действительно хорошая новость. Если оценки разные, то оценщики объясняют, почему поставили высокие или низкие оценки. Важно, чтобы это не вызывало атак на авторов этих оценок. Вместо этого вы просто хотите узнать, о чем они думали.
Покерное планирование очень эффективно, поскольку помогает людям воспользоваться накопленным опытом и объединить мнения и оценки всей команды в одно число. Значения карт не являются жестко фиксированными. Например, в прошлом некоторые команды использовали карточки с числами из последовательности Фибоначчи – 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, однако они не совсем удобны, потому что разница между соседними значениями довольно велика. Необходимо, чтобы выбор был легче, чем решение, займет задача 13 или 21 час, а история – 5 или 8 очков.
Как вы управляетесь с территориально разнесенными и большими командами?
Это непростой вопрос. Распределение команды по офисам в разных точках мира создает большие сложности. Нельзя назвать их непреодолимыми – многие agile-команды создают программное обеспечение, даже если они не сидят в одном помещении. Но когда вы снижаете возможности общения лицом к лицу и полагаетесь на менее надежные формы коммуникации, вы рискуете получить в своем проекте большее число дефектов, вызванных искажениями при передаче информации, как в детской игре «испорченный телефон».
Один из способов справиться с этой проблемой состоит в том, чтобы разделить крупные разнесенные scrum-команды на небольшие scrum-группы, работающие в одном офисе. Помимо ежедневных scrum-митингов они также планируют дополнительные ежедневные совещания (scrum-of-scrums), где члены каждой команды, собравшись вместе, отвечают на три вопроса. Используя бэклог своей команды, они самоорганизуются для работы над глобальным проектом и могут создавать друг для друга новые задачи, чтобы процесс интеграции работы каждой группы в общий проект был легким. Этот способ эффективен, потому что формирует для всей большой команды ее укрупненный план работ, который проверяется каждый день.
Scrum-of-Scrums – это не «серебряная пуля» и не решит всех или хотя бы большинства проблем больших территориально разнесенных команд. Самая большая трудность для такой команды заключается в поддержании каждого члена команды мотивированным общей целью. Как нам уже известно из главы 4, это главным образом достигается тем, что члены команды становятся «свиньями», а не «курами». Хотя безусловно можно сделать это независимо от удаленности членов команды друг от друга, гораздо более сложно для владельца продукта сделать так, чтобы у всех существовало единое видение задач. Потому что он должен передать его другим через разные часовые пояса при помощи телеконференций и электронной почты, а это гораздо труднее, чем при личном общении.
Я понимаю, что ежедневные scrum-митинги обеспечивают работу людей над правильными задачами. Но даже добросовестные разработчики способны увязнуть во второстепенных делах. Может ли нечто подобное произойти со scrum-командами?
Да, может. Основатель Scrum Джефф Сазерленд совсем недавно опубликовал вместе со Скоттом Дауни документ[47] под названием «Метрики для сверхпроизводительных scrum-команд», касающийся именно этой темы. Они работали со многими scrum-командами, чтобы определить набор параметров, позволяющий точно выяснить, насколько в действительности продуктивны «сверхпроизводительные» команды. Обнаружилось, что эффективная scrum-команда может выполнять проекты до пяти раз быстрее, чем обычная. И удержание разработчиков на главном направлении разработки имеет много общего с получением этого улучшения.
Сазерленд и другие scrum-лидеры постоянно ищут способы улучшить эту методику. Одна из многих интересных мыслей в этой статье заключается в том, что небольшая корректировка ежедневного scrum-митинга, направленная на удержание разработчиков в рамках наиболее ценных задач, создает значительную разницу в том, насколько успешно работает команда. Внесенные ими изменения состояли в том, что команда отвечала на различные вопросы по каждому элементу бэклога спринта, начиная с первого по порядку:
• Чего мы вчера достигли для истории первого элемента?
• Каков был наш вклад в историю первого элемента, выраженный в очках историй?
• Каков наш план по выполнению истории первого элемента сегодня?
• Что делать, если сегодня что-то блокирует нашу работу или замедляет ее?
Команда работает вместе, чтобы ответить на эти вопросы. Затем, вместо того чтобы поочередно опрашивать каждого ее члена, она движется по бэклогу спринта в порядке убывания важности задач, останавливаясь, когда закончится список или выйдет время ежедневного scrum-митинга.
Так почему этот процесс работает? Благодаря ежедневным scrum-митингам он удерживает членов команды от появления у них отстраненности (сквозь зевоту: «Я вчера работал над моим кодом, сегодня продолжаю над ним работать и завтра буду делать то же самое»). Митинги поддерживают всех в тонусе и фокусируют на приносимой командой ценности. Даже эффективные гибкие команды могут ненароком оступиться, если программисты чересчур увлекутся задачами, которые кажутся интересными им, отложив в сторону работу, важную для команды. Именно об этом заставляют думать всю команду приведенные выше вопросы.
Это возвращает нас к основной мысли, что scrum-митинг – фактически формальная совместная инспекция (подобная тем, о которых вы, возможно, слышали в университетском курсе по разработке ПО), цель которой – улучшить качество командного планирования и коммуникаций. Просто она проводится так, чтобы быть интересным и полезным занятием для команды.
Это одна из наилучших составляющих Scrum, потому что она постоянно развивается, а ведущие специалисты по этой методике могут вносить свой вклад в ее постоянное совершенствование.
Предлагаем несколько вариантов действий, которые вы можете предпринять уже сегодня (самостоятельно или вместе с командой).
• Если вы до сих пор не применяете пользовательские истории, то возьмите одну функцию, которую вы в настоящее время создаете, и напишите пользовательскую историю для нее. Поделитесь ею с остальными членами команды – что они думают об этом?
• Попробуйте покерное планирование уже сегодня и выделите время вместе с командой, чтобы попробовать оценить несколько задач текущего проекта. Вы можете напечатать карточки сами или купить их (свои мы приобрели в компании Mountain Goat Software – можно также попробовать их онлайновую игру по покерному планированию).
• После того как вы сформировали оценку, воспользуйтесь доской или прикрепите большой лист бумаги на стену и приступите к созданию диаграммы сгорания работ. Как долго вы сможете поддерживать ее актуальной? Обратите внимание на то, что происходит на графике в конце проекта или итерации.
• Можете ли вы проанализировать ваш последний проект или итерацию и оценить скорость работы?
Ниже перечислены ресурсы, которые помогут вам узнать больше об идеях, описанных в этой главе.
• Вы можете узнать больше о Scrum и коллективных обязательствах в книге Кена Швабера Agile Project Management with Scrum (Microsoft Press, 2004).
• Вы узнаете больше о пользовательских историях и общепринятой scrum-практике в книге Майка Кона «Пользовательские истории. Гибкая разработка программного обеспечения» (М.: Вильямс, 2012).