Существует грандиозный миф, связанный с требованиями, – считается, что если требования записаны, то пользователь получает в точности то, что он хочет. Это неправда. Лучшее, что ожидает пользователя, – он получит то, что написано. Это может совпадать с тем, что он хочет, а может и не совпадать. Письменный текст создает ошибочное представление – он выглядит более точным, чем является на самом деле. Вот пример: недавно я должен был провести трехдневный семинар. Мы с ассистентом уже договорились об этом. Так что я послал ей мэйл: "Пожалуйста, забронируйте Хьятт в Денвере" и напомнил ей о датах. На следующий день я получил от нее мэйл: "Отель уже забронирован". Я ответил ей: "Спасибо" и вернулся к повседневным делам.
Примерно через неделю она прислала мне очередное письмо, где спрашивала: "Отель забронирован в те дни, что вы хотели. Что же мне делать? Попытаться забронировать места в другом отеле? На следующую неделю? В другом городе?" Она и я ошибочно воспринимали слово " забронировано". Когда она писала мне, то имела в виду, что комнаты, которые мы обычно снимаем в Хьятте, заняты. Когда я читал текст: "Отель уже забронирован", я полагал, что она выполнила мое поручение. Ни один из нас не совершал ошибок в нашем обмене сообщениями. Скорее, это пример того, как просто быть превратно понятым, особенно при письменном способе общения. Если бы мы говорили по телефону, а не посылали сообщения по электронной почте, я вряд ли поблагодарил бы ее при сообщении, что "отель уже забронирован". Ее бы озадачил счастливый тон моего голоса в ответ на ее грустную новость. Мы бы обнаружили ошибку ошибочной коммуникации немедленно.
Помимо этой причины, есть и другие доводы в пользу устных обсуждений перед документами.
Этот пример взят из одной из важных для agile книг "Достижение успехов с Agile", написанной Майклом Коном [Cohn 2010], широко используемой и цитируемой в agile мире. Автор является опытным консультантом и одной из центральных фигур agile движения. Текст, приводимый ниже, представляет выдержку из главы, посвященной преимуществам вербальных контактов над письменными документами.
Я намереваюсь сказать вам, что думаю об этой истории и ее обобщении. Но прежде задумайтесь на минутку и попытайтесь сформулировать свою точку зрения. Это должно сделать обсуждение более интересным.
Начнем с двух наблюдений: одно следует непосредственно, другое менее очевидно.
Рассмотрим неудачную аргументацию. Первая проблема состоит в том, что она следует той форме логики, которая, к сожалению, довольно часто применяется в компьютерной литературе (особенно, но не исключительно в agile книгах) – доказательство, построенное на примере. Пример не является доказательством, как уже отмечалось во введении. Пример может лишь опровергнуть обобщение. Он даже не может служить аргументом. Он может способствовать аргументации, но лишь в том случае, когда есть много подобных примеров, свидетельствующих о возможности обобщения. В данном случае на каждую историю об ошибочном толковании "бронирования в отеле" при обмене письмами, которого можно было бы избежать при устном общении, можно привести другую историю, свидетельствующую об обратном эффекте. Я мог бы рассказать вам историю о том времени, когда хотел предложить своей будущей жене выйти погулять со мной, но по телефону сказал… Я мог бы, но (расслабьтесь) не буду этого делать, во-первых, потому, что моя любовная жизнь вас не касается, во-вторых, вы сами уже догадались, о чем идет речь.
Расскажу другую историю, основанную на факте и связанную на этот раз с разработкой ПО. В проекте возникла ошибка, которую мы не могли понять и исправить в течение длительного времени, поскольку разработчик важного фрагмента программы в это время отсутствовал. Программа в некоторых ситуациях зацикливалась. Методу, созданному отсутствующим разработчиком, передавалась некоторая структура данных. "Жучок" состоял в том, что в методе предполагалась ациклическая структура, в реальности она временами была циклической, и тогда возникал бесконечный цикл. Разработчик обнаружил несоответствие и сказал, что "каждый знает", что ацикличность структуры необходима. Возможно, каждый должен знать, но кто-то забыл. Хорошо еще, что хоть кто-то помнил! Даже без возможности написать непосредственно в коде предусловие к методу (require structure.is aciclic), как это может быть сделано в некоторых языках программирования, было бы лучше просто записать соответствующее требование, что позволило бы избежать непроизводительных затрат времени.
Я нахожу, что эта история в большей степени относится к обсуждаемой проблеме программной инженерии, чем анекдотичная история с бронированием отеля. Но кто-то может с этим не согласиться. И ни один из нас ничего не может доказать. Адвокаты вербальных контактов и сторонники письменных спецификаций могут бесконечно приводить друг другу одну историю за другой, не убеждая ни в чем другую сторону. Пример есть просто пример.
История с Майклом Коном доказывает лишь то, что ему следует найти лучшего ассистента. В противоположность тому, что он пишет: "Ни один из нас не совершал ошибок в нашем обмене сообщениями", ассистент, конечно же, совершил ошибку. Он обязан был уже в первом письме при неудаче бронирования, спросить о том, что ему делать в этой ситуации. Такие ошибки, однако, встречаются, они могут возникать как при устном, так и при письменном общении.
В случае программных проектов, которые находятся в центре нашего рассмотрения, много доводов в пользу записи, по меньшей мере, части требований.
Дискуссия о вербальных и письменных контактах имеет смысл не только в рамках программных проектов. Если бы вербальные контакты поистине превосходили письменные соглашения, то инженерия любого вида могла бы отбросить такие старомодные приемы, как планирование и проектирование спецификаций, заменив их частыми контактами между инженерами и другими сопричастниками. Так строили пирамиды и кафедральные соборы наши предки. Но современная инженерия точна по той причине, что строительство мостов, зданий, авианосцев, электронных схем и, да-да, программных проектов не сводится к приятным беседам и пожатию рук, а настаивает на задании спецификаций в письменном виде с подписями всех сторон, участвовавших в обсуждении.
Спасибо, что в школьные годы мы тратили время на обучение чтению и письму. А могли бы вместо этого бродить по парку в веселых беседах, совершенствуя вербальные навыки
Оставив в стороне метод (доказательство, основанное на примере) и его гиперболизацию, заметим, что в рассуждениях Кона содержатся три важных урока, хотя они и не рекламируются автором.
Гениальной находкой является наблюдение: "Письменный текст создает ошибочное представление – он выглядит более точным, чем является на самом деле". Авторитетность письменного слова может быть опасной. Человеческий язык, письменный или устный, богат двусмысленностями. Хорошо известным примером является требование: "Система должна давать ответ в реальное время", которое по сути ничего не определяет. Ответ, приходящий через одну десятую секунды, обеспечивает "реальное время" для банковского терминала, но совсем неудовлетворителен для сетевого роутера. Однако альтернативой не является разговорный язык, который еще менее точен.
Альтернативой, когда точность – цель, является математика. Требование: answer.time – query.time < 0.1 не выглядит более точно, чем оно есть. Оно выглядит точно и является точным. Но это не совсем то, что подразумевал Кон. Его волновала проблема письменных требований, но он слишком много значения придавал тому, что они письменные. Сама по себе проблема правильная, из нее следует первый существенный урок: Не следует считать, что если требования сформулированы в письменной форме, то это означает, что они четко определены. Из записи требований еще не следуют ни их точность, ни их корректность.
Полезное само по себе, это наблюдение описывает проблему, но не дает ее решения. Решение, если оно существует, конечно же, не состоит в переходе на устную речь.
Второй урок состоит в том, что коммуникация трудна. Это верно. Этот факт известен всем еще до чтения текста Кона и данного обсуждения. Но коммуникация необходима при разработке ПО, и это тот вызов, который требует ответа. В любом большом и амбициозном проекте (как и во многих малых) проблема коммуникации так же важна, как и технические проблемы. Проект легко можно погубить, если руководство не решит проблемы общения своевременно и нужным образом. Эти проблемы особо критичны для географически распределенных проектов, где на обычные проблемы общения накладываются расстояния, разница во времени, языковые проблемы, различия в культурах. (Веселой иллюстрацией к сказанному является запись в YouTube инженера из Индии, где он объясняет разницу смысла "да" и "нет" и кивками головы в Индии [Dhawan 2008].)
Что можно сказать об устном общении? Урок здесь состоит в том, что
Вербальная коммуникация, однако, является дополнением к письменным документам, а не их заменой.
Рассмотренный выше пример является представителем того, что часто можно найти в литературе по agile. Его анализ дает руководство к тому, как использовать такую литературу.
Нетрудно заметить, что наше заключение тоже строится на основе одного примера, но обобщение носит довольно безопасный характер, поскольку предпочтение вербальных и других неформальных форм коммуникации обще характерно для agile и не является спецификой цитируемой книги. Элистер Кокбурн [Cockburn 2005], например, пишет, что "печатная документация, основанная на бумаге, является одной из наиболее дорогих, затратных по времени и наименее эффективных форм коммуникации (не имеет значения, что традиционно это наиболее часто запрашиваемая форма)". Заметим, что если такие документы часто запрашиваются, то их можно правильно организовать и сделать легкодоступными для поиска и архивирования.
В качестве примера замены Кокбурн предлагает, чтобы команда выполняла "видеозапись в тот момент, когда один из проектировщиков поясняет раздел проекта", далее он отмечает, что "бумажные салфетки, случалось, были моими любимыми средствами документации. Их можно размещать на стенах или сканировать". Конечно, это так, но когда приходит время найти, как и почему было установлено то или иное ключевое свойство системы, поиск в печатных текстах выигрывает в сравнении с просеиванием видеозаписей и груды отсканированных бумажных салфеток.
Agile авторы являются миссионерами, обращающими читателя в свою веру. Их цель приводит к тому, что сложные вещи упрощаются, делаются заключения, которые иногда гарантируются, иногда нет.
Благодаря прогрессу книги и статьи смогут отвечать более высоким интеллектуальным стандартам. Но это в будущем, а пока нужно быть начеку и готовым делать собственные заключения даже тогда, когда автор не призывает вас к этому.
Проведенный анализ неточностей в текстах является хорошей подготовкой для применения его к другим приемам, используемым agile авторами для пропаганды своих подходов. В качестве тренинга в оставшейся части нашего путешествия и для безопасности вашего собственного похода в agile литературу приведу список Топ 7 наиболее возмутительных риторических механизмов, хотя и не являющихся agile уникальными, но широко распространенными в их текстах.
Сомнительные риторические приемы не отрицают значимость предлагаемых идей, но они должны предупреждать читателя о необходимости осторожности. Нам следует быть готовыми к восприятию идей, но не ложиться под нашего методологического гида. Первым шагом является предупреждение об этих семи ловушках, к описанию которых мы переходим.
Книги по agile свои выводы делают большей частью на основании примеров. Типичным является пример, приведенный в начале этой главы.
Примеры хороши для книг и при обучении. Они могут иметь и обратный эффект: если пример служит основой обобщения, то читатель, чей собственный опыт противоречит опыту автора, не согласится с обобщением. Мы увидим подобный пример в одной из последующих глав. В этом примере автор для поддержки своей точки зрения на разработку ПО ссылается на опыт выдающегося велосипедиста Ланса Армстронга.
Еще один пример того же автора – душераздирающая история о водителе автобуса в Диснейленде, который, заметив плачущую маленькую девочку, сумел сделать так, что актер, играющий Микки Мауса, приветствовал девочку. Эта история должна была иллюстрировать важность качества работы. Для читателя, кто провел целый день в Диснейленде с детьми, стоя в очередях, ассоциация с качеством не покажется убедительной. Скорее, возникнет ассоциация с сайтом, имеющим привлекательный интерфейс и долгое время отклика на запросы. Апелляция к сознанию читателя – хорошее дело, но следует опасаться, что ассоциации могут возникать разные.
Общая проблема с примерами такая же, как и с принципом, согласно которому тесты задают спецификацию. И в том и в другом случае, имея пример, нет никакой уверенности, насколько справедливо экстраполирование примера на общий случай.
Существуют эффективные, хотя и недостойные способы критики чужой идеи. В agile литературе применяют два варианта – позитивный и негативный.
Позитивный вариант состоит в том, чтобы для вашей идеи выбрать подходящее имя, ассоциирующееся с приятными чувствами. Тогда идеи, противоречащие вашей, автоматически попадут в разряд неприятных. Это великолепный маркетинговый ход, которым можно только восхищаться. Как отмечалось во введении, выбор слова agile был такой блестящей находкой. Всякая не agile идея является негибкой, окостенелой, бюрократической.
Негативный вариант состоит в том, чтобы в сознании читателя связать чужую идею с другой идеей, всеми отвергаемой. Любимой для agile "нехорошей" идеей является процесс разработки ПО, называемый презрительно "водопадом". Конечно же, никто из тех, кто не принимает идеи agile, не собирается возвращаться к методам разработки ПО семидесятых годов, когда появилась модель "водопада". Фактически никто и не применял ее в чистом виде, и нет никого, кто рекомендовал бы ее применение. Все же, как мы увидим в следующей главе, ведущие agile авторы постоянно называют "водопадом" любой не-agile подход. Это дешевый трюк, не попадайтесь на него.
Следующее множество сомнительных аргументов использует преимущества положительных эмоций, связанных со словом "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 подходов, то вы рискуете получить "удары" от "истинных последователей". К счастью, вы предупреждены. В этой книге мы бесстрашно (аплодисменты храбрецам, пожалуйста) попытаемся отделить лучшее от не столь хорошего и от откровенно плохого.
Когда вы защищаете новый подход, то естественно высвечивать недостатки существующего. Иначе, если бы у существующих методов не было недостатков, и изобретать новые не имело бы смысла. Естественно, состояние программной инженерии вполне может быть подвергнуто критике. Однако, чтобы критика заслуживала доверия, она должна быть корректной и справедливой.
Началом становления программной инженерии можно считать 1968 год, когда стали говорить о "кризисе создания ПО". В течение ряда лет стало привычкой начинать любую статью с жалоб на ужасную ситуацию в этой области. Неявно предполагалось, что тот небольшой вклад вашей статьи – методологическая идея, новый язык программирования, инструментальное средство – поможет в преодолении кризиса.
Через некоторое время этот скорбный стиль (не все в порядке в королевстве программной инженерии) вышел из моды. Действительно, глупо утверждать, что все неладно с разработкой ПО в мире, где программно поддерживаются каждое устройство, каждый доступный нам сервис.
Апокалипсическая мода вернулась на новом витке с agile литературой, которая любит цитировать так называемые "хаос"-отчеты, публикуемые корпорацией Standish Group, специализирующейся на анализе неудачных программных проектов. В этих отчетах показано, что большое число проектов либо не достигают намеченных целей, либо выходят за рамки поставленных ограничений (в известном треугольнике "время – стоимость – качество" достижимы только два свойства из трех). Было модно цитировать эти отчеты (я сам включил такую цитату в одну из своих статей в 2003 году). Но, начиная с 2006 года [Glass 2006], [Eveleens 2010] методология этих отчетов и сами результаты были полностью развенчаны. Было показано, что результаты не согласованы, не подтверждаются другими исследованиями, основываются на частных данных, к которым не допускаются независимые исследователи. И все же они продолжают постоянно цитироваться для обоснования поддержки agile процессов, включаются в современные книги от создателей Scrum [Schwaber 2012], кто добавляют:
Вы были больны, служа программной инженерии в течение 40 лет – не бесцельно, но хаотически. Мы хотим восстановить партнерство.
Добавить нечего! Программная инженерия трудна сама по себе и сталкивается с множеством трудностей, очевидных для каждого в индустрии (и для пользователей тоже), так что нет необходимости придумывать воображаемые ужасы.
Истории в отчетах фирмы Standish также напоминают нам об угрозах гиперболизации любого вида, как об ужасных ошибках, сделанных другими, так и о наших триумфах. Программная инженерия нуждается в эмпирических результатах, внушающих доверие.
В то время как некоторые agile тексты и методы предлагают соразмерные подходы, другие, как отмечалось во введении, настаивают на применении их метода с использованием всех предлагаемых практических приемов.
Нельзя отрицать право методологов специфицировать немногие бесспорные принципы, определяющие их методы, но число таких абсолютных требований должно быть невелико. В противном случае принципы начинают напоминать маркетинговые приманки, как это можно видеть в презентациях, демонстрирующих успешные и провальные проекты. Успешные проекты демонстрируют мощь метода. Провальные проекты потерпели неудачу только по той причине, что не следовали методу.
Трюк блестящий, но не следует на него попадаться. Индустрия, как отмечалось, игнорирует такой абсолютизм. Каждая группа делает свой собственный выбор, принимая некоторые приемы, отказываясь от других. Программные проекты различны, а их разработка трудна. Здесь нет единого рецепта, пригодного на все случаи жизни.
Не все agile авторы хотят, чтобы их воспринимали как экстремистов, но даже те, кто пытается избежать этого образа, зачастую оставляют читателя в темноте, не говоря о том, когда следует применять их приемы, а когда не следует этого делать. Типичная схема состоит в пропаганде радикальных идей, затем краткого упоминания, что они не всегда применимы, без указания каких-либо критериев, позволяющих принять решение. Это говорит о рассудительности автора, но мало помогает практику, который должен принять решение.
Типичный пример появляется в основополагающей книге по LSD (Lean Software Development), написанной Марией и Томом Поппендик [Poppendieck 2003]. После семи глав, восхваляющих изменения, которые следует сделать в практике разработки ПО, каждое из которых зиждется на одном из семи принципов, в заключительной главе, названной с юмором "Инструкции и гарантии", утверждается:
Соблюдайте баланс в применении Lean принципов:
исключение непроизводительных затрат (первый принцип) не означает полного отказа от документации; усиление внимания к обучению (второй принцип) не означает, что все изменения нужно хранить в памяти; принятие решения настолько поздно, насколько это возможно (третий принцип), не означает откладывания решения.
Также обстоит дело и с оставшимися четырьмя принципами, о применении каждого говорится, что принцип "не означает", что его следует применять во всех ситуациях. Эти комментарии показывают рекомендуемые ограничения, но они бесполезны для практиков, так как глава содержит только восемь страниц и почти ничего не говорит практикам, ожидающим совета: когда принципы не применимы или применимы частично и как они должны ослабляться в подобных случаях.
Разработчики и менеджеры не нуждаются в пустых наблюдениях. Нужны критерии, задающие исключения, когда принципы могут не соблюдаться. Исключения и критерии должны формулироваться одновременно с заданием каждого принципа, а не в отговорках, разрушающих доверие к самим принципам. Не будучи инструкциями и гарантиями, такие отговорки напоминают предупреждения, присоединяемые ко многим товарам. Их смысл не в том, чтобы помочь пользователям метода, они помогают только авторам, обеспечивая им защиту, своего рода "соломенную подстилку". Вы применяли принцип X, и все у вас закончилось неудачей? Сожалеем, что слышим это. Но ведь вас предупреждали, что нужно соблюдать баланс в применении принципов.
(Да, предупреждали. Но я предпочел бы, чтобы мне сказали, в чем же этот баланс состоит.)
Все это напоминает общую ситуацию, когда подстилается соломка: "А1 не означает А2", где А1 почти ничем не отличается от А2. Например, А1 – "решать настолько поздно, насколько это возможно", а А2 – "отсрочить принятие решения". Если здесь есть разница, то ее трудно уловить.
Способ "подстилки соломы" не является спецификой цитируемой книги или метода Lean. Подобные примеры встречались во многих других источниках, например такая цитата:
"Хотя все решает сама команда, она не является не-управляемой".
Когда мы обнаруживаем пределы догматического применения agile методов, нам самим не следует попадаться в такую же ловушку. Эта книга пытается объяснить, когда и как agile предписания должны заменяться или комбинироваться с другими методами. Другими словами, мы пытаемся совместить "баланс интересов". Примером является agile правило, требующее наличия работающей системы на каждом шаге, и приемы программной инженерии, дающие преимущества от построения инфраструктуры даже без непосредственно видимых результатов для пользователя. Обе точки зрения могут иметь ценность в зависимости от обстоятельств. Результатом обсуждения является конкретная политика "дуальной разработки", комбинирующая подходы в зависимости от специфики ситуации.
Документ одного из создателей 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 лет – не бесцельно, но хаотически.
Существует грандиозный миф, связанный с требованиями, – считается, что если требования записаны, то пользователь получает в точности то, что он хочет. Это неправда. Лучшее, что ожидает пользователя, – он получит то, что написано. Это может совпадать с тем, что он хочет, а может и не совпадать. Письменный текст создает ошибочное представление – он выглядит более точным, чем является на самом деле. Вот пример: недавно я должен был провести трехдневный семинар. Мы с ассистентом уже договорились об этом. Так что я послал ей мэйл: "Пожалуйста, забронируйте Хьятт в Денвере" и напомнил ей о датах. На следующий день я получил от нее мэйл: "Отель уже забронирован". Я ответил ей: "Спасибо" и вернулся к повседневным делам.
Примерно через неделю она прислала мне очередное письмо, где спрашивала: "Отель забронирован в те дни, что вы хотели. Что же мне делать? Попытаться забронировать места в другом отеле? На следующую неделю? В другом городе?" Она и я ошибочно воспринимали слово " забронировано". Когда она писала мне, то имела в виду, что комнаты, которые мы обычно снимаем в Хьятте, заняты. Когда я читал текст: "Отель уже забронирован", я полагал, что она выполнила мое поручение. Ни один из нас не совершал ошибок в нашем обмене сообщениями. Скорее, это пример того, как просто быть превратно понятым, особенно при письменном способе общения. Если бы мы говорили по телефону, а не посылали сообщения по электронной почте, я вряд ли поблагодарил бы ее при сообщении, что "отель уже забронирован". Ее бы озадачил счастливый тон моего голоса в ответ на ее грустную новость. Мы бы обнаружили ошибку ошибочной коммуникации немедленно.
Помимо этой причины, есть и другие доводы в пользу устных обсуждений перед документами.
Этот пример взят из одной из важных для agile книг "Достижение успехов с Agile", написанной Майклом Коном [Cohn 2010], широко используемой и цитируемой в agile мире. Автор является опытным консультантом и одной из центральных фигур agile движения. Текст, приводимый ниже, представляет выдержку из главы, посвященной преимуществам вербальных контактов над письменными документами.
Я намереваюсь сказать вам, что думаю об этой истории и ее обобщении. Но прежде задумайтесь на минутку и попытайтесь сформулировать свою точку зрения. Это должно сделать обсуждение более интересным.
Начнем с двух наблюдений: одно следует непосредственно, другое менее очевидно.
Рассмотрим неудачную аргументацию. Первая проблема состоит в том, что она следует той форме логики, которая, к сожалению, довольно часто применяется в компьютерной литературе (особенно, но не исключительно в agile книгах) – доказательство, построенное на примере. Пример не является доказательством, как уже отмечалось во введении. Пример может лишь опровергнуть обобщение. Он даже не может служить аргументом. Он может способствовать аргументации, но лишь в том случае, когда есть много подобных примеров, свидетельствующих о возможности обобщения. В данном случае на каждую историю об ошибочном толковании "бронирования в отеле" при обмене письмами, которого можно было бы избежать при устном общении, можно привести другую историю, свидетельствующую об обратном эффекте. Я мог бы рассказать вам историю о том времени, когда хотел предложить своей будущей жене выйти погулять со мной, но по телефону сказал… Я мог бы, но (расслабьтесь) не буду этого делать, во-первых, потому, что моя любовная жизнь вас не касается, во-вторых, вы сами уже догадались, о чем идет речь.
Расскажу другую историю, основанную на факте и связанную на этот раз с разработкой ПО. В проекте возникла ошибка, которую мы не могли понять и исправить в течение длительного времени, поскольку разработчик важного фрагмента программы в это время отсутствовал. Программа в некоторых ситуациях зацикливалась. Методу, созданному отсутствующим разработчиком, передавалась некоторая структура данных. "Жучок" состоял в том, что в методе предполагалась ациклическая структура, в реальности она временами была циклической, и тогда возникал бесконечный цикл. Разработчик обнаружил несоответствие и сказал, что "каждый знает", что ацикличность структуры необходима. Возможно, каждый должен знать, но кто-то забыл. Хорошо еще, что хоть кто-то помнил! Даже без возможности написать непосредственно в коде предусловие к методу (require structure.is aciclic), как это может быть сделано в некоторых языках программирования, было бы лучше просто записать соответствующее требование, что позволило бы избежать непроизводительных затрат времени.
Я нахожу, что эта история в большей степени относится к обсуждаемой проблеме программной инженерии, чем анекдотичная история с бронированием отеля. Но кто-то может с этим не согласиться. И ни один из нас ничего не может доказать. Адвокаты вербальных контактов и сторонники письменных спецификаций могут бесконечно приводить друг другу одну историю за другой, не убеждая ни в чем другую сторону. Пример есть просто пример.
История с Майклом Коном доказывает лишь то, что ему следует найти лучшего ассистента. В противоположность тому, что он пишет: "Ни один из нас не совершал ошибок в нашем обмене сообщениями", ассистент, конечно же, совершил ошибку. Он обязан был уже в первом письме при неудаче бронирования, спросить о том, что ему делать в этой ситуации. Такие ошибки, однако, встречаются, они могут возникать как при устном, так и при письменном общении.
В случае программных проектов, которые находятся в центре нашего рассмотрения, много доводов в пользу записи, по меньшей мере, части требований.
Дискуссия о вербальных и письменных контактах имеет смысл не только в рамках программных проектов. Если бы вербальные контакты поистине превосходили письменные соглашения, то инженерия любого вида могла бы отбросить такие старомодные приемы, как планирование и проектирование спецификаций, заменив их частыми контактами между инженерами и другими сопричастниками. Так строили пирамиды и кафедральные соборы наши предки. Но современная инженерия точна по той причине, что строительство мостов, зданий, авианосцев, электронных схем и, да-да, программных проектов не сводится к приятным беседам и пожатию рук, а настаивает на задании спецификаций в письменном виде с подписями всех сторон, участвовавших в обсуждении.
Спасибо, что в школьные годы мы тратили время на обучение чтению и письму. А могли бы вместо этого бродить по парку в веселых беседах, совершенствуя вербальные навыки
Оставив в стороне метод (доказательство, основанное на примере) и его гиперболизацию, заметим, что в рассуждениях Кона содержатся три важных урока, хотя они и не рекламируются автором.
Гениальной находкой является наблюдение: "Письменный текст создает ошибочное представление – он выглядит более точным, чем является на самом деле". Авторитетность письменного слова может быть опасной. Человеческий язык, письменный или устный, богат двусмысленностями. Хорошо известным примером является требование: "Система должна давать ответ в реальное время", которое по сути ничего не определяет. Ответ, приходящий через одну десятую секунды, обеспечивает "реальное время" для банковского терминала, но совсем неудовлетворителен для сетевого роутера. Однако альтернативой не является разговорный язык, который еще менее точен.
Альтернативой, когда точность – цель, является математика. Требование: answer.time – query.time < 0.1 не выглядит более точно, чем оно есть. Оно выглядит точно и является точным. Но это не совсем то, что подразумевал Кон. Его волновала проблема письменных требований, но он слишком много значения придавал тому, что они письменные. Сама по себе проблема правильная, из нее следует первый существенный урок: Не следует считать, что если требования сформулированы в письменной форме, то это означает, что они четко определены. Из записи требований еще не следуют ни их точность, ни их корректность.
Полезное само по себе, это наблюдение описывает проблему, но не дает ее решения. Решение, если оно существует, конечно же, не состоит в переходе на устную речь.
Второй урок состоит в том, что коммуникация трудна. Это верно. Этот факт известен всем еще до чтения текста Кона и данного обсуждения. Но коммуникация необходима при разработке ПО, и это тот вызов, который требует ответа. В любом большом и амбициозном проекте (как и во многих малых) проблема коммуникации так же важна, как и технические проблемы. Проект легко можно погубить, если руководство не решит проблемы общения своевременно и нужным образом. Эти проблемы особо критичны для географически распределенных проектов, где на обычные проблемы общения накладываются расстояния, разница во времени, языковые проблемы, различия в культурах. (Веселой иллюстрацией к сказанному является запись в YouTube инженера из Индии, где он объясняет разницу смысла "да" и "нет" и кивками головы в Индии [Dhawan 2008].)
Что можно сказать об устном общении? Урок здесь состоит в том, что
Вербальная коммуникация, однако, является дополнением к письменным документам, а не их заменой.
Рассмотренный выше пример является представителем того, что часто можно найти в литературе по agile. Его анализ дает руководство к тому, как использовать такую литературу.
Нетрудно заметить, что наше заключение тоже строится на основе одного примера, но обобщение носит довольно безопасный характер, поскольку предпочтение вербальных и других неформальных форм коммуникации обще характерно для agile и не является спецификой цитируемой книги. Элистер Кокбурн [Cockburn 2005], например, пишет, что "печатная документация, основанная на бумаге, является одной из наиболее дорогих, затратных по времени и наименее эффективных форм коммуникации (не имеет значения, что традиционно это наиболее часто запрашиваемая форма)". Заметим, что если такие документы часто запрашиваются, то их можно правильно организовать и сделать легкодоступными для поиска и архивирования.
В качестве примера замены Кокбурн предлагает, чтобы команда выполняла "видеозапись в тот момент, когда один из проектировщиков поясняет раздел проекта", далее он отмечает, что "бумажные салфетки, случалось, были моими любимыми средствами документации. Их можно размещать на стенах или сканировать". Конечно, это так, но когда приходит время найти, как и почему было установлено то или иное ключевое свойство системы, поиск в печатных текстах выигрывает в сравнении с просеиванием видеозаписей и груды отсканированных бумажных салфеток.
Agile авторы являются миссионерами, обращающими читателя в свою веру. Их цель приводит к тому, что сложные вещи упрощаются, делаются заключения, которые иногда гарантируются, иногда нет.
Благодаря прогрессу книги и статьи смогут отвечать более высоким интеллектуальным стандартам. Но это в будущем, а пока нужно быть начеку и готовым делать собственные заключения даже тогда, когда автор не призывает вас к этому.
Проведенный анализ неточностей в текстах является хорошей подготовкой для применения его к другим приемам, используемым agile авторами для пропаганды своих подходов. В качестве тренинга в оставшейся части нашего путешествия и для безопасности вашего собственного похода в agile литературу приведу список Топ 7 наиболее возмутительных риторических механизмов, хотя и не являющихся agile уникальными, но широко распространенными в их текстах.
Сомнительные риторические приемы не отрицают значимость предлагаемых идей, но они должны предупреждать читателя о необходимости осторожности. Нам следует быть готовыми к восприятию идей, но не ложиться под нашего методологического гида. Первым шагом является предупреждение об этих семи ловушках, к описанию которых мы переходим.
Книги по agile свои выводы делают большей частью на основании примеров. Типичным является пример, приведенный в начале этой главы.
Примеры хороши для книг и при обучении. Они могут иметь и обратный эффект: если пример служит основой обобщения, то читатель, чей собственный опыт противоречит опыту автора, не согласится с обобщением. Мы увидим подобный пример в одной из последующих глав. В этом примере автор для поддержки своей точки зрения на разработку ПО ссылается на опыт выдающегося велосипедиста Ланса Армстронга.
Еще один пример того же автора – душераздирающая история о водителе автобуса в Диснейленде, который, заметив плачущую маленькую девочку, сумел сделать так, что актер, играющий Микки Мауса, приветствовал девочку. Эта история должна была иллюстрировать важность качества работы. Для читателя, кто провел целый день в Диснейленде с детьми, стоя в очередях, ассоциация с качеством не покажется убедительной. Скорее, возникнет ассоциация с сайтом, имеющим привлекательный интерфейс и долгое время отклика на запросы. Апелляция к сознанию читателя – хорошее дело, но следует опасаться, что ассоциации могут возникать разные.
Общая проблема с примерами такая же, как и с принципом, согласно которому тесты задают спецификацию. И в том и в другом случае, имея пример, нет никакой уверенности, насколько справедливо экстраполирование примера на общий случай.
Существуют эффективные, хотя и недостойные способы критики чужой идеи. В agile литературе применяют два варианта – позитивный и негативный.
Позитивный вариант состоит в том, чтобы для вашей идеи выбрать подходящее имя, ассоциирующееся с приятными чувствами. Тогда идеи, противоречащие вашей, автоматически попадут в разряд неприятных. Это великолепный маркетинговый ход, которым можно только восхищаться. Как отмечалось во введении, выбор слова agile был такой блестящей находкой. Всякая не agile идея является негибкой, окостенелой, бюрократической.
Негативный вариант состоит в том, чтобы в сознании читателя связать чужую идею с другой идеей, всеми отвергаемой. Любимой для agile "нехорошей" идеей является процесс разработки ПО, называемый презрительно "водопадом". Конечно же, никто из тех, кто не принимает идеи agile, не собирается возвращаться к методам разработки ПО семидесятых годов, когда появилась модель "водопада". Фактически никто и не применял ее в чистом виде, и нет никого, кто рекомендовал бы ее применение. Все же, как мы увидим в следующей главе, ведущие agile авторы постоянно называют "водопадом" любой не-agile подход. Это дешевый трюк, не попадайтесь на него.
Следующее множество сомнительных аргументов использует преимущества положительных эмоций, связанных со словом "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 подходов, то вы рискуете получить "удары" от "истинных последователей". К счастью, вы предупреждены. В этой книге мы бесстрашно (аплодисменты храбрецам, пожалуйста) попытаемся отделить лучшее от не столь хорошего и от откровенно плохого.
Когда вы защищаете новый подход, то естественно высвечивать недостатки существующего. Иначе, если бы у существующих методов не было недостатков, и изобретать новые не имело бы смысла. Естественно, состояние программной инженерии вполне может быть подвергнуто критике. Однако, чтобы критика заслуживала доверия, она должна быть корректной и справедливой.
Началом становления программной инженерии можно считать 1968 год, когда стали говорить о "кризисе создания ПО". В течение ряда лет стало привычкой начинать любую статью с жалоб на ужасную ситуацию в этой области. Неявно предполагалось, что тот небольшой вклад вашей статьи – методологическая идея, новый язык программирования, инструментальное средство – поможет в преодолении кризиса.
Через некоторое время этот скорбный стиль (не все в порядке в королевстве программной инженерии) вышел из моды. Действительно, глупо утверждать, что все неладно с разработкой ПО в мире, где программно поддерживаются каждое устройство, каждый доступный нам сервис.
Апокалипсическая мода вернулась на новом витке с agile литературой, которая любит цитировать так называемые "хаос"-отчеты, публикуемые корпорацией Standish Group, специализирующейся на анализе неудачных программных проектов. В этих отчетах показано, что большое число проектов либо не достигают намеченных целей, либо выходят за рамки поставленных ограничений (в известном треугольнике "время – стоимость – качество" достижимы только два свойства из трех). Было модно цитировать эти отчеты (я сам включил такую цитату в одну из своих статей в 2003 году). Но, начиная с 2006 года [Glass 2006], [Eveleens 2010] методология этих отчетов и сами результаты были полностью развенчаны. Было показано, что результаты не согласованы, не подтверждаются другими исследованиями, основываются на частных данных, к которым не допускаются независимые исследователи. И все же они продолжают постоянно цитироваться для обоснования поддержки agile процессов, включаются в современные книги от создателей Scrum [Schwaber 2012], кто добавляют:
Вы были больны, служа программной инженерии в течение 40 лет – не бесцельно, но хаотически. Мы хотим восстановить партнерство.
Добавить нечего! Программная инженерия трудна сама по себе и сталкивается с множеством трудностей, очевидных для каждого в индустрии (и для пользователей тоже), так что нет необходимости придумывать воображаемые ужасы.
Истории в отчетах фирмы Standish также напоминают нам об угрозах гиперболизации любого вида, как об ужасных ошибках, сделанных другими, так и о наших триумфах. Программная инженерия нуждается в эмпирических результатах, внушающих доверие.
В то время как некоторые agile тексты и методы предлагают соразмерные подходы, другие, как отмечалось во введении, настаивают на применении их метода с использованием всех предлагаемых практических приемов.
Нельзя отрицать право методологов специфицировать немногие бесспорные принципы, определяющие их методы, но число таких абсолютных требований должно быть невелико. В противном случае принципы начинают напоминать маркетинговые приманки, как это можно видеть в презентациях, демонстрирующих успешные и провальные проекты. Успешные проекты демонстрируют мощь метода. Провальные проекты потерпели неудачу только по той причине, что не следовали методу.
Трюк блестящий, но не следует на него попадаться. Индустрия, как отмечалось, игнорирует такой абсолютизм. Каждая группа делает свой собственный выбор, принимая некоторые приемы, отказываясь от других. Программные проекты различны, а их разработка трудна. Здесь нет единого рецепта, пригодного на все случаи жизни.
Не все agile авторы хотят, чтобы их воспринимали как экстремистов, но даже те, кто пытается избежать этого образа, зачастую оставляют читателя в темноте, не говоря о том, когда следует применять их приемы, а когда не следует этого делать. Типичная схема состоит в пропаганде радикальных идей, затем краткого упоминания, что они не всегда применимы, без указания каких-либо критериев, позволяющих принять решение. Это говорит о рассудительности автора, но мало помогает практику, который должен принять решение.
Типичный пример появляется в основополагающей книге по LSD (Lean Software Development), написанной Марией и Томом Поппендик [Poppendieck 2003]. После семи глав, восхваляющих изменения, которые следует сделать в практике разработки ПО, каждое из которых зиждется на одном из семи принципов, в заключительной главе, названной с юмором "Инструкции и гарантии", утверждается:
Соблюдайте баланс в применении Lean принципов:
исключение непроизводительных затрат (первый принцип) не означает полного отказа от документации; усиление внимания к обучению (второй принцип) не означает, что все изменения нужно хранить в памяти; принятие решения настолько поздно, насколько это возможно (третий принцип), не означает откладывания решения.
Также обстоит дело и с оставшимися четырьмя принципами, о применении каждого говорится, что принцип "не означает", что его следует применять во всех ситуациях. Эти комментарии показывают рекомендуемые ограничения, но они бесполезны для практиков, так как глава содержит только восемь страниц и почти ничего не говорит практикам, ожидающим совета: когда принципы не применимы или применимы частично и как они должны ослабляться в подобных случаях.
Разработчики и менеджеры не нуждаются в пустых наблюдениях. Нужны критерии, задающие исключения, когда принципы могут не соблюдаться. Исключения и критерии должны формулироваться одновременно с заданием каждого принципа, а не в отговорках, разрушающих доверие к самим принципам. Не будучи инструкциями и гарантиями, такие отговорки напоминают предупреждения, присоединяемые ко многим товарам. Их смысл не в том, чтобы помочь пользователям метода, они помогают только авторам, обеспечивая им защиту, своего рода "соломенную подстилку". Вы применяли принцип X, и все у вас закончилось неудачей? Сожалеем, что слышим это. Но ведь вас предупреждали, что нужно соблюдать баланс в применении принципов.
(Да, предупреждали. Но я предпочел бы, чтобы мне сказали, в чем же этот баланс состоит.)
Все это напоминает общую ситуацию, когда подстилается соломка: "А1 не означает А2", где А1 почти ничем не отличается от А2. Например, А1 – "решать настолько поздно, насколько это возможно", а А2 – "отсрочить принятие решения". Если здесь есть разница, то ее трудно уловить.
Способ "подстилки соломы" не является спецификой цитируемой книги или метода Lean. Подобные примеры встречались во многих других источниках, например такая цитата:
"Хотя все решает сама команда, она не является не-управляемой".
Когда мы обнаруживаем пределы догматического применения agile методов, нам самим не следует попадаться в такую же ловушку. Эта книга пытается объяснить, когда и как agile предписания должны заменяться или комбинироваться с другими методами. Другими словами, мы пытаемся совместить "баланс интересов". Примером является agile правило, требующее наличия работающей системы на каждом шаге, и приемы программной инженерии, дающие преимущества от построения инфраструктуры даже без непосредственно видимых результатов для пользователя. Обе точки зрения могут иметь ценность в зависимости от обстоятельств. Результатом обсуждения является конкретная политика "дуальной разработки", комбинирующая подходы в зависимости от специфики ситуации.
Документ одного из создателей 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 лет – не бесцельно, но хаотически.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.