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
RSS Feed / Subscribe
2 comments:
> SOA и Agile позиционируются как методологии жизни в хаосе.
Скорее SOA и Agile позиционируются как методологии жизни в быстро меняющемся мире.
> Новые методологии отрицают планирование, никаких планов развития. Они все сиюминутны.
Отрицание планов не обязательно отрицает развития -- смысл как раз в том, чтобы не имея четких планов оставлять открытыми возможности развития в непрогнозируемых направлениях. А основной фактор, ограничивающий возможность планирования -- внешний. Горизонты планирования в бизнесе сокращаются (иными словами, действительно "хаос наступает"), IT всего лишь реагирует на это и пытается предложить более адаптивные методологии.
Развитие конечно есть. Но куда?
Мне нравятся и SOA, и Agile. Но они имеют ограничения. И, как раз об ограничениях, нигде, практически, не пишется. Все хорошо в свое время и к месту.
Для сервисов и коробочного софта сиюминутный подход очень удобен. Изменились желания пользователей или выяснились проблемы текущей реализации – быстренько выпустили изменения и, если удалось, еще и денег с пользователя собрали. Все довольны – пользователи получили актуальный продукт, разработчик получил прибыль. Плюс здесь разработчик выступает сам себе заказчиком и может плотно участвовать в процессе разработки, как того требует agile.
Но корпоративный рынок – это совсем другое. Промышленность не может изменяться мгновенно. Для того чтобы построить завод нужен ни один год. Новые технологии в производстве внедряются десятилетиями. Мне кажется IT мир забыл что все остальные не могут меняться мгновенно.
Для долгой и успешной жизни корпорациям нужны длительные планы развития. Это не значит что они не корректируются, но нужен четкий вектор движения. Сейчас IT лежит в основе всех бизнес-процессов. Прошло время, когда наличие IT системы были преимуществом, сейчас они есть у всех. И эти системы уже не только отражают построение компаний.
IT имеет очень большое влияние на построение компаний. Это очень важно понимать. Это очень большая ответственность IT. Когда IT отдел говорит биг боссам что, то, как мы все строили раньше – это не правильно, что теперь все можно делать быстро, дешево и гораздо оптимальнее боссы в это верят, потому что очень хочется верить что можно получить идеал быстро и дешево. Плюс IT перестает задавать "неудобные" вопросы как увязывать не стыкующиеся бизнес-процессы. Вроде бы все довольны, но такой подход отучает крупный бизнес планировать. Сейчас влияние этой тенденции пока не заметны, т.к. крупные компании живут тем, что заложили 15-20 лет назад. А что будет дальше?
Post a Comment