Разбор agile текстов

2.2.3 Запугивание

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

Хорошей концентрацией такого вида артиллерии является статья Стива Деннинга [Denning 2012] "Десять возражений к методам управления", опубликованная в журнале Forbs и призванная защитить agile методы управления. Как и всякая страстная agile речь, она не отличается вежливостью и представляет фронтальную атаку на всякого, кто отважится замахнуться на святое слово. Ценность ее в том, что извлечения из нее дают возможность составить полезный список того, чего можно ожидать в подобных случаях.

Вас сразу же заставляют замолчать, поскольку вы отрицаете инновации. Статья Деннинга начинается с цитаты Эйнштейна:

"Если идея с первого взгляда не кажется абсурдной, то она не заслуживает внимания".

Хороший прием для автора, чьи аргументы шатки, использовать цитату Эйнштейна, затасканную от многократного применения (в интернете можно найти многочисленные примеры). Кто может поспорить с самим Эйнштейном?

Поощрять посредственность? Вы этого хотите?

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

Шуткой Эйнштейна можно оправдать все что угодно. Особый интеллектуальный механизм, используемый здесь, представляет вариацию логического обмана, основанного на использовании перехода от "A влечет B" к выводу "B влечет A". Можно назвать это синдромом Колумба: люди полагали, что проект Колумба абсурден, а он оказался грандиозным. Вы полагаете, что мой проект абсурден, следовательно, он должен оказаться великим.

Приведу на эту же тему хороший пример, взятый из юмористического журнала и также связанный с Эйнштейном:

– Мой ребенок гениален!

– Вы так полагаете?

– У Эйнштейна в школе были плохие отметки. У Миши они гораздо хуже!

Рис. 2.1. Из комикса на тему Эйнштейна и его школьных оценок

Один из главных аргументов в статье Деннинга может служить учебным примером синдрома Колумба. В четырех абзацах пересказывается история открытия, сделанного Джоном Харрисоном в восемнадцатом столетии, о том, что, используя лучший хронометр, можно точнее измерять долготу, так что "Ученым пришлось признать, что они ошибались в течение долгого времени, и им пришлось дать Джону Харрисону заслуженную премию".

Так не пора ли вам, посредственностям, некомпетентным бюрократам, признать agile методы? Деннинг поясняет:

"Нечто подобное должно случиться с Agile".

Теперь появилось много людей с идеями, отвергаемыми экспертами. Иногда ошибаются эксперты, но чаще всего они правы в отрицании предлагаемых идей. Если я начну утверждать, что Земля плоская, эксперты с пренебрежением отнесутся к моим доводам и я не получу (какой скандал!) мою "заслуженную премию". Нечто подобное уже случалось. Почему же следует считать, что эксперты ошибаются в случае с agile? Объяснений нет.

Ссылки на происки экспертов являются еще одним риторическим приемом. Многие чувствуют себя комфортнее, если создан образ врага и, в частности, если утверждается, что против их идей выступают "власть имущие". В случае с agile "враг" довольно доброжелателен. Мир программной инженерии сочувствовал agile идеям, предоставив возможность быть услышанным на наиболее престижных форумах сообщества, включая конференции высшего ранга (OOPSLA, ICSE, ESEC и другие). Важная книга [Boehm 2004], которая эмпирически оценивает agile методы, была опубликована вскоре после того, как agile идеи стали широко пропагандироваться. Ее автор, являющийся одной из почитаемых фигур в традиционной программной инженерии, обеспечил открытый и количественно измеряемый подход. "Власть имущие" были исключительно доброжелательны.

Помогут ли вам, если, следуя за эмпирическим подходом Боема и Тернера, вы захотите выполнить объективный, эмпирический анализ того, как agile методы работают в вашей организации? Скорее всего, это будет признано неуместным. Если вы применили agile метод и нашли, что он не работает, какое заключение можно из этого вывести? Глупый вопрос. Проблема не в методе, а в вас!

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

