Agile software development

[bowhill]

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

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

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

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

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

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

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

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

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

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

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

Comments

[1master.livejournal.com]

Я не соглашусь с тобой по обоим вопросам.
1. Agile требует проектирования, просто оно покрывает более короткий период времени.
2. Нормальная agile команда ничего никуда не перекладывает, а занимается всем как и положено.

Т.е. мне кажется, что ты взял наблюдения за низкокачественными командами и обобщил это на всю методологию.

[bowhill.livejournal.com]

Hmm, а ещё я удалил абзац про то, что сторонники Agile обычно опираются на субъективный опыт неудачного классического проектирования :D Great minds think alike

1. "Классическое" проектирование подразумевает цикличность и итерационность.
1.1. В классическом подходе размер циклов может быть большим, средним маленьким, разноуровневым и это, в идеале, величина определяемая измеряемая изменяемая и т.д. В Agile микроциклы практически hard-coded, это некий культ. :)
1.2. Определение и реализация тактических параметров без закрытия стратегических, очень хорошо может оказаться бессмыслицей. Так же как и без понимания картины в целом, хотя бы в крупную клетку, которая определяет взаимосвязи между отдельными элементами. Это как перед испытаниями выяснить, что танк должен плавать. Начинать что-то кодировать до того, как сложена общая картинка теоретически можно, но практически это работает на достаточно узком классе задач. Хорошо ещё когда разработчик знает этот класс.
2.1 imho, это не вопрос субъективной нормальности. Когда на раннем этапе нет достаточных данных, объективно нельзя принять правильное решение, его можно только угадать или не угадать. Нормальная команда может чаще угадывать, но всё равно пролёт это вопрос времени.
Нет данных, это не просто "то-то не ясно", а неясен ни масштаб, ни функциональность, ни динамика её изменения, ни взаимозависимости. И т.д.
2.1 Заказчик сказал, надо сделать A,B и С, команда сделала, потом выясняется, что это какие-то частные отображения, надо было делать не то и не так, выяснилось тогда, когда потом до этого дошли. Кто виноват? Заказчик вообще-то не специалист в разработке, сказал чего бы ему хотелось в первую очередь, заявка есть, работы выполнены, ресурсы потрачены. Исполнитель хотелки сделал. Я в целом не о злонамеренности.
2.2 Нормальная команда может сделать что-то хорошее в очень широких методических рамках, выдающийся специалист может и методологию под себя прогнуть. :)

[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 минут во время которой отвечается только на три вопроса "что сделано?", "что запланировано?", "что мешает?".
Во-первых, команда оказывается в курсе того, что делают остальные. Во-вторых, ничего не успело забыться. В третьих, обеспечивается хорошая скорость реакции на проблемы. В четвертых, руководитель проекта каждый день знает в каком состоянии проект.

[1master.livejournal.com]

1. Одинаково
1.1. Да. Впрочем, не вижу в том вреда.
1.2. Нигде в agile не сказано, что нужно определять тактику без определенности в стратегии.
2.1. Если заказчик позволяет себе говорить, что нужно сделать "A, B и C", то он сам себе дятел. Команда не телепаты и не предсказатели судьбы, и не знает насколько заказчику нужно именно это. Вставать в позу "пока мы твой проект полностью не обследуем - ни строчки кода не будет" еще больший идиотизм. В разы больший.
2.2. Не существует единой agile методологии. Даже если рассматривать фундаменталистов - их уже набралось на любой вкус и цвет, можно не гнуть текущих, а выбрать соседних, которые на копейку отличаются :)

[thesz.livejournal.com]

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

[1master.livejournal.com]

А еще там не сказано, что за столом нужно пользоваться ножом и вилкой.

[thesz.livejournal.com]

То есть, там нет так называемых "прописных истин".

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

Пока это невозможно, надо говорить об этом при каждом удобном случае.

Чего в Agile нет.

Как и понимания, какие истины являются прописными, а какие нет - у его сторонников.

[1master.livejournal.com]

Ну да, а у любителей футбола нет единства по вопросу сортов пива. Это неопровержимо доказывает нам, что футбол - фигня.

