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

2.1 Приключение путешествующего семинариста

Этот пример взят из одной из важных для agile книг "Достижение успехов с Agile", написанной Майклом Коном [Cohn 2010], широко используемой и цитируемой в agile мире. Автор является опытным консультантом и одной из центральных фигур agile движения. Текст, приводимый ниже, представляет выдержку из главы, посвященной преимуществам вербальных контактов над письменными документами.

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

2.1.1 Доказательство, построенное на примере

Начнем с двух наблюдений: одно следует непосредственно, другое менее очевидно.

• Аргументация автора вполне подошла бы для вербального семинара, вероятно, она там и возникла. Будучи же записанной, она становится довольно нелепой, так что серьезный читатель вряд ли воспринимает ее всерьез. Этот пример является лучшим свидетельством того, что абсурдность, которая вербально могла остаться незамеченной, становится очевидной при записи.
• Бессмысленность придуманного урока не должна затушевать частицу мудрости, в нем заложенной, даже если это не то, что имел в виду автор.

Рассмотрим неудачную аргументацию. Первая проблема состоит в том, что она следует той форме логики, которая, к сожалению, довольно часто применяется в компьютерной литературе (особенно, но не исключительно в agile книгах) – доказательство, построенное на примере. Пример не является доказательством, как уже отмечалось во введении. Пример может лишь опровергнуть обобщение. Он даже не может служить аргументом. Он может способствовать аргументации, но лишь в том случае, когда есть много подобных примеров, свидетельствующих о возможности обобщения. В данном случае на каждую историю об ошибочном толковании "бронирования в отеле" при обмене письмами, которого можно было бы избежать при устном общении, можно привести другую историю, свидетельствующую об обратном эффекте. Я мог бы рассказать вам историю о том времени, когда хотел предложить своей будущей жене выйти погулять со мной, но по телефону сказал… Я мог бы, но (расслабьтесь) не буду этого делать, во-первых, потому, что моя любовная жизнь вас не касается, во-вторых, вы сами уже догадались, о чем идет речь.

Расскажу другую историю, основанную на факте и связанную на этот раз с разработкой ПО. В проекте возникла ошибка, которую мы не могли понять и исправить в течение длительного времени, поскольку разработчик важного фрагмента программы в это время отсутствовал. Программа в некоторых ситуациях зацикливалась. Методу, созданному отсутствующим разработчиком, передавалась некоторая структура данных. "Жучок" состоял в том, что в методе предполагалась ациклическая структура, в реальности она временами была циклической, и тогда возникал бесконечный цикл. Разработчик обнаружил несоответствие и сказал, что "каждый знает", что ацикличность структуры необходима. Возможно, каждый должен знать, но кто-то забыл. Хорошо еще, что хоть кто-то помнил! Даже без возможности написать непосредственно в коде предусловие к методу (require structure.is aciclic), как это может быть сделано в некоторых языках программирования, было бы лучше просто записать соответствующее требование, что позволило бы избежать непроизводительных затрат времени.

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

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

2.1.2 Когда запись побеждает речь

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

• Устное слово двусмысленно в значительно большей мере, чем записанные требования. Если мы полагаем, что требования "выглядят более точными, чем являются на самом деле", значит, мы нуждаемся в более точной форме записи требований, что означает необходимость перехода к формальным (математическим) спецификациям. Вероятно, это не совсем то, что имел в виду Кон в своем пассаже.
• Трудность достижения точности в устном общении является той самой причиной, по которой многие вербальные требования или устные обсуждения заканчиваются советом: "пожалуйста, запишите это", поскольку человеку, прежде чем принять окончательное решение, необходимо видеть запрос на бумаге.
• Сегодня многие разработки включают людей с разным уровнем подготовки, с различным знанием языка. Довольно трудно выяснить детали того, что участники пытаются сказать, когда обсуждение идет, например, в Скайпе между членами команды, находящимися в Германии и Индии и использующими для общения английский язык или тот язык, который они называют английским. И в этом случае все обычно заканчивается просьбой написать все по электронной почте. Хотя люди также делают ошибки в письме, но намного проще при написании использовать общее подмножество языка, которое каждый понимает единообразно.
• Устные обсуждения хороши для тех, кто присутствовал на них. Письменные описания не имеют того теплого и расплывчатого чувства согласия, которое возникает при устной беседе, но они могут быть адресованы многим людям. Когда говорят о сопричастниках проекта – людях, так или иначе вовлеченных в проект, то часто неизвестно, имеет ли конкретный человек достаточный для выражения свойств системы опыт или он высказывает свое частное предпочтение. В окружении компании есть много людей и множество точек зрения, поэтому опасно следовать за человеком, которого выслушали последним. Все, что записано, может быть оценено разными сопричастниками проекта. Когда кто-то из них заметит неполноту или неточность в требованиях, он поднимет тревогу еще до того, как исправление ошибок будет дорого стоить.
• Люди в проектах приходят и уходят. Одно из преимуществ записанных требований в том, что они сохраняют контекст обсуждения, когда после шести месяцев никто не может вспомнить, по какой причине было принято то или иное решение.

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

Спасибо, что в школьные годы мы тратили время на обучение чтению и письму. А могли бы вместо этого бродить по парку в веселых беседах, совершенствуя вербальные навыки^{1Сократ и Пифагор не вели записей. К счастью, это делали их ученики. Беседы с Сократом сохранились благодаря Платону – ученику Сократа. Он же за большие деньги приобрел записи бесед Пифагора, сделанные его учеником.}.

