Всем привет. В свежем выпуске NT Insider обнаружил материал как раз для этого форума — представляю вашему вниманию статью из серии "Все что ты давно знал про Agile, но боялся сказать вслух"

I know that you, dear reader, have come to expect a certain level of sophistication and journalistic integrity when it comes to my monthly pontifications: A gloss of civility, a certain level of refinement, and an even airing of all sides of an issue. Thus, on those very rare occasions when I have a personal opinion to present, I feel the need to make my viewpoint on the issue under discussion extremely clear. And so it is for today‘s topic: Agile software development methodology.

Let me start, then, by clearly, dispassionately, and logically describing my point of view:

Agile software development methodology sucks ass. Big time. Totally. 100%. Entirely.

Gosh, I hope I‘ve stated that clearly enough.

Let me explain further: I have never, not once, not ever, participated in, seen, or even heard of a project in which Agile works better than any well-organized alternative. Agile is without question the refuge of those with small minds, poor writing skills, and extremely high-levels of tolerance for incomplete functionality that‘s written in a way that‘s "good enough" to pass whatever tests happen to exist.

Just to make sure that you understand that I mean to slag the entire, wide-ranging, genre that is Agile, I specifically mean to include Agile permutations like Scrum. Basically, I mean to include any software development methodology that relies on references to barnyard animals, where you stand-up to have meetings, or where you‘re supposed to account for what you‘re doing in units of, like, 45 minutes.

My major objections to Agile come from what I view as the unmitigated stupidity of its three most important tenets:

A maniacal emphasis on "just getting something working" as opposed to thinking something through, designing how it should work, and getting something working correctly.

Requiring detailed estimates of how long it‘s going to take to implement some piece of functionality.

An insane reliance on – and limitation to implementing features for – user stories (AKA scenarios), which yield fragmented feature sets as opposed to designing for well-reasoned comprehensive functionality.

For the life of me, I do not understand why I would ever want to write code for a complex facility before I have had the chance to design that facility and consider how it will interact with everything else in its environment. For sure, managers like it. They think designing things is a waste of time anyhow. This reminds me of clients who tell me to «just write some code» to do so-and-so. I work in kernel-mode, boys. I often work on complex pieces of larger systems. It doesn‘t make a lot of sense to just «write some code» that‘s «good enough» – when you do that, you get code that doesn‘t handle corner cases, doesn‘t work or play well with others, and is generally ill-conceived.

But Agile is all about «just writing code» System architecture? Design? In Agile, that‘s not in the plan. What‘s in the plan is «code it up and see how it works» and «you can fix it in the next sprint» That‘s hosed. It‘s a waste of time. And while I‘m all about «plan to write one to throw away», I sorta think that the word «plan» is important there.

Ever build a house? ...

(continued on page 5 of The latest issue of The NT Insider (July/August 2010) is now exclusively available for download in PDF format.)

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

Здравствуйте, Valery A. Boronin, Вы писали:

VAB>Всем привет. В свежем выпуске NT Insider обнаружил материал как раз для этого форума — представляю вашему вниманию статью из серии "Все что ты давно знал про Agile, но боялся сказать вслух"

С таким подходом статью можно написать о чем угодно. Например, колонка "Плюсы и минусы заведения собаки" для журнала "Вестник кошатника":

Вот что я должен вам сказать, коллеги, положа руку на сердце и выступая со всей прямотой: собаки — отвратительны. И точка. Я ни разу не владел, не видел и даже не представляю себе, как собака могла бы быть лучше кошки.
Чтобы не быть голословным, я сейчас подробно докажу свое мнение в трех пунктах. Итак:

• От них пахнет псиной.
  
• Они грызут тапки и мебель!
  
• Собак надо выгуливать и убирать за ними!

Одно остается для меня загадкой — и почему это все вокруг так любят этих зверюг?

Ну а вообще, да, нормальное такое мнение, с дельными замечаниями. Только непонятно: если автор (чем он известен, кстати? книжкой про написание драйверов?) не работал в аджайле — то откуда такие ценные знания, а если работал — то почему мужественно все это терпел, не ушел и не сделал лучше?

Здравствуйте, rlabs, Вы писали:

