Одна из напастей в этом всё более портящемся мире -- популяр-
ная технология 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.
Возврат на главную страницу Александр Бурьяк / Дегенератская технология Agile и грядущая глобальная катастрофа