Agile software development

[bowhill]

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

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

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

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

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

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

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

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

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

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

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

Comments

[nove-ali.livejournal.com]

Суть любой хорошей методики и должна заключаться в том, чтобы выполнить качественно работы даже со специалистами не экстра класса. Посетив больше 40 проектировочных фирм, команд, по всей стране я наблюдала за тем, как все методики "расползаются". Видела 2 блестящие команды: одну в Перми, другую в Кишеневе (мирового уровня, поставщика решений для ведущих банков мира). В обоих случаях, применяя западные подходы к проектированию, руководство отдавало себе отчет в особенностях нац. характера, и добавляла лучшее, что было в советской системе проектирования. Хотя наверно, это не вполне корректные примеры - команды были очень сильными, руководство - умное.
А в другом месте, мне угрожали, когда отказалась дать положительный отзыв именно о команде проектирования (через 2,5 года команда огребла проблемы по полной, со статьями в печати не удовлетворив и запоров проект для одного из крупнейших заказщиков в стране). Самым проблемным местом везде была проверка выполнения: никто точно не знал почему и на сколько сдвигаются сроки, а уж сколько раз хватала за руку, что не все требования заказчика регистрируются -- не счесть...

[bowhill.livejournal.com]

Вряд ли тебе попадался именно Agile, эта методика не подразумевает усилий по документированию и такому матёрому аудитору там делать особо нечего.

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

Да, умное руководство -- это прекрасно, но тривиально. Но интересно. :) Вот проверка выполнения это предмет, можно сказать, водораздел. И управление требованиями -- предмет. Вроде и не бозон Хиггса, а обычно запущенно.

PS: написала бы книжку.

[nove-ali.livejournal.com]

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

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

( и уж совсем личное: очень трудно объяснить начальству, что нельзя вынуждать делать человека то, в чем он не вполне разбирается (оставляя при этом без помощи)).

[bowhill.livejournal.com]

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

Простые навыки честного труда... Проверять за собой непросто, и не всем дано. Тем более в нашей суете. Но вообще конструктивная проверка -- не ужас как сложно. Скорее мало востребовано.

А начальство думает "А чё, я-то обхожусь и ничё" :)

[1master.livejournal.com]

Ну это тоже неправда. Agile не диктует, как нужно обходится с документацией.

[bowhill.livejournal.com]

И не запрещает мне танцевать в Большом театре, но я не танцую.

Опять же кто и что пишет? Когда пишет? Кто и когда читает? Пишет кодер после беседы с заказчиком? Ведь беседа кодера с каким-то представителем заказчика -- это то, что если не диктует, то продвигает Agile?

Если нет ролей да и людей в штате, если нет таймслотов, если банально нет технологии и управления документирования, то откуда возмётся документация? Как говорил один персонаж "порнография сама себя не скачает. :)

[1master.livejournal.com]

Давай договоримся про какой agile мы говорим. А то их там уже под сотню набралось и какие-то пытаются такие вещи регламентировать, а какие-то нет.

[bowhill.livejournal.com]

Хорошее предложение. Я говорю о достаточно народной (как я это понимаю) версии, которая начинается с Манифеста и продолжается использованием в разной степени элементов XP и Scrum. К таким методикам (XP etc) я отношусь как к бибилиотекам, реализующим определённый кусочек. Например, scrum, кажется, занимается коммуникацией, и т.д.

[1master.livejournal.com]

Они и есть библиотеки. По крайней мере мне еще не попадалось ничего с лейблом Agile претендующего на всеобщность.

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

[1master.livejournal.com]

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

[bowhill.livejournal.com]

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

[1master.livejournal.com]

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

[bowhill.livejournal.com]

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

При этом я считаю, что орудием инженера является слово. :)

[1master.livejournal.com]

Про слово согласен.
Фокус в том, что заставлять команду писать еженедельные отчеты - херовый способ потратить время. Хороший способ - ежедневная летучка на 10-15 минут во время которой отвечается только на три вопроса "что сделано?", "что запланировано?", "что мешает?".
Во-первых, команда оказывается в курсе того, что делают остальные. Во-вторых, ничего не успело забыться. В третьих, обеспечивается хорошая скорость реакции на проблемы. В четвертых, руководитель проекта каждый день знает в каком состоянии проект.