Для поддержки приводится еще одна цитата, прошу прощения, не Эйнштейна, а только Брехта:

"Если люди утратили доверие правительства, то не проще ли не избавляться от людей, а выбрать новое правительство".

В статье Деннинга этот аргумент не подкрепляется никакими фактами, так что он может служить поддержкой любой радикальной идеи, полезной или глупой. Заметьте, как обоснование заменяется аргументами, основанными на вере: можно, не глядя на результаты бизнес-анализа фирмы. На таком уровне иррациональности непонятно, что предполагается делать. Как можно обсуждать методы управления, не анализируя результаты деятельности?

Если вы не являетесь приверженцем agile подходов, то, по определению, вы – динозавр! Технический термин – "член бюрократически управляемой группы". В то время как agile команды являются самоорганизуемыми, используют "радикальное управление", не являются последователями "практиков и теоретиков командного стиля управления". Мне на память приходят несколько человек, подходящих под последнее определение, Стив Джобс, например. Судя по достигнутому эффекту его управления (хотя, несомненно, это означает обращение к результатам бизнес-анализа фирмы), его никак нельзя признать неэффективным менеджером. Его стиль управления не всем может нравиться. Следует признать: существует большой спектр стилей, от сложной самоорганизующейся команды до команд, где управление построено по военизированному образцу. Между этими граничными стилями существует множество промежуточных вариантов. Работать может не только одна стратегия. Более того, стратегия, успешная в одном окружении, может приводить к неуспеху в других условиях. Осуждение тех, кто слепо не следует последней моде, вредно и не дает никаких преимуществ.

Остальная часть статьи, которую следует прочесть как некоторую форму вакцинации, выдержана в таком же духе.

Часто последователи идеи являются большими фанатиками, чем ее создатели. Как говорят в этих ситуациях: "быть святее папы" или "быть большим роялистом, чем сам король". Основополагающие agile тексты, таких авторов, как Бек, Ларман, Кокбурн, выдерживают высокую планку обсуждения и не прибегают к "ударам ниже пояса" при ссылках на другие подходы.

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

2.2.4 Катастрофизм

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

Началом становления программной инженерии можно считать 1968 год, когда стали говорить о "кризисе создания ПО". В течение ряда лет стало привычкой начинать любую статью с жалоб на ужасную ситуацию в этой области. Неявно предполагалось, что тот небольшой вклад вашей статьи – методологическая идея, новый язык программирования, инструментальное средство – поможет в преодолении кризиса.

Через некоторое время этот скорбный стиль (не все в порядке в королевстве программной инженерии) вышел из моды. Действительно, глупо утверждать, что все неладно с разработкой ПО в мире, где программно поддерживаются каждое устройство, каждый доступный нам сервис.

Апокалипсическая мода вернулась на новом витке с agile литературой, которая любит цитировать так называемые "хаос"-отчеты, публикуемые корпорацией Standish Group, специализирующейся на анализе неудачных программных проектов. В этих отчетах показано, что большое число проектов либо не достигают намеченных целей, либо выходят за рамки поставленных ограничений (в известном треугольнике "время – стоимость – качество" достижимы только два свойства из трех). Было модно цитировать эти отчеты (я сам включил такую цитату в одну из своих статей в 2003 году). Но, начиная с 2006 года [Glass 2006], [Eveleens 2010] методология этих отчетов и сами результаты были полностью развенчаны. Было показано, что результаты не согласованы, не подтверждаются другими исследованиями, основываются на частных данных, к которым не допускаются независимые исследователи. И все же они продолжают постоянно цитироваться для обоснования поддержки agile процессов, включаются в современные книги от создателей Scrum [Schwaber 2012], кто добавляют:

Вы были больны, служа программной инженерии в течение 40 лет – не бесцельно, но хаотически. Мы хотим восстановить партнерство.

