Дегенератская технология Agile и будущ. катастрофа

Александр Бурьяк
Дегенератская технология Agile и грядущая глобальная катастрофа

  Одна из напастей в этом всё более портящемся мире -- популяр-
ная технология Agile.

  Agile -- это НЕ технология программирования, НЕ технология
разработки программных систем. Это лишь технология МЕНЕДЖМЕНТА
разработки:
  - пришпоривания коллектива разработчиков;
  - длительного удержания заказчика в зависимости от поставщика.

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

  Agile -- это по сути большой развод со стороны прослойки так
называемых "каучей" (coaches), зарабатывающих "впариванием" своей
ерунды страдающему доверчивому плебсу, алчущему эффективных
решений.

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

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

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

  Сопливый программер нового поколения, освоивший азы кодирова-
ния, техники drag-and-drop и поиска готовых решений в google,
норовит сбегать от своих трудовых обязанностей раз за разом в
интернет или в коридор -- охмуряться псевдоинформацией и наслаж-
даться радостью пустого общения с себе подобными элойчиками. До
некоторого времени аутсорсинг позволял компенсировать ухудшение
качества инженеров в переразвитых странах привлечением "человече-
ского материала" из стран, менее порченных псевдопрогрессом, но
теперь он уже не даёт прежнего эффекта, потому что порча широко
распространилась по миру.

  Agile -- это плотная опека несамостоятельных и морально разло-
женных личностей: организация их взаимного наблюдения (стараются
садить весь коллектив в одном месте, чтобы он своим галдёжем ме-
шал работать тонким натурам, нуждающимся в тишине) и взаимной
проверки (коллеги устраивают ревизию кода и документации друг у
друга и докладывают результаты на общем собрании команды). Ещё
характерное для Agile -- это каждодневные отчёты команде по сле-
дующей схеме:
   - чем занимался со времени предыдущего отчёта;
   - что успел сделать;
   - чем будешь заниматься в промежутке до следующего отчёта;
   - какие у тебя "блокеры" (тормозящие обстоятельства).

  Ежедневные командные сборы и подготовка к ним отнимают рабочее
время (процентов 10% как минимум), отвлекают от собственно дела
в неподходящие моменты, вынуждают заботиться о том, чтобы выгля-
деть бойким на фоне других, и имитировать активность. Тебя оцени-
вают каждый день. Не будешь убедительно изображать ежедневное
продвижение вперёд не хуже коллег -- тебя сочтут слабым членом
команды и избавятся от тебя. Физиологически естественные подъёмы
и спады активности -- это уже не для тебя: ты должен постоянно
быть на подъёме или хотя бы делать вид, что он есть. Если решение
какой-то проблемы растягивается на несколько дней, ты начинаешь
выглядеть тугодумом.

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

  Есть области, в которых внедрять Agile могут отважиться только
латентные самоубийцы. Это, к примеру, управление движением транс-
портных средств. Самолёты у вас падают? Таки да. А поезда сталки-
ваются? Бывает. А вы проверяли, какие там использовались техноло-
гии менеджмента при разработке программного обеспечения? Даже ес-
ли это был не Agile, то, возможно, были задействованы люди, кото-
рым Agile успел испортить профессиональное мышление.

                *  *  *

   Пройдёмся по трескучим ценностям Agile:

 1. ЛЮДИ И ВЗАИМОДЕЙСТВИЕ ВАЖНЕЕ ПРОЦЕССОВ И ИНСТРУМЕНТОВ.

     По-видимому, имеется в виду компенсация "человеческим факто-
   ром" недостатков инструментов, разработанных с применением
   Agile, и плохого проектирования процессов.

 2. РАБОТАЮЩИЙ ПРОДУКТ ВАЖНЕЕ ИСЧЕРПЫВАЮЩЕЙ ДОКУМЕНТАЦИИ.

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

 3. СОТРУДНИЧЕСТВО С ЗАКАЗЧИКОМ ВАЖНЕЕ СОГЛАСОВАНИЯ УСЛОВИЙ
    КОНТРАКТА.

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

 4. ГОТОВНОСТЬ К ИЗМЕНЕНИЯМ ВАЖНЕЕ СЛЕДОВАНИЯ ПЕРВОНАЧАЛЬНОМУ
    ПЛАНУ.

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

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

 5. ВОЛЯ К ПОБЕДЕ ВАЖНЕЕ КОМПЕТЕНТНОСТИ.

 6. ИНТУИЦИЯ ВАЖНЕЕ РАСЧЁТА.

 7. ВЗАИМОПОМОЩЬ ВАЖНЕЕ САМОСТОЯТЕЛЬНОСТИ.

 8. ГИБКОСТЬ ВАЖНЕЕ ТВЁРДОСТИ.

 9. НАСТОЙЧИВОСТЬ ВАЖНЕЕ ПЛАНИРОВАНИЯ.