R>Одно остается для меня загадкой — и почему это все вокруг так любят этих зверюг?
R>Ну а вообще, да, нормальное такое мнение, с дельными замечаниями. Только непонятно: если автор (чем он известен, кстати? книжкой про написание драйверов?) не работал в аджайле — то откуда такие ценные знания, а если работал — то почему мужественно все это терпел, не ушел и не сделал лучше?

Вы можете по существу его претензий возразить?

Здравствуйте, Valery A. Boronin, Вы писали:

VAB>

A maniacal emphasis on "just getting something working" as opposed to thinking something through, designing how it should work, and getting something working correctly.

VAB>

Requiring detailed estimates of how long it‘s going to take to implement some piece of functionality.

VAB>

An insane reliance on – and limitation to implementing features for – user stories (AKA scenarios), which yield fragmented feature sets as opposed to designing for well-reasoned comprehensive functionality.

Прочитал в оригинале — у чувака негативный опыт работы с недоделанными PM и TL. Где в agile принципах написано — никакого планирования, и так сойдет??? Что плохого в прогнозировании времени выполнения? Чувак вообще слышал про фокус фактор?! Набор user story — входные данные для архитектора системы, это промежуточный этап — столбики на дороге реализации. А про жухло с деланием всего заранее и вставкой в след. спринт уже сделанного — в таком случае заказчику Ваша работа нафиг не нужна. Когда заказчик заинтересован — такая ситуация вряд ли возможна. ИМХО

Здравствуйте, A.Lokotkov, Вы писали:

AL>Здравствуйте, rlabs, Вы писали:

AL>Вы можете по существу его претензий возразить?

По существу я мого доложить вам следующее:

1. нет одинаковых проектов
   
2. нет одинаковых команд
   
3. исходя из первых двух пунктов, нельзя говорить о сферических agile/waterfall методологиях в вакууме. Можно — об успешности или неуспешности адаптации конкретной методологии конкретной командой в конкретном проекте

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

Конкретные же претензии автора, после фразы "But Agile is all about "just writing code". System architecture? Design? In Agile, that‘s not in the plan." можно обсудить, но уже не как "Pros & Cons of Agile SW Development", а как конкретные неудачи, с которыми автор столкнулся и обобщил их на всю методологию.

Здравствуйте, rlabs, Вы писали:

R>Конкретные же претензии автора, после фразы "But Agile is all about "just writing code". System architecture? Design? In Agile, that‘s not in the plan." можно обсудить, но уже не как "Pros & Cons of Agile SW Development", а как конкретные неудачи, с которыми автор столкнулся и обобщил их на всю методологию.

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

К чему это я?
А то, что дух, настроения, мотивация и атмосфера, которые окутывают идеи,
еще как сказываются на конкретных реализациях идей, с которыми мы в итоге и сталкиваемся.

Здравствуйте, Аноним, Вы писали:

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

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

А>Вот сейчас мы (наша команда) начинаем совместный проект с другой "гибкой командой"
А>и мы понятия не имеем, как отвлечь их от кодописательства и начать думать
А>об архитектуре и других долгосрочных вещей, игнорирование которых приводит
А>в итоге к проблемам и большим тратам.

Собственно целью любой команды, гибкой или нет, является выпуск продукта. Если ваши коллеги ставят кодинг выше этой цели — значит, это не гибкая команда, а обычный бардак.

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

Здравствуйте, rlabs, Вы писали:

R>С другой стороны, то, что выглядит как "кодописательство", может преследовать вполне конкретную и понятную цель, направленную на выпуск продукта. Имеет смысл это выяснить, может их и не надо отвлекать.

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

Здравствуйте, rlabs, Вы писали:

AL>>Вы можете по существу его претензий возразить?

R>По существу я мого доложить вам следующее:
R>

R>
1. нет одинаковых проектов
   R>
2. нет одинаковых команд
   R>
3. исходя из первых двух пунктов, нельзя говорить о сферических agile/waterfall методологиях в вакууме. Можно — об успешности или неуспешности адаптации конкретной методологии конкретной командой в конкретном проекте
   R>

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

И ведь нет одинаковых людей, казалось бы! И врачей одинаковых нет! Откуда, казалось бы, точно также, должна следовать полная невозможность каких-либо обобщений! Только конкретный человек принимающий конкретную какашку — и не дай бог никакой статистики! Никаких контрольных групп с плацебо и старыми препаратами!

