Agile скорее мертв, чем жив, или скорее жив, чем мертв?

К 2001 году малые и средние компании IT-индустрии столкнулись с тем, что они стали проигрывать таким гигантам, как IBM, Apple и т. д., в борьбе за клиентов. Крупные компании могли позволить себе содержать целые отделы, занимающиеся составлением техзаданий и контролем за их выполнением, огромный штат инженеров и программистов. Ресурсно тягаться с такими монстрами малым и средним компаниям было не под силу. Требовался новый продукт, который дал бы им конкурентное преимущество. Таким стала методология Agile, принципы которой были сформулированы в специальном манифесте.

Их всего четыре, и специалистам ныне они хорошо известны:

1. люди и взаимодействие важнее процессов и инструментов;
2. работающий продукт важнее исчерпывающей документации;
3. сотрудничество с заказчиком важнее согласования условий контракта;
4. готовность к изменениям важнее следования первоначальному плану.

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

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

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

Как с этим бороться? И нужно ли с этим бороться или честно сказать, что Agile is dead? Наверное, все-таки следует освободиться от стереотипов и заявить хотя бы шепотом, что Agile не является панацеей в решении всех проблем. Эта методология хороша при создании прототипов или новых оригинальных продуктов, которые представляют нетривиальное решение задач конкретного заказчика или самой команды разработчиков. Однако при решении типовых задач, описании стандартных бизнес-процессов и встраивании их в действующую систему лучше использовать старый проверенный метод фиксированного задания с четким результатом в конце. На мой взгляд, лишь владение этими двумя полярными методологиями позволит современным IT-компаниям удержаться на рынке, сохранить старых клиентов и привлечь новых. По крайней мере, опыт существования Git in Sky подсказывает мне именно такой путь.