Роберт Мартин - Чистый Agile. Основы гибкости

Автор Сандро Манкузо, 27 апреля 2019 года

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

Но большинство из них смогли это сделать и были приятно удивлены. Вдруг все изменилось. У нас появились списки невыполненных задач и пользовательские истории вместо документов с требованиями. У нас появились настоящие доски и диаграммы сгорания задач вместо диаграмм Ганта. У нас появились стикеры, которые мы передвигали каждое утро в соответствии с ходом работ. В стикерах чувствовалась какая-то мощная энергетика — что-то, что вызывало сильную психологическую зависимость. Они как будто представляли нашу приверженность Agile. Чем больше таких заметок было на стене, тем более вовлеченными в Agile мы себя ощущали. Мы стали командой, работающей по Scrum, а не бригадой строителей. У нас больше не было менеджеров проекта. Нам сказали, что нам не нужны менеджеры, теперь наши менеджеры будут «владельцами продукта», а у нас будет самоорганизация. Нам сказали, что владельцы продукта и разработчики будут тесно сотрудничать, словно одна команда. И отныне, поскольку наша команда работает по Scrum, мы наделены правом принятия решений. Не только технических, но и тех, что связаны с самим проектом. Или мы так думали.

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

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

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

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

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

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