Из гибких проектов высосана вся гибкость

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

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

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

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

Agile обещал ускорить разработку ПО и обеспечить клиента более быстрый возврат инвестиций за счет быстрой скорости разработки и вывода проект. Однако реальность часто не соответствует этим ожиданиям, и в 99% случаев результаты agile-проектов разочаровывают.

Агайл превращается в скуфа

Agile стал настолько популярным, что клиенты или выбирают компании / команды которые работаю с ним или начали требовать agile подход у проекта, даже если этот подход не подходил для их задач или у них не было нужных специалистов.

В книге «Sooner Safer Happier» авторы критикуют тенденцию использовать Agile формально, вместо того чтобы действительно быть гибкими. Agile превратился в продукт, а не образ мышления.

Многие компании и команды разработчиков стремятся к «agile-поставке», которая включает бэклоги продукта, спринты и фиксированные сроки/стоимость. При этом ключевые элементы гибкости часто игнорируются:

1. Ретроспективы исчезли
2. Гибкость и изменение методов работы ушли в прошлое
3. Быстрая поставка в производство стала редкостью
4. Ожидается строгое соблюдение сроков
5. Команды лишены реальных полномочий и автономии

В результате мы получаем гибрид каскадного подхода с предварительными требованиями, фиксированными сроками, формальными спринтами и регулярными демонстрациями.

Само слово «Agile» потеряло свое значение, а из Agile-проектов выжали всю реальную гибкость.

Худший из миров

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

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

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

Wagile

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

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

Зачем мы сюда попали?

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

Теперь мы наблюдаем эффект «трава зеленее»:

1. Раньше, на фоне проблем Водопада, Agile казался идеальным решением
2. Теперь, столкнувшись с проблемами Agile, некоторые ностальгируют по более структурированным подходам

Слишком заняты, чтобы думать

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

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

Методология Agile не исчезнет, но она находится в стадии «дойной коровы» — проекты используют термин Agile, не являясь по-настоящему гибкими.

Заключение

Успех или неудача проекта в первую очередь зависит от людей, а не от методологии. Подходы к управлению проектами, технологии и языки программирования — это лишь инструменты для создания ПО.

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

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

Ключевые факторы успеха проекта остаются неизменными:

1. Четкое понимание целей проекта
2. Эффективная коммуникация между всеми участниками
3. Компетентная и мотивированная команда
4. Реалистичные ожидания и планирование
5. Гибкость в адаптации к изменениям
6. Фокус на создании ценности для пользователей

Вместо слепого следования какой-либо методологии, командам стоит:

1. Критически оценивать свои процессы и постоянно их улучшать
2. Адаптировать подходы под специфику конкретного проекта и команды
3. Поощрять открытое обсуждение проблем и поиск решений
4. Фокусироваться на результатах и ценности для пользователей, а не на формальном соблюдении процессов
5. Инвестировать в развитие навыков и знаний членов команды
6. Поддерживать культуру доверия, ответственности и постоянного обучения

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

В конечном счете, ключ к успеху — это люди: их навыки, мотивация, способность к сотрудничеству и решению проблем. Никакая методология не заменит талантливых и увлеченных профессионалов, работающих вместе над достижением общей цели. Там что всех нас ждет Wagile, недо Scrum и прочие методологии.