Коучи понимают, как люди учатся
Хорошая модель освоения чего-либо (если освоение в принципе возможно) пришла из боевых искусств. Ученик боевых искусств проходит через три этапа мастерства, которые называются «сю», «ха» и «ри». «Сю» означает «следуй правилу». «Ха» – «ломай правила». «Ри» – «будь правилом».
Лисса Адкинс. Coaching Agile Teams: A Companion for ScrumMasters
Кент Бек, автор книги Extreme Programming Explained, описывал применение экстремального программирования (ХР), используя аналогичные уровни. Когда его спросили об ХР и пяти уровнях «модели зрелости возможностей», разработанных Институтом программной инженерии, он ответил, что ХР имеет три уровня зрелости:
1. Делайте все, как написано.
2. После того как работа выполнена, экспериментируйте с вариациями в правилах.
3. В итоге не беспокойтесь о том, соответствуете вы ХР или нет.
Алистер Кокберн. «Быстрая разработка программного обеспечения».
Вернемся к , в которой мы узнали, как по-разному люди воспринимают Agile. Так же как слепой, встретивший слона, каждый человек по-своему ответит на вопрос «что такое Agile?».
Разработчик, знающий о таких ХР-практиках программирования, как разработка через тестирование и инкрементальный дизайн, решит, что Agile – это о разработке ПО, его проектировании и архитектуре. Менеджер проекта, прочитав о scrum-спринтах, планировании, бэклоге и ретроспективах, подумает, что Agile – это об улучшении практик управления проектами.
Чтобы объяснить суть Scrum, ХР, Lean и Канбана, потребовались сотни страниц. Мы говорили о мировоззрении, ценностях, принципах и практиках. И показали вам, как использовать их все вместе, чтобы помочь команде поставлять большую ценность для клиентов. Мы объяснили, что вы можете сделать сегодня, чтобы помочь команде. Мы предложили инструменты (например, неоднократное повторение вопроса «считаете ли вы это нормальным?»), чтобы помочь вашей команде изменить мировоззрение и для изучения Agile, понимания Scrum, XP, Lean и Канбана.
Это не тот способ, которым большинство людей внедряют Agile.
Как было бы хорошо, если бы все разработчики мира купили и прочли нашу книгу. Но, к сожалению, большинство людей изучают Agile не при помощи книг. Они учатся на практике. И проще всего выполнять задачу, если она разбита на небольшие части.
Другими словами, когда люди пытаются освоить Agile, они хотят получить список простых правил, который поможет им быстрее и качественнее создавать программное обеспечение.
Если вы новичок в agile-коучинге, то это может вызвать у вас разочарование. Представьте, что вы пытаетесь научить команду внедрять Scrum. Из вам известно, что если кто-то не понимает принципа самоорганизации и коллективной ответственности, то у него не получится Scrum. Поэтому вы тратите время, объясняя такие scrum-ценности, как мужество, приверженность, уважение, сосредоточенность и открытость, и то, как работает самоорганизация. Но команда разочарована, потому что это очень абстрактные понятия. Люди хотят поговорить о доске задач и пользовательских историях. Вы стремитесь научить их Scrum, а они, по всей видимости, полны решимости удовлетвориться результатом «лучше-чем-ничего». И ничего с этим не поделаешь. Так что же происходит?
Есть старая поговорка об учениках: встречайте их там, где они находятся, а не там, где бы вы хотели, чтобы они вас ждали. Хороший agile-коуч понимает, как происходит процесс обучения, и предлагает людям информацию, поддержку и примеры, помогающие подняться на следующую ступень знаний. Коучи знают, что люди не меняются в одночасье.
В уже упоминавшейся книге «Быстрая разработка программного обеспечения» Алистер Кокберн рассказывает об основной идее обучения, которая называется «сюхари». Это очень ценный инструмент коуча, старающегося понять, где команда находится в текущий момент. «Сюхари» взята из боевых искусств, но это хороший способ подумать о том, как вообще происходит процесс обучения.
В «сюхари» различают три этапа обучения. Первый этап, «сю» (守, «повиновение» или «наблюдение»), описывает мышление человека, впервые сталкивающегося с новой идеей или методикой. Ученик хочет получить простые правила, которым может следовать. Именно поэтому люди чаще всего держатся за практики: команда может создать правило внедрения спринтов, заниматься парным программированием, использовать доску задач и т. д. И каждый может сказать, соблюдается или нет правило, о котором идет речь.
Правила особенно важны для взрослых, потому что, в отличие от детей, они не привыкли постоянно познавать новое. Предлагая тому, кто изучает новую систему – например, Agile, – простые правила, вы даете возможность начать их применять. Несложные практики, являющиеся частью таких методологий, как Agile, Scrum, XP и Канбан, хорошо подходят тем, кто находится на этапе «сю», потому что благодаря своей простоте дают возможность людям сосредоточиться на оттачивании мастерства. Установив для команды правило (например, «ежедневно в 10:30 проходит scrum-митинг, где каждый отвечает на три вопроса»), вы можете направить ее по верному пути для изучения принципа («мы используем принцип самоорганизации для постоянного анализа и коррекции плана»).
Цель коуча – не в навязывании слепой веры в чудо Agile. Фанатик Agile – это тот, кто решил, что каждая команда имеет только один способ применения этой методологии. И он назойливо навязывает его всем и каждому. Адепты Agile, как правило, сосредоточиваются только на тех правилах, которые поняли, и останавливаются на уровне «сю». Они считают, что все проблемы можно решить при помощи усвоенного и проповедуемого ими правила. Из agile-фанатиков не получается хороших коучей, потому что они не тратят время на попытки понять, где находятся люди, которых они обучают.
Чтобы привести нас к этапу «сюхари» – «ха», agile-коуч должен подняться выше понимания простых правил (破, «обособление» или «перелом»). Это этап, где люди уже овладели правилами и могут усваивать принципы, которые управляют ими. На протяжении всей книги мы повторяли, насколько эффективно для изменения мировоззрения команды внедрение практик и как через них (и многочисленные командные обсуждения) приходит понимание ценностей и принципов методологии. Когда команда достигает уровня «ха», она начинает двигаться от результата «лучше-чем-ничего» к реальному приросту производительности. А он возможен, когда все разработчики действительно приняли мировоззрение Agile.
Мы еще ничего не сказали об этапе «ри» (離, «освобождение от правил»). Когда вы достигаете этого уровня обучения, вы в совершенстве владеете идеями, ценностями и принципами и меньше заботитесь о методологии, потому что продвинулись гораздо дальше. Если появляется проблема, которую можно решить при помощи определенной практики, то команда просто выполняет ее. Вас действительно не волнует, Scrum ли это, XP, Канбан или каскадная модель. Потому что ваш процесс не нуждается в имени. Но это не тот хаос, который характерен для команд, где никогда не пытались использовать Agile. Команда, в которой каждый достиг этапа «ри», – это отлаженная, хорошо функционирующая производственная единица, где каждый делает то, что ему положено.
Кокберн отмечает, насколько «удручающим дзеном» это может прозвучать. В книге «Быстрая разработка программного обеспечения» он рассказывает, как люди в стадии обучения «ри» говорят то, что трудно понять ученикам, находящимся на этапе «сю»:
«Делайте все, что работает».
«Когда вы действительно делаете это, вы не отдаете себе отчет, что вы это делаете».
«Используйте методологию до тех пор, пока она приносит хороший результат».
Для того, кто находится на уровне освобождения от правил, это полностью верно. А тех, кто еще только пытается разобраться, это сбивает с толку. Тем же, кто ищет порядка, это не принесет пользы.
Хороший коуч первым делом выясняет у каждого члена команды, каков текущий этап обучения. Если люди находятся на уровне «ри», то с ними легко работать, потому что каждый член команды знает, как учиться, и готов адаптироваться к новым практикам.
И наоборот, на уровне «сю» все хотят иметь однозначные правила. Вы используете стикеры или карточки на доске задач? Как коучу вам известно, что на самом деле это не имеет значения. Но тот, кто никогда не использовал доску задач, понятия не имеет, важно это или нет. Поэтому ваша цель – дать ему правило. Позже с вашей помощью он поймет, почему вы выбрали стикеры, и узнает, что карточки также подойдут. Просто они немного разные – например, на карточке можно писать с обеих сторон, а на стикере только с одной. И вы будете использовать сходства и различия, чтобы члены команды разобрались, как стикеры и карточки реализуют одни и те же принципы.
Используйте «сюхари», чтобы помочь команде понять ценности методологии
Вновь обратимся к ситуации, когда разочарованный коуч старается «внедрить» Scrum. «Сюхари» поможет понять, почему команда разочаровывается, пытаясь осознать ценности, и почему хочет говорить только о наиболее значимых практиках: досках задач и пользовательских историях. Доску задач или пользовательскую историю нетрудно представить в качестве этапа «сю» данной концепции: простое правило, которое можно начать применять прямо сегодня. Scrum полон подобных правил («встречайтесь каждый день и отвечайте на три вопроса»). В этом причина, что команды успешно внедряют scrum-практики.
Такие ценности, как открытость и приверженность, – это уже идеи уровня «ха»: абстрактные понятия, управляющие тем, как вы используете правила в системе. Самоорганизация и коллективные обязательства возможны только тогда, когда каждый член команды действительно понял и усвоил эти ценности. «Сюхари» помогает понять, почему команда должна пройти через применение практик, прежде чем сможет отказаться от них и осознать, что на самом деле понимается под открытостью и приверженностью.
Именно поэтому внедрение практик Scrum – очень эффективный первый шаг в оказании помощи команде, пытающейся постичь ценности этой методологии. Хороший коуч терпелив и во время каждого спринта ждет подходящего момента, чтобы рассказать команде о ценностях. Часто такая возможность возникает тогда, когда два человека имеют разные точки зрения на аспекты «слона» Scrum.
Предположим, разработчик обнаруживает в середине спринта, что функциональность не будет закончена. На ближайшем scrum-митинге он просит владельца продукта перенести ее разработку на следующий спринт. Владелец продукта рассержена. Она боится гнева клиента или менеджера по этому поводу и требует, чтобы разработчик «сделал все возможное» для реализации функционала – даже за счет «срезания углов» и отсутствия законченного кода. На эту проблему есть ответ на уровне «сю»: правила Scrum диктуют, что команда должна демонстрировать только полностью готовый программный продукт, а незаконченная версия передвигается в следующий спринт. Agile-коуч знает правила Scrum и может использовать их для разрешения конфликта.
Кроме того, agile-коуч также видит, что есть возможность для обучения уровню «ха». Признав существование раздробленного видения (об этом мы говорили в ), которое может стать целостным, коуч поможет владельцу продукта взглянуть на проблему с точки зрения разработчика: некачественное выполнение работы увеличит технический долг, а это приведет к сложностям в поддержании всей кодовой базы. Технический долг, в свою очередь, станет причиной удлинения спринтов. Таким образом, хотя владелец продукта и может быстрее поставить функционал клиенту, игнорируя правила Scrum, в итоге команда окажется в худшем положении, потому что дальнейшая разработка будет протекать более медленно. Это важный урок, который поможет владельцу продукта узнать больше о такой scrum-ценности, как сосредоточенность, и о том, как команда, сфокусировавшая свое внимание на завершении работы, быстрее получит более качественный продукт.
Коуч также может помочь разработчику понять, насколько важна эта функциональность и как она обеспечивает ценность для клиентов. Кроме того, команда узнает, как в дальнейшем лучшее понимание ценности поможет ей установить более тесный контакт с владельцем продукта, чтобы найти способ разбить функционал на мелкие части и поставлять клиентам больше ценности максимально быстро. Этот важный урок даст возможность разработчику подробнее узнать о такой scrum-ценности, как обязательство, а также о том, как команда становится эффективнее, если понимает, что действительно важно для клиентов.
Это пример того, как коуч с глубоким пониманием методологии выполняет важную роль в команде. Он помогает ей понять и принять методы и правила методологии. И через них может помочь каждому члену команды усвоить ценности Agile. А используя эти ценности, он поможет каждому человеку и команде в целом развить в себе гибкое мировоззрение.