10. СПАЯННОСТЬ КОЛЛЕКТИВА ВАЖНЕЕ ОСТОРОЖНОСТИ.

   И т. д.

  Якобы принципы Agile ("Манифест гибкой разработки программ-
ного обеспечения", Agile Manifesto):

1. НАИВЫСШИМ ПРИОРИТЕТОМ ЯВЛЯЕТСЯ УДОВЛЕТВОРЕНИЕ ПОТРЕБНОСТЕЙ
   ЗАКАЗЧИКА, БЛАГОДАРЯ РЕГУЛЯРНОЙ И РАННЕЙ ПОСТАВКЕ ЦЕННОГО
   ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ.

   Тра-та-та. Реальный смысл такой: бомбить заказчика сырыми,
   часто обновляемыми версиями.

2. ИЗМЕНЕНИЕ ТРЕБОВАНИЙ ПРИВЕТСТВУЕТСЯ, ДАЖЕ НА ПОЗДНИХ СТАДИЯХ
   РАЗРАБОТКИ.

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

3. РАБОТАЮЩИЙ ПРОДУКТ СЛЕДУЕТ ВЫПУСКАТЬ КАК МОЖНО ЧАЩЕ, С
   ПЕРИОДИЧНОСТЬЮ ОТ ПАРЫ НЕДЕЛЬ ДО ПАРЫ МЕСЯЦЕВ.
    
     То есть, надо чаще беспокоить юзеров сменами сырых версий: не
   успеют юзеры приспособиться к какой-нибудь "кривизне", как эта
   "кривизна" заменяется другой.

4. НА ПРОТЯЖЕНИИ ВСЕГО ПРОЕКТА РАЗРАБОТЧИКИ И ПРЕДСТАВИТЕЛИ
   БИЗНЕСА ДОЛЖНЫ ЕЖЕДНЕВНО РАБОТАТЬ ВМЕСТЕ.
   
     У представителей бизнеса, наверное, мало других забот.

5. НАД ПРОЕКТОМ ДОЛЖНЫ РАБОТАТЬ МОТИВИРОВАННЫЕ ПРОФЕССИОНАЛЫ.
   ЧТОБЫ РАБОТА БЫЛА СДЕЛАНА, СОЗДАЙТЕ УСЛОВИЯ, ОБЕСПЕЧЬТЕ ПОД-
   ДЕРЖКУ И ПОЛНОСТЬЮ ДОВЕРЬТЕСЬ ИМ.

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

6. НЕПОСРЕДСТВЕННОЕ ОБЩЕНИЕ ЯВЛЯЕТСЯ НАИБОЛЕЕ ПРАКТИЧНЫМ И
   ЭФФЕКТИВНЫМ СПОСОБОМ ОБМЕНА ИНФОРМАЦИЕЙ КАК С САМОЙ КОМАНДОЙ,
   ТАК И ВНУТРИ КОМАНДЫ.
    
     Передача важной информации через письменно не фиксируемое
   bla-bla-bla порождает неопределённости, недокументированность,
   хлопотность выяснения, откуда что пошло, а вдобавок трудность
   поиска виноватых, если что.
     И сложное плохо воспринимается на слух и даже через наблю-
   дение за тем, как кто-то водит пальцем по небрежно нарисован-
   ной схеме (которая скоро будет стёрта с доски) или курсором по
   экрану.

7. РАБОТАЮЩИЙ ПРОДУКТ — ОСНОВНОЙ ПОКАЗАТЕЛЬ ПРОГРЕССА.
    
     Тра-та-та. Возможно, тут намекается на то, что надо пораньше
   выдать заказчику хоть что-то шевелящееся.

8. ИНВЕСТОРЫ, РАЗРАБОТЧИКИ И ПОЛЬЗОВАТЕЛИ ДОЛЖНЫ ИМЕТЬ ВОЗМОЖ-
   НОСТЬ ПОДДЕРЖИВАТЬ ПОСТОЯННЫЙ РИТМ БЕСКОНЕЧНО.
    
     Что имеется в виду, не понятно. Наверное, бесконечная
   зависимость заказчика от разработчика: если однажды попался 
   на крючок аджайлистам, то потом с него не слезешь.
   
9. ПОСТОЯННОЕ ВНИМАНИЕ К ТЕХНИЧЕСКОМУ СОВЕРШЕНСТВУ И КАЧЕСТВУ
   ПРОЕКТИРОВАНИЯ ПОВЫШАЕТ ГИБКОСТЬ ПРОЕКТА.
 
     Agile и качество -- плохо совместимые вещи. Проектирование
   при Agile - это кто в лес, кто по дрова, лишь бы скорее.
 
10. ПРОСТОТА — ИСКУССТВО МИНИМИЗАЦИИ ЛИШНЕЙ РАБОТЫ — КРАЙНЕ
   НЕОБХОДИМА.
    
     Покажите тех, кто против простоты.

11. САМЫЕ ЛУЧШИЕ ТРЕБОВАНИЯ, АРХИТЕКТУРНЫЕ И ТЕХНИЧЕСКИЕ РЕШЕНИЯ
    РОЖДАЮТСЯ У САМООРГАНИЗУЮЩИХСЯ КОМАНД.
   
      ...а руководитель коллектива при этом не разбирается ни в
    каких вещах, кроме Agile.

12. КОМАНДА ДОЛЖНА СИСТЕМАТИЧЕСКИ АНАЛИЗИРОВАТЬ ВОЗМОЖНЫЕ СПОСОБЫ
    УЛУЧШЕНИЯ ЭФФЕКТИВНОСТИ И СООТВЕТСТВЕННО КОРРЕКТИРОВАТЬ СТИЛЬ
    СВОЕЙ РАБОТЫ.

      Команда должна бороться с отклонениями от Agile, то есть, с
    попытками работать более систематично?

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

  Agile -- это когда интеллектуально деградировавший заказчик об-
ращается к морально и технологически деградировавшему разработчи-
ку с заданием: сделай мне приблизительно вот это и поскорее, по-
тому что я, будучи не в состоянии толком предвидеть, планировать
и анализировать, оказался перед необходимостью срочной заделки
дыры хоть чем-нибудь; или потому что я хочу быть передовым, а не
консервативным (основательным, осторожным), и меня впечатлил лжи-
вый манипулятивный трёп про Agile.

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

  Можно быстро разрабатывать системы и используя технологию стру-
ктурного программирования, но это хлопотно в управлении. В случае
сложных программных систем налаженная технология структурного
программирования способна обеспечивать выдачу продукта даже быст-
рее, чем технологи Agile, причём продукта высококачественного,
дешёвого в сопровождении, но соль в том, что менеджмент тоже
дергадирует. Agile -- это и реакция на деградацию менеджмента, и
и обеспечение дальнейшей его деградации.
 
  Разработчику, конечно, выгоднее дорогие в сопровождении продук-
ты. Но заказчик, которому дороговизна сопровождения ни к чему,
имеет возможность требовать, чтобы система для него разрабатыва-
лась не по методике Agile. Но проблема в том, что высококачест-
венных разработчиков найти всё труднее.

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

                *  *  *

  У этого дерьма, оказывается, ещё и разновидности есть: scrum,
kanban и т. п. Впрочем, кто б сомневался. Плодить формальные раз-
новидности -- это обычный приём самоутверждения и втюхивания:
немножко что-то поменял (хотя бы соотношение разных компонентов
гадости), обозвал всё это новым звучным словом и потом корчишь из
себя новатора и ловишь свою долю лохов, верящих в "прогресс".

                *  *  *

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

  А ещё в Agile противна игроватость. Agile -- это типа забавно и
весело. Он -- для заигравшегося поколения. И для обчитавшегося
fiction в жанре fantasy (там тоже всё выстраиваются мирки).

  И вызывает сильную неприязнь то, что манипулянты и искренне
уверовавшие в эту чушь адепты рвутся своему Agile ОБУЧАТЬ -- и
даже какие-то сертификаты потом присваивают. На самом деле, коне-
чно, набивают себе цену и доят "лохов". Господи, ну чему-там обу-
чаться-то? Тридцать минут почитал -- и этого достаточно (если ты
не совсем уж дурак). Это ведь не решение каких-нибудь уравнений и
не приёмы рукопашного боя.
  Основная задача "обучения" состоит, наверное, в том, чтобы...
  1) не ознакомить, а надёжно впарить; сформировать чувство по-
     свящённости, чувство превосходства над "необученными";
  2) вызвать стремление внедрять эту мерзость в практику и втю-
     хивать другим: как же, надо ведь пробовать окупить затраты
     времени и денег на "обучение".

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

  Некоторые специалисты потолковее выкручиваются из сложившейся