Добавить нечего! Программная инженерия трудна сама по себе и сталкивается с множеством трудностей, очевидных для каждого в индустрии (и для пользователей тоже), так что нет необходимости придумывать воображаемые ужасы.

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

2.2.5 Все или ничего

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

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

Трюк блестящий, но не следует на него попадаться. Индустрия, как отмечалось, игнорирует такой абсолютизм. Каждая группа делает свой собственный выбор, принимая некоторые приемы, отказываясь от других. Программные проекты различны, а их разработка трудна. Здесь нет единого рецепта, пригодного на все случаи жизни.

2.2.6 Подстелите соломку

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

Типичный пример появляется в основополагающей книге по LSD (Lean Software Development), написанной Марией и Томом Поппендик [Poppendieck 2003]. После семи глав, восхваляющих изменения, которые следует сделать в практике разработки ПО, каждое из которых зиждется на одном из семи принципов, в заключительной главе, названной с юмором "Инструкции и гарантии", утверждается:

Соблюдайте баланс в применении Lean принципов:

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

Также обстоит дело и с оставшимися четырьмя принципами, о применении каждого говорится, что принцип "не означает", что его следует применять во всех ситуациях. Эти комментарии показывают рекомендуемые ограничения, но они бесполезны для практиков, так как глава содержит только восемь страниц и почти ничего не говорит практикам, ожидающим совета: когда принципы не применимы или применимы частично и как они должны ослабляться в подобных случаях.

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

(Да, предупреждали. Но я предпочел бы, чтобы мне сказали, в чем же этот баланс состоит.)

Все это напоминает общую ситуацию, когда подстилается соломка: "А1 не означает А2", где А1 почти ничем не отличается от А2. Например, А1 – "решать настолько поздно, насколько это возможно", а А2 – "отсрочить принятие решения". Если здесь есть разница, то ее трудно уловить.

Способ "подстилки соломы" не является спецификой цитируемой книги или метода Lean. Подобные примеры встречались во многих других источниках, например такая цитата:

"Хотя все решает сама команда, она не является не-управляемой".

Когда мы обнаруживаем пределы догматического применения agile методов, нам самим не следует попадаться в такую же ловушку. Эта книга пытается объяснить, когда и как agile предписания должны заменяться или комбинироваться с другими методами. Другими словами, мы пытаемся совместить "баланс интересов". Примером является agile правило, требующее наличия работающей системы на каждом шаге, и приемы программной инженерии, дающие преимущества от построения инфраструктуры даже без непосредственно видимых результатов для пользователя. Обе точки зрения могут иметь ценность в зависимости от обстоятельств. Результатом обсуждения является конкретная политика "дуальной разработки", комбинирующая подходы в зависимости от специфики ситуации.

2.2.7 Неверифицируемые заявления

Документ одного из создателей Scrum озаглавлен "Искусство сделать двойную работу за половинное время". Если моя арифметика корректна, это означает рост производительности в четыре раза. Кто не ухватился бы за это? В одной из презентаций от создателей agile метода я слышал более радикальные заявления – улучшение на порядок и более. Из уже упомянутой книги Поппендиков, которая вскоре будет подробно разбираться, следует, что даже применение только одной из их рекомендаций позволяет уменьшить затраты в десять раз.

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

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

• Для работы в реальных условиях необходимы реальные проекты. Необходимо выполнять точные измерения, но не все компании готовы тратить усилия на это и немногие готовы предоставить результаты, даже если они получены.
• Иногда успех одного метода связан с тем, что первый проект потерпел неудачу. Этот случай часто является аргументом в пользу нового метода: "мы достигли успеха, где ранее потерпели неудачу". Возможно, это соответствует истине, но сравнение неоднозначно: во второй раз работая над проектом, команда извлекла уроки из ошибок, сделанных в первом проекте, даже если он оказался неуспешным. Проекты можно сравнивать только при условии, что они выполняются параллельно, а не последовательно.
• Немногие компании могут найти два проекта, схожих по задачам и уровню сложности, что позволит провести оценивание методов разработки.
• Даже если предположить, что такая возможность существует, мы будем иметь дело с частным случаем, не позволяющим делать обобщения, так как результаты зависят от специфики задач и от индивидуальных особенностей команд. Эксперименты должны повторяться для различных проектов и в идеале для нескольких компаний.

