Александр Бурьяк

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

bouriac@yahoo.com На главную страницу
Одна из напастей в этом всё более портящемся мире -- популяр- ная технология Agile. Agile -- это НЕ технология программирования, НЕ технология разработки программных систем. Это лишь технология МЕНЕДЖМЕНТА разработки: - пришпоривания коллектива разработчиков; - длительного удержания заказчика в зависимости от поставщика. Всякие технические вещи, существенные для удобных и надёжных программных систем, -- вне Agile. Agile-менеджеру безразлично, какую архитектуру системы ты используешь и хороший ли ты пишешь код: лишь бы ты писал его в срок, а этот код потом хоть кое-как работал (кстати, если он работает плохо, то это для менеджера хорошо, потому что позволяет тянуть и тянуть с заказчика деньги на всякие улучшения-исправления; лишь бы код не работал настолько плохо, что заказчик послал бы к чертям аджайлистов вместе с их доставучим продуктом). Agile -- это по сути большой развод со стороны прослойки так называемых "каучей" (coaches), зарабатывающих "впариванием" своей ерунды страдающему доверчивому плебсу, алчущему эффективных решений. Среди прочего, Agile -- средство выжимания хоть чего-нибудь из всё ухудшающегося "человеческого материала", страдающего от вся- ких зависимостей, включая игровую и интернетную. Курсы по обуче- нию программистов работе по принципам Agile обычно проводятся, как для умственно неполноценных, между тем психически развитому программеру достаточно почитать всего лишь 30 минут про этот Agile в википедии, чтобы понять, чего от него, программера, хо- тят и к чему всё это приведёт. Довольно большое количество специалистов в области программиро- вания настроено по отношению к 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. * * * Кстати, из Википедии (= не так уж сложно понять), статья "Дейкстра": "По мнению Дейкстры, господствующий в компьютерной индустрии подход к программированию как к процессу достижения результата методом проб и ошибок (написать код - протестировать - найти ошибки - исправить - протестировать - ...) порочен, поскольку стимулирует программистов не думать над задачей, а писать код, что при этом совершенно не гарантирует корректность программ, которая не может быть доказана тестированием в принципе. Многократно предостерегал от попыток превратить разработку про- грамм в некий тривиальный процесс; по его мнению, программирова- ние в сути своей - чрезвычайно сложная научная и инженерная дея- тельность, и никакие новые методы и инструменты не смогут карди- нально изменить это положение - они лишь освобождают программиста от части рутинной работы. Попытки же превратить программирование в простое занятие, доступное каждому, обречены на провал." Уточню, что это будет за провал: провалится наша цивилизация.

Литература:

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

Возврат на главную страницу            Александр Бурьяк / Дегенератская технология Agile и грядущая глобальная катастрофа