Постигая Agile

Часто люди говорят так, потому что привыкли создавать подробные планы или описания проектов, прежде чем начать реальную работу. Они не могут представить процесс иным. Руководители проектов и те, кто привык к командно-административному стилю мышления, чувствуют себя комфортнее, имея оформленные в виде бумажных документов описания задач, требования и план проекта до начала любых работ. Точно так же архитекторы и разработчики успокаиваются, когда весь дизайн системы отражен на бумаге до того, как написана первая строка кода. И вдруг их просят доверить команде принятие решений – вплоть до последнего ответственного момента, а это означает потерю контроля. Поэтому они будут повторять: «У нас очень сложный бизнес. Люди в других компаниях, может быть, и в состоянии с ходу включиться в проект, но из-за нашей специфики необходимо планировать и проектировать все заранее». Действительно, любой бизнес сложный и каждый проект требует анализа и планирования. Agile-коуч поможет менеджерам, представителям бизнес-подразделений и руководителям разработки понять, что команды намного лучше справляются с этими сложностями, если позволить им разделить проект на более мелкие части. И у них должна быть возможность принимать решения в последний ответственный момент.

«Именно это мы и делаем, только называется по-другому».

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

Попробуйте ввести в строку поиска «Agile – ерунда» (Agile sucks), и обнаружите высказывания людей, которые сделали именно это. Они называют Agile «очковтирательством», считая, что это просто практики каскадной модели, но под новыми названиями. Agile даже будут называть способом «запутать» принципы разработки программного обеспечения, диктуемые здравым смыслом.

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

Коучи понимают, как люди учатся

Хорошая модель освоения чего-либо (если освоение в принципе возможно) пришла из боевых искусств. Ученик боевых искусств проходит через три этапа мастерства, которые называются «сю», «ха» и «ри». «Сю» означает «следуй правилу». «Ха» – «ломай правила». «Ри» – «будь правилом».

Лисса Адкинс. Coaching Agile Teams: A Companion for ScrumMasters

Кент Бек, автор книги Extreme Programming Explained, описывал применение экстремального программирования (ХР), используя аналогичные уровни. Когда его спросили об ХР и пяти уровнях «модели зрелости возможностей», разработанных Институтом программной инженерии, он ответил, что ХР имеет три уровня зрелости:

1. Делайте все, как написано.

2. После того как работа выполнена, экспериментируйте с вариациями в правилах.

3. В итоге не беспокойтесь о том, соответствуете вы ХР или нет.

Алистер Кокберн. «Быстрая разработка программного обеспечения».

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

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