Эмпирические индустриальные результаты, вызывающие доверие, пока еще не появились. Большей частью вся "мудрость" приходит от экспериментов с командами, составленными из студентов. Но в этом случае есть очевидные ограничения. Еще один интересный эксперимент, связанный с оценкой agile методов, проведен фирмой IBM в сотрудничестве со Scrum Alliance – организацией, пропагандирующей Scrum. Пропаганда – дело уважаемое, но не лучшая гарантия объективности. В их отчете говорится много хорошего о Scrum. Вызывает ли это у вас удивление? Кажется, что благодаря энергии agile удалось убедить столь степенную компанию, как IBM, отбросить свою методологическую осмотрительность. Не поступайте так.

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

Эффект Хавторна – феномен, связанный с фирмой Western Electric и наблюдаемый в 1930 году после депрессии, когда рабочие стали работать лучше после того, как им сказали, что они участвуют в эксперименте с новым подходом, даже если они в нем и не принимали участие.

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

Помните: прежде чем пойти к руководству и сказать, что вы переключаетесь на agile методы, позволяющие улучшить производительность в четыре раза или более, следует тщательно подумать. Ведь руководство может вам поверить.

Послесловие: Вы были больны, служа программной инженерии!

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

Холодным утром в феврале 2012 года мистер S проснулся рано. Разбудил его, как обычно, будильник в iPhone, играющий любимую Вагнеровскую мелодию из "Сумерков Богов", загруженную им недавно из свободно доступного MP3 сайта. Яичница на завтрак была превосходна, приготовленная тем специфическим способом, который он запрограммировал для микроволновки, установив точную комбинацию температуры и времени.

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

Что же касается его самого, то он собирался воспользоваться общественным транспортом. Посмотрев расписание в интернете, он увидел, что до автобуса остается несколько минут, времени было достаточно для проверки электронной почты. Он обнаружил в PDF вложении уведомление об оплате своей последней консультации в качестве agile консультанта. Мистер S был высоко востребованным специалистом. О деталях расчета он не беспокоился, поскольку знал, что его расчетная система получит всю необходимую информацию.

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

Активируя "заснувший" компьютер, мистер S почему-то вспомнил: ему нравились подобные мелочи, что Windows – операционная система компьютера содержит более 50 миллионов строк кода. Мистер S подумал о том, что теперь система как-то делает то, что он ожидал. Последнее время он подумывал о переходе на Mac, как это сделали многие его друзья, но преимущества были неясны, ему нравился старый приятель Word – привычный текстовый редактор, на котором он вчера набирал свой последний текст, прославляющий agile, предварительно названный "Программный продукт за 30 дней".

Мистер S открыл документ в том месте, где он окончил работу над ним вчерашним вечером. В заголовке было указано его полное имя – "Shwaber" или, быть может, "Sutherland", хотя возможно и "Scrum" или "Sprint", – некоторые детали этой истории утеряны. Как и подобает хорошему автору, ему предстояло поставить финальную точку – написать введение. До сих пор ни к нему, ни к его соавтору вдохновение не приходило, всегда так трудно написать удачную первую фразу. В течение всего прошлого месяца, проводя много долгих обсуждений в Скайпе, независимо от того, где каждый из них находился, они предлагали и отвергали многочисленные варианты, часто одновременно редактируя их совместный Google Docs черновик документа. Но неожиданно пришло вдохновение, и он понял, что следует сказать и что, несомненно, привлечет внимание читателей.

Фраза выстроилась в его голове и, как выстрел, отразилась на экране компьютера:

Вы были больны, служа программной инженерии в течение 40 лет – не бесцельно, но хаотически.