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

Как коуч вы должны признать, что это делается не по злому умыслу. Это естественная реакция человека, который никогда не видел, что такое настоящая Agile (но думает, что видел). Задача коуча – помочь команде понять, что Agile действительно отличается от всего того, что они до сих пор делали, а вовсе не «ерунда».

Вернемся к главе 2, в которой мы узнали, как по-разному люди воспринимают Agile. Так же как слепой, встретивший слона, каждый человек по-своему ответит на вопрос «что такое Agile?».

Разработчик, знающий о таких ХР-практиках программирования, как разработка через тестирование и инкрементальный дизайн, решит, что Agile – это о разработке ПО, его проектировании и архитектуре. Менеджер проекта, прочитав о scrum-спринтах, планировании, бэклоге и ретроспективах, подумает, что Agile – это об улучшении практик управления проектами.

Чтобы объяснить суть Scrum, ХР, Lean и Канбана, потребовались сотни страниц. Мы говорили о мировоззрении, ценностях, принципах и практиках. И показали вам, как использовать их все вместе, чтобы помочь команде поставлять большую ценность для клиентов. Мы объяснили, что вы можете сделать сегодня, чтобы помочь команде. Мы предложили инструменты (например, неоднократное повторение вопроса «считаете ли вы это нормальным?»), чтобы помочь вашей команде изменить мировоззрение и для изучения Agile, понимания Scrum, XP, Lean и Канбана.

Это не тот способ, которым большинство людей внедряют Agile.

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

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

Если вы новичок в agile-коучинге, то это может вызвать у вас разочарование. Представьте, что вы пытаетесь научить команду внедрять Scrum. Из главы 5вам известно, что если кто-то не понимает принципа самоорганизации и коллективной ответственности, то у него не получится Scrum. Поэтому вы тратите время, объясняя такие scrum-ценности, как мужество, приверженность, уважение, сосредоточенность и открытость, и то, как работает самоорганизация. Но команда разочарована, потому что это очень абстрактные понятия. Люди хотят поговорить о доске задач и пользовательских историях. Вы стремитесь научить их Scrum, а они, по всей видимости, полны решимости удовлетвориться результатом «лучше-чем-ничего». И ничего с этим не поделаешь. Так что же происходит?

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

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

В «сюхари» различают три этапа обучения. Первый этап, «сю» (守, «повиновение» или «наблюдение»), описывает мышление человека, впервые сталкивающегося с новой идеей или методикой. Ученик хочет получить простые правила, которым может следовать. Именно поэтому люди чаще всего держатся за практики: команда может создать правило внедрения спринтов, заниматься парным программированием, использовать доску задач и т. д. И каждый может сказать, соблюдается или нет правило, о котором идет речь.