Если вы обучаете много команд, то слышите одинаковые мнения от разных людей. Приведем несколько высказываний членов команды, которые могут свидетельствовать об их дискомфорте в связи с изменением, а также о том, что можно предпринять в такой ситуации. На все это полезно взглянуть с точки зрения коуча, даже если вы им не являетесь.
«Мы и так успешно разрабатываем программное обеспечение. Почему ты призываешь меня делать что-то по-другому?»
Трудно спорить с успехом. Если вы работаете с командой, которая имеет свою историю разработки ПО для клиентов, то у нее есть право знать, почему нужно меняться. Недостаточно просто сказать, что это решение руководства, – такое заявление ослабит моральный дух. Как коуч вы должны позитивно относиться к работе, которую проделала команда. Но не нужно стесняться указывать на недостатки. Практики в каждой методологии Agile направлены на решение проблем команды. Если вы сможете помочь понять, почему эти проблемы возникают, и предложить команде решения, то шансы, что они будут одобрены, возрастают.
«Это слишком рискованно».
Это очень распространенная реакция на Agile, особенно среди тех, кто привык к командно-административному стилю управления проектом. Где все эти буферы, реестр рисков, лишняя бюрократия, которая тормозит проект и дает возможность в случае чего спасти свою шкуру? План проекта может быть непрозрачным, что порой удобно для команды: им не нужно делиться деталями, кроме как при завершении отдельных этапов; они могут вставлять буферы в промежутках, чтобы уменьшить и даже ликвидировать неопределенность. При использовании отчетов о статусе в качестве основного показателя прогресса разработки вам удается контролировать информацию, которая поступает к пользователям и клиентам. Команды, работающие по таким принципам, чувствуют в Agile угрозу. В главе 3 упомянут agile-принцип, в котором говорится, что работающее программное обеспечение – основной показатель прогресса проекта. Если в agile-команде что-то идет не так, то все об этом знают. Задача agile-коуча – помочь менеджерам, пользователям и клиентам освоиться с этими неприкрашенными критериями достигнутого прогресса и предоставить команде безопасную среду, в которой она получит возможность ошибиться, чтобы впоследствии иметь возможность учиться на собственном опыте. Но если пока это нереально, то ваша задача подсказать всем, а особенно руководителю, какую поставить перед собой цель и как изменить климат и настрой команды в будущем.
«Парное программирование (разработка через тестирование или другие практики) не подходят мне».
Программист, привыкший работать в одиночку, может интуитивно чувствовать, что парное программирование будет тормозить его работу. Особенно понятна такая позиция, когда человек работает в атмосфере, не принимающей ошибок. Вполне объяснимо, что он чувствует себя неуютно в присутствии другого человека, наблюдающего за тем, как он пишет код. И каждому, кто когда-либо обучал юного новичка водить автомобиль, знакомо неприятное чувство, которое испытывает старший член команды, передавая клавиатуру неопытному сотруднику при работе в паре. Существует много причин, по которым люди чувствуют себя некомфортно при использовании этих практик, особенно когда мировоззрение команды им не соответствует. Хороший agile-коуч сначала поможет команде выбрать практики, совместимые с ее мышлением. И в процессе их применения члены команды увидят преимущества и поймут, как и почему эти практики работают. Под руководством коуча все начинают активнее воспринимать гибкое мышление.
«Agile не подходит для нашего бизнеса».
Часто люди говорят так, потому что привыкли создавать подробные планы или описания проектов, прежде чем начать реальную работу. Они не могут представить процесс иным. Руководители проектов и те, кто привык к командно-административному стилю мышления, чувствуют себя комфортнее, имея оформленные в виде бумажных документов описания задач, требования и план проекта до начала любых работ. Точно так же архитекторы и разработчики успокаиваются, когда весь дизайн системы отражен на бумаге до того, как написана первая строка кода. И вдруг их просят доверить команде принятие решений – вплоть до последнего ответственного момента, а это означает потерю контроля. Поэтому они будут повторять: «У нас очень сложный бизнес. Люди в других компаниях, может быть, и в состоянии с ходу включиться в проект, но из-за нашей специфики необходимо планировать и проектировать все заранее». Действительно, любой бизнес сложный и каждый проект требует анализа и планирования. Agile-коуч поможет менеджерам, представителям бизнес-подразделений и руководителям разработки понять, что команды намного лучше справляются с этими сложностями, если позволить им разделить проект на более мелкие части. И у них должна быть возможность принимать решения в последний ответственный момент.
«Именно это мы и делаем, только называется по-другому».
Это одна из наиболее распространенных причин, по которым люди отвергают методологии Agile. Они будут искать способы продолжать работать в привычном стиле, используя при этом новые названия гибких практик, о которых читали или слышали. В таком случае Agile станет выглядеть обыденной – и даже неправильной, – если они решат присвоить это имя своей неудавшейся практике.
Попробуйте ввести в строку поиска «Agile – ерунда» (Agile sucks), и обнаружите высказывания людей, которые сделали именно это. Они называют Agile «очковтирательством», считая, что это просто практики каскадной модели, но под новыми названиями. Agile даже будут называть способом «запутать» принципы разработки программного обеспечения, диктуемые здравым смыслом.
Как коуч вы должны признать, что это делается не по злому умыслу. Это естественная реакция человека, который никогда не видел, что такое настоящая Agile (но думает, что видел). Задача коуча – помочь команде понять, что Agile действительно отличается от всего того, что они до сих пор делали, а вовсе не «ерунда».
Коучи понимают, как люди учатся
Хорошая модель освоения чего-либо (если освоение в принципе возможно) пришла из боевых искусств. Ученик боевых искусств проходит через три этапа мастерства, которые называются «сю», «ха» и «ри». «Сю» означает «следуй правилу». «Ха» – «ломай правила». «Ри» – «будь правилом».
Кент Бек, автор книги Extreme Programming Explained, описывал применение экстремального программирования (ХР), используя аналогичные уровни. Когда его спросили об ХР и пяти уровнях «модели зрелости возможностей», разработанных Институтом программной инженерии, он ответил, что ХР имеет три уровня зрелости:
1. Делайте все, как написано.
2. После того как работа выполнена, экспериментируйте с вариациями в правилах.
3. В итоге не беспокойтесь о том, соответствуете вы ХР или нет.
Вернемся к главе 2, в которой мы узнали, как по-разному люди воспринимают Agile. Так же как слепой, встретивший слона, каждый человек по-своему ответит на вопрос «что такое Agile?».
Разработчик, знающий о таких ХР-практиках программирования, как разработка через тестирование и инкрементальный дизайн, решит, что Agile – это о разработке ПО, его проектировании и архитектуре. Менеджер проекта, прочитав о scrum-спринтах, планировании, бэклоге и ретроспективах, подумает, что Agile – это об улучшении практик управления проектами.
Чтобы объяснить суть Scrum, ХР, Lean и Канбана, потребовались сотни страниц. Мы говорили о мировоззрении, ценностях, принципах и практиках. И показали вам, как использовать их все вместе, чтобы помочь команде поставлять большую ценность для клиентов. Мы объяснили, что вы можете сделать сегодня, чтобы помочь команде. Мы предложили инструменты (например, неоднократное повторение вопроса «считаете ли вы это нормальным?»), чтобы помочь вашей команде изменить мировоззрение и для изучения Agile, понимания Scrum, XP, Lean и Канбана.
Это не тот способ, которым большинство людей внедряют Agile.
Как было бы хорошо, если бы все разработчики мира купили и прочли нашу книгу. Но, к сожалению, большинство людей изучают Agile не при помощи книг. Они учатся на практике. И проще всего выполнять задачу, если она разбита на небольшие части.
Другими словами, когда люди пытаются освоить Agile, они хотят получить список простых правил, который поможет им быстрее и качественнее создавать программное обеспечение.
Если вы новичок в agile-коучинге, то это может вызвать у вас разочарование. Представьте, что вы пытаетесь научить команду внедрять Scrum. Из главы 5 вам известно, что если кто-то не понимает принципа самоорганизации и коллективной ответственности, то у него не получится Scrum. Поэтому вы тратите время, объясняя такие scrum-ценности, как мужество, приверженность, уважение, сосредоточенность и открытость, и то, как работает самоорганизация. Но команда разочарована, потому что это очень абстрактные понятия. Люди хотят поговорить о доске задач и пользовательских историях. Вы стремитесь научить их Scrum, а они, по всей видимости, полны решимости удовлетвориться результатом «лучше-чем-ничего». И ничего с этим не поделаешь. Так что же происходит?
Есть старая поговорка об учениках: встречайте их там, где они находятся, а не там, где бы вы хотели, чтобы они вас ждали. Хороший agile-коуч понимает, как происходит процесс обучения, и предлагает людям информацию, поддержку и примеры, помогающие подняться на следующую ступень знаний. Коучи знают, что люди не меняются в одночасье.