Избегайте личностных конфликтов
Механики безусловно представляют собой важную часть подготовки спринта, однако гораздо большую угрозу представляют собой межличностные отношения. Планирование непосредственно связано с отношениями между членами команды, и всегда есть много моментов, которые могут пойти и, скорее всего, пойдут не так, как надо.
• Потеря интереса. Планирование должно быть быстрым, интересным и мотивирующим. Обычно если команде скучно, это значит, что команда либо не видит пользы в планировании, либо же Скрам-мастер не сумел заинтересовать ее участников. Несколько наиболее распространенных причин включают отсутствие понимания того, что требуется от команды, а также эгоистическое поведение отдельных участников, которые хотят, чтобы оставшиеся участники беспрекословно следовали их указаниям.
• Споры. Здоровое обсуждение – важная часть планирования, но споры исключительно контрпродуктивны и очень отвлекают от насущных задач. Не забывайте, что на этом шаге главное действующее лицо – это владелец продукта, от решений которого зависит то, как будет действовать команда.
• Фрустрация. Дайте команде возможность быть услышанной! Есть мало вещей, которые столь же контрпродуктивны и раздражающи, как игнорирование. Члены команды несут ответственность за реализацию проекта, и без них появление продукта будет невозможным. Поэтому, если любой из них хочет что-то сказать, лучше дать им такую возможность.
• Поиск решений. Если команда разработчиков начинает вдаваться в большое количество деталей при планировании, то существует вероятность того, что они пытаются найти решение. Задача планирования заключается в том, чтобы решить, что команда может выдать в конце спринта. Подробности того, как это сделать, лучше оставить для следующих этапов.
• Давление. Не стоит заставлять команду браться за большее количество работы, чем она может выполнить. Члены команды должны сами определить объемы работ. Это священное право членов команды, и его стоит беречь: если команда постоянно будет браться за слишком масштабные задачи или перетруждаться, последствия будут отрицательными.
Выработка хороших практик
Скрам-мастер несет ответственность за налаживание взаимоотношений между участниками и за формальные составляющие фазы планирования, но выработка хороших практик является коллективной задачей. Скрам-мастер должен стараться предотвратить возникновение плохих практик, но если это произойдет, то команде придется приложить усилия, чтобы преодолеть их. Один человек не может нести ответственность за работу всего коллектива.
• Никогда не переходите к планированию в отсутствие Владельца продукта и представителей ключевых отраслей.
• Избегайте соблазна принять плохо написанные или неподготовленные пользовательские истории, даже если вам кажется, что у вас будет время доработать их в дальнейшем.
• Не пытайтесь спасти ситуацию, интерпретируя истории, пытаясь связать их и вырабатывая критерии оценки на лету.
• Убедитесь в том, что все проблемы и возможные вопросы разрешены прежде, чем вы будете двигаться дальше. Иногда Владельцу продукта и команде может потребоваться для этого время.
• Если процесс забуксовал, примите меры. Старайтесь сохранять темп. Перейдите к следующему этапу и, если нужно будет, вернитесь к проблемному этапу позже.
• Не разрешайте никому и особенно Скрам-мастеру решать за команду, что делать и диктовать другим свои решения.
Блистательный пример
Скрам-команда выпустила новый электронный инструмент для управления корпоративными данными, и Владелец продукта запросил добавление новой функциональности. Во время планирования спринта ведущий IT-специалист оценил, что для реализации функциональности понадобится не больше 10 минут. Несмотря на то что график спринта был уже довольно напряженным, команда согласилась включить в работу эту небольшую задачу. На практике оказалось, что для реализации задачи требуется имплементация нескольких сложных процессов. Понадобились дни, чтобы учесть все возможные проблемы и провести необходимые тесты. Причиной было то, что представители команды по тестированию не присутствовали при планировании.
Небольшое изменение так и не удалось реализовать в ходе спринта, и две другие исключительно важные задачи пострадали от этого. Отсутствие представителей команды по тестированию означало, что решение было принято на основе недостаточной информации. Соответственно, невзирая на все старания, спринт закончился неудачей.
Владелец продукта был крайне недоволен, но вся команда получила очень полезный урок: в отсутствие представителей всех направлений вы можете полагаться только на удачу, а она улыбается далеко не всегда.
Рабочий процесс
Как только планирование завершено, наступает время для самой работы. С точки зрения команды, то, что происходит в это время, очень зависит от самой сути проекта. Главная цель команды – выпустить тот продукт, который был запланирован и утвержден. Скрам-мастер в это время играет важную роль, помогая команде следующим образом.
• Сохранение заданного темпа. Это кажется очевидным, но слишком часто упускается из виду. Всем ясно, что именно они должны делать? Нужна ли команде какая-то дополнительная информация? Чего члены команды ожидают друг от друга, как связана работа одних с другими? Даже опытным специалистам может понадобиться напоминание, что нужно обсуждать проблемы. Скрам-мастеру придется постоянно разрешать эти вопросы.
• Устранение препятствий (блокеров). Это наиболее широко известная задача Скрам-мастера и вопрос номер один на ежедневной встрече: есть ли у вас какие-то затруднения? Речь идет о том, что нужно сделать, чтобы работа шла постоянно. Задачи могут приходить в любой форме, от распутывания проводов под столами до помощи Владельцу продукта в составлении отчета для старшего руководства.
• Обеспечение обмена информацией. В обе стороны – как из команды, так и в команду. От команды ожидается информация обо всех взаимодействиях, трудностях и, разумеется, отчеты о ходе работы. В свою очередь, команда разработчиков будет ожидать ответы на вопросы со стороны владельца продукта и ясный и доступный журнал. Содействие этому двустороннему потоку информации, работа с людьми и обработка всех данных могут занимать весь рабочий день и быть непростой задачей.
• Отслеживание прогресса. Диаграмма сгорания и диаграмма сжигания – два наиболее полезных инструмента для отслеживания прогресса проекта. Диаграмма сгорания показывает, сколько задач осталось сделать, а диаграмма сжигания – сколько работы было уже сделано. Мы рекомендуем использовать как минимум диаграмму сгорания задач и обновлять ее на ежедневной основе.
• Подготовка к следующему спринту. Обновляется ли журнал регулярно? Хорошо ли сформулированы и проработаны пользовательские истории? Зарезервированы ли необходимые помещения для следующей встречи и приглашены ли на них необходимые люди? Все ли нормально с логистикой проекта? Ничего сложного, но это постоянно требующие внимания вопросы, за которыми нужно следить для избежания неприятных ситуаций. Лучше все продумать наперед.
Блистательный пример
Для отслеживания и демонстрации прогресса работы наиболее широко применяется диаграмма сгорания задач. Эта диаграмма показывает, сколько задач осталось до завершения спринта. На диаграмме изображены два графика:
• история выполнения задач во времени;
• целевая линия выполнения задач.
Начальная точка – это все задачи, которые должны быть выполнены за отведенное время. На рисунке ниже точками показана диагональная линия, начинающаяся от суммарной оценки задач до нуля, проходящая через все время, отведенное на спринт. Это целевая линия выполнения задач, на которую и следует опираться.
Упрощенно, если линия, отображающая прогресс работы, окажется выше этой диагонали – значит, налицо отставание от графика, а если ниже – команда выполняет работу раньше срока.
Точки, которые соединяет пунктирная линия, – это количество оставшейся работы. Как только задача выполнена, ее «стоимость» в баллах сложности отнимается от прошлого числа и отображается на графике. Некоторые задачи могут не быть выполнены в срок, поэтому график наверняка не получится ровным.
На примере ниже видно, что вначале команда испытывала некие трудности, но смогла завершить работу вовремя. Нет ничего необычного в том, что прогресс отклоняется от идеальной линии – но любые заметные отклонения свидетельствуют о том, что дела идут слишком хорошо или очень плохо.
Рис. 6.1. Блистательная диаграмма сгорания задач
Блистательная мысль
Если в конце спринта вас могут ожидать плохие новости, например, связанные с невыполнением поставленных задач, то владелец продукта должен узнать об этом как можно раньше, чтобы ожидания всех сторон соотносились с реальной ситуацией. Никогда не забывайте о важности перспективы.