Немного вы можете доложить по существу, короче. У вас есть по существу что-нибудь еще? Ну, что-нибудь помимо запретов о чем-нибудь говорить?

Здравствуйте, Аноним, Вы писали:

А>Ну, у врачей как-никак получается говорить о методах лечения и лекарственных препаратах. О гомеопатии, скажем. Об антибиотиках фторхилиновой группы. Об НПВП.

Фторхиноловой, конечно. Но это ерунда, в общем.

Главное — что инструкции к препаратам надо запретить. Нельзя говорить о действии цифрана или аспирина на сферического человека в вакууме при сферическом враче! Нельзя!

Каждый раз заново испытывать надоть — загнется или нет, и если да — то от какой дозы.

А>Каждый раз заново испытывать надоть — загнется или нет, и если да — то от какой дозы.

Кажется, я догадываюсь, кто этот аноним

Здравствуйте, A.Lokotkov, Вы писали:

А>>Каждый раз заново испытывать надоть — загнется или нет, и если да — то от какой дозы.

AL>Кажется, я догадываюсь, кто этот аноним

Не, ты ошибаешься

Здравствуйте, Аноним, Вы писали:

А>Немного вы можете доложить по существу, короче. У вас есть по существу что-нибудь еще? Ну, что-нибудь помимо запретов о чем-нибудь говорить?
А у вас? Ну, кроме акробатов, или как их там, в цирке в общем такие?

Здравствуйте, rlabs, Вы писали:

А>>Немного вы можете доложить по существу, короче. У вас есть по существу что-нибудь еще? Ну, что-нибудь помимо запретов о чем-нибудь говорить?
R>А у вас? Ну, кроме акробатов, или как их там, в цирке в общем такие?

А у нас по существу в статье. Давайте про статью, про цирк с этимикаких в другой раз расскажете, ладно?

Как по мне — Скрам очень большая х-ня (кроме отдельных случаев, где он применим, но таких мало).
Особенно настораживает то, что люди его проповедующие скорее похожи на НЛП практиков и религиозных фанатиков, нежели на профессионалов.
Но это мое ИМХО.

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

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

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

Здравствуйте, SpaceConscience, Вы писали:

SC>Очевидно, что для разных проектов нужны разные методологии. Выбор методологии, например, определяется соотношением сложности требований к сложности их реализации. Например, в бизнес-приложениях обычно не требуется сложных алгоритмов и нестандартных архитектурных решений, но сложность и изменчивость требований может быть колоссальной;

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

Здравствуйте, bkat, Вы писали:

SC>>Очевидно, что для разных проектов нужны разные методологии. Выбор методологии, например, определяется соотношением сложности требований к сложности их реализации. Например, в бизнес-приложениях обычно не требуется сложных алгоритмов и нестандартных архитектурных решений, но сложность и изменчивость требований может быть колоссальной;

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

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

Для проектов методологии не нужны — понятие методологии противоречит самой сути "гибкости". Нужны методы, которые можно свободно комбинировать.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, bkat, Вы писали:

SC>>>Очевидно, что для разных проектов нужны разные методологии. Выбор методологии, например, определяется соотношением сложности требований к сложности их реализации. Например, в бизнес-приложениях обычно не требуется сложных алгоритмов и нестандартных архитектурных решений, но сложность и изменчивость требований может быть колоссальной;

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

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

А>Для проектов методологии не нужны — понятие методологии противоречит самой сути "гибкости". Нужны методы, которые можно свободно комбинировать.

А что же тогда продавать?

Здравствуйте, gandjustas, Вы писали:

А>>Для проектов методологии не нужны — понятие методологии противоречит самой сути "гибкости". Нужны методы, которые можно свободно комбинировать.

G>А что же тогда продавать?

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

Однако, по настоящему грамотные пацаны тренингами не зарабатывают. Якобсон, если посмотрите его сайт, увидите — разделяет мою точку зрения. Хрюшка (один из авторов Andrenaline Junkies & Template Zombies) — тоже.

У всех этих парней основной доход с конкретной работы. Хрюшка, например, — оказывает услуги организациям по управлению конкретными требованиями. Том ДеМарко, со слов Хрюшки, также имеет основной доход далеко не с книг и тренингов.

Делайте выводы.