Избегайте личностных конфликтов

Механики безусловно представляют собой важную часть подготовки спринта, однако гораздо большую угрозу представляют собой межличностные отношения. Планирование непосредственно связано с отношениями между членами команды, и всегда есть много моментов, которые могут пойти и, скорее всего, пойдут не так, как надо.

 

• Потеря интереса. Планирование должно быть быстрым, интересным и мотивирующим. Обычно если команде скучно, это значит, что команда либо не видит пользы в планировании, либо же Скрам-мастер не сумел заинтересовать ее участников. Несколько наиболее распространенных причин включают отсутствие понимания того, что требуется от команды, а также эгоистическое поведение отдельных участников, которые хотят, чтобы оставшиеся участники беспрекословно следовали их указаниям.

• Споры. Здоровое обсуждение – важная часть планирования, но споры исключительно контрпродуктивны и очень отвлекают от насущных задач. Не забывайте, что на этом шаге главное действующее лицо – это владелец продукта, от решений которого зависит то, как будет действовать команда.

• Фрустрация. Дайте команде возможность быть услышанной! Есть мало вещей, которые столь же контрпродуктивны и раздражающи, как игнорирование. Члены команды несут ответственность за реализацию проекта, и без них появление продукта будет невозможным. Поэтому, если любой из них хочет что-то сказать, лучше дать им такую возможность.

• Поиск решений. Если команда разработчиков начинает вдаваться в большое количество деталей при планировании, то существует вероятность того, что они пытаются найти решение. Задача планирования заключается в том, чтобы решить, что команда может выдать в конце спринта. Подробности того, как это сделать, лучше оставить для следующих этапов.

• Давление. Не стоит заставлять команду браться за большее количество работы, чем она может выполнить. Члены команды должны сами определить объемы работ. Это священное право членов команды, и его стоит беречь: если команда постоянно будет браться за слишком масштабные задачи или перетруждаться, последствия будут отрицательными.

Выработка хороших практик

Скрам-мастер несет ответственность за налаживание взаимоотношений между участниками и за формальные составляющие фазы планирования, но выработка хороших практик является коллективной задачей. Скрам-мастер должен стараться предотвратить возникновение плохих практик, но если это произойдет, то команде придется приложить усилия, чтобы преодолеть их. Один человек не может нести ответственность за работу всего коллектива.

• Никогда не переходите к планированию в отсутствие Владельца продукта и представителей ключевых отраслей.

• Избегайте соблазна принять плохо написанные или неподготовленные пользовательские истории, даже если вам кажется, что у вас будет время доработать их в дальнейшем.

• Не пытайтесь спасти ситуацию, интерпретируя истории, пытаясь связать их и вырабатывая критерии оценки на лету.

• Убедитесь в том, что все проблемы и возможные вопросы разрешены прежде, чем вы будете двигаться дальше. Иногда Владельцу продукта и команде может потребоваться для этого время.

• Если процесс забуксовал, примите меры. Старайтесь сохранять темп. Перейдите к следующему этапу и, если нужно будет, вернитесь к проблемному этапу позже.

• Не разрешайте никому и особенно Скрам-мастеру решать за команду, что делать и диктовать другим свои решения.

 

Блистательный пример

Скрам-команда выпустила новый электронный инструмент для управления корпоративными данными, и Владелец продукта запросил добавление новой функциональности. Во время планирования спринта ведущий IT-специалист оценил, что для реализации функциональности понадобится не больше 10 минут. Несмотря на то что график спринта был уже довольно напряженным, команда согласилась включить в работу эту небольшую задачу. На практике оказалось, что для реализации задачи требуется имплементация нескольких сложных процессов. Понадобились дни, чтобы учесть все возможные проблемы и провести необходимые тесты. Причиной было то, что представители команды по тестированию не присутствовали при планировании.

Небольшое изменение так и не удалось реализовать в ходе спринта, и две другие исключительно важные задачи пострадали от этого. Отсутствие представителей команды по тестированию означало, что решение было принято на основе недостаточной информации. Соответственно, невзирая на все старания, спринт закончился неудачей.

