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