IT стремится к хаосу. SOA – хаос в архитектуре систем. Agile (XP и, особенно, Scrum) – хаос в производстве систем.
Причем хаос - это не мое видение. SOA и Agile позиционируются как методологии жизни в хаосе.
Новые методологии отрицают планирование, никаких планов развития. Они все сиюминутны.
Все это выгодно разработчикам и продавцам систем. Если у бизнеса нет планов развития и четкого понимания как и в чем его IT система даст преимущества перед конкурентами не только сейчас, то и в дальнейшем, то с вероятностью, приближающейся к 100% завтра бизнесу потребуется совсем не то, что сделали сегодня. И завтра разработчики легко смогут продать что-то новое.
Чем методология разработки более гибкая тем больше ее сейчас любят. Каждая следующая методология оставляет все меньше места планированию и контролю. Roy Osherove, agile консультант, пишет что Scrum продается лучше чем XP в основном потому, что Scrum более настраиваемый, требует меньше управления и не содержит страшного слова "Extreme". Т.е. разработчик наслушавшись как все может быть хорошо с agile, где ему не надо ни за что отвечать ведется и хочет применить это на себя. Причем выбирает методологию – чем проще звучит тем лучше.
Все аgile методологии построены на очень активном участии заказчика, вплоть до того, что заказчик фактически напрямую ставит задачу команде разработчиков (архитекторы, аналитики, технологи – все лишние). Это, опять же, очень выгодно разработчику. Зачем долго выяснять что надо заказчику, потом это согласовывать с десятками отделов, если можно привлечь заказчика к разработке и получать изменения и дополнения от каждого отдела отдельно. Никакой головной боли с противоречием требований. В результате можно сказать – вы именно это и хотели. Если же заказчик начинает понимать к чему может привести этот хаос ему приходится самому внутри себя создавать команду, которая утрясает все требования и разногласия между отделами и уже выдает разработчикам спланированные данные, т.е. разработчик сбрасывает с себя задачу планирования (а с ней и ответственность) на заказчика.
Без отсутствия изначальных требований к разрабатываемой системе (а аgile отрицает любые планы далее чем на одну итерацию) нельзя оценить результат разработки. Никто не сможет сказать сделали ли то, что было нужно или не то. В любом случае разработчик не виноват – он только выполнял пожелания заказчика.
Disclamer: Не бейте меня сильно! Описание ситуации немного утрировано, но, иногда, карикатурная утрированность помогает взглянуть на ситуацию по новому.
technorati tags: SOA, Agile, Scrum, eXtreme Programming