2.1.3 Обнаружение жемчужных зерен

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

Гениальной находкой является наблюдение: "Письменный текст создает ошибочное представление – он выглядит более точным, чем является на самом деле". Авторитетность письменного слова может быть опасной. Человеческий язык, письменный или устный, богат двусмысленностями. Хорошо известным примером является требование: "Система должна давать ответ в реальное время", которое по сути ничего не определяет. Ответ, приходящий через одну десятую секунды, обеспечивает "реальное время" для банковского терминала, но совсем неудовлетворителен для сетевого роутера. Однако альтернативой не является разговорный язык, который еще менее точен.

Альтернативой, когда точность – цель, является математика. Требование: answer.time – query.time < 0.1 не выглядит более точно, чем оно есть. Оно выглядит точно и является точным. Но это не совсем то, что подразумевал Кон. Его волновала проблема письменных требований, но он слишком много значения придавал тому, что они письменные. Сама по себе проблема правильная, из нее следует первый существенный урок: Не следует считать, что если требования сформулированы в письменной форме, то это означает, что они четко определены. Из записи требований еще не следуют ни их точность, ни их корректность.

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

Второй урок состоит в том, что коммуникация трудна. Это верно. Этот факт известен всем еще до чтения текста Кона и данного обсуждения. Но коммуникация необходима при разработке ПО, и это тот вызов, который требует ответа. В любом большом и амбициозном проекте (как и во многих малых) проблема коммуникации так же важна, как и технические проблемы. Проект легко можно погубить, если руководство не решит проблемы общения своевременно и нужным образом. Эти проблемы особо критичны для географически распределенных проектов, где на обычные проблемы общения накладываются расстояния, разница во времени, языковые проблемы, различия в культурах. (Веселой иллюстрацией к сказанному является запись в YouTube инженера из Индии, где он объясняет разницу смысла "да" и "нет" и кивками головы в Индии [Dhawan 2008].)

Что можно сказать об устном общении? Урок здесь состоит в том, что письменных описаний недостаточно. Различные сопричастники проекта^{2Сопричастник (stakeholder) – члены команды, заказчики, пользователи, все те, кто так или иначе причастны к проекту, например, те, кто из-за внедрения проекта может лишиться рабочего места.} должны разговаривать. Кон, несомненно, имел это в виду, полагая, что документов недостаточно. Вот не анекдот, а реальный пример из истории программной инженерии. В 1999 году NASA потеряла 125 миллионов долларов при запуске орбитального спутника Марса из-за программной ошибки, которая не была обнаружена при всех инспекциях кода и при наличии письменных требований. Ошибка состояла в том, что в проектах NASA использовалась метрическая система мер, но один из разработчиков в Англии использовал английскую систему мер, что и привело к критической ошибке, погубившей проект. Анализируя этот пример, можно вполне согласиться с Коном: документы хороши, но они могут пропустить базисную, вполне очевидную информацию. Так что люди должны разговаривать друг с другом!

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

2.1.4 Agile тексты: читатель, будь осторожен!

Рассмотренный выше пример является представителем того, что часто можно найти в литературе по agile. Его анализ дает руководство к тому, как использовать такую литературу.

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

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

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

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

2.2 Топ семи риторических ловушек

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

1. Доказательство, основанное на примере, применение которого мы уже видели. История, одна или десять, доказательством не является.
2. Клевета по ассоциации: идея, которую автор собирается критиковать, ассоциируется с идеей, которую все критикуют. Ни одна из идей, не входящих в сферу agile, не избежала этой участи.
3. Запугивание: на всех, кто не принимает евангелие от agile, навешивается ярлык реакционера и чудака.
4. Катастрофизм: убеждать, что применяемые сегодня методы разработки ПО обязательно ведут к катастрофе (так что только agile методы могут спасти проект).
5. Все или ничего: успех проекта зависит от применения agile метода в полном объеме; неудачи связаны с неполнотой применения.
6. Подстелите соломку: вам предлагают радикальные меры, а в сносках говорят о том, что они не всегда применимы, но никогда точно не говорят, когда эти меры могут использоваться, а когда нет.
7. Неверифицируемые заявления. Литература по Scrum, в частности, назойливо рекламирует чрезвычайное улучшение производительности. Кто же не хочет вдвое увеличить эффективность проекта? В отсутствие достоверной независимой верификации такие утверждения должны (в зависимости от вашего настроения) либо приниматься, если энтузиазм автора вас очаровал, либо отвергаться, если считаете, что имеет место назойливая реклама.

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

2.2.1 Доказательство, основанное на примере

Книги по agile свои выводы делают большей частью на основании примеров. Типичным является пример, приведенный в начале этой главы.

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

Еще один пример того же автора – душераздирающая история о водителе автобуса в Диснейленде, который, заметив плачущую маленькую девочку, сумел сделать так, что актер, играющий Микки Мауса, приветствовал девочку. Эта история должна была иллюстрировать важность качества работы. Для читателя, кто провел целый день в Диснейленде с детьми, стоя в очередях, ассоциация с качеством не покажется убедительной. Скорее, возникнет ассоциация с сайтом, имеющим привлекательный интерфейс и долгое время отклика на запросы. Апелляция к сознанию читателя – хорошее дело, но следует опасаться, что ассоциации могут возникать разные.

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

2.2.2 Клевета по ассоциации

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

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

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