Владелец продукта был крайне недоволен, но вся команда получила очень полезный урок: в отсутствие представителей всех направлений вы можете полагаться только на удачу, а она улыбается далеко не всегда.

Рабочий процесс

Как только планирование завершено, наступает время для самой работы. С точки зрения команды, то, что происходит в это время, очень зависит от самой сути проекта. Главная цель команды – выпустить тот продукт, который был запланирован и утвержден. Скрам-мастер в это время играет важную роль, помогая команде следующим образом.

• Сохранение заданного темпа. Это кажется очевидным, но слишком часто упускается из виду. Всем ясно, что именно они должны делать? Нужна ли команде какая-то дополнительная информация? Чего члены команды ожидают друг от друга, как связана работа одних с другими? Даже опытным специалистам может понадобиться напоминание, что нужно обсуждать проблемы. Скрам-мастеру придется постоянно разрешать эти вопросы.

• Устранение препятствий (блокеров). Это наиболее широко известная задача Скрам-мастера и вопрос номер один на ежедневной встрече: есть ли у вас какие-то затруднения? Речь идет о том, что нужно сделать, чтобы работа шла постоянно. Задачи могут приходить в любой форме, от распутывания проводов под столами до помощи Владельцу продукта в составлении отчета для старшего руководства.

• Обеспечение обмена информацией. В обе стороны – как из команды, так и в команду. От команды ожидается информация обо всех взаимодействиях, трудностях и, разумеется, отчеты о ходе работы. В свою очередь, команда разработчиков будет ожидать ответы на вопросы со стороны владельца продукта и ясный и доступный журнал. Содействие этому двустороннему потоку информации, работа с людьми и обработка всех данных могут занимать весь рабочий день и быть непростой задачей.

• Отслеживание прогресса. Диаграмма сгорания и диаграмма сжигания – два наиболее полезных инструмента для отслеживания прогресса проекта. Диаграмма сгорания показывает, сколько задач осталось сделать, а диаграмма сжигания – сколько работы было уже сделано. Мы рекомендуем использовать как минимум диаграмму сгорания задач и обновлять ее на ежедневной основе.

• Подготовка к следующему спринту. Обновляется ли журнал регулярно? Хорошо ли сформулированы и проработаны пользовательские истории? Зарезервированы ли необходимые помещения для следующей встречи и приглашены ли на них необходимые люди? Все ли нормально с логистикой проекта? Ничего сложного, но это постоянно требующие внимания вопросы, за которыми нужно следить для избежания неприятных ситуаций. Лучше все продумать наперед.

 

Блистательный пример

Для отслеживания и демонстрации прогресса работы наиболее широко применяется диаграмма сгорания задач. Эта диаграмма показывает, сколько задач осталось до завершения спринта. На диаграмме изображены два графика:

• история выполнения задач во времени;

• целевая линия выполнения задач.

Начальная точка – это все задачи, которые должны быть выполнены за отведенное время. На рисунке ниже точками показана диагональная линия, начинающаяся от суммарной оценки задач до нуля, проходящая через все время, отведенное на спринт. Это целевая линия выполнения задач, на которую и следует опираться.

Упрощенно, если линия, отображающая прогресс работы, окажется выше этой диагонали – значит, налицо отставание от графика, а если ниже – команда выполняет работу раньше срока.

Точки, которые соединяет пунктирная линия, – это количество оставшейся работы. Как только задача выполнена, ее «стоимость» в баллах сложности отнимается от прошлого числа и отображается на графике. Некоторые задачи могут не быть выполнены в срок, поэтому график наверняка не получится ровным.

На примере ниже видно, что вначале команда испытывала некие трудности, но смогла завершить работу вовремя. Нет ничего необычного в том, что прогресс отклоняется от идеальной линии – но любые заметные отклонения свидетельствуют о том, что дела идут слишком хорошо или очень плохо.

 

Рис. 6.1. Блистательная диаграмма сгорания задач

 

Блистательная мысль

Если в конце спринта вас могут ожидать плохие новости, например, связанные с невыполнением поставленных задач, то владелец продукта должен узнать об этом как можно раньше, чтобы ожидания всех сторон соотносились с реальной ситуацией. Никогда не забывайте о важности перспективы.

 

Приближаясь к концу

Конец спринта всегда ближе, чем может показаться, и поэтому всегда стоит подготовиться к нему заранее. Скрам-мастер должен приготовить все для обзора продукта, ретроспективы для анализа действий команды и, конечно же, следующего спринта. Помимо планирования самих собраний необходимо учитывать вопросы, связанные с логистикой. Часто приходится прикладывать значительные усилия для того, чтобы собрать всех в одном месте и в одно и то же время.

В одном вы можете быть уверены наверняка: что-нибудь обязательно пойдет не по плану. Никто не может предсказать будущее, и поэтому невозможно предвидеть миллионы причин, которые могут нарушить план спринта. Начиная с непредвиденной болезни и заканчивая внезапным компьютерным вирусом, всегда будут вещи, которые сумеют сорвать самый совершенный план. Именно поэтому ключевой результат спринта – реализация договоренностей с владельцем продукта вместе с получением ценной обратной связи. Команда должна быть заинтересована в том, чтобы реализовать цели, поставленные в начале спринта, даже если для этого потребуется потратить чуть больше усилий, чем предполагалось первоначально.

За день или два до окончания спринта Скрам-мастеру следует перейти в состояние повышенной готовности и постараться определить список вопросов, которые должны быть разрешены для успешной реализации спринта.

Блистательная мысль

Планируйте заранее и старайтесь забронировать все, что нужно для Скрам-событий, как можно раньше, особенно когда речь идет о спринте, растянутом во времени. Старайтесь придерживаться одного и того же дня недели и того же времени. Постарайтесь сделать так, чтобы спринт стал частью привычного распорядка участников, и не меняйте этот распорядок без крайней нужды.

То же время и то же место – залог идеального спринта.

Это самое лучше время для того, чтобы обратить внимание группы на текущие проблемы и обсудить их в ходе ежедневной Скрам-встречи. Более того, это оптимальное время для определения и решения дополнительных проблем. Следите за поведением членов команды и обращайте особое внимание на тех, кто выглядит беспокойно или прячет глаза. Не забывайте задавать наводящие вопросы и помните, что Скрам-мастер является ключевым лицом в организации проекта, от деятельности которого зависят взаимоотношения команды разработчиков и Владельца продукта.

Конец спринта

Если результаты спринта не достигнуты, то это не очень хорошие новости, однако и не конец света. Конечно же, было бы неплохо понять, что именно пошло не так, и избежать этой проблемы в дальнейшем: этот принцип заложен в основу Agile с упором на наблюдения и адаптацию. И, конечно же, есть большая разница между факторами, которые невозможно контролировать (например, болезнью), и факторами, которые поддаются нашему контролю (например, разумное дозирование работы). Любые пользовательские истории, которые не были проработаны, могут быть перенесены на следующий спринт, но не стоит думать, что их проработка окажется легкой задачей. Обычно наилучшим подходом считается тот, при котором проработку этих историй придется начинать с нуля, чтобы избежать недооценки предстоящего массива работ.

Блистательная мысль

В конце каждого спринта общее количество баллов сложности выполненных пользовательских историй называют скоростью работы команды. Со временем средняя скорость становится более достоверным показателем.

Команда может в дальнейшем оценивать, сколько задач имеет смысл брать на следующий спринт.

В конце спринта вы уже имеете то, что имеете. К тому времени Скрам-мастер и опытные члены команды уже подумали о том, как прошел спринт, и сделали заметки о том, что прошло хорошо и плохо и на что нужно обратить особое внимание в следующий раз. Ведение этих заметок не обязательно должно быть буквальным – нет необходимости стоять у доски и измерять производительность труда.

Изучение уроков – жизненно важная составляющая гибкого процесса разработки, и лучшие Скрам-команды постоянно анализируют и улучшают свои рабочие практики. Мысленных замечаний обычно вполне хватает, и динамика взаимоотношений в команде представляет собой отличный источник информации. Как члены команды взаимодействуют друг с другом во время дневного Скрама? Как они разговаривают друг с другом и как обстоят дела в офисе? Кто настойчиво делает вид, что ему все равно, а кто явно обеспокоен? Что насчет групповой динамики, слухов и громких заявлений?

Стоит сосредоточиться на сообщении членов команды о том, что было закончено. Вне зависимости от того, какой был результат (или какого не было) – будут высказаны комментарии и вопросы. Иногда обсуждения продуктивности и результатов команды бывают даже слишком бурными. Наилучшая стратегия здесь – быть реалистами, однако картина сделанной работы должна быть позитивной. Расскажите о том, как прошел спринт и как вы пришли к этим результатам.

Окончание спринта – обычно самая напряженная и загруженная часть для Скрам-мастера и команды. Все напряжены, так как ожидания должны быть оправданы. Нужно осветить много тем, а еще потом предстоят обзор итогов, ретроспектива и планирование спринта. Важно, чтобы команда держалась вместе и стояла на своем, даже если ее приперли к стенке. Будьте профессиональны и последовательны; сосредоточьтесь на самых важных аспектах. Успокойтесь. Будьте терпеливы. И все будет хорошо.

Блистательный пример

Неопытному Скрам-мастеру необходимо выйти к группе из приблизительно 30 человек, включая нескольких высокопоставленных членов организации, которые ожидают оценки спринта, и сообщить им, что за последний трехнедельный спринт не была проработана ни одна пользовательская история. Скрам-мастер выглядит очень усталым после бессонной ночи, и очевидно, что ему очень неприятно сообщать о провале.

Невзирая на это, Скрам-мастер подробно объясняет, что произошло, и сообщает, какие выводы команда вынесла из спринта и как она собирается избегать неудач в дальнейшем. За этим следует нечто неожиданное. Начальство хвалит Скрам-мастера и его команду. Высокопоставленные члены организации оценили их честность и готовность учиться на ошибках. Более того, они предлагают им поддержку и ресурсы, чтобы выйти из этой ситуации.

Даже Скрам-проекты иногда терпят неудачи. Открытость – лучший подход в этих случаях, использование которого вызывает уважение. Всегда лучше выработать план по исправлению ошибок, чем потратить это время на придумывание оправданий.

 

Завершающие слова

Если в конце спринта Скрам-мастер и Владелец продукта выглядят спокойными, значит, дела идут хорошо. Мир и спокойствие – это священный Грааль Скрама: все его ищут, но мало кто находит. Когда Скрам работает хорошо, он выглядит очень легким в применении. В реальности идеал недостижим. Нет верного или неверного способа применять Скрам, но это всегда можно делать лучше. Даже если дела идут прекрасно, постоянно ищите способы для усовершенствования.

Скрам-команду в первую очередь будут оценивать по результату, но есть и другие положительные признаки. Один из них – полное взаимопонимание между командой разработки и владельцем продукта. Второй – самоорганизующаяся команда, способная принимать решения. Еще один – когда старшим менеджерам, конечным пользователям и прочим заинтересованным сторонам нравится, а главное, совершенно понятен ход работ над продуктом. Чего еще желать, если рабочий продукт выпускается в срок, ретроспективы выявляют только легко устранимые проблемы? Разве что не заскучать, почивая на лаврах.

Дух Скрама побуждает искать улучшения. В самом начале Скрам-проекта может быть очень много вариантов для совершенствования – иногда даже будет казаться, что некоторые проблемы слишком серьезные, но решать их интересно и даже иногда весело. Парадоксально, но и сам Скрам может стать препятствием. Команда может обнаружить, что именно эта методология сдерживает их дальнейшее развитие. Не все добираются до этой точки. Для большинства из нас важно искать что-то новое. Не останавливайтесь в своем поиске лучшего.

Именно практика приводит к совершенству.

Блистательный итог

• Устанавливайте планку высоко. Постоянно обновляйте журнал, выработайте критерии принятия и используйте в спринтах только хорошо написанные пользовательские истории.

• Скрам-мастер организует команду, помогает ей, разрабатывает новые практики и решает проблемы.

• Хорошие показатели помогают принимать взвешенные решения и обеспечивают отличный доклад.

• Не вмешивайтесь в работу команды – они прекрасно знают, как решить проблемы.

• Учитесь на ошибках и просчитывайте наперед.