Теперь Том – владелец продукта, и он в восторге от возможности определять, над чем стоит работать команде. Но он разрывается на части, потому что чувствует: команде нужно, чтобы он работал с ней полный день. Он должен принимать участие в ежедневных встречах и постоянно отвечать разработчикам, интересующимся деталями программы, которую они пишут. Иногда они спрашивают о том, чего он не знает, а порой он хочет, чтобы они ответили на эти вопросы сами. Ему и так есть чем заняться, но он чувствует, что остальные члены команды, дойдя до середины пути, готовы переложить всю ответственность за создание столь важного продукта именно на его плечи. А у него нет ответов на все вопросы.

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

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

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

Сложилось общее мнение, что проект прошел путь от неконструктивной стадии к конструктивной – и это очень хорошо. Получилось то, что мы называем «лучше-чем-ничего». Но действительно ли суть Agile заключается в этом?

Раздробленное видение

Команды сталкиваются с проблемами с тех пор, как начали создавать ПО. Еще в 1960-х годах специалисты открыто говорили о том, что разработка программного обеспечения фактически разрушена. Они использовали термин кризис программного обеспечения, который был придуман на конференции для разработчиков НАТО в 1968 году вместе с другим термином – разработка программного обеспечения. «Кризис программного обеспечения» говорит о состоянии разработки софта в типичной компании 1970–1980-х годов, когда серьезные (знакомые и сейчас) проблемы были очень распространены, что приводило к провалу множества проектов. Со временем наша индустрия начала понимать основные источники кризиса ПО. Важной вехой стала публикация в 1970 году статьи Уинстона Ройса, инженера компании Lockheed, в которой описывалась крайне популярная, но неэффективная модель разработки ПО. В начале 1980-х этот метод был широко известен как водопадный подход. Потребовалось еще 10–20 лет, прежде чем многие команды, добивавшиеся успеха в прошлом, перестали слепо доверять ему. Многие команды обнаружили, что agile-методы могут решить проблемы, типичные для водопадного подхода, но одновременно выяснилось, что это не так просто, как кажется.

Разработчики используют программные средства каждый день, чтобы построить свой код. Специалист, владеющий несколькими инструментами, всегда более востребован, чем тот, кто знает меньше. Поэтому многие профессионалы, впервые сталкиваясь с Agile, сразу же воспринимают его как совокупность средств, способов и методов.