дурацкой ситуации так: они лишь ИМИТИРУЮТ использование Agile.
Испольняют какой-то минимум обрядов. Получается, внешне ты -- в
тренде, а на самом деле работаешь в основном по-старому, то есть
хорошо. Но это, конечно рискованно в плане карьеры: какая-нибудь
подсиживающая карьеристская дрянь может начать вонять, что ты по
сути не знаешь и не понимаешь великого Agile, не способен ухваты-
вать "современные технологии", показываешь дурной пример молодё-
жи, сдерживаешь развитие предприятия и негативно отражаешься на
его прибылях.

                *  *  *

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

                *  *  *

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

                *  *  *

  Agile -- это старое микрософтовское [презренное] "экстремальное
программирование", доведенное до состояния товара. В самом деле,
если деньги не пахнут, то почему не втюхивать ещё и это?

                *  *  *

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

  Зло, которое убьёт человечество, не будет носить явно деструк-
тивный характер: наоборот, оно будет выглядеть, как местами боль-
шое добро. И это убивающее зло не будет являть собой какой-то
один тип мерзости: это будет множество всяких как бы мелочей,
каждая из которых сама по себе не очень-то разрушительна. Но эти
как бы мелочи будут воздействовать одновременно и кое-где даже
взаимомвязанно. Agile -- из таких вот мелочей, неявно убивающих
человечество.

                *  *  *

  Хорошо программировать с "добросовестным" использованием Agile
