Agile software development

[bowhill]

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

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

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

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

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

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

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

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

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

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

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

Comments

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