Постигая Agile

Предположим, разработчик обнаруживает в середине спринта, что функциональность не будет закончена. На ближайшем scrum-митинге он просит владельца продукта перенести ее разработку на следующий спринт. Владелец продукта рассержена. Она боится гнева клиента или менеджера по этому поводу и требует, чтобы разработчик «сделал все возможное» для реализации функционала – даже за счет «срезания углов» и отсутствия законченного кода. На эту проблему есть ответ на уровне «сю»: правила Scrum диктуют, что команда должна демонстрировать только полностью готовый программный продукт, а незаконченная версия передвигается в следующий спринт. Agile-коуч знает правила Scrum и может использовать их для разрешения конфликта.

Кроме того, agile-коуч также видит, что есть возможность для обучения уровню «ха». Признав существование раздробленного видения (об этом мы говорили в главе 2), которое может стать целостным, коуч поможет владельцу продукта взглянуть на проблему с точки зрения разработчика: некачественное выполнение работы увеличит технический долг, а это приведет к сложностям в поддержании всей кодовой базы. Технический долг, в свою очередь, станет причиной удлинения спринтов. Таким образом, хотя владелец продукта и может быстрее поставить функционал клиенту, игнорируя правила Scrum, в итоге команда окажется в худшем положении, потому что дальнейшая разработка будет протекать более медленно. Это важный урок, который поможет владельцу продукта узнать больше о такой scrum-ценности, как сосредоточенность, и о том, как команда, сфокусировавшая свое внимание на завершении работы, быстрее получит более качественный продукт.

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

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

Коучи понимают, что делает методологию работающей

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

В частности, как коуч смог в конкретной конфликтной ситуации, о которой мы рассказали выше, увидеть возможность объяснить команде о таких scrum-ценностях, как сосредоточенность и обязательство? Относились ли эти ценности к данной конкретной проблеме?

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

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