Дэн уже писал автоматизированные модульные тесты для своих предыдущих проектов, но многие разработчики музыкальных автоматов никогда не делали этого. Он начал сотрудничать с разработчиками, чтобы организовать модульное тестирование и разработку через тестирование. Создал автоматизированный сборочный скрипт и настроил сервер сборки для проверки кода, создания программного обеспечения и проведения тестирования раз в час. И это сработало! Программисты сразу же увидели улучшение в их коде. Каждый день разработчик находил ошибку, которую никогда не выявил бы без автоматических тестов, и было ясно, что удалось избежать недельных отладок и отслеживания неприятных проблем в этой области. Мало того что стало меньше ошибок, облегчилась и процедура изменения кода, который пишут разработчики.
(Ничего страшного, если вы не знаете всех этих методов, включая разработку через тестирование. Вы познакомитесь с ними в нашей книге, мы будем выделять новые практики жирным шрифтом, чтобы их было проще обнаружить.)
Джоанна прошла обучение Scrum, и команда решила называть ее scrum-мастер (хотя во время обучения она узнала о большой разнице между понятиями «scrum-мастер» и «руководитель проекта» и вовсе не была уверена, что роль, которую она играет в проекте, действительно заслуживает названия «scrum-мастер»). Она помогает команде разбивать проект на итерации, отслеживая прогресс на доске задач и используя скорость работы команды и графики сгорания (линейные графики, которые позволяют ежедневно отслеживать объем выполняемой работы, «сжигание» ее до нуля, когда работа выполнена полностью), чтобы держать всех в курсе. Впервые команда действительно заинтересовалась тем, чем занят менеджер проекта, и это способствовало продвижению в работе.
Том тоже хотел пройти обучение Agile. Дэн, Брюс и Джоанна начали называть его владельцем продукта, и Том принялся писать пользовательские истории для команды, чтобы она лучше представляла свою задачу. Он работал с ними ради создания планов релизов, основанных на историях, и теперь чувствовал, что напрямую контролирует то, что будет создавать команда.
Но главное – Брюс начал проводить ежедневные митинги с Джоанной, Дэном и всеми программистами. Том тоже посещал их. Сначала не все удавалось, но к моменту, когда проект набрал обороты, никто не испытывал дискомфорта и все давали друг другу объективную оценку того, как продвигается их общее дело. Брюс убедил команду проводить совместную ретроспективу в конце каждой итерации и был рад, что коллеги действительно пытаются осуществить улучшения, о которых говорили в ходе ретроспективы.
Все удавалось. Команда продвинулась, проект становился все лучше и лучше, но… до определенного момента.
За счет «внедрения Agile» все добились улучшений на своем рабочем месте. Дэн и разработчики начали развивать навыки и тщательнее писать код. Джоанна имела точное представление о том, в каком состоянии находится проект в каждый отдельный момент времени. Том гораздо больше общался с командой, и это давало возможность тщательнее контролировать программное обеспечение, которое они создавали, и, следовательно, максимально удовлетворять запросы клиентов. Брюс смог сосредоточиться на улучшении навыков своей команды и коммуникации.
Но
Они переняли немало хороших практик. Многие из этих методов были улучшенными версиями прежних, и все вместе они помогли каждому члену команды стать продуктивнее. В этом, несомненно, было продвижение.
Но наряду с тем, что команда становилась счастливее, а проект «Музыкальный автомат» действительно продвигался лучше, чем любой из предыдущих, у них все же остались опасения в отношении того нового, более гибкого мира, обитателями которого они оказались. Дэн, например, считал, что команда определенно создает код лучше, чем раньше, но приходится идти на отступления от технологий, чтобы уложиться в срок.
Джоанна довольна, что контролирует ход выполнения проекта. Но из-за того, что его приходится разбивать на короткие итерации, она чувствует себя некомфортно. Отказавшись от возможности использовать полный график проекта как дорожную карту, она обнаружила, что оказывается во все большей зависимости от команды, которая посвящает ее в текущую ситуацию во время ежедневных митингов. Эти встречи полезны, но на них в основном озвучивается статус каждого члена команды, а Джоанна лишь послушно все записывает, чтобы довести информацию до заинтересованных сторон. Она начала чувствовать себя простым координатором, а не менеджером, управляющим проектом. Теперь она фокусируется на статусе, что затрудняет выявление и устранение препятствий. Команда лучше реагирует на изменения, но это ставит Джоанну в неловкое положение, потому что все ее внимание теперь обращено на реагирование, а не на планирование.
Теперь Том – владелец продукта, и он в восторге от возможности определять, над чем стоит работать команде. Но он разрывается на части, потому что чувствует: команде нужно, чтобы он работал с ней полный день. Он должен принимать участие в ежедневных встречах и постоянно отвечать разработчикам, интересующимся деталями программы, которую они пишут. Иногда они спрашивают о том, чего он не знает, а порой он хочет, чтобы они ответили на эти вопросы сами. Ему и так есть чем заняться, но он чувствует, что остальные члены команды, дойдя до середины пути, готовы переложить всю ответственность за создание столь важного продукта именно на его плечи. А у него нет ответов на все вопросы.
В конце концов, его основная должность – менеджер по работе с клиентами. Ведь музыкальные автоматы не продают сами себя. Как можно вести отчетность и оставаться в курсе потребностей пользователей, если все его время уходит на ответы программистам?
Брюс рад, что команда работает продуктивнее. Но когда он внимательнее всматривается в происходящее, что-то кажется ему неправильным, но он не может понять, что именно. Очевидно, что это является улучшением, учитывая, что большинство его предыдущих проектов были на волосок от провала. По мнению Брюса, использование Agile сделало ситуацию лучше, уменьшило необходимость личного героизма, сократило количество работы по ночам и в выходные дни. Но он также чувствует, что появились новые проблемы.
Нередко члены команды и особенно ее руководитель испытывают то же самое, что и Брюс: некоторое разочарование после первой попытки применения Agile. Блоги и книги, которые они читали, и то, что они слышали во время обучения, обещали «поразительные результаты» и «гиперпродуктивные команды». Команда ощущает, что проект создания музыкального автомата – это улучшенная версия предыдущих проектов. Но, безусловно, и речи нет о гиперпродуктивности или поразительных результатах.
Сложилось общее мнение, что проект прошел путь от неконструктивной стадии к конструктивной – и это очень хорошо. Получилось то, что мы называем «лучше-чем-ничего». Но действительно ли суть Agile заключается в этом?
Раздробленное видение
Команды сталкиваются с проблемами с тех пор, как начали создавать ПО. Еще в 1960-х годах специалисты открыто говорили о том, что разработка программного обеспечения фактически разрушена. Они использовали термин
Разработчики используют программные средства каждый день, чтобы построить свой код. Специалист, владеющий несколькими инструментами, всегда более востребован, чем тот, кто знает меньше. Поэтому многие профессионалы, впервые сталкиваясь с Agile, сразу же воспринимают его как совокупность средств, способов и методов. Практически любой разработчик, начавший работу с Agile, в течение нескольких месяцев обновляет свое резюме, чтобы включить в него новую практику. Это первое впечатление от Agile – хороший признак, потому что оно помогает сделать agile-методы привлекательными и вызывает интерес.
Но видя в Agile лишь инструменты, технологии и методы, вы делаете только первый шаг на пути к «переходу к гибким технологиям» – и это создает проблемный побочный эффект. Взгляните на ситуацию с точки зрения Дэна. Как разработчик и архитектор он будет концентрироваться на том, что непосредственно влияет на развитие: методах, которые помогают ему улучшить код путем устранения или предотвращения ошибок, инструментах, позволяющих выполнять сборку быстрее и проще, и практиках, улучшающих способы разработки, проверки и сборки кода.