Agile software development

[bowhill]

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

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

Можно сказать, что Agile является формой естественного эскапизма, когда необходимая, но сложная или неинтересная работа заменяется не бездельем, а другой [как бы] работой, более простой или интересной. Безделье само по себе тягостно, к тому же требует оправдания. А тут все работают.

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

Проектирование – это тоже сложная деятельность, результат которой можно оценить. Успешное проектирование ценится не слишком хорошо, на уровне «само собой разумеется», в то время как провалы в проектировании наглядно портят весь проект. Используя Agile, сама деятельность по проектному управлению сохраняется, но переводится в спонтанную категорию (ad hoc) где её качество становится смутно оцениваемым.

Второе, на мой взгляд, выдающееся качество -- ответственность практически полностью перекладывается на заказчика, особенно в областях не входящих в компетенцию заказчика. Вот это последнее особенно ценно. Это позволяет почти любую проблему исполнителя документально обосновать запросами заказчика.

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

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

Процесс выполнения работ неявно приводится к схемам Time&Material и Outstaffing. Собственно, проблема тут в неявности, поскольку контроль, в том числе и времени и состава аренды, остаются у исполнителя.

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

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

Comments

[1master.livejournal.com]

А XP это не agile, это скорее первая попытка подумать в этом направлении. Типа "мы тут много лет что-то делаем, а можно ли делать это иначе". Это же относится к парному программированию, которое работает на коротких дистанциях, но на длинных задолбает очень быстро.

[bowhill.livejournal.com]

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

[1master.livejournal.com]

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