Чистый Agile. Основы гибкости - [60]

Agile бурей захватил отрасль программного обеспечения. Но, как и в игре в испорченный телефон, изначальный посыл Agile исказили и упростили, преподнося его компаниям как методологию, которая ускорит выпуск программного обеспечения. Для компаний и руководителей, применяющих каскадную модель или RUP, это звучало райской песнью.

Менеджеры и заинтересованные лица пришли в восторг. В конце концов, кто бы не хотел испробовать Agile? Кто бы не хотел быстрее выпускать программное обеспечение? Даже среди скептиков Agile вызывал интерес. Если ваши конкуренты хвастаются тем, что используют Agile, а вы нет, что вам мешает? Что о вас подумают ваши потенциальные клиенты? Компании не могут позволить себе отказаться от Agile. За годы, последовавшие за саммитом Agile, компании по всему миру встали на путь перехода к Agile. Началась эра внедрения Agile.

Похмелье от Agile

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

Продать методы Agile менеджерам среднего звена было легко — всем им хотелось, чтобы ПО выпускалось быстрее. «Инжиниринг — это несложно. Если наладить процесс разработки, с ним тоже будет все в порядке, — говорили менеджерам. — Дело всегда в людях». И они покупали. Руководители работают с людьми и покуда занимают свою должность, они счастливы, когда их подчиненные работают быстрее.

Множество компаний на самом деле получили пользу от перехода на Agile, и сегодня их положение дел гораздо лучше, чем до этого.

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

В их модели Agile нет никакой стратегическо-технической работы. В ней нет требований к архитектуре или проектированию. Порядок таков, что нужно просто сосредоточиться на какой-либо невыполненной работе из списка, которую нужно выполнить незамедлительно и которой присвоили наивысший приоритет. И так одно задание с наивысшим приоритетом следует за другим. Такой подход приводит к длинной последовательности итеративных тактических работ и накоплению технического долга. Хрупкое программное обеспечение, знаменитые монолиты (или распределенные монолиты, если говорить о командах, которые пробуют использовать микросервисную архитектуру) становятся в порядке вещей. Ошибки и неполадки оказываются излюбленной темой для обсуждения на ежедневном стендап-митинге и ретроспективах. Релизы выходят не так часто, как ожидали клиенты. Тестирование вручную занимает целые дни, а то и недели. И надежда на то, что применение Agile убережет от всех напастей, бесследно уходит. Менеджеры обвиняют разработчиков, что те слишком медленно работают. Разработчики обвиняют менеджеров, что те не дают им проводить необходимые стратегические и технические работы. Владельцы продукта не считают себя частью команды, поэтому не берут на себя никакой ответственности за то, что дела пошли не так. Начинает преобладать порядок «свои против чужих».

Это то, что мы называем похмельем от Agile. После долгих лет вложения средств в переход на Agile компании понимали, что у них до сих пор много тех же проблем, которые были до него. И конечно, во всем виноват Agile.

Ожидание и реальность

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

Слаженное сотрудничество убирает некоторые барьеры, которые мешают работать, но не обязательно добавляет мастерства работникам.