Agile software development
Dec. 21st, 2010 12:51 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
bowhillКогда в открытой аудитории начинается обсуждение проблем проектирования, то весьма часто к обсуждению присоединяются сторонники подхода Agile. И, обычно, говорят, что проблемы от того, что традиционное проектирование плохое, а в Agile никаких проблем не будет, потому что Agile хорошее.
У меня же Agile вызывает стойкую ассоциацию с бегом курицы без головы. Если отойти от того, что сама ассоциация неприятна, то определяет она вполне характерное движение. Бег не потому, что в этом движении есть смысл или польза, а потому что помимо головы ещё есть ноги, рефлексы и реакции.
Можно сказать, что Agile является формой естественного эскапизма, когда необходимая, но сложная или неинтересная работа заменяется не бездельем, а другой [как бы] работой, более простой или интересной. Безделье само по себе тягостно, к тому же требует оправдания. А тут все работают.
Помимо психологического фактора, Agile своеобразно соответствует нескольким, в том числе современным, особенностям индустрии. Тезисно, можно посмотреть на следующие направления.
Проектирование – это тоже сложная деятельность, результат которой можно оценить. Успешное проектирование ценится не слишком хорошо, на уровне «само собой разумеется», в то время как провалы в проектировании наглядно портят весь проект. Используя Agile, сама деятельность по проектному управлению сохраняется, но переводится в спонтанную категорию (ad hoc) где её качество становится смутно оцениваемым.
Второе, на мой взгляд, выдающееся качество -- ответственность практически полностью перекладывается на заказчика, особенно в областях не входящих в компетенцию заказчика. Вот это последнее особенно ценно. Это позволяет почти любую проблему исполнителя документально обосновать запросами заказчика.
Этим же подходом качество архитектурных решений и общая системотехника так же переводится в смутную область.
Обходится проблема массового привлечения персонала недостаточной квалификации. Задача формулирования заданий и контроля исполнения сводится к утилизации простейших доступных навыков исполнителей. Результат неквалифицированного труда так же представляется как результат выполнения запроса.
Процесс выполнения работ неявно приводится к схемам Time&Material и Outstaffing. Собственно, проблема тут в неявности, поскольку контроль, в том числе и времени и состава аренды, остаются у исполнителя.
Или кратко, Agile позволяет переложить на заказчика проблемы проектирования, архитектуры и общей низкой квалификации производителей работ и исполнителей.
PS: Прочитав этот текст должен признать его видимую черствость к сторонникам Agile, это уже моя проблема формы изложения, а не отношение к людям.
У меня же Agile вызывает стойкую ассоциацию с бегом курицы без головы. Если отойти от того, что сама ассоциация неприятна, то определяет она вполне характерное движение. Бег не потому, что в этом движении есть смысл или польза, а потому что помимо головы ещё есть ноги, рефлексы и реакции.
Можно сказать, что Agile является формой естественного эскапизма, когда необходимая, но сложная или неинтересная работа заменяется не бездельем, а другой [как бы] работой, более простой или интересной. Безделье само по себе тягостно, к тому же требует оправдания. А тут все работают.
Помимо психологического фактора, Agile своеобразно соответствует нескольким, в том числе современным, особенностям индустрии. Тезисно, можно посмотреть на следующие направления.
Проектирование – это тоже сложная деятельность, результат которой можно оценить. Успешное проектирование ценится не слишком хорошо, на уровне «само собой разумеется», в то время как провалы в проектировании наглядно портят весь проект. Используя Agile, сама деятельность по проектному управлению сохраняется, но переводится в спонтанную категорию (ad hoc) где её качество становится смутно оцениваемым.
Второе, на мой взгляд, выдающееся качество -- ответственность практически полностью перекладывается на заказчика, особенно в областях не входящих в компетенцию заказчика. Вот это последнее особенно ценно. Это позволяет почти любую проблему исполнителя документально обосновать запросами заказчика.
Этим же подходом качество архитектурных решений и общая системотехника так же переводится в смутную область.
Обходится проблема массового привлечения персонала недостаточной квалификации. Задача формулирования заданий и контроля исполнения сводится к утилизации простейших доступных навыков исполнителей. Результат неквалифицированного труда так же представляется как результат выполнения запроса.
Процесс выполнения работ неявно приводится к схемам Time&Material и Outstaffing. Собственно, проблема тут в неявности, поскольку контроль, в том числе и времени и состава аренды, остаются у исполнителя.
Или кратко, Agile позволяет переложить на заказчика проблемы проектирования, архитектуры и общей низкой квалификации производителей работ и исполнителей.
PS: Прочитав этот текст должен признать его видимую черствость к сторонникам Agile, это уже моя проблема формы изложения, а не отношение к людям.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2010-12-21 08:55 pm (UTC)no subject
Date: 2010-12-21 09:08 pm (UTC)no subject
Date: 2010-12-21 09:15 pm (UTC)Чтобы понимание отношения стратегии и тактики было настолько же прописной истиной, которую можно вынести за скобки, её надо вдалбливать столь же часто, как человек кушает в присутствии следящих за этикетом. То есть, трижды в день на протяжении двадцати лет.
Пока это невозможно, надо говорить об этом при каждом удобном случае.
Чего в Agile нет.
Как и понимания, какие истины являются прописными, а какие нет - у его сторонников.
no subject
Date: 2010-12-21 09:19 pm (UTC)no subject
Date: 2010-12-21 09:31 pm (UTC)На этот раз даже без намёка на какую-либо связь с тем, что я сказал, поэтому я совершенно не в силах расшифровать ваш комментарий.
Не затрудните себя более развёрнутым комментарием?
no subject
Date: 2010-12-21 09:39 pm (UTC)Я уж и не говорю, что и изначальное утверждение о том, что тактика должна следовать после стратегии - безосновательно.
no subject
Date: 2010-12-21 10:32 pm (UTC)Во-первых, вы считаете тезис "тактика следует за стратегией" прописной истиной для образованного человека, сродни умению пользоваться ножом и вилкой. Или умению делить в столбик для физика-теоретика.
Во=вторых, вы считаете, что моё первоначальное утверждение "тактика следует за стратегией" безосновательно, то есть, спорно.
Я вижу здесь непоследовательность.
no subject
Date: 2010-12-21 10:40 pm (UTC)no subject
Date: 2010-12-22 03:09 pm (UTC)Вто время как мы с тобой вполне обходимся словами и ничего из пенопласта при этом не выпиливаем :)
no subject
Date: 2010-12-22 03:02 pm (UTC)no subject
Date: 2010-12-22 02:59 pm (UTC)Вот так говоришь "ну мы тут все культурные люди", а потом оказывается что в метро шесть молодцев в ряд сидят при стоящих дамах.
Программист php не обязан хорошо писать на c, agile разработчик не обязан хоть что-то знать из понятий классического проектирования. В школах им не учат.
Опять же, хороший специалист, умный, образованный, эрудированный, опытный может работать с очень разными методиками. Как говорится, при некотором уровне мастерства вид спорта не имеет значения.
no subject
Date: 2010-12-22 04:06 pm (UTC)