[thesz.livejournal.com]

Итак, вы уже второй раз переводите тему разговора.

На этот раз даже без намёка на какую-либо связь с тем, что я сказал, поэтому я совершенно не в силах расшифровать ваш комментарий.

Не затрудните себя более развёрнутым комментарием?

[1master.livejournal.com]

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

Я уж и не говорю, что и изначальное утверждение о том, что тактика должна следовать после стратегии - безосновательно.

[thesz.livejournal.com]

Что я сумел здесь (и выше) прочитать.

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

Во=вторых, вы считаете, что моё первоначальное утверждение "тактика следует за стратегией" безосновательно, то есть, спорно.

Я вижу здесь непоследовательность.

[1master.livejournal.com]

Я нигде не утверждал первого. То, что обычно так и происходит и чаще так получается лучше не значит, что это непреложная истина. Пример обратного: прототипирование (тактический ход на основе которого будет определена стратегия).

[bowhill.livejournal.com]

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

Вто время как мы с тобой вполне обходимся словами и ничего из пенопласта при этом не выпиливаем :)

[bowhill.livejournal.com]

Можно предположить что agile расчитана не на ядерных физиков, а в целом на менее подготовленный контингент. :)

[bowhill.livejournal.com]

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

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

Программист php не обязан хорошо писать на c, agile разработчик не обязан хоть что-то знать из понятий классического проектирования. В школах им не учат.

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

[nove-ali.livejournal.com]

Про культурных людей. Ко мне на курсы приходили менеджеры среднего звена (иногда и топы), почти у всех высшее техническое образование. Но когда я однажды сказала, что это проблема -- "о малое", и можно пренебречь ответом мне были мутные глаза и робкий вопрос о том, что такое это о малое. (спросил не самый глупый, а самый честный).

[bowhill.livejournal.com]

1.1 Вред в догматизме. Политика циклов не такая, как определяется задачей, а как прописано в идеологии.
1.2 Кем и когда определяется такая стратегия, я не вижу ни ролей, ни времени, ни техпроцесса, ни бюджета etc в рамках подхода Agile.
2.1 У заказчика нет экспертизы. Административный молоток есть и всё. Откуда у него в штате будет системотехник? То, что предметную область надо для автоматизации формализовать и систематизировать -- это задача и навык исполнителя.
Поза немного другая -- мы не будем тратиться на реализацию, пока не поймём где, что и как нам делать. Что исследовать, что моделировать, что прототипировать, что кодировать.
2.2 Я сужу об Agile с чужих слов и документов :) Не хотелось бы тебя за что-то грузить необходимостью ответов на глупые вопросы, но ссылку на какие-то канонические принципы Agile посмотрел бы с интересом. Я не просто так говорил про умных специалистов -- есть у меня ощущение, что есть классика, есть Agile, а есть классика раскрашенная под хохлому, то есть в Agile skin. ;)

[1master.livejournal.com]

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

[dimas.livejournal.com]

У меня есть ощущение, что агиле неплохо работает во всяких стартапах и вообще веб-проектах, когда надо быстро сляпать макет решения, который надо быстро показать инвестору, или зазвать пользователям … а уж потом, когда понятно, что “сработало”, можно и переписать-перепроектировать-доточить неудачные части … а вот когда это всё пытаются перетащить на более сложные многокомпонентные системы, да еще заказные — вот тут то и начинается попандос …

отмазка: я, правда, книжек по агилу не читал и тренингов не проводил, и может просто каждый называет агилом то, что полноценым агилом не является :)

[bowhill.livejournal.com]

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

Например, если надо сделать кастомизацию Joomla под серию заказчиков, то, наверное, это не хуже чем ничего. Ведь переписывать Джумлу задача не стоит, [бедные] кодеры работают за еду. Кусок управления изменениями как-то живет.

Если говорить об идеологических стартапах, то тут неочевидно. Всё же такие стартапы строятся вокруг полноценной идеи, со всеми её концепциями и прочими богатствами.

И если Agile банально является альтернативой отсутствию или профанации управления, то может и баталий не было бы… :)