НЕВОЗМОЖНО. А вот халтурно программировать без использования Agi-
le можно вполне. Agile всего лишь обеспечивает чуть более БЫСТРЫЙ
вариант производства чуть более работоспособной халтуры чуть ме-
нее качественными кадрами.

                *  *  *

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

                *  *  *

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

                *  *  *

  Ни одно предприятие, занимающееся разработкой и сопровождением
программного продукта, НЕ СПОСОБНО выступить против Agile -- по
ряду причин. А значит, не заинтересовано и в его критике. А зна-
чит, к отказу от Agile оно должно быть ПРИНУЖДЕНО СО СТОРОНЫ. Со
стороны государства.

  Причины того, почему в отрасли IT не критикуют Agile:
 1. Agile вполне служит текущему общему интересу отрасли: ста-
    вить клиента в как можно большую зависимость от себя. Высту-
    пать против Agile значит немножко пилить сук, на котором си-
    дишь (потом, правда, тебя на нём и повесят -- может быть).
 2. Критикнёшь Agile -- вывалишься из трендов, станешь "белой во-
    роной", нарушишь сплочённость шеренги. Клиент тебя адекватно
    не оценит (он -- более-менее жертва рекламных манипуляций), а
    "свои" начнут в отместку понемногу тебя бойкотировать и тра-
    вить.
 3. Agile -- это в отрасли IT далеко не единственная мерзость,
    используемая для лучшего вытягивания денег из клиентов. С ка-
    кого рожна относиться к ней не так, как к другим мерзостям,
    -- хороший вопрос.
 4. Начнёшь критиковать Agile -- рискуешь вызвать резко критичес-
    кий интерес вообще к феномену IT. Дело может закончиться
    "схлопыванием" отрасли процентов на 90 -- и ты очень даже в
    состоянии не оказаться в оставшихся 10%.

                *  *  *

  Кое-кому, наверное, можно было бы и потерпеть Agile как средст-
во выдуривания денег у клиентов (зачастую клиенты эти деньги вряд
ли вполне заслужили), но достают ведь требованиями, чтобы ты был
как можно аджайлистее, сертифицировался, гордился своим Agile,
писал у себя [на любу] в "резюме" слово Agile, играл не только в
основные аджайлские игры, но и в дополнительные. Это как от рас-
стрельной команды требовать, чтобы она расстреливала "с огоньком"
и пришивала себе на рукава ленточку с надписью "расстрельщик".
Солдат не в праве уклониться от назначения его в расстрельную ко-
манду, но вдобавок сертифицироваться на расстрельщика -- это для
нормального военнослужащего, как правило, уже слишком.

                *  *  *

  Бывает забавно наблюдать, как АДЖАЙЛЯТСЯ менеджеры и мечтающие
стать менеджерами. Иногда при этом плюются, но аджайлятся всё ра-
вно: хочешь лезть в кузов -- называйся груздем. Пой ту же песню,
что и другие. Не важно, что колонна марширует в ад: важно, что ты
 уже в командирах, а до ада ещё не совсем близко.

                *  *  *

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

  Аджайлцы придумали "образ врага" -- Waterfall method: водопад-
ный, значит; то есть, движение только прямолинейное, итерации не-
возможны, результат ожидается лишь в конце. Это, разумеется, гнус-
ная чушь собачья и мерзкая клевета. На самом деле всегда имело
место стремление пораньше показать что-то работающее заказчику,
чтобы он мог уточнить свои требования и подправить разработчика.
Никаких технических или юридических препятствий для этого не бы-
ло. Полезность довольно тесного взаимодействия с заказчиком в
процессе разработки -- вещь очевидная, потому что заказчик эле-
ментарно не в состоянии предусмотреть ВСЁ. Вдобавок его требова-
ния со временем меняются уже просто потому, что "жизнь не стоит
на месте". Доброжелательные отношения заказчика и разработчика,
взаимопомощь, хождение друг другу навстречу -- основа общего
успеха. Заказчик заинтересован в долговременном сотрудничестве с
разработчиком, разработчик -- с заказчиком. Лично я не помню ни
одного доаджайлового проекта, на котором это было бы не так.


                *  *  *

  Кстати, из Википедии (= не так уж сложно понять), статья
"Дейкстра":

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


Литература:

  Алан Купер "Психбольница в руках пациентов", 1998.
 
  Фредерик Брукс "Мифический человеко-месяц", 1975.

  Никлаус Вирт "Систематическое программирование", 1977.

  Эдсгер Вибе Дейкстра "Дисциплина программирования", 1978.