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