Рисунок 16.7 – План сезона с учетом неопределенностей
Альтернативный вариант – представить план в виде таблицы, где спринты перечислены последовательно слева направо. Важно сделать его наглядным: полученные данные используются для прогнозирования взаимозависимостей.
Нет смысла быть сверхточным в прогнозировании того, что будет только через несколько спринтов. Это можно отразить в плане, ограниченном лишь рамками сезона.
В план добавлены неопределенности: они расположены на соответствующих границах.
Другой способ изображения неопределенностей в плане – представить бэклог тремя зонами (рисунок 16.8): что точно будет завершено с учетом максимальной скорости команды, что точно не будет завершено с низкой скоростью – и зона неопределенности между ними.
Рисунок 16.8 – Бэклог с зоной неопределенности
Лучше быть правым в целом, чем неправым в конкретном. План предназначен для ответа на важнейшие вопросы, а не для микроменеджмента.
Вернемся к первым вопросам команды Peetic.
– Сможем ли мы использовать управление подписками для выставки собак в марте?
Да. В плане представлены функциональности, и это одна из функциональностей, которые команда обязательно реализует.
– Через сколько времени мы сможем анонсировать запуск приложения на планшет?
Эта функциональность запланирована на следующий сезон, который завершится в августе.
– Какой бюджет необходим для разработки версии 2 приложения?
Команда Peetic выбрала сезон с фиксированными датами. Бюджет обговаривается заранее, его легко определить на основе размера команды и продолжительности.
– Когда нам понадобится компонент онлайн-платежей?
Через два спринта, когда будет разработана функциональность корзина.
16.6 Антипаттерны
Ситуация. Те, кто привык к подробным спецификациям, считают, что сезон закончится, когда бэклог опустеет. Вот только он никогда не бывает пустым.
Последствия. Бэклог живет, развивается и представляет собой постоянно пополняемый поток. Стремиться к пустому бэклогу не стоит. Я знаю одну команду, которая пыталась этого добиться на протяжении 18 спринтов – и безуспешно!
Как сделать лучше? Использовать паттерн сезонного ритма, чтобы запланировать даты начала и окончания сезона. Планировать несколько сезонов наперед не имеет смысла.
Ситуация. Некоторые менеджеры, только узнавшие об Agility, с энтузиазмом набрасываются на концепцию скорости команды: ого, цифры, мы сможем их посчитать, контролировать, ставить планки, можем сравнивать команды и людей и т. д.
Последствия. Все уже перечислено выше. Скорость команды используется для давления на команду.
Бывает даже, что под контроль ставится индивидуальная скорость, что является полнейшей чепухой.
Скорость команды подразумевает всех участников, а не отдельных лиц.
Как сделать лучше? Поразмышлять, для чего необходимо измерение скорости команды и какие решения могут быть приняты на ее основе.
Ситуация. Команде кажется, что она слишком много времени тратит на оценку.
Последствия. У команды остается меньше времени на разработку, что обидно: ведь это важнее оценки.
Как сделать лучше? Поговорить об этом во время ретроспективы и предложить более простые способы оценки. Научиться разбивать работу на маленькие части (см. паттерн разделение в главе 8).
Ситуация. В погоне за прозрачностью команда публикует подробный план, включающий мельчайшие истории предстоящих спринтов. Заинтересованные стороны теряются в этом плане: истории для них слишком детальные.
Последствия. В плане нет смысла.
Как сделать лучше? Заинтересованные стороны лучше разбираются в функциональностях, чем в историях. С ними стоит общаться именно на уровне функциональностей.
Чтобы идти дальше
Книги
‣ Майк Кон, «Agile. Оценка и планирование проектов», Альпина Паблишер, 2021
‣ Vasco Duarte, NoEstimates, How to measure project progress without estimating, Oiko Sofy, 2014
17Ценность инструментов
Во Франции совершенно точно существует такая тенденция: сначала выбор информационно-технических средств, затем уже определение и овладение методом. На этот счет мне вспоминается одна большая компания в области аэронавтики, где целые армии разработчиков тратили время на оснащение метода инструментами – а сам метод еще не был освоен.
В этом плане Agile-методы – все же за здравый смысл: сначала приобщение к ценностям и практикам, а затем уже выбор инструмента.
Некоторые могут пойти еще дальше и интерпретировать первую строку из Agile-манифеста – люди и взаимодействие важнее процессов и инструментов – как совет вовсе не пользоваться инструментами во время Agile-разработки.
Люди важны в первую очередь. Но очевидно, что для разработки пригодятся инструменты. Они необходимы, например, для непрерывной интеграции и тестирования.
Что касается Scrum-инструментов, все зависит от контекста. К примеру, если вся команда находится в одном рабочем пространстве, она не так сильно нуждается в электронном ведении бэклога, как команда, чьи участники разбросаны по разным континентам.
Самое интересное, что Agile-методы пересматривают понятие инструментов. Ведь речь не только об электронных инструментах. Информационно-технические средства – это одно решение, обладающее множеством функций. Но (и именно этому учит Lean Startup) лучше сначала узнать, в чем проблема, прежде чем заниматься ее решением.
Цель этой главы – познакомить вас с инструментами, которые могут стать эффективными помощниками для Scrum-команды. Мы поговорим о компьютерных приложениях, а также играх, досках и, конечно, Post-it®.
17.1 Post-it®
О том, что в компании применяется Scrum, зачастую можно судить по цветным стикерам на стенах.
До появления Post-it® мы использовали обычные блоки для записей, это было обычным делом на ранних этапах работы над пользовательскими историями. Рон Джеффрис в посвященной этому статье вывел формулу 3С, где первая С означает Сard, то есть карточка, заметка.
Я использовал карточки для своих первых бэклогов. Это практично, их можно менять местами в зависимости от приоритетов, если ты Владелец продукта, и на обороте можно фиксировать основные моменты с собраний. Вот только ими сложно делиться с другими – разве что крепить на пробковую доску или приклеивать к стене.
Можно, например, использовать карточки с клейким краем, чтобы свободно их перемещать.
Когда в команде есть открытое рабочее пространство, да или просто стена – это наиболее эффективный инструмент для плодотворного общения между всеми участниками.
Их использование особенно рекомендуется для мониторинга спринта. Scrum-доска – это идеальное место для проведения ежедневных схваток.
Рисунок 17.1 – Война Post-it®
Post-it® легко клеятся и бывают разных цветов. Но, в отличие от обычных карточек, у них можно использовать только одну сторону, что вынуждает быть максимально кратким и писать большими буквами, чтобы написанное было видно издалека.
А еще они могут оторваться и улететь вместе с написанной на них информацией. Южный тулузский ветер – враг Post-it®. Однажды я решил открыть окно после собрания по планированию спринта – и в итоге все ползали на четвереньках в поисках разлетевшихся Post-it®.
Стикеры, ко всему прочему, упрощают коллективную и творческую работу во время собраний по подготовке первоначального бэклога.
Рисунок 17.2 – Владелец продукта собирает бэклог после рабочей встречи
Я советую всегда использовать Post-it® на рабочих встречах и по возможности – для таблицы спринта.
Это основа визуального менеджмента и прозрачности.
Если нужны еще доказательства того, что стикеры – это настоящий инструмент, советую ознакомиться со статьей Матти Шнайдера, который провел сравнительное исследование 23 моделей [50].
17.2 Информационные технологии
Судя по результатам опросов, наиболее используемым информационно-технологическим решением для Agile-проектов был и остается Excel. Что важно для бэклога: истории расположены в строках, а их характеристики – в колонках.
Я считаю, что использование электронных таблиц имеет множество изъянов. В первую очередь, этот инструмент не способствует обмену информацией между людьми в команде.
Онлайн-таблицы позволяют, пусть и частично, уменьшить этот недостаток.
Очень популярны инструменты для учета и контроля ошибок. Они основаны на тикетах, каждый из которых позволяет проследить жизнь ошибки от ее нахождения и до исправления. Некоторые команды, использовавшие багтрекеры до перехода к Scrum, продолжают ими пользоваться и пытаются встроить Scrum в устоявшийся рабочий процесс.
Так появляется риск смешения понятий: тикет для задачи или для истории? Вот почему я не рекомендую их использование для бэклога.
Есть много самых разных инструментов, посвященных Scrum, в том числе для ведения бэклога. Если немного поискать, можно найти сразу с десяток, а то и больше, что, вероятно, здорово вдохновляет. Цена входного билета, как говорится, невысока, зато у команды сразу появляется инструмент, который легко и просто ведет бэклог или содержит три колонки для спринта.