Дженнифер Грин - Постигая Agile

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

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

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

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

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

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

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

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

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