/
Автор: Коберн А.
Теги: программирование программное обеспечение языки программирования компьютерные технологии
ISBN: 0-201-69969-9
Год: 2002
Похожие
Текст
Серия “Быстрая разработка программного обеспечения"
Редакторы серии: Коберн • Хайсмит
Быстрая разработка
программного
обеспечения
Алистер Коберн
Издательство "Лори"
Agile Software Development
Alistair Cockburn
Copyright © 2002
All rights reserved
Быстрая разработка программного обеспечения
Алистер Коберн
Переводчик В. Стрельцов
Научный редактор А. Вендров
Корректор Л. Осипова
Верстка И. Нагорновой
Copyright © 2002 by Addison-Wesley
Pearson Education Corporate Sales Division
201 W. 103rd Street
Indianapolis, IN 46290
(800) 428-5331
corpsales@pearsoned. com
ISBN 0-201-69969-9
© Издательство "Лори", 2002
Изд. № : OAI (03)
ЛР № : 070612 30.09.97 г.
ISBN 5-85582-182-Х
Подписано в печать 18.09.2002 Формат 70 х 100/16
Гарнитура Литературная Печать офсетная
Печ. л. 21 Тираж 3200 Заказ № 715
Цена договорная
Издательство "Лори". Москва 123100, Шмитовский пр., д. 13/6, стр. 1
(пом. ТАРП ЦАО)
Телефон для оптовых покупателей: (095)256-02-83
Размещение рекламы: (95)259-01-62
www.lory-press.ru
Отпечатано в типографии ООО "Типография ИПО профсоюзов Профиздат"
109044, Москва, ул. Крутицкий вал, д. 18
СОДЕРЖАНИЕ
Введение. Непознаваемое и невыразимое 7
Проблема с анализом опыта......................................2
Винная этикетка......................................... 2
Противоречивые варианты анализа ......................... 2
Обнаружение вариантов анализа.............................6
Небрежные мысли...........................................7
Невозможность коммуникации.....................................8
Внутренняя реструктуризация..............................10
Соприкосновение в совместном опыте.......................11
Справляясь с несовершенством коммуникации................13
Три уровня понимания..........................................15
Три уровня и методологии.................................16
Три уровня и эта книга...................................19
Shu-Ha-Ri................................................19
Что дальше?...................................................21
Глава 1. Кооперативная игра
в изобретения и коммуникации 23
Программное обеспечение и поэзия..............................23
Программное обеспечение и игры................................26
Разновидности игр........................................26
Программное обеспечение и альпинизм......................28
Игра изобретения и коммуникации..........................30
Программное обеспечение и инженерия......................31
Программное обеспечение и моделирование..................32
Второй взгляд на кооперативную игру...........................33
Программисты как специалисты
по коммуникации..........................................34
viii Содержание
Ускоритель игры.............................................35
Метки и реквизит............................................35
Сокращение отдачи...........................................36
Достаточность для главной цели..............................36
Достаточность в наследстве..................................39
Игра внутри игры............................................41
Разработка с открытыми исходными текстами...................42
Что все это означает?............................................42
Глава 2. Индивидуумы 45
Необычные люди......................................................45
В поисках характеристической функции...........................46
Элементы отличия...............................................47
Неминуемое разнообразие........................................50
Место технологии...............................................50
Противоречивые обобщения.......................................51
Преодоление неудач................................................ 52
Совершение ошибок..............................................53
Предпочтительность консервативной неудачи......................54
Не исследование, а изобретение.................................55
Непоследовательность рабов привычек............................56
Возражения против дисциплины и терпимости......................58
Одни способы работают лучше, чем другие.............................60
Конкретное.....................................................61
Осязаемое..................................................... 62
Изменение......................................................64
Наблюдать и слушать............................................65
Поддерживать концентрацию и коммуникацию.......................66
Рабочие назначения, соответствующие личным качествам...........67
Способности....................................................68
Вознаграждения, сохраняющие удовлетворение.....................69
Комбинирование вознаграждений..................................73
Обратная связь ................................................74
Использование сильных сторон........................................76
Хорошее умение ориентироваться.................................76
Люди обучаются.................................................78
Восприимчивость................................................79
Вклад в общую работу и проявление инициативы...................79
Содержание ix
Комбинированные факторы успеха......................80
Герои как обычные люди..............................81
Что дальше?..............................................83
Глава 3. Коммуникация
и сотрудничество в командах 85
Конвекционные потоки информации..................................86
Цена опозданий и упущенных возможностей.....................86
Эрг-секунды.................................................89
Осмотическая коммуникация...................................92
“Сквозняки”.................................................94
Излучатели информации.......................................96
Применение теории “горячего воздуха”.......................101
Преодоление разрывов коммуникации...............................105
Модальности в общении......................................106
Влияние удаления модальностей..............................108
Использование модальностей.................................110
“Устойчивость” и преодоление разрывов в пространстве.......112
Команды как сообщества людей....................................116
Дружелюбие и конфликты.....................................118
Проявления чувства долга в рабочее время...................119
Сравнение враждебной методологии ХР с дружественной ХР.....120
Создание “команды” с помощью побед.........................122
Культуры и субкультуры в команде...........................123
Команды как экосистемы..........................................128
Что дальше?................................................... 130
Глава 4. Методологии 133
Экосистема, поставляющая программное обеспечение................133
Понятия методологии........................................134
Структурные термины........................................135
Область действия...........................................140
Концептуальные термины................. ...................144
Публикация методологии.....................................158
Принципы создания методологии...................................165
Общие ошибки создания методологии..........................166
Методологически успешные проекты...........................171
X
Содержание
Восприимчивость автора методологии......................172
Семь принципов..........................................175
ХР под микроскопом...........................................197
Коротко об ХР......................................... 197
Препарирование ХР.......................................199
Адаптация ХР............................................200
Зачем вообще нужна методология ..............................202
К чему обращена методология.............................202
Как оценить методологию......................................204
Что дальше?................................................ 205
Глава 5. Быстрота и адаптируемость 207
Быстрота и адаптируемость...............................207
Легкая, но достаточная.......................................208
Едва достаточная методология............................209
Рекомендации по документированию........................211
Быстрота.................................................... 211
Наиболее эффективные участки............................212
Проблемы с виртуальными командами.......................215
Добиться адаптируемости......................................219
Остановиться и подумать.................................219
Способ выращивания методологии..........................220
Техника проведения рабочих семинаров.........................230
Что дальше?..................................................233
Глава 6. Методологии семейства Crystal 235
Формирование семейства Crystal...............................236
Основные элементы методологий Crystal...................238
Crystal Clear................................................240
Краткое описание Crystal Clear..........................240
Размышления о Crystal Clear.............................242
Crystal Orange...............................................243
Краткое описание Crystal Orange.........................243
Размышления о Crystal Orange............................245
Crystal Orange Web...........................................246
Краткое описание Crystal Orange Web.....................247
Размышления о Crystal Orange Web........................250
Содержание xi
Что дальше?............................................252
Приложение А. Манифест быстрой
разработки программного обеспечения 253
Быстрый альянс.........................................254
Манифест...............................................255
Размышления о манифесте...........................258
Поддержка ценностей....................................258
Размышления о перечисленных положениях............264
Приложение В. Наур, Эн и Мусаши 265
Питер Наур. Программирование как построение теорий.....265
“Программирование как построение теорий”..........266
Применение “построения теорий”....................279
Пелле Эн. Языковые игры Витгенштейна...................280
“Об участии и умении”.............................281
Мусаши.................................................296
Книга пяти колец..................................297
Применение методов Мусаши к разработке ПО.........299
Приложение С. Книги и ссылки 303
Книги, упорядоченные по названиям......................303
Ссылки, упорядоченные по фамилиям авторов..............308
Предисловие
Разработка ПО — это что: искусство, ремесло, наука, инженерия или нечто абсо-
лютно иное? И имеет ли ответ на этот вопрос хоть какое-то значение?
Да, он имеет значение и важен для вас. От того, какой из ответов более вер-
ный, будут зависеть ваши действия и их результаты.
Вот что самое главное: вы хотите, чтобы ваши программы появлялись на
свет быстро и не содержали дефектов, но еще больше вам нужен способ провер-
ки, как ваша команда справляется со своей задачей в процессе разработки.
Цель
Пришла пора пересмотреть понятия, лежащие в основе разработки ПО.
Трудность заключается в том, что, когда мы смотрим на проекты, наша спо-
собность замечать ограничена нашим знанием. В чрезвычайно обильном потоке
впечатлений, текущем через нас, мы учимся различать отдельные вещи и извле-
каем их из этого потока для изучения. Если нам недостает разнообразных ключе-
вых отличительных признаков, мы можем пропустить вещи, находящиеся прямо
перед нами.
Мы закрепляем эти отличительные признаки в памяти с помощью слов и по-
льзуемся этими словами, чтобы отразить наш опыт. В той степени, в которой нам
недостает слов для закрепления в памяти отличительных признаков, нам не хва-
тает способности пользоваться нашей памятью в разнообразных диалогах и вы-
страивать значимые стратегии на будущее.
Иначе говоря, чтобы переосмыслить понятия, лежащие в основе разработки
ПО, нужно заново рассмотреть отличительные признаки, которыми мы пользу-
емся, чтобы препарировать наш опыт, и слова, которые мы применяем, чтобы
закрепить его в нашей памяти.
Это, конечно, непростая задача для любой книги. И поэтому несколько час-
тей этой книги будут довольно абстрактными. Но что делать, если я не вижу ино-
го пути.
xiv
Предисловие
Глоссарий для разработки ПО создавался последний раз в конце 1960-х го-
дов, когда появилось новое выражение — программная инженерия (software en-
gineering), — в котором разработчики отразили свое желание двигаться в этом
направлении в будущем.
Знаменательно, что в то же время, когда было заявлено, что программиро-
вание следует отнести к области инженерии, Джеральд Вейнберг (Gerald Wein-
berg) написал книгу “Психология программирования” (The Psychology of
Computer Programming). В ней разработка ПО вовсе не выглядела инженерной
дисциплиной, а представлялась как нечто очень зависящее от человека и обще-
ния. Из этих двух подходов именно наблюдениями Вейнберга руководствовались
люди в последовавшие затем 30 лет, а программная инженерия остается терми-
ном, отражающим желание.
В данной книге сделано следующее:
Выстроены отличительные признаки и глоссарий для разговора о разработ-
ке ПО.
Этот глоссарий использован для анализа и фиксации важнейших аспектов
программных проектов, которые слишком часто отодвигались на второй план.
Проработаны идеи и методологические принципы как “правила поведения”.
Объединена наша потребность в правилах поведения с идеей уникальности
каждого проекта и выведены эффективные и саморазвивающиеся правила.
Надеюсь, что после чтения книги вы сможете использовать новый глоссарий
для ревизии вашего собственного проекта и, заметив то, на что ранее не обраща-
ли внимания, сумеете выразить свои наблюдения. Приобретя такие способности,
вы сможете:
Обсуждать Extreme Programming, Capability Maturity Model, Personal Soft-
ware Process или ваш излюбленный процесс
Определять, при каких условиях каждый процесс более или менее применим
Понимать людей, имеющих иные мнения, способности и опыт
Круг читателей
Все те, кто обращается к данной книге, различаются опытом, стилем чтения и ро-
лью. Читать эту книгу, чтобы извлечь для себя наибольшую пользу, вы тоже може-
те соответственно: по опыту, по стилю чтения или по роли.
По опыту
Эта книга предназначена для квалифицированных читателей. В ней не приводятся
процедуры, которым нужно следовать при разработке ПО; центральным является
Предисловие
xv
представление об ограниченности всех приемов. Следовательно, невозможно на-
звать один наилучший и правильный способ разработки программ. В идеале эта
книга поможет вам достичь такого понимания и приведет к конструктивным идеям,
позволяющим справиться с реальной ситуацией.
Если вы имеете средний опыт разработки программных проектов и в настоя-
щее время ищете границы применения освоенных правил, для вас наиболее по-
лезными будут следующие темы:
Виды методологий, соответствующие различным видам проектов
Показатели для выбора подходящей категории методологии для проекта
Принципы, стоящие за “быстрыми” методологиями
Имея средний опыт практической работы, вы поймете, что, применяя эти
идеи, должны добавить к ним собственное мнение.
Если вы обладаете значительным опытом, то уже знаете, что все рекоменда-
ции различаются по применимости. Возможно, вам нужны слова, которые помо-
гут это выразить. Вы найдете их в тех местах, где обсуждаются следующие темы:
Преодоление неполноты коммуникации
Постоянное изобретение методологии заново
Манифест быстрой разработки ПО
Несколько тем будут в новинку даже опытным разработчикам ПО: глоссарий
для описания методологий и приемы своевременной настройки методологий.
По стилю чтения
Начальные главы более абстрактны, чем последующие.
Если вы получаете удовольствие от чтения абстрактного материала, прочи-
тайте книгу от начала до конца, наблюдая за изложением абстрактных тем, чтобы
по ходу книги понять разрешение сложных проблем.
Если вы хотите как можно быстрее получить в руки конкретные материалы,
при первом чтении можете пропустить начальные главы и начать с главы 4 (“Ме-
тодологии”). Чтобы получить основные сведения из нового глоссария, вернитесь
к разделам “Кооперативные игры” и “Конвекционные потоки информации”. Что-
бы заполнить пробелы, пролистайте введение и главы об отдельных лицах и
командах. kiu‘
По роли
Люди, финансирующие разработку ПО, с помощью этой книги поймут, как раз-
личные организационные, поведенческие и финансовые структуры влияют на
темп, с которым они извлекают пользу от своих команд разработчиков. Лица, фи-
xvi
Предисловие
нансирующие проекты, могут обращать меньшее внимания на детали методоло-
гий, чем люди, непосредственно вовлеченные в проекты. И все же, думаю, они
разберутся в последствиях отдельных видов методологических решений.
Руководители групп и менеджеры проектов смогут понять, как назначения на
должности, распределение работы и индивидуальные особенности влияют на ре-
зультат их проекта. Они также узнают, какого рода вмешательства наиболее ве-
роятно приводят к лучшим и худшим последствиям. Им потребуется понять
структуру и значимость, а также принципы развития их методологии, т.е. как сде-
лать ее более компактной, но все такой же эффективной.
Разработчики процессов и методологий могут изучить мой выбор сроков и
принципов построения методологий и поспорить с ним. Последующее обсужде-
ние будет полезным для всех этих сотрудников.
Разработчикам ПО следует познакомиться с этим материалом просто пото-
му, что он относится к их профессии. В ходе естественного продвижения от но-
вичка к руководителю они должны обращать внимание на то, что работает и что
не работает в их проектах. Им также понадобится узнать, как настроить свою ра-
бочую среду, сделать ее более продуктивной. “Наша методология” в действите-
льности означает “соглашения, которым мы всегда следуем”, и поэтому
ответственность за понимание основ создания методологии ложится на каждого
профессионала.
Структура книги
Материал книги организован таким образом, чтобы сначала поставить два чрезвы-
чайно сложных вопроса и получить ответы на них в конце:
Если коммуникация между разработчиками по существу невозможна, то
как людям, участвующим в проекте, удается ее осуществить?
Если все люди и все проекты различаются, как можем мы создать какие-ли-
бо правила для результативных проектов?
Чтобы осуществить эти намерения, я написал книгу в несколько “детектив-
ном” жанре. Она начинается с широкого философского исследования: “Что та-
кое коммуникация?” и “Что такое разработка ПО?”
Исследование продвигается через весьма абстрактные темы: “Каковы харак-
теристики человека?” и “Что влияет на движение идей внутри группы?
Со временем оно переходит на более конкретную почву с обсуждением во-
проса “Каковы элементы и принципы методологий?” И с этого места хорошо на-
чать чтение, если вы с малых лет стремитесь только к конкретным материалам.
Наконец исследование принимается за наиболее конкретные предметы:
“Как выглядит легкая, достаточная, саморазвивающаяся методология?” и “Как
группа своевременно создает адаптированную к потребностям заказчика и ’’бы-
струю” методологию, чтобы она принесла проекту какую-либо пользу?"
Предисловие
xvii
Приложения А и В содержат вспомогательный материал. Первое приложе-
ние — это “Манифест быстрой разработки ПО”, подписанный 17 опытными
разработчиками ПО и методологий.
Во втором приложении приведены отрывки из трех работ, которые не так
широко известны, как они того заслуживают. Я включил их, поскольку они очень
важны для тем, рассматриваемых в данной книге.
Идеи, унаследованные данной книгой
Идеи книги опираются на 25-летний опыт разработки и 10-летние исследования
различных проектов ее автором.
В 1991 г. IBM Consulting Group попросила меня создать первую для нее
объектно-ориентированную методологию. Я без особой пользы просмотрел до-
вольно противоречивые работы по “методологиям” того времени. С моим руко-
водителем Кэти Улисс мы решили, что я должен опросить команды,
выполнявшие различные проекты, чтобы лучше понять, как они в действитель-
ности работают. И — какой сюрприз! Слова, которыми они пользовались, почти
не соприкасались с терминологией из книг.
Эти беседы были настолько полезными, что я до сих пор посещаю группы,
успешно работающие над проектами, чтобы узнать, с чем они столкнулись, чему
научились и что рекомендуют. Решающий вопрос, который я задаю перед бесе-
дой, звучит так: “А вы хотели бы снова работать таким образом?” Если мне рас-
сказывают о приобретенном опыте в словах, отсутствующих в моем словаре, то
это указывает на новые области, в которых мне не хватает отличительных при-
знаков и терминов.
Данная книга написана потому, что слова и отличительные признаки в ко-
нечном счете непосредственно связаны с описанием хода и результатов проектов.
Оказалось, что для оценки проекта и воздействия на него они ценнее любых ин-
струментов, которые я использовал прежде.
Идеи этой книги были реализованы многими командами разработчиков, в
восьми проектах методологий и во мн<л их удачных проектах, в которых я участ-
вовал.
Быстрота
Не я один пользуюсь этими идеями.
Кент Бек (Kent Beck) и Уорд Каннингем (Ward Cunningham) в конце 1980-х
годов разработали то, что в конце 1990-х получило название Extreme Pro-
gramming (ХР).
Джим Хайсмит (Jim Highsmith) исследовал язык и использование в бизнесе
сложных адаптивных систем в середине 1990-х годов и написал о примене-
нии этого языка в разработке ПО в работе Adaptive Software Developement.
xviii
Предисловие
Кен Швабер(Кеп Schwaber)H Джефф Сазерленд (Jeff Sutherland) пример-
но в то же время сконструировали метод разработки Scrum, и многие руко-
водители проектов в те же годы предприняли аналогичные попытки описать
похожие идеи.
Когда в составе группы из нескольких человек мы встретились в феврале
2001 г., чтобы обсудить, в чем мы сходимся и каковы наши разногласия, оказа-
лось, что мы на удивление едины по очень многим пунктам. Для описания наших
намерений мы выбрали слово agile (быстрый, ловкий, стремительный) и написа-
ли “Манифест быстрой разработки ПО” (Приложение А).
Мы продолжаем формулировать наши общие принципы и находим немало
людей, которые могли бы приехать на ту встречу, если бы знали о ней или если
бы их загруженность позволила в ней участвовать.
Центральными для быстрой разработки ПО являются простые, но достаточ-
ные правила проведения проекта, а также ориентация на людей и коммуникацию.
Быстрота предполагает маневренность — характеристику, которая в настоя-
щее время становится более важной, чем когда-либо. Распространение ПО в
Интернете еще больше усилило конкуренцию между программными продуктами.
Чтобы остаться в бизнесе, нужно не только выпускать программы на рынок и со-
кращать число дефектов в них, но и постоянно следить за изменяющимися требо-
ваниями пользователей и рынка. Чтобы одержать победу в бизнесе, все в
большей мере требуется побеждать в игре разработки ПО. Возможность побе-
дить в этой игре зависит от понимания ее сути.
Лучшее описание “быстроты” в бизнесе я нашел у Голдмана (Goldman,
1997):
“Быстрота динамична и контекстно-специфична; она активно воспри-
нимает изменения и ориентирована на рост. Она не имеет отношения к
повышению эффективности, снижению издержек или принятию мер
для благополучного преодоления зловещих ’’штормов" конкурентной
борьбы. Быстрота имеет отношение к преуспеванию и выигрышу: к
преуспеванию на возникающих конкурентных аренах и выигрышу в
прибыли, доле на рынке и клиентах в эпицентре конкурентных бурь,
которых так боятся теперь многие компании".
Серия “Agile Software Development”
Среди людей, связанных с “быстротой” в разработке ПО, мы с Джимом Хайсми-
том обнаружили так много общего, что решили объединить наши усилия и опубли-
ковать серию “Agile Software Development”, базирующуюся на сравнительно
легких, эффективных, поддерживаемых разработчиками приемах разработки ПО.
В этой серии мы опираемся на две центральные идеи:
Разным проектам нужны разные процессы и методологии.
Предисловие
xix
Концентрация внимания не на процессах, а на практических навыках, ком-
муникации и коллективе разработчиков повышает эффективность и ско-
рость выполнения проекта.
Серия имеет три главных направления:
Приемы, повышающие результативность исполнителя, занимающегося
конкретным видом работы. Это может быть человек, который проектирует
пользовательский интерфейс, собирает требования, планирует проект,
проектирует или тестирует. Любой человек, выполняющий подобную рабо-
ту, захочет узнать, как делают свою работу лучшие специалисты. Writing
Effective Use Cases (Cockburn, 2001c) и GUIs with Glue (Hohmann, гото-
вится к печати) — две книги, посвященные индивидуальным приемам.
Приемы, повышающие эффективность работы группы людей. Это могут
быть приемы создания команды, ретроспективы проектов, принятия реше-
ний и т.п. Групповым приемам посвящены две книги: Improving Software
Organizations (Mathiassen, 2002) и Surviving Object-Oriented Projects
(Cockburn, 1998).
Примеры конкретных, успешных “быстрых” методологий. Любой человек,
подбирающий базовую методологию для своих целей, захочет найти такую,
которая уже успешно применялась в аналогичной ситуации. Модифициро-
вать существующую методологию легче, чем создавать новую, и эффектив-
нее, чем использовать ту, которая предназначена для другой ситуации.
Образец методологии приведен в книге Crystal Clear (Cockburn, готовится
к печати). Мы активно ищем другие примеры, достойные публикации.
Две книги кладут начало серии “Agile Software Development”:
В данной книге выражены мысли о быстрой разработке ПО с помощью мо-
его излюбленного словаря, в котором представлены: разработка ПО как
кооперативная игра, методологии как соглашения о координации и семей-
ства методологий.
Вторая книга — это книга Хайсмита Agile Software Developement Ecosys-
tems. В ней продолжается обсуждение проблем разработки ПО, общих
принципов из разнообразных рекомендациях людей, подписавших “Мани-
фест быстрой разработки ПО”, и общих практических правил быстрой раз-
работки. Предыдущая книга Хайсмита Adaptive Software Developement
выражает его мысли о разработке ПО с использованием его любимого сло-
варя сложных адаптивных систем.
В Интернете можно найти дополнительную информацию о Crystal, Adaptive
и других “быстрых” методологиях. Специальные сайты и темы включены в ссыл-
XX
Предисловие
ки, приведенные в конце книги. Для начала можно воспользоваться следующим
набором сайтов:
www.CrystalMethodologies.org
www.AdaptiveSD.com
www.AgileAlliance.org
мой собственный сайт: members.aol.com/acockburn
Благодарности отдельным лицам
Ральф Ходжсон владеет уникальной библиотекой малоизвестных и интересных
книг. Еще более удивительно, как он ухитрился засунуть в свой портфель в числе
други^эти неизвестные книги, и поэтому мне посчастливилось их прочитать: Sket-
ches of Thoughts Вайноэда (Vinoed) и Situated Learning Лейва (Lave). Те интерес-
ные и почти неизвестные книги, которые вы найдете в главе ссылок, вероятно,
находятся в библиотеке Ральфа.
Люк Хоманн познакомил меня с трудами Карла Вейка (Karl Weick) и Эллио-
та Соловея (Elliot Soloway). Джим Хайсмит научил меня понимать “возникающее
поведение” как характеристику правил, а не просто “неожиданность”. Каждый из
них потратил много драгоценного времени, сверяя последовательность тем и точ-
ность ссылок, высказывая свое мнение практически по каждой странице.
Джейсон Иип прекрасно высмеял мою первую попытку описать распростра-
нение информации как рассеяние газа. Он написал: “Ким распространяет инфор-
мацию. Информация — это зеленый газ. Ким распространяет зеленый газ ...”
Ого! Можете не сомневаться, что эти высказывания были изменены!
Во Леуф придумал прекрасный каламбур: арг-минуту (вместо эрг-секунды)
для обозначения единицы измерения бесполезных сеансов общения. Он также
был настолько любезен, что дважды проверил некоторые мои суждения. Напри-
мер, он написал каким-то израильтянам и попросил проверить мое утверждение
о том, что в Израиле “учтивость в разговоре воспринимается в большей степени
как обида, чем как любезность”. Эта его просьба привела к захватывающей пе-
реписке по электронной почте, которая завершилась таким сообщением (от из-
раильтян): “Твой автор в этом определенно не прав. ... Мы всегда здороваемся и
пожимаем руку, если не видели человека несколько дней. ... Я думаю, твой автор
принимает очень низкую терпимость к ошибкам в работе за нехватку вежливо-
сти”. Другой написал: “По поводу твоего ’’наезда”. Из этого нет выхода, что бы
ты ни говорил. По моему мнению, израильтяне потребовали бы от тебя иметь
собственное мнение и отстаивать его. И, конечно, у них есть собственное мнение
(по крайней мере одно :-)". Бенни Садех предложил слово “искренность”, кото-
рым я в конце концов воспользовался.
Мартин Фаулер внес в обсуждение методологии удобное понятие “видимо-
сти”, а также помог дельными замечаниями и вел себя очень благородно, когда
находил ужасающие вещи.
Предисловие
xxi
Мне хотелось бы выразить признательность и благодарность другим актив-
ным рецензентам: Алану Харриману, Аллену Галлеману, Андреа Бранка, Энди
Сену, Биллу Капуто, Шарлю Эрбо, Чарли Тоуленду, Крису Лопесу, Дебби Атли,
Гленну Вандербургу, Джеймсу Ханраану, Джеффу Миллеру, Джеффу Паттону,
Джесперу Корнерапу, Джиму Сойеру, Джону Брюеру, Джону Куку, Киту Деймо-
ну, Лоране Арчер, Майклу ван Хилсту, Нику Фортескью, Патрику Мэниону,
Филу Гудвину, Ричарду Пфайферу, Рону Холидею, Скотту Джексону, Теду Янгу,
Тому ДеМарко и Трейси Бьялик.
Группа Silicon Valley Patterns совместно постаралась критически проанали-
зировать черновой вариант книги, за что я им вдвойне благодарен.
Команда из Salt Lake в составе Элизабет Уилкокс, Кэти Гилмор, Джона Ро-
бертса и Малии Хоуленд проделала фантастическую работу по превращению ру-
кописи в окончательный вариант книги за чрезвычайно короткий период
времени.
Эти люди сделали все от них зависящее, наблюдая, как я переделывал сла-
бые и сохранял сильные части книги. Если бы у меня нашлось еще несколько лет
на переработку книги, я мог бы даже довести ее до такого уровня, что они смогли
бы с ней смириться.
Не имея этих дополнительных лет, я благодарю их за помощь и прошу про-
стить, что не смог переделать все неуклюжие места.
Слава Богу, что в кафе Beans & Brews наконец-то снова начали играть джаз
и рок. Но я потерял несколько месяцев, вынужденный писать под тяжелый ме-
талл и музыку кантри. Выражаю признательность Salt Lake Roasting Company за
то, что они не закрывались до полуночи.
Чтобы оградить нас с вами от недоразумений в будущем, замечу, что моя фа-
милия произносится “Ко-о-берн”, с длинным “о”.
Дополнительная информация об авторских
правах
Статья “Scandinavian Design” Пелле Эна (Pelle Ehn) из книги Usability: Turning Tec-
hnology into Tools, Paul S. Alder and Terry A. Winograd (Eds.), Copyright © 1992 by
Oxford University Press, Inc. Используется с разрешения Oxford University Press, Inc.
Статья “Programming as Theory Building” Питера Haypa (Peter Naur) из кни-
ги Computing: A Human Activity, ACM Press, 1992. Используется с разрешения
Питера Haypa.
Из The Book of Five Rings Миямото Мусаши (Miyamoto Musashi) в перево-
де Томаса Клири (Thomas Cleary), © 1993, 1994. Перепечатывается по догово-
ренности с Shambhala Publications, Inc., 300 Massachusetts Avenue, Boston,
www.shambhala.com.
“Shu Ha Ri” Рона Фокса (Ron Fox) из The laido Newsletter, Volume 7 num-
ber 2 #54, February, 1995. Используется с разрешения Ron Fox, MSU Kendo
Club for Shu Ha Ri.
xxii
Предисловие
Ссылки на eBucks.com и описание Crystal Orange Web используются с раз-
решения Michael Jordaan, eBucks.com.
Рис. 3.10 используется с разрешения Joshua Kerievsky, Industrial Logic, Inc.,
www.indastriallodgic.com, Copyright © 2001.
Рис. 3.11 используется с разрешения Ron Jeffries, Ann Anderson, & Chet
Hendrickson, Extreme Programming Installed, Addison-Wesley, 2001.
Рис. 3.1, 3.9, 3.15 и 3.16 используются с разрешения Evant Solutions Corpo-
ration, www.evantsolutions.com, Copyright © 2001.
Рис. 3.2, 3.3, 3.6, 3.7 и 3.8 используются с разрешения ThoughtWorks, Inc.,
www.thoughtworks.com, Copyright © 2001.
Рис. 3.12 и 3.13 используются с разрешения Ken Auer, RoleModel Software,
Inc., www.rolemodelsoft.com, Copyright © 2001.
Введение
Непознаваемое
и невыразимое
В этой вводной главе поднимаются два вопроса: “Можем ли мы вообще знать, ка-
кой опыт мы приобретаем и можно ли хоть как-то его описать”? Краткий ответ
“Нет, не можем” обозначает основную проблему, с которой постарается справить-
ся данная книга.
Если вы не можете знать, какой опыт приобретаете, то как вы можете вли-
ять на проекты и формулировать рекомендации, чтобы улучшить работу? Вы
будете страдать от нерационального расходования времени на посторонние
факторы, не замечая основных. С этой проблемой неизбежно сталкивается
каждый человек, пытающийся работать лучше: методолог, исследователь и
практик.
Понимание невозможности идеального общения освобождает вас от по-
пыток достичь этого идеала. Вместо этого вы учитесь справляться с несовер-
шенством общения. Не стараясь создать документ о требованиях или модель
проекта, понятные каждому, вы останавливаетесь, когда документ становится
достаточен для достижения цели среди намеченной аудитории. “Справиться с
несовершенством общения” — это ключ для управления быстрой разработ-
кой ПО.
После постановки этих вопросов в данной главе поднимается вопрос о дей-
ствиях на различных уровнях компетентности. Новичок слушает не так, как спе-
циалист, и требует иного руководства. В третьем разделе обсуждается важность
понимания степени проявления внимания к людям, вовлеченным в проект.
Последний раздел связан с абстрактными понятиями каждодневной жизни.
Это наиболее абстрактная глава в книге. Если вам не нравятся абстрактные
темы, тогда бегло пролистайте ее и вернитесь к ней после прочтения следующих,
более конкретных глав.
2
Введение
Проблема с анализом опыта
Винная этикетка
Войдя в дом, я, как вежливый гость, передал хозяйке бутылку вина
и с любопытством проследил за тем, как она поставила ее в холо-
дильник.
Прежде чем сесть за стол, она достала бутылку и сказала:
— Оно хорошо подойдет к рыбе.
— Но это же красное вино, — осмелился заметить я.
— Белое, — сказала она.
— Красное, — продолжал настаивать я и указал на этикетку.
— Нет, конечно. Оно красное. — Она принялась читать этикетку
вслух: — О! Оно красное! Зачем же я ставила его в холодильник?
Мы рассмеялись и какое-то время вспоминали о своих попытках про-
верить наши собственные представления об "истине". Как это мож-
но, — воскликнула она. — Столько раз смотреть на бутылку и не
заметить, что вино красное!
Люди, рассказывающие о проектах разработки ПО, также допускают ошиб-
ки наблюдения, проходя мимо “фактов”. И авторы требований не могут избежать
этих ошибок. Они наблюдают за своим сообществом пользователей и создают
документы, содержащие, как они считают, только “требования”, но в них часто
можно найти и ошибки наблюдения.
Противоречивые варианты анализа
Приобретая в жизни какой-либо опыт, мы анализируем (parse) его, если использо-
вать лингвистический термин. Мы разделяем этот опыт на отдельные значимые ку-
ски и сохраняем для будущего извлечения. Человеческий мозг выполняет эту
операцию, хотим мы того или нет.
Существуют многие и многие разнообразные варианты, которые можно ис-
пользовать, чтобы препарировать опыт. Каждый вариант означает уникальное
восприятие опыта.
Вкус бифштекса
Когда я только начал питаться в ресторанах, я развлекался, находя
различия во вкусе бифштексов, и получал от этого удовольствие.
Однажды кто-то мне сказал, что бифштексы различаются не вку-
сом, а текстурой.
Одно это замечание сделало несостоятельным все, что я думал о бифштек-
сах, и установило новый вариант анализа на будущее.
Непознаваемое и невыразимое
Каждый вариант анализа чего-либо оставляет в результате мелкие, незапол-
ненные пробелы. Когда мы выполняем анализ по любому варианту, а позднее сое-
диняем кусочки вместе, мы получаем искаженный, упрощенный и незавершенный
результат. Мы лишь надеемся, что он “достаточно близок” к оригиналу и может
оказаться полезным при наших способах использования памяти.
Когда два человека используют различные варианты анализа, результирую-
щие, по-разному сформулированные мысли дают им абсолютно разные словари
для описания одних и тех же событий и разные результаты после того, как кусоч-
ки соединяются вместе (искаженные, упрощенные и незавершенные). Таким об-
разом, один человек может описывать бифштексы, основываясь на вкусе, а
другой — на текстуре. Ни одно из этих описаний не будет полным, но хуже, что
эти двое не смогут поделиться результатами друг с другом.
Рассмотрим эту идею в двух различных контекстах, сначала на изобразитель-
ном примере, а затем в применении к разработке ПО.
Посмотрите, как я собираю картинку, полностью состоящую из дуг окружно-
стей (рис. i.l).
Рис. i. 1. Одна дуга и пара дуг
Из дуг и нескольких маленьких окружностей я собираю следующую картинку,
немного напоминающую голову совы (рис. i.2). Заметьте, что в этот момент я по-
влиял на ваше будущее восприятие этих картинок. Один из важных моментов в этом
обсуждении заключается в возникновении предубеждения, когда я слишком рано
даю картинке название.
о
Рис. i.2. Дуги, составляющие голову
Соединяя вместе две совиные головы, я получаю картинки, которые могут
показаться лимской фасолью, лицами, сердцевиной яблока или чем-то еще, чему
вы дадите свое название (рис. i.3).
4
Введение
Рис. i.3. Сердцевинки яблок?
Наконец я закончил ту картинку, которую держал в уме (рис. i.4). Что вы на
ней видите? Как вы ее разберете на различимые секции? Вы видите наглазник,
эмбрионы или лимскую фасоль? Или видите фигуры инь-янь?
Рис. i.4. Составной круг
На самом деле я держал в уме две наложенные фигуры инь-янь (рис. i.5). В
моем замысле не возникали ни дуги, ни совы, ни яблоки, ни эмбрионы. Все это
было побочными эффектами, артефактами, проявившимися, пока я комбиниро-
вал два значка инь и янь, один — зеркально отраженный и повернутый по отно-
шению к другому, и разбирал картинку в соответствии с другим образцом.
Я представил эти изображения в другом порядке, чтобы проиллюстрировать
три вещи:
Любую составную картинку можно анализировать согласно различным
образцам.
Наше восприятие изображения действует в различных направлениях
в зависимости от составляющих элементов.
То, что мы замечаем, зависит от словаря, который мы используем
вначале.
Непознаваемое и невыразимое
5
Рис. 1.5. Инь и Янь
При разработке ПО каждый использует собственный вариант для анализа
опыта, полученного в каком-либо проекте. При этом каждый может пасть жерт-
вой общих ошибок.
Кто-то может считать, что фактор влажности имеет решающее значение
для успешной разработки ПО. Соответственно это лицо приложит громадные
усилия, измеряя и контролируя влажность в помещениях, где реализуется про-
ект, и долгое время не будет замечать, что между влажностью и результатами
работы нет значимой взаимосвязи. Поскольку в моем варианте анализа проекта
влажности нет, я не могу сказать, какая влажность была в каждом из моих про-
ектов, как она менялась со временем и как могла быть связана с результатами
работы.
Кто-то может верить, что для успеха проекта крайне важно следовать опре-
деленному процессу. Соответственно это лицо приложит громадные усилия, кон-
тролируя строгое соблюдение этого процесса, и долгое время не будет замечать
отсутствия взаимосвязи между следованием этому процессу и результатами ра-
боты по проекту.
Пренебрегать чем-либо важным при анализе так же плохо, как и обращать
внимание на что-либо, не имеющее отношения к делу. На минуту предположим,
что ученый, проводящий в здании геомагнитные эксперименты, не знает, содер-
жится ли железо в стенах здания. Он не только получит неправильные результа-
ты, но и не поймет, отчего они такие и как нужно изменить условия
эксперимента, чтобы компенсировать это влияние.
Присутствие в проекте людей — это просто такое же решающее для резуль-
татов проекта условие.
Те, у кого в варианте анализа человеческий фактор отсутствует, просто не
заметят влияния людей на их проекты. При чтении статей, описывающих влия-
ние использования конкретного нового процесса (например, Webb 1999), можно
заметить, что в основной части описания участие людей комментируется, но в за-
ключении о людях не говорится ничего. Исследователи, не включающие этот
ключевой элемент в свой рабочий словарь, не могут им пользоваться для на-
стройки результатов своего проекта.
6
Введение
Тот же довод применим к каждому практику, методологу или исследователю,
включая меня. Существует одна причина, почему я 13 лет ждал, прежде чем на-
писать эту книгу. Почти так же, как я обнаружил различие между текстурой и
вкусом в оценке бифштексов, я продолжал открывать новые варианты анализа
для проектов разработки ПО. Результаты использования разных вариантов на-
столько различались, что я не мог довериться ни одному из них.
Теперь, когда я изучаю проект, во мне периодически возникает чувство, что я
не знаю, что именно я не знаю, но должен бы знать — на что я должен был бы
обратить внимание, но не имею соответствующего условия анализа.
В ограниченности наших знаний относительно основных вариантов анализа
нет ничего ненормального. Мир не так уж добр к нам, чтобы заранее снабдить
нас значками инь и янь для использования в каждодневном опыте. Нам не дали
сначала вариант анализа, чтобы затем спрашивать, каков будет результат. Ско-
рее мы приобрели непростой опыт работы с вариантами анализа, при которой
побочные эффекты легко управляют нашим вниманием. Хотя это обстоятельство
может послужить причиной затруднений, оно, естественно, стоит того, чтобы
иногда обдумывать его заново.
Обнаружение вариантов анализа
Моя роль методолога заключается в анализе опыта разработки ПО, который при-
обретается на полном ходу, в выяснении границ анализа и назначении отдельным
частям названий, которые можно будет использовать в следующем проекте. Обна-
ружение этих отличительных признаков и присваивание им имен обеспечивает до-
полнительные фильтры, через которые можно исследовать опыт разработки ПО.
Эта работа не создает новых приемов; она помогает обнаруживать то, что уже про-
исходит в проектах, и снова соединять разрозненные части вместе таким образом,
чтобы они наиболее близко соответствовали будущему опыту.
В последнее время я прошу людей рассказать о проекте какую-либо историю
(желательно что-то работающее, но вообще принимаю любой существенный
эпизод). Затем я смотрю, могу ли я воссоздать эту историю, используя понятия
из проектного опыта, сохранившиеся в моей памяти. Мне это удается все чаще и
чаще. Когда это не получается, я сохраняю историю для более позднего сравне-
ния. Если две истории содержат аналогии, я ищу слова, которые можно исполь-
зовать для обозначения общих частей.
Мы все еще находимся на ранней стадии присваивания имен тому, что в дей-
ствительности происходит с проектами разработки ПО. Это не процесс, не моде-
лирование и не математика, хотя и они играют свои роли. В гораздо большей
степени ответ имеет отношение к мастерству, сообществу, профессиональной
гордости и обучению.
Следующий шаг методолога состоит в сотрудничестве с этнографами, социо-
логами и антропологами для того, чтобы узнать у них слова, фиксирующие другие
части опыта. Из такого партнерства в одном проекте я узнал, что системные ар-
Непознаваемое и невыразимое
7
хитекторы действуют как рассказчики. Они поддерживают жизнеспособность бу-
дущей системы, что особенно ценно в беспорядке начала проекта.
Исследователям и компаниям — разработчикам программных продуктов, кото-
рые хотят научиться работать более эффективно, я решительно рекомендую со-
трудничество со специалистами в социальной сфере.
Небрежные мысли
Мы не замечаем, что находится прямо перед нами, и не можем дать точные назва-
ния тому, что замечаем. Еще хуже: когда мы начинаем общение, то даже не знаем
точно, что именно мы намереваемся сообщить.
В идеальном мире у нас была бы точная мысль, которую мы хотели бы сооб-
щить, и наша работа состояла бы лишь в подборе слов, необходимых для переда-
чи этой мысли. Однако обычно то, что мы хотим выразить, забивается в щель
между всеми словами, которыми мы обладаем. Мы используем различные слова,
двигая их по кругу, пытаясь заставить их выразить, что, как нам кажется, мы на-
мереваемся сказать.
В некоторых случаях наша идея даже недоступна сознательному мышлению.
Эта идея — лишь ощущение, что какая-то такая идея здесь должна быть. Выска-
зываясь, мы пытаемся нащупать ее внутри себя и надеемся, что некий набор
предложений, произнесенный нами, извлечет мысль, которую нам хотелось бы
сообщить партнерам по разговору.
Посмотрите, как много слов вам требуется, чтобы высказать мысль, и заме-
тьте: вы выразили не то, что хотели, и, вполне возможно, хотели сказать вовсе не
то, что чувствовали.
Из этого следуют выводы и для проектирования, и для коммуникации.
В книге Sketches of Thought Вайнод Гоел (Vinod Goel, 1995) исследует
идею о полезности умственной работы, происходящей в сфере неточной мыс-
ли, в области прото-мыслей об идеях, границы которых еще не установлены
мозгом.
Участники исследования обсуждали ущерб, нанесенный развивающейся
идее, когда неразграниченные мысли принудительно слишком рано становились
точным высказыванием. Заданная работа может выполняться наилучшим обра-
зом, в то время как прото-мысли еще не разграничены.
Два участника жаловались на работу с точными изображениями: “Вы почти
фиксируете что-то, а затем уже понимаете, нравится вам это или нет” и “Я дол-
жен заранее решить, что я хочу, прежде чем смогу это нарисовать” (Goel, стр.
200). Один человек сказал:
“Чувствуешь, что вся работа выполняется внутренне и затем записы-
вается системой символов другого типа, вероятно потому, что внеш-
няя система символов не может поддерживать такие операции” (Goel,
стр. 200).
8
Введение
Пелле Эн (Pelle Ehn) описывает аналогичным образом создание ПО. Осоз-
нав, что ни пользователи, ни проектировщики не могут адекватно идентифициро-
вать и анализировать свой опыт, он попросил их “проектировать действием”
(design by doing). В своей статье (см. приложение В) он пишет:
“Языковые игры при проектировании действием можно оценивать как
с точки зрения пользователей, так и с точки зрения проектировщиков.
Этот тип проектирования становится языковой игрой, в которой поль-
зователи узнают возможности и ограничения новых компьютерных ин-
струментов, могущих стать частью их обычных языковых игр.
Проектировщики становятся педагогами, которые обучают пользова-
телей этой конкретной языковой игре в проектирование. Однако, что-
бы создать такого рода языковые игры, проектировщики, в свою
очередь, должны учиться у пользователей.
Тем не менее, как ни парадоксально это звучит, пользователи и проек-
тировщики, играя вместе, не должны полностью понимать друг друга.
Участие в языковой игре и использование элементов проектирования
могут иметь разный смысл для пользователей и проектировщиков".
Это подводит нас почти к самой границе незнания: мы не замечаем того, что
находится прямо перед нами, а для того, что мы замечаем, у нас нет соответству-
ющих названий. При этом, собираясь обменяться информацией, мы не можем
определить точно, что именно хотим сообщить. И что еще хуже — может вообще
отсутствовать возможность передать наше сообщение.
Невозможность коммуникации
Этой легкой гримаской, едва уловимой,
ты послала мне через обеденный стол
массу сведений, важных, понятных,
но остались в неведенье все вокруг нас.
Так же и вчера ты скривила губы,
показывая отношение к тому парню,
что вел себя недопустимо нагло, хотя
ты, как могла, старалась быть милой.
Я полностью согласен.
На самом деле, пожалуй, он напоминает
мужчину слева от тебя.
Я чуть приподнял бровь
и стрельнул взглядом в его сторону.
Как ни в чем ни бывало, ты продолжала есть,
Непознаваемое и невыразимое
9
но слегка затвердевшая верхняя губка
ясно выразила твое одобрение.
Ох, похоже, нас выследили.
Ну и пусть!
Диалог наш замечен, но так и не понят,
ничего он не значит для других.
А бедняга (тот, слева) навсегда обречен носить
навешенный ему ярлык
в этом коротком разговоре.
— Алистер Коберн, 1986
Каково информационное содержание поднятой брови?
Не ищите ответа в статьях Клода Шеннона по теории информации (Shannon,
1963). Он анализировал ограниченные каналы (constrained channels), в которых
словарь коммуникации известен заранее. В реальной коммуникации канал не
имеет ограничений. Когда именно вы поднимете бровь и поднимете ли ее вообще,
не известно заранее. “Но слегка затвердевшая верхняя губка” — это изобрете-
ние, связанное с совместным опытом (shared experience), имеющимся у вас с
партнером по разговору. В приведенном выше стихотворении партнер обладал
этим совместным опытом, а наблюдатель — нет. И поэтому наблюдатель не уз-
нал того же самого информационного содержания, которое получил партнер.
Биологи Матурана (Maturana) и Варела (Varela) исследовали этот вопрос
в контексте биологических систем. Их результаты описаны в следующем тексте
из книги The Tree of Knowledge (Maturana 1998, стр. 196):
“Наше исследование позволило сделать вывод, что биологически в ком-
муникации не существует ’’передаваемой информации". Общение про-
исходит всякий раз при поведенческой согласованности в сфере
структурной связности. Этот выводудивляет, только если мы не наста-
иваем на рассмотрении самой последней метафоры для коммуника-
ции... [согласно которой] коммуникация — это нечто, порожденное в
определенной точке. Она переносится по каналу (или трубе) и достав-
ляется получателю на другой стороне. Значит, существует нечто, что
сообщается, и это нечто является неотъемлемой частью того, что пе-
ремещается в этой трубе. Так мы обычно говорим об “информации”,
заключенной в картине, объекте или, более очевидный пример, в пе-
чатном слове... В соответствии с нашим анализом эта метафора в
основном ложна... Каждое лицо слышит то, что оно слышит, согласно
его собственному структурному представлению... Феномен коммуни-
кации зависит не от того, что передается, а что происходит с лицом, по-
лучающим это. И это совсем не то же самое, что “передача
информации”.
10
Введение
Выражаясь проще, хотя, возможно, менее точно биологически, каждое живое
существо существует внутри оболочки, превращающей бомбардирующие ее собы-
тия во внутренние сигналы, инициирующие внутреннюю активность. На самом
деле существо “замечает” только внутренние сигналы, но не внешние. Удивитель-
но, что внутренние сигналы могут также порождаться активностью и событиями
внутри этого существа!
Замечая что-то, существо не может быть уверено, возникает ли это от внут-
реннего или внешнего сигнала. Так, мы “видим” образы во снах и галлюцинаци-
ях, когда наши глаза закрыты. Матурана и Варела исследовали этот эффект в
цветном зрении и обнаружили, что мы регулярно видим цвет в обстановке, кото-
рая не содержит явно этого цвета. Мы порождаем присутствие этого цвета через
внутренние механизмы.
“Поведенческая согласованность в сфере структурной связанности” — это
взаимосвязь между такими вещами, которые бомбардируют оболочку снаружи, и
последующей внутренней активностью. Очевидно, мы не сохранились бы как
живые существа так долго, если бы не существовало достаточно хорошей взаимо-
связи между внешними событиями и порожденной внутренней активностью. Одна-
ко важно осознать, что внутренняя активность в равной степени определяется
внутренним состоянием существа, его “собственным структурным представлени-
ем”. Полученная информация — это не то, что бомбардирует получателя, а то,
что потом происходит внутри получателя.
Рассмотрим это на конкретном примере. Предположим, что кто-то вбегает в
комнату и кричит “Пожар!” по-японски. Слушатель, понимающий японский
язык, получает существенную информацию, немедленно вскакивает на ноги и
выбегает из комнаты. Находящийся рядом с ним японец спит и не получает ника-
кой информации. Внешнее воздействие никак не преобразовалось во внутренний
сигнал. Лицо, не говорящее по-японски, замечает, что кто-то вошел и что-то
прокричал, но из произнесенных звуков не получает никакой конкретной инфор-
мации. Получение каждым лицом информации от звуков зависит от внутреннего
состояния данного лица.
Внутренняя реструктуризация
Информация на стороне получателя является не статической, внешне определяе-
мой величиной, а в большей степени величиной переменной, динамической, инди-
видуальной. Полученная информация — это мера внутренней реструктуризации,
следующей за звуком сигнала. Эта величина представляет масштаб изменений,
происходящих в прогнозирующей модели мира адресата после получения инфор-
мации.
Рассмотрим несколько примеров, чтобы увидеть это в действии. Говорящий
произносит:
“Я думаю о ряде чисел. Этот ряд включает 1, 3, 7, 11, 13,...”
Непознаваемое и невыразимое
11
В этот момент слушатель построил прогнозирующую модель, в которой хра-
нятся эти числа. Они образуют ряд, и числа 5 и 9, очевидно, пропущены. Они
явно пропущены, и поэтому обычно человек строит вторую модель рядом с пер-
вой: “нечетные числа без 5 и 9".
Говорящий продолжает:
"... в этом ряду содержится 15...”
После этих слов модель растет на один элемент: “в этом ряду содержится
15". Никакие новые образцы не появляются.
Говорящий продолжает:
“... в этом ряду содержатся 5 и 9...”
В это мгновение модель разительно изменяется, поскольку предложение со-
держит много “информации” для слушателя, гораздо больше, чем при предыду-
щем появлении числа 15. Вместо включения еще двух значений в перечень
чисел, входящих в ряд, слушатель преобразует модель к более простому виду —
“нечетное числа”. Сведения о вхождении в ряд чисел 5 и 9 добавили больше, чем
просто две небольшие единицы информации: они превратили две конкурирую-
щие модели среднего размера в одну маленькую модель. Изменение в размере
прогнозирующей модели было довольно значительным.
“Полученная информация”, будучи мерой моментальных изменений в получа-
теле, является переменной величиной. Прослушанное второй раз то же самое
предложение не несет той же информации. Обычно внутренняя прогнозирующая
модель не изменяется сильно, поскольку реструктуризация, как правило, меньше.
Предположим, говорящий повторяет:
“... в этом ряду содержатся 5 и 9...”
Слушатель уже знает, что 5 и 9 содержатся в ряду. В этот момент говорящий
может продолжать называть нечетные числа, не нарушая прогнозирующую мо-
дель слушателя. Каждое новое число увеличивает уверенность в модели, но не
более того.
Если говорящий называет четное число, то слушатель в панике пытается
припомнить, какие числа назывались. Он должен отбросить модель “нечетных
чисел” и снова вспомнить отдельно каждое число. Момент добавления четного
числа дает слушателю очень много информации.
Соприкосновение в совместном опыте
Как же узнать, какое сообщение получает ваш слушатель? В разговоре он отвеча-
ет вам, и вы убеждаете себя, что он действительно понимает подразумеваемое со-
общение (по крайней мере, довольно близко).
12
Введение
Конечно, иногда вы неправильно понимаете его ответ и приходите к ложному
заключению, что он понимает вас. Когда в конце концов вы это обнаруживаете,
вы восклицаете: “Но я думал, что выразился ясно”!
Успех общения, таким образом, заключен в наличии у отправителя и получа-
теля совместного опыта, на который можно сослаться.
Гримаса в магазине
Вчера, когда мы с тобой были в магазине, я поморщился, услышав за-
мечание продавца. Сегодня я сделал ту же гримасу, и тебе вспомни-
лась ситуация с продавцом. Сравнив настоящий момент со вчерашним
происшествием, ты обнаружил общность между ними и перенес вче-
рашнее эмоциональное состояние на сегодняшнюю ситуацию. Ты по-
нял, что я подразумеваю, поскольку мы оба помним о той гримасе.
. Когда вы обладаете опытом, в достаточной степени общим с другим лицом,
вам требуется всего лишь повторно пробудить в нем этот опыт. Когда вы сталки-
ваетесь со вторым опытом, следующим почти подряд, вы связываете первый со
вторым и создаете новую информацию. Учет этих двух опытов, как имеющих отно-
шение к данному моменту, становится новым, совместным опытом для вас обоих,
таким, на который позднее вы сможете сослаться. Таким способом люди сообща
строят понемногу новые представления, создавая новые точки соприкосновения из
известного опыта. Человеку, присоединившемуся к разговору в его конце, не хва-
тает этих промежуточных точек соприкосновения, и, чтобы “быстро войти в курс”
и понять, о чем идет речь, ему требуется получить достаточное число таких точек.
Число этих точек соприкосновения множится по мере того, как лицо разви-
вает свой опыт, переходя от новичка к младшему партнеру, эксперту и в конце
концов к работающему партнеру.
Новички посещают лекции по программированию, где они знакомятся с на-
чальным глоссарием, на котором будет построено все остальное. Они изучают
стандартную нотацию и простые идиомы, создающие точки соприкосновения для
низкоуровневых элементов проектирования. Те, кто изучает объектно-ориенти-
рованное проектирование, на ранней стадии приобретают знания о создании про-
изводных классов и полиморфизме, затем они знакомятся с диаграммами
последовательности, кардинальным числом и, возможно, несколькими образца-
ми проектирования (Gamma, 1995). Опытное лицо, пытаясь объяснить конст-
рукцию новичку с минимальным опытом, может использовать лишь эти
низкоуровневые термины. Опытный проектировщик обычно считает это нудным
и лишенным общего замысла занятием.
Младший программист присоединяется к ряду проектов, поэтапно создавая
общий словарь и идеи. Опытное лицо, описывающее конструкцию лицу, находя-
щемуся на этой ступени, может сделать обзор какого-то исходного кода, совмест-
но разработать программу, разыграть ролевую игру с несколькими индексными
карточками, нарисовать различные UML-диаграммы и во время разговора на-
Непознаваемое и невыразимое
13
чертить на белой доске какие-нибудь условные каракули. Опытное лицо помога-
ет младшему лицу создавать другой словарь, и оба они формируют совместный
опыт, на который позднее будут ссылаться.
Два опытных программиста, не участвовавших вместе в одних проектах, ссы-
лаются на общие, продвинутые идиомы проектирования. Их беседа может вклю-
чать такие фрагменты: “...просто используй здесь Composite, а в горизонтальном
представлении Decorator”, “...установи их как h-файлы, но подключить не за-
будь...” и т.д. Через крупные элементы описания, рисуя на белой доске, можно
передать понимание структуры проекта и, скорее всего, осуществить замысел.
Программисты, проработавшие вместе годы, имеют гораздо больше точек
соприкосновения. Их описания требований и проекта могут быть очень кратки-
ми, построенными на ссылках на предыдущие проекты: “...Это та же псевдо-DNA
структура, которую мы использовали для проекта Fox, но на этот раз разделяю-
щая...” Сокращенные выражения позволяют общаться и продвигаться со скоро-
стью, невозможной при работе с посторонними людьми, хотя бы и очень
опытными. Такие выражения способны гораздо лучше передавать намерения в
отношении работы.
В профессиональной жизни у людей нет времени на полную реконструкцию
словаря всякий раз, когда им нужно общаться. Они определяют самый высокий
уровень совместного опыта и от него строят новый опыт. Но никогда они не могут
быть уверены, что слушатель действительно понимает то, что подразумевается.
Справляясь с несовершенством коммуникации
Коммуникация никогда не бывает совершенной и полной. Такое просто невозмож-
но. Даже если предположить на мгновение, что вы сами знаете, что имеете в виду,
получатели сообщения должны в какой-то момент перепрыгнуть через расщелину,
причем прыгать они должны абсолютно самостоятельно.
Люди со схожим опытом могут перепрыгнуть через широкую расщелину, по-
льзуясь только мычанием и жестами.
Чем больше другое лицо отличается от вас, тем уже расщелина в коммуни-
кации, через которую оно способно перепрыгнуть. Вы должны повторяться, объ-
яснять основные понятия и затем продолжать, пока оно не построит из этого
опыта собственный мост и не поймет, о чем вы говорите.
Этим повторам нет конца. Не имеет значения, сколько раз вы будете возвра-
щаться назад, все равно найдется кто-то, не понимающий вас.
Напрашивается ирония: в компьютерной индустрии мы пишем специфика-
ции и проектные документы, будто в самом деле можем объяснить, что мы подра-
зумеваем. Не можем. Никогда не стоит надеяться полностью специфицировать
требования или проект.
Мы должны предположить, что читатель обладает определенным уровнем
опыта. При наличии у него большего опыта можно написать меньше. Если пред-
полагается наличие незначительного опыта, мы должны написать больше.
14
Введение
Российские программисты
Ко мне обратилась одна группа из американской фирмы, заключив-
шая договор на разработку ПО с российской компанией. Они хоте-
ли, чтобы я их научил, как написать варианты использования для
российских программистов, не очень хорошо знающих английский
язык и предметную область.
Я ответил: "Вы не можете рассчитывать, что научите их предмету по
документу, описывающему требования. Сначала научите их этому
предмету, а затем напишите краткие требования, обращаясь к ко-
му-либо, хорошо осведомленному в этой предметной области".
В течение нескольких часов они пытались заставить меня раскрыть
секрет общения через эту огромную расщелину и наконец призна-
лись, что прежде работали (и успешно), просто помещая главных
специалистов в одну комнату. Они надеялись, что у меня есть спо-
соб сообщить требования через океан только с помощью вариантов
использования.
В конце концов они усовершенствовали мое предложение. Они напи-
сали краткий документ с требованиями для своих экспертов в этой
области, а затем отправили одного из этих экспертов в Россию, что-
бы объяснить требования и вообще обеспечить правильное выполне-
ние задачи программистами.
Эксперт в предметной области смог ликвидировать значительный разрыв,
представленный кратким документом с описаниями вариантов использования,
а затем выработать только необходимую коммуникацию и сократить размер
расщелины настолько, чтобы российские программисты смогли ее преодолеть.
Эксперт в предметной области не пытался организовать совершенную комму-
никацию. Он справился с неполнотой коммуникации, лично взаимодействуя с про-
граммистами и наблюдая за результатами их работы. Люк Хоманн (1997) называет
такой подход “сокращением двусмысленности” в коммуникации.
Эксперт понял, что ему не нужно было снижать двусмысленность до нуля.
Он должен был лишь сократить ее до такой степени, чтобы российские програм-
мисты могли предпринять осмысленные действия.
Так как полная коммуникация невозможна, для реализации проекта требует-
ся не пытаться достичь ее полноты, а лишь справиться с неполнотой.
Цель состоит в достаточном сокращении двусмысленности, чтобы стало воз-
можным соответствующее действие. Это значит, нужно догадаться, что именно
необходимо, где именно остановиться, когда и как уменьшать расщелины и как
помочь получателям перепрыгнуть широкие расщелины.
Программные проекты испытывают недостаток во времени и деньгах, а для
уменьшения расщелин требуется и то и другое. Вы должны определить, насколь-
ко широкая расщелина для вас приемлема, с какой двусмысленностью вы готовы
примириться, чтобы на этом остановиться.
Непознаваемое и невыразимое
15
Три уровня понимания
Изучая и усваивая новые навыки, люди проходят через три довольно разные стадии
поведения: следование (following), отделение (detaching) и беглость (fluent).
В стадии следования люди ищут одну работающую процедуру. Даже если де-
сять процедур могут работать, они не могут научиться всем десяти сразу. Сначала
им нужно освоить одну — одну работающую. Они ее копируют, они ее изучают.
На этой стадии практики успех измеряется следующим образом: (а) работает ли
эта процедура, (б) насколько хорошо они могут выполнить эту процедуру.
Устройство считывания перфокарт 1708
Мы наблюдали за первой встречей студентки, специализирующейся
в гуманитарных науках, с устройством считывания перфокарт Univac
1708 (шел 1974 год).
Ее небольшая программа не компилировалась. Расстроенная неуда-
чей, она попросила помощи у ассистента-студента. Когда компиля-
ция программы и во второй раз завершилась с ошибками, с ней
случилась почти истерика, и она в слезах прокричала ассистенту: "Но
ты же обещал, что она будет работать!"
Это типичная реакция на первой стадии изучения. Вознаграждение за успех
на этой первой стадии обычно звучит так: “Наконец-то эта штука заработала”
или “По крайней мере, я могу с ней справиться”.
Переходя в область, требующую новых навыков, будь то программирование
или что-то другое, люди хотят получить явно выраженные инструкции. В терми-
нах методологий разработки ПО это означает толстое подробное руководство.
Толщина руководства и подробность воспринимаются как признаки надежного
обучения.
На стадии отделения, или на втором уровне, люди обнаруживают ограниче-
ния в единственной процедуре и ищут правила, чтобы определить, когда эта про-
цедура перестает работать. Фактически, они находятся на первой стадии нового
обучения, а именно: они изучают пределы этой процедуры. Лицо на стадии отде-
ления учится приспосабливать процедуру к изменяющимся обстоятельствам. Те-
перь оно более заинтересовано в изучении десяти альтернативных процедур; оно
хочет узнать, когда лучше применять каждую из них и когда каждая из них пере-
стает работать.
Такого сорта широкомасштабный кризис технических приемов случился в
нашей отрасли, когда крупные фирмы, производящие ПО, прекрасно приспосо-
бившиеся к разработке с использованием информационной инженерии (Informa-
tion Engineering, IE), должны были перейти на производство объектно-ориен-
тированного ПО. Потратив годы на безуспешные попытки адаптации IE-мето-
дов, они должны были создать абсолютно новые методологии разработки, часто
двигаясь вспять через довольно хаотические построения, пока не нашли новые
16
Введение
структуры, поддерживающие новые проекты. Большинство этих организаций те-
перь имеют две методологии: одну для IE, а другую для объектно-ориентирован-
ной разработки.
На третьей стадии, стадии беглости, для исполнителя несущественно, испо-
льзует ли он какие-либо конкретные приемы или нет. Его знания стали всеобъ-
емлющими под влиянием тысяч мыслей и действий. Спросите у него, следует ли
он определенной процедуре, и он, вполне вероятно, пожмет плечами: для него не
имеет значения, следовать ли процедуре, импровизировать с ней или создавать
новую процедуру. Он понимает желаемый конечный эффект и просто проклады-
вает свой путь к этой цели.
Руководитель группы, который вел несколько проектов в различных облас-
тях, больше не заботится о “методологии”: “Просто оставьте нас в покое, и мы
это сделаем”, — говорит он. Он наблюдает и чувствует, что здесь нужно больше
дисциплины, там больше свободы, в каком-то другом месте — больше коммуни-
кации. Это практик третьего уровня.
Три уровня и методологии
Те же уровни применимы к изучению, наставничеству или чтению литературы о
разработке ПО. Важно соблюдать все три уровня, что иллюстрирует следующая
история.
Путаница в уровнях с CRC-картами
Не подозревая о существовании этих уровней, мы втроем непреду-
мышленно перешли на неверный уровень, когда были назначены на
нацц первый проект. Мы решили проводить короткие совещания по
проекту, используя карты "класс-обязанность-сотрудничество"
(Class-Responsibility-Collaborator, CRC, см. Beck, 1989).
Мы все трое работали немного по-разному, что расстраивало раз-
работчиков — новичков в объектно-ориентированном проектирова-
нии. Они говорили: “Каждый из вас делает что-то другое! Кто из вас
прав, и почему бы остальным не делать то же самое?!"
Мы пытались отвечать: "Это не имеет значения. Главное, что все ра-
ботает". Но это не помогло запутавшимся новичкам: должны ли они
поднимать карты вверх или оставлять их на столе? Нужно ли записы-
вать все переменные экземпляров, или лишь некоторые, или ника-
кие? И все в таком духе.
Мы знали, что наши совещания могут работать при использовании
любого из вариантов, но начинающие все еще находились на первом
уровне и нуждались в одном определенном способе работы, кото-
рый они могли бы применять несколько раз подряд.
Книга по программированию, предназначенная для аудитории первого уров-
ня, должна убедить читателя, что действительно существует способ создания ра-
Непознаваемое и невыразимое
17
ботающей программы, и если читатель будет просто ему следовать, то успех ему
гарантирован. Такая книга может называться “Наука программирования” (The
Science of Programming, Gries, 1981) или “Обучение программной инжене-
рии” (A Discipline for Software Engineering, Humphrey, 1995).
Методологические тексты, предназначенные для аудитории первого уровня,
детально описывают процессы, приемы и стандарты. Для практиков первого
уровня подходят очень подробные шаблоны в Rational Unified Process (RUP).
Под эту категорию подпадают серьезные методологии Andersen Consulting, Ernst
& Young и других фирм.
Книга по программированию, адресованная аудитории второго уровня, мо-
жет называться “Искусство компьютерного программирования” (The Art of
Computer Programming, Knuth, 1997). В ней читателю должно быть показано не-
сколько приемов работы с примерами и примечаниями о том, когда и какой из
них более полезен.
Книга, предназначенная для смешанной аудитории второго и третьего уров-
ней, может называться “Интуитивное программирование” (The Laissez-Faire
of Programming, можете считать это альтернативным названием нашей книги)
или “Практичный программист” (The Pragmatic Programmer, Hunt, 2000).
Она должна определить вопросы, которые следует держать в уме, и приемы, ко-
торые практик при необходимости может освоить, а затем взять на вооружение
или отложить в сторону. Эксперт найдет в этой книге полезное собрание идей, но
начинающему будет недоставать конкретных правил.
Слушатель третьего уровня знает, что все опубликованные методы разра-
ботки ПО индивидуальны и в какой-то степени произвольны. Обсуждения среди
людей, принадлежащих к третьему уровню, мучительно напоминают принципы
“дзен”:
“Делай все, что работает”.
“Когда ты это действительно делаешь, то и не подозреваешь об этом”.
“Используй прием, если он в чем-то хорош”.
Для кого-либо, принадлежащего к беглому уровню поведения, все это верно.
Кого-то с уровнем отделения это сбивает с толку. Для тех, кто ищет процедуру,
которой можно следовать, это бесполезно.
Моя книга Writing Effective Use Cases (Cockburn, 2001c) посвящена техно-
логии, и в ней содержится информация для читателей всех трех уровней.
Для практиков первого уровня, начавших писать варианты использования,
она опускается до мелочей, им даются конкретные процедуры, которым можно
следовать. Для практиков второго уровня книга содержит правила и рекоменда-
ции по варьированию базовых правил. В ней нет попыток научить чему-либо осо-
бому читателя третьего уровня, но так или иначе он найдет в ней что-то новое,
18
Введение
что можно будет однажды попробовать. Кроме того, прочитав эту книгу, он убе-
дится, что правила не связывают, а многие способы работы могут быть эффек-
тивны.
Книга позволяет читателю первого уровня получить конкретный совет, чита-
телю второго уровня — узнать границы правил, а читателю третьего уровня —
двигаться свободно.
Один из элементов семейства методологий Crystal называется Crystal Clear.
Для слушателя третьего уровня он может быть описан следующими словами:
“Поместите от четырех до шести человек в комнату с рабочими станциями,
белыми досками и доступом к пользователям. Убедите их производить для поль-
зователей работающие, протестированные программы каждые один-два месяца,
во всем остальном оставьте их в покое”.
Я на самом деле описал Crystal Clear этими словами одному смышленому
спонсору проекта. Он последовал этим инструкциям и спустя пять месяцев сооб-
щил: “Мы сделали, что вы сказали, и это сработало!”
Еще через несколько месяцев я проинтервьюировал руководителя группы, и
его отчет оказался почти таким же кратким, как мои инструкции:
“Следуя вашему предложению, четыре человека разместились в конфе-
ренц-зале, располагающем сетевыми соединениями. Мы занимали его все четы-
ре месяца, рисуя на белых досках и программируя. Это сработало здорово”.
Если вы опытный разработчик ПО и можете применить эти инструкции, то
вам не требуется читать всю книгу, названную Crystal Clear. Однако если вы или
ваш спонсор не находитесь на этой стадии, вам потребуется прочитать всю книгу
полностью. В этом тексте детально описаны ключевые технологии, демонстриру-
ются используемые принципы, рассматривается зона применимости данной ми-
нималистской методологии и приводятся способы выхода из Crystal Clear, когда
проект перемещается из зоны применимости.
Из всего этого следует вынести один урок: если вы читаете методологиче-
ские тексты, находясь на первом уровне, количество технологий и принципов,
которые нужно усвоить, не должно приводить вас в уныние. Желание видеть мир
настолько простым, чтобы одной технологии программирования было достаточ-
но — это напрасное желание. Наймите сотрудника, находящегося на втором или
третьем уровне.
Если вы читаете методологические тексты, находясь на втором уровне, обра-
щайте внимание на альтернативные приемы и ищите места, где их можно изме-
нять.
Если вы читаете тексты по методологии, находясь на третьем уровне, осознай-
те постоянную необходимость определения методологии на первом уровне. В этой
области всегда будут появляться новые люди, которым поначалу потребуется
дать явное направление, даже если вам оно не нужно.
Кент Бек, автор книги Extreme Programming Explained (Beck, 2000), опи-
сал использование экстремального программирования (ХР) с помощью анало-
Непознаваемое и невыразимое
19
гичных уровней. Когда его спросили об ХР и пяти уровнях модели Capability
Maturity Model, разработанной в Software Engineering Institute, он в ответ на-
звал три уровня зрелости ХР:
1. Делайте все, как написано.
2. Сделав это, экспериментируйте с изменениями в правилах.
3. В конце концов не обращайте внимания, используете ли вы
ХР или нет.
Три уровня и эта книга
Эта книга адресована главным образом читателям второго и третьего уровней.
Она сможет немногое предложить программисту-практику первого уровня, ищу-
щему простую процедуру, чтобы ей следовать. На самом деле ключевой момент со-
стоит в том, что все методологии имеют ограничения — области, в которых они
более или менее применимы. Невозможно назвать один самый лучший способ раз-
работки ПО. Книга поможет вам достичь этого понимания и приведет к действен-
ным идеям о том, как справиться с реальной ситуацией. В этом смысле книга
нацелена на перемещение читателей со второго на третий уровень.
Темы для читателей второго уровня содержат эвристические правила для
выбора базовой методологии проекта и идеи, стоящие за методологиями быстрой
разработки ПО.
Если вы — читатель третьего уровня, то, я надеюсь, вы найдете слова, кото-
рые помогут выразить то, что вы уже знаете.
Несколько тем книги, вероятно, будут новыми даже для опытных разработ-
чиков. Большинство людей принадлежат к первому уровню, когда речь заходит о
словаре для описания методологий и своевременной настройке методологии. По-
этому они описываются более подробно.
Shu-Ha-Ri
Три уровня практики известны в других областях, требующих навыков. В айкидо
они называются shu, ha и ri (что приблизительно переводится как учиться, от-
делять и превосходить). Чтобы разыскать информацию о shu-ha-ri, вы можете
начать с поиска в Интернете или по адресу: www.aikidofaq.com/essays/tin/shuha-
ri.html. Следующий отрывок взят из статьи “Shu На Ri” Рона Фокса (Ron Fox,
1995), опубликованной на этом сайте. (В этом отрывке в квадратных скобках при-
ведены ссылки, указанные Роном Фоксом в его статье.) Меня приводит в восторг,
как это изображение столь точно иллюстрирует нашу давнишнюю ошибочную по-
пытку научить проектированию при помощи CRC-карт.
“Shu, или Мамору, означает держать, защищать, хранить или поддерживать
[ 1 ]. В фазе Shu учащийся строит технический фундамент искусства. Shu также по-
дразумевает верность или постоянство в отношении единственного ruy или, в со-
20
Введение
временной интерпретации, единственного учителя [2]. В Shu учащийся должен
работать, чтобы копировать приемы, как его учили, без изменений, не пытаясь
пока прикладывать какие-либо усилия, чтобы понять подоплеку техники шко-
лы/учителя [3]. Таким способом строится прочный технический фундамент, на
котором может базироваться более глубокое понимание искусства.
Сущность Shu заключается в том, что прочный специальный фундамент
наиболее эффективно можно создать, следуя к этой цели одним единственным
путем. Общение-с другими школами до постижения того, на что в действитель-
ности вы способны, — это приглашение ступить на неверный путь. Путь, на ко-
тором технические приемы развиваются, не будет иметь устойчивой
теоретической или практической ценности. В традиционной интерпретации ста-
дии Shu не учащийся, а учитель решает, когда переходить от Shu к На. От уча-
щегося требуется следовать наставлениям учителя, пока пустой сосуд не
наполнится [ 1 ].
На — вторая стадия процесса. Она означает некоторое отделение учащегося
от традиций шу [2]. На стадии На учащийся должен размышлять о значении и
цели всего, что он изучил, и, таким образом, прийти к более глубокому понима-
нию своего искусства, невозможному при следовании практике чистого повторе-
ния. На этой стадии, поскольку каждый прием был основательно изучен и впитан
мускульной памятью, учащийся готов задуматься о том, что стоит за этими прие-
мами [3]. Стадию На можно сравнить с этапом в учебном заведении, на котором
студент обладает достаточным количеством базовой информации, чтобы присту-
пить к написанию исследовательских работ обзорного характера.
Ri означает продвигаться дальше или превосходить. На этой стадии учащий-
ся перестает быть таковым в обычном смысле, а становится практиком. Практик
должен мыслить оригинально, развивать из накопленного опыта оригинальные
мысли о своем искусстве и проверять их на собственных знаниях и заключениях,
а также на требованиях повседневной жизни. На стадии Ri искусство в самом
деле становится для практика своим и даже в какой-то мере создается практи-
ком. В учебных заведениях этой стадии соответствует степень доктора филосо-
фии или более высокое звание.
[1] Kuroda, Ichitaro, ‘Shu-Ha-Ri’ в Sempo Spring, pp. 9-10, 1994.
[2] McCarthy, Patrick, ‘The World within Karate & Kinjo Hiroshi’
в Journal of Asian Martial Arts, V. 3 No. 2, 1994.
[3] Private conversations with Nakamura, L. Sensei Toronto.
Spring, 1994".
С фундаментом, построенным на трех этапах обучения, мы продолжим раз-
гадывать тайну, как вообще возможно что-либо передать при общении и что это
предвещает для разработки ПО.
Непознаваемое и невыразимое
21
Что дольше?
Секрет заключается в том, что мы не можем добиться совершенной коммуника-
ции. А его разгадка такова: совершенная коммуникация нам и не требуется. Про-
сто очень часто нам бывает нужно подойти к ней достаточно близко.
Чтобы лучше понять идеи этой главы, подумайте, каким должен быть чело-
век, способный понять проект вашей системы по доступной проектной докумен-
тации.
Обратите внимание на следующие виды событий, возникающих при комму-
никации:
Окружающие вас люди пребывают в счастливом неведении, пропуская
смысл, передаваемый ими при общении друг с другом. Заметьте, как часто,
тем не менее, им удается с этим справиться.
Кто-то дает вам чересчур туманные инструкции, и поэтому вы не можете
уловить смысл.
Кто-то дает вам слишком подробные инструкции — настолько подробные,
что вы не можете их воспринять.
На совещании люди разговаривают, пользуясь разными словарями, и до-
стигают соприкосновения через различный опыт.
Люди разных профессий опираются на очень разный совместный опыт, что-
бы экономно передать информацию.
У вас за спиной официант записывает инструкцию для повара, пока вы за-
казываете завтрак из “двух яиц, слегка поджаренных, картошки с луком,
цельного пшеничного тоста, кофе”. Попросите показать листок с заказом.
Вероятно, он написал что-нибудь вроде “№3 сп. цп. (меню №3, слегка под-
жарить, цельный пшеничный).
Насколько было бы неэффективно, если бы каждый человек должен был
разбивать свое сообщение на элементы, понятные каждому прохожему.
Обратите внимание на уровень вашего чтения различных частей нашей книги.
Если вы читали эту главу, будучи на первом уровне, привыкните к мысли,
что проектные документы не содержат всей информации о проекте, а опытные
разработчики общаются скорописью.
Если вы читали эту главу, находясь на втором уровне, поэкспериментируйте,
попытайтесь выразить проект вашей системы с использованием UML, образцов
проектирования и ссылок на предыдущие проекты. Понаблюдайте, как это влияет
на ваших коллег, и заметьте, на каких уровнях они действуют при обсуждениях.
Если вы — читатель третьего уровня, попробуйте сообщить эти идеи ко-
му-либо еще.
Глава 1
Кооперативная игра
в изобретения и коммуникации
Полезно представить себе разработку ПО как кооперативную игру в изобретения
и коммуникации.
В первом разделе задается вопрос: “Каков был бы опыт разработки ПО,
если бы мы разрабатывали не программы, а что-то другое?” Задача этого разде-
ла — отойти на некоторое расстояние от предмета, чтобы исследовать иные пути
его обсуждения.
Во втором разделе дается обзор широкого спектра видов деятельности, на-
зываемых играми, и определяется место в этом спектре для разработки ПО. Если
вам уже хорошо знакомы игры с нулевой суммой, позиционные, кооперативные,
конечные и бесконечные игры, то вы можете быстро пролистать первую часть
этого раздела. Далее разработка ПО сравнивается с другой командно-коопера-
тивной игрой — альпинизмом и с двумя общими участниками сравнения — ин-
женерией и построением моделей.
В третьем разделе идея о разработке ПО как о кооперативной игре в изобре-
тения и коммуникации исследуется более тщательно. Рассматривается главная
цель игры — выпуск работающего ПО и вспомогательная цель — подготовка к
следующей игре. Следующая игра состоит в изменении или замене системы или в
создании похожей системы.
Последний раздел главы связан с идеями, взятыми из повседневной жизни.
Программное обеспечение и поэзия
А если бы разработка ПО была на самом деле разработкой чего-то иного? Тогда
чем бы это могло быть и каким был бы приобретаемый опыт? Я полагаю, что это
похоже на совместное сочинение эпической поэмы. Такое предположение я делаю
потому, что, вероятно, у вас отсутствует опыт участия в совместном сочинении сти-
24
Глава 1
хов. Воображение подскажет вам все виды противоречий, которые я при этом за-
интересован вызвать.
Представьте себе 50 человек, собравшихся вместе, чтобы написать эпичес-
кую поэму в 20 тысяч строк за определенные деньги и определенное время. Что
же вы здесь обнаружите? Прежде всего, многочисленные споры. Люди пытаются
творить, стараются сделать все от них зависящее, не имея необходимого таланта,
времени и возможностей.
Кто участвует в этой драме? Во-первых, те, кто заказал поэму. Чего они хо-
тят? Они хотят развлечься, произвести впечатление на друзей, и для этого им
нужно что-то не слишком дорогое, причем быстро.
Далее имеются ключевые проектировщики поэмы.
Как вы можете вообразить, эта работа начиналась с проекта для одного
лица. Но наша мифическая поэтесса обнаружила, что пообещала гораздо боль-
ше, чем может произвести за выделенный ей период времени. Поэтому она по-
просила помощи у нескольких друзей. Они назначили ее главным поэтом и
проектировщиком поэмы. Она вчерне набросала тему и последовательность раз-
вития событий.
Друзья начали ей помогать, но столкнулись с проблемами синхронизации и
общения по поводу их работы. Также оказалось, что они не успевают все сделать
вовремя. Поэтому они включили в свою группу пару канцелярских служащих,
позвали еще друзей и, в отчаянии, нескольких соседей. Друзья и соседи, конечно,
не были настоящими поэтами. Поэтому наши главные конструкторы набросали
для них вкратце те разделы поэмы, которые не требовали слишком большого та-
ланта.
Что, по-вашему, произошло?
Были хорошие новости: один человек проявил способности к описательным
пассажам, другой оказался хорош в кровавых эпизодах, третий ловко изображал
портреты людей. Никому не удавалось выразить чувства, кроме главного поэта,
правда, она рвала на себе волосы, поскольку у нее не было времени на поэзию,
она была слишком занята координацией, проверкой и раздачей работы.
Несколько человек никак нельзя было предоставить самим себе. Двое, кото-
рым поручили второстепенных персонажей, исписывали страницу за страницей,
и наша главная поэтесса не могла их заставить сократить объем. Еще несколько
человек постоянно переписывали и перерабатывали свои строфы, недовольные
результатом. Она требовала перейти к другим эпизодам, но они просто не могли
остановиться и продолжали так и сяк крутить свои первые части.
Поскольку время проходило, доведенная до отчаяния группа приняла новых
людей. Но проблема-то была в том, что они превысили бюджет и не могли себе
позволить нанимать всех этих сотрудников. Обмен информацией находился в
ужасающем состоянии, никто не имел текущего варианта поэмы, и никто не знал
ее фактического состояния.
Теперь давайте приведем эту историю к счастливому концу...
Кооперативная игра в изобретения и коммуникации
25
К счастью, они наняли администратора, прекрасно знающего свое дело, ко-
торый привел в порядок план всей поэмы, провел инвентаризацию квалифика-
ции каждого лица, установил интервал и график обмена информацией по каждой
части, стандарты для контроля версий и объединяемых частей поэмы, занялся
секретарской и другой технической работой.
Поэма была передана довольным заказчикам со значительным превышением
бюджета. А главному поэту пришлось отправиться в отпуск, чтобы привести в
порядок расшатавшиеся нервы. Она поклялась, что никогда больше не станет
этим заниматься (но мы-то знаем, что это не так).
Конечно, для написания длинных поэм группы собираются. И я уверен, что
они сталкиваются в основном с теми же проблемами, что и разработчики ПО:
темпераментные гении и обычные работники, жесткие требования и затруднения
с общением. Люди работают вместе, создавая то, что не совсем понимают. Хоро-
шая работа — и результат потрясающий, неудачная работа — и все отправляет-
ся в корзину.
Баланс в проектировании ПО
Когда я занимался рецензированием проекта объектно-ориентиро-
ванной системы, один из экспертов предложил альтернативный под-
ход к проектированию.
Главный проектировщик ответил, что альтернативный вариант не так
сбалансирован и не позволит обеспечить такое же хорошее течение
процесса проектирования, как первоначальный.
Таким образом, даже в кругах закоренелых программистов мы на-
ходим разработчиков, обсуждающих проектирование в терминах ба-
ланса и течения процесса.
Разработчики ПО взвалили на себя более тяжкое бремя, чем наши гипоте-
тические поэты, — логику. Результат должен не просто быть гармоничным, он
должен себя вести должным образом: если не абсолютно правильно, то “доста-
точно точно”.
Суть в том, что, хотя программирование — основанная на вдохновении и ло-
гике деятельность одиночек, это также групповая инженерная деятельность.
Причем это парадоксальный вид деятельности, поскольку, если о разработке ПО
можно что-либо утверждать, то в то же время это можно и категорически опро-
вергать. Разработка ПО — это:
Математика, как часто говорил Хоар (C.A.R. Hoar)
Инженерное дело, как часто говорил Бертран Мейер
(Bertrand Meyer)
Ремесло, как говорят многие программисты
Мистический акт творения, как утверждают многие программисты
26
Глава 1
Создание ПО чувствительно к инструментам, и качество зависит от инст-
рументов. Некоторые программы считаются прекрасными, другие — рухлядью.
В них соединяются противоположности и множество наборов противоположно-
стей.
Эта деятельность связана с познаванием и выражением; она осуществляется
общающимися и думающими людьми, работающими по разные стороны эконо-
мических границ; она обусловлена их культурами и чувствительна к конкретным
участвующим индивидуумам.
Программное обеспечение и игры
Игры нужны не только детям, хотя и дети тоже играют. Игры придумываются и ис-
пользуются многими людьми, в том числе романистами, математиками и корпора-
тивными стратегами.
Разновидности игр
Если бы вы сидели зимним вечером у себя в гостиной и кто-то сказал: “Давайте по-
играем”, во что вы могли бы сыграть?
Вы могли бы сыграть в шарады (разгадывание скрытой фразы), в крести-
ки-нолики или шашки, в покер или бридж, в прятки или в настольный теннис. Вы
могли бы сыграть в “Когда я поехал” — игру, в которой каждый человек добав-
ляет предложение к истории, разрастающейся в целое повествование. А закон-
чить вы могли бы, особенно в компании с детьми, соревнованиями по борьбе на
полу.
Игры делятся на множество категорий: с нулевой суммой, с ненулевой сум-
мой, позиционные, конкурентные, кооперативные, конечные и бесконечные (см.
рис. 1.1), причем это далеко не все категории игр. Попытаемся определить, к ка-
кой разновидности может относиться разработка ПО, и для этого рассмотрим на-
званные категории.
В играх с нулевой суммой участвуют две противоположные стороны, так что
если одна сторона выигрывает, то другая проигрывает. К таким играм относятся
шашки, крестики-нолики, бридж и теннис. Ясно, что разработка ПО — это не
игра с нулевой суммой.
В играх с ненулевой суммой есть несколько выигравших и несколько проиг-
равших. Многие из игр, в которые вы могли бы сыграть в тот зимний вечер, от-
носятся к играм с ненулевой суммой, например покер или прятки. К играм с не-
нулевой суммой разработку ПО также отнести нельзя.
В позиционных играх состояние игры в целом можно узнать, посмотрев, как
расположены фишки на доске в данный момент. Примерами служат шахматы и
крестики-нолики. Бридж — не позиционная игра, поскольку разыгранные карты
не показывают, кто ими играет.
Кооперативная игра в изобретения и коммуникации
27
Рис. 1.1. Различные категории игр
Некоторые пытаются играть в разработку ПО, как в позиционную игру, тре-
буя, чтобы документация отражала историю и текущее состояние проекта. Они
имеют в виду, что если кто-либо покинет проект, то пришедший на смену человек
сможет присоединиться к команде, прочитать документацию и подхватить работу
в том месте, где она была остановлена. Мы увидим, что для разработки ПО эта
игровая стратегия неэффективна.
(На самом деле позиционные игры гораздо интереснее, чем можно судить по
простому описанию, приведенному выше. Джону Конвею (John Conway) в книге
On Numbers and Games (1976) удалось показать, что позиционные игры двух
лиц формируют надмножество всех чисел: действительных, мнимых, конечных и
трансфинитных. Он конструирует понятие числа непосредственно по позицион-
ным играм двух лиц.)
Все вышеперечисленные игры являются конкурентными, поскольку явно
содержат понятия выигравшего и проигравшего.
В кооперативных играх участники или стараются выиграть совместно, или
продолжают играть так долго, пока считают, что играть стоит. Первые игры на-
зываются целенаправленными, вторые — нецеленаправленными. Рассказ ис-
торий, джазовая импровизация и борьба на ковре относятся к нецеленаправ-
ленным кооперативным играм. В этих играх участники не стараются как можно
быстрее достичь цели и закончить игру. Игра заканчивается, только если доста-
точно большое число игроков устает и выходит из игры.
Шарады, альпинизм и разработка ПО — это целенаправленные коопера-
тивные игры (посмотрите на рис. 1.1 еще раз).
Все перечисленные игры должны заканчиваться, поэтому они называются
конечными. В бесконечных играх главное намерение игроков состоит в продол-
жении игры. В эти игры играют организации, корпорации и страны. Основная их
цель — поддерживать свое существование.
28
Глава 1
Профессия человека — тоже бесконечная игра. Человек, не желая остав-
лять профессиональную деятельность, совершает ряд ходов, позволяющих ему
продолжать работать в той же сфере.
Часто человек или компания стремится в конкретном проекте сыграть лучше,
чтобы получить лучшую позицию в следующей игре. Как и в карточной игре с со-
ответствующим названием “Прощай, простофиля”, команды и союзы такого рода
постоянно меняются без предупреждения.
Программное обеспечение и альпинизм
Из всех сравнимых с разработкой ПО игр, которые я знаю, альпинизм выделяется
как самая близкая игра. Очень полезно иметь такой объект сравнения, чтобы отойти
подальше от нашего предмета и обнаружить словарь, который мы сможем приме-
нить при разработке ПО. Альпинизм — не метафора относительно разработки ПО,
а партнер в сравнении, другой элемент того же самого класса игр.
Посмотрим, как некоторые слова и выражения, которые ассоциируются с аль-
пинизмом, связаны с разработкой ПО.
Кооперативная и целенаправленная игра. Команда альпинистов и скало-
лазов работает совместно, чтобы достичь вершины. Они будут оценивать вос-
хождение по тому, как хорошо они поднимались вместе и как приятно им было
находиться в таком обществе, но главным мерилом успеха будет покорение вер-
шины. Достичь конечной точки — вот главная цель, и игра заканчивается, когда
они поднимаются на вершину.
(Если вы альпинист, то в этом месте легко можете мне возразить. Для мно-
гих альпинистов конец восхождения — грустный момент, означающий окончание
игры. Это справедливо для кооперативных игр вообще. Игра заканчивается, ког-
да достигнута конечная точка, но, если игроки получают при этом удовольствие,
они не хотят останавливаться. Точно так же иногда разработчики ПО не хотят за-
канчивать проектирование, поскольку тогда доставляющая удовольствие часть их
работы будет завершена.)
Весовая нагрузка. Альпинисты действительно должны выдерживать тя-
жесть своего веса руками и ногами. Это особенно важное сравнение между дву-
мя играми: программы должны работать и выдавать верные ответы. Хотя
возможны различные решения, но не любое решение даст желаемый результат.
Команда. Альпинизм — обычно командный спорт. Конечно, есть альпини-
сты-одиночки, но в основном альпинисты формируют команды с целью восхож-
дения.
Талантливые личности. Некоторые люди совершенно естественно лазают
по скалам лучше других. А иные никогда не справятся с определенными восхож-
дениями.
Значение мастерства. Альпинист должен обладать определенной сноров-
кой. Новичок может приступить лишь к простым маршрутам. Накопив практиче-
ский опыт, альпинист сможет штурмовать более сложные вершины.
Кооперативная игра в изобретения и коммуникации
29
Тренировка. Альпинисты и скалолазы постоянно отрабатывают специаль-
ные приемы.
Инструменты. Для серьезного занятия альпинизмом необходимы инстру-
менты: мел, зажимы, ремни, трос, карабин и другие. Важно иметь возможность в
нужный момент дотянуться до нужного инструмента. На небольшую высоту мож-
но влезть по скале, вовсе не пользуясь инструментами. Однако, чем длиннее
маршрут, тем важнее подбор инструментов.
Ограниченные ресурсы. Обычно подъем нужно закончить до темноты или
до перемены погоды. Альпинисты планируют восхождения так, чтобы они соот-
ветствовали выделенному времени и запасам топлива.
План. Собираются ли альпинисты подняться на отвесную скалу, пройти в од-
ной связке или совершить многодневное восхождение, они всегда составляют
план. Чем дольше восхождение, тем более подробным должен быть план, даже
если команда знает, что план будет неполным и в некоторых местах неверным.
Импровизация. Непредвиденные и совершенно случайные преграды всегда
проявляются даже в наиболее тщательно спланированных альпинистских экспе-
дициях, если только восхождение не короткое и команда не выполняла его неско-
лько раз до этого. Следовательно, альпинисты должны быть готовы менять свои
планы — импровизировать, причем немедленно.
Удовольствие. Альпинисты идут в горы, поскольку получают от этого удо-
вольствие. Совершая восхождение, они испытывают чувство единого движения
(Csikszentmihalyi, 1991), и эта общая занятость доставляет им удовольствие.
Аналогично программистам обычно нравится их работа, а включение в общий ход
проектирования и программирования составляет часть этого удовольствия. Для
альпинистов — это физическое и внутреннее движение. Движение в случае про-
граммирования — чисто внутреннее.
Испытания. Альпинисты идут в горы, "поскольку это испытание для них:
действительно ли они могут подняться до самой вершины? И программисты тоже
часто нуждаются в испытаниях. Если они не считают свое задание испытанием,
они могут его бросить или начать разнообразить систему элементами дизайна,
находя в этой работе вызов себе (ну прямо как отдельные поэты, упоминавшиеся
в проекте с эпической поэмой).
Опасность. Возможно, один аспект альпинизма не переносится на разра-
ботку ПО — я имею в виду опасность. Если альпинист неудачно упадет, он мо-
жет разбиться насмерть. Альпинисты любят говорить, что восхождение,
совершаемое с должной осторожностью, менее опасно, чем вождение автомоби-
ля. Однако я не слышал, чтобы программисты сравнивали опасность своей рабо-
ты с опасностью вождения автомобиля.
Разработку ПО сравнивают со многими другими вещами, в том числе с мате-
матикой, наукой, инженерией, театром, строительством мостов и юриспруден-
цией. Хотя некоторое понимание можно приобрести, рассматривая эти виды
деятельности, сравнение с альпинизмом наиболее полезно, чтобы понять факто-
ры, затрагивающие разработку ПО.
30
Глава 1
Игра изобретения и коммуникации
Итак, мы определили, что разработка ПО — это групповая игра, к тому же целе-
направленная, конечная и кооперативная. Команда, состоящая из спонсора, ме-
неджера, специалистов-пользователей, экспертов предметной области,
проектировщиков, тестировщиков и разработчиков программ работает вместе,
чтобы выпустить работающую полезную систему. В большинстве случаев участни-
ки команды нацелены на как можно более быстрое производство системы, но они
могут сосредоточиться и на удобстве ее использования, снижении стоимости, без-
дефектности или защите от помех.
Это конечная игра, поскольку она заканчивается, когда цель достигнута. Ино-
гда производство системы означает конечную точку, иногда завершение происхо-
дит немного позднее. Финансирование разработки обычно изменяется примерно в
то же время, когда выпускается система, и новое финансирование определяет но-
вую игру. Новая игра может состоять в улучшении системы, ее замене, построении
абсолютно другой системы или, возможно, в расформировании группы.
Это кооперативная игра, поскольку члены команды помогают друг другу до-
стичь цели. Оценка их качества как команды определяется тем, насколько хоро-
шо они сотрудничают и общаются во время игры. Эта оценка влияет на удачное
достижение цели.
Если это целенаправленная кооперативная игра, то в чем она заключается?
Что представляют собой ходы в этой игре?
Задача, стоящая перед разработчиками, такова: они работают над не до кон-
ца понятной проблемой, обитающей в сфере эмоций, желаний, мыслей и изменя-
ющейся в процессе их работы. Они должны:
Понять место, занимаемое проблемой
Представить себе некоторый механизм, разрешающий проблему в жизне-
способном технологическом пространстве
Описать системе, не прощающей ошибок, мысленную конструкцию на вы-
полнимом языке, которому недостает нужных средств выражения
Стремясь преодолеть эту ситуацию, они:
Используют реквизит и приемы, чтобы выработать новые идеи, которые
помогут им понять проблему и сконструировать решение.
Оставляют следы — метки для тех, кто будет продолжать работу, — метки,
отслеживающие и контролирующие их продвижение и понимание. Они
сами используют те же метки, когда возвращаются к соответствующим час-
тям для переработки.
Следовательно, разработка ПО представляет собой кооперативную игру в изо-
бретения и коммуникации. В этой игре нет ничего, кроме идей участников и об-
щения с целью донести эти идеи коллегам и компьютеру.
Кооперативная игра в изобретения и коммуникации
31
Не многие авторы в нашей области смогли ясно выразить это. Это сделали
Питер Наур в статье 1985 г. “Programming as Theory Building”, а также Пелле
Эн в “Scandinavian Design: On Participation and Skill” (1992) и в великолепной,
но ставшей редкостью книге Work-Oriented Design of Software Artifacts (1988).
Наур и Эн изложили это так замечательно, что две их статьи я включил практи-
чески полностью в приложение В. Об этом же писал Роберт Гласс (Robert Glass)
в “Software Tasks: Intellectual or Clerical?” (1992), а Фред Брукс (Fred Brooks)
увидел в этом настолько дьявольски тяжелую задачу, что написал статью “No Sil-
ver Bullet” (1995).
Возможные результаты этой кооперативной игры в изобретения и коммуни-
кации рассматриваются в оставшейся части этой главы. В остальных главах кни-
ги исследуются эти результаты.
Программное обеспечение и инженерия
Разработку ПО выгодно рассматривать в качестве игры с ходами, поскольку при
этом мы получаем способ принятия значимых и полезных решений по проекту. Для
сравнения, если говорить о разработке ПО как об инженерии или создании моде-
ли, то это не поможет нам в принятии таких же полезных решений.
При ссылках на инженерию трудность заключается в том, что мы, как сооб-
щество, не знаем, что это означает. Не имея общего понимания, что такое инжене-
рия, трудно убеждать людей работать “в большей степени как инженеры”. В своих
поездках я сталкивался с людьми, которые слово “инженерия” использовали
главным образом для того, чтобы создать ощущение вины за невыполнение че-
го-то до конца, не поясняя, чего именно.
В словаре недвусмысленно сказано, что “инженерия” — это "применение
науки и математики, благодаря которому природные свойства материи
и источники энергии становятся полезными для человека" (Webster’s New
Collegiate Dictionary, 1977).
Это определение не объясняет, что значит “заниматься инженерией”. По
моему опыту, этим занятием является создание компромиссного решения, не-
смотря на обычно противоречивые требования. Хотя один человек мне написал:
“Основная концепция инженерного дела состоит в том, чтобы браться за проб-
лемы повторяющимся и непротиворечивым образом”. Путать действие, выпол-
няющее инженерную работу, с результатом выполнения инженерной работы —
широко распространенная ошибка.
В результате выполнения инженерной работы появляется работающая фаб-
рика, а специальный персонал внимательно наблюдает за изменениями качества
и количества производимых изделий.
Действие, выполняющее инженерную работу, — это скрытый творческий
процесс, через который проходит инженер-технолог, чтобы изобрести конструк-
цию завода-изготовителя. Этот процесс не имеет ничего общего с выборочным
контролем, измерением количества и качества выработки. Как и разработка ПО,
32
Глава 1
этот процесс выполняется как кооперативная игра в изобретения и коммуника-
ции, в которой участвуют отдельные люди с разными биографиями, собирающие-
ся вместе, чтобы размышлять о реально выполнимом проекте.
Когда люди говорят: “Сделайте разработку ПО более похожей на инжене-
рию”, то часто имеют в виду: “Сделайте это более похожим на работающий завод
с выборочным контролем качества”. Но, как мы видели, управление заводом —
это не действие, выполняющее инженерную работу.
Другой аспект “занятия инженерией” — поиск предыдущих решений в сво-
дах норм и правил.
От инженеров-строителей, проектирующих мосты, не требуется изобретать
новые конструкции. Когда река выбрана и известен предполагаемый транспорт-
ный поток, они берут пробы грунта и используют своды норм и правил для поис-
ка простейшей конструкции, которая справится с заданным потоком на заданном
расстоянии, будучи возведенной на имеющемся грунте. Они базируются на изве-
стных решениях, веками сводимых в таблицы.
Это лишь в самой малой степени пригодно к текущему состоянию разработ-
ки ПО. Мы все еще находимся на той стадии, когда любая команда считает свой
проект лучше, чем у соседей, и технологии меняются так быстро, что количество
сборников действующих норм и правил оказывается недостаточным. С течением
времени этих книг появится больше. Однако сегодня между системами по-преж-
нему имеется больше различий, чем сходств.
Вернемся к рассмотрению “инженерии” как к “размышлению и созданию
компромиссных решений”. Это подходящее выражение. Мы хотим, чтобы наши
разработчики ПО думали и понимали компромиссы, на которые они идут. Однако
это выражение не обеспечивает руководства разработкой проекта.
Программное обеспечение и моделирование
За последнее десятилетие у моделирования появилось много сторонников, в том
числе Ивар Якобсон, провозгласивший: “Разработка ПО — это моделирование”.
Если определение разработки ПО как инженерии не может предоставить до-
статочное количество правил для управления проектом, то определение ее как
моделирования прямо ведет к неверным проектным решениям.
Если бы разработка ПО была моделированием, то справедливой мерой ка-
чества ПО или процесса разработки было бы качество моделей, их точность по
отношению к реальному миру и их полнота. Однако вот что мне говорили участ-
ники многих команд, разработавших успешные проекты по всему миру:
“Интересная часть работы, которую мы хотим выразить, не фиксиру-
ется в этих моделях. Интересно то, что мы говорим друг другу, когда
рисуем на доске”.
“У нас нет времени создавать причудливые или полные модели. Часто
у нас вообще нет времени создавать модели”.
Кооперативная игра в изобретения и коммуникации
33
В тех местах, где люди старательно создавали модели, программы не выпус-
кались. Если они уделяли внимание моделям, это мешало им разрабатывать про-
граммы.
Построение модели не является целью проекта. Оно интересно лишь в том
случае, когда это помогает победить в игре.
А цель игры заключается в производстве ПО. Любая другая деятельность имеет
вспомогательное значение. Модель, как любое средство коммуникации, обоснован-
на, если только она позволяет еще одному человеку продвинуться в работе.
Рабочие продукты команды следует оценивать по их достаточности по отно-
шению к коммуникации с целевой группой. Не имеет значения неполнота, некор-
ректность синтаксиса и несоответствие реальному миру, если они дают своим
получателям достаточный объем информации.
Ярко написал о вариантах использования Джим Сойер, участвовавший в ди-
скуссии по электронной почте (Cockburn, 2001с):
"... пока шаблоны не покажутся настолько формальными, что вы поте-
ряетесь в рекурсивном спуске по этим туннелям, проложенным в про-
странстве проекта. Если это начинает происходить, плюньте,
разденьте этих маленьких жуликов догола и начинайте рассказывать
друг другу истории да царапать на салфетках”.
Эффект общения более важен, чем форма общения. Некоторые команды,
успешно создававшие проекты, построили больше изощренных моделей, чем
команды, не добившиеся успеха. Отсюда многие заключают: чем больше модели-
рования, тем лучше.
Некоторые успешные команды строили меньше моделей и более небрежно,
чем некоторые неуспешные группы. Другие отсюда делают вывод: чем меньше
моделирования, тем лучше.
Ни одно из этих заключений не верно. Моделирование служит одним из спо-
собов обмена информацией в команде. Его может быть и слишком много, и
слишком мало. Время от времени вполне можно обойтись, нацарапав что-то на
салфетке, но в другое время требуется гораздо больше деталей.
Данная книга помогает понять, как много моделирования требуется и когда.
Если вы будете считать разработку ПО кооперативной игрой, имеющей главную
и второстепенную цели, это поможет вам развить понимание того, какую модель
нужно построить и нужно ли ее строить вообще.
« .
Второй взгляд на кооперативную игру
Принцип кооперативной игры
Разработка ПО — это (ограниченная в ресурсах) кооперативная игра
в изобретения и коммуникации. Главная цель этой игры состоит в вы-
34
Глава 1
пуске полезного, работающего ПО. Вспомогательная цель, или оста-
ток игры, заключается в подготовке следующей игры. Следующая
игра может состоять в изменении или замене существующей систе-
мы или в создании похожей системы.
Программисты как специалисты по коммуникации
Выражение “разработка ПО — это кооперативная игра в изобретения и коммуни-
кации” внезапно показывает в абсолютно новом свете людей, работающих в на-
шей области. Обычно программистов стереотипно представляют как необщи-
тельных индивидуумов, любящих сидеть в затемненных комнатах наедине со свои-
ми компьютерами.
Однако это неверный стереотип. Просто программисты любят говорить о пред-
метах, которые их интересуют, в частности о программах, в разработке которых
они участвуют. Программистам очень нравится обмениваться замечаниями об
XML-RPC или о трудностях отображения объектно-ориентированных проектов
на реляционные базы данных. Они просто не любят вступать в пустые разговоры
о вещах, которые не считают относящимися к делу.
Удивительно высокое признание получило парное программирование —
технология, при которой два человека сидят рядом и совместно пишут программу
(Beck, 2000). Я говорю “удивительно”, поскольку многие программисты понача-
лу предсказывают, что не смогут работать таким образом, а затем, попробовав
этот способ одну-две недели, обнаруживают, что на самом деле предпочитают
именно его (Cockburn, 2001b).
Насколько этот стереотип верен, он выделяет ту часть кооперативной игры,
которая относится к “изобретению”. Вплоть до недавнего времени на програм-
мирование больше обращали внимание как на игру в изобретения, а не игру в
коммуникации. Интерес программистов к обсуждению между собой программи-
стских тем мешает им обсуждать деловые вопросы со спонсорами, пользователя-
ми и бизнес-экспертами.
Причину можно хотя бы частично приписать учебным планам наших уни-
верситетов. Вообразите себе нескольких студентов, листающих список учебных
планов. Они видят два пути: один означает много читать, писать, говорить и не-
много программировать; второй предусматривает меньше чтения, письменных
работ, меньше разговоров и больше индивидуальной работы с созданием раз-
личных артефактов. Легко можно представить, что люди, больше ориентиро-
ванные на беседы, выбирают первый план, а менее склонные к устной речи —
второй.
Исторически успех в нашей профессии приходил к тем, кто был способен
проводить долгие часы в одиночестве, ни с кем не разговаривая и глядя в бумаги
или на экран. Те, кому не нравился такой режим работы, просто покидал эту сфе-
ру деятельности. Более новые и особенно “быстрые” методологии большее зна-
чение придают коммуникации. Неожиданно людей, избравших профессию, не
Кооперативная игра в изобретения и коммуникации
35
требовавшую частого межличностного общения, попросили проявить способно-
сти в этой сфере.
Только университеты могут изменить общие характеристики на прямо про-
тивоположные, создавая такие учебные планы для разработчиков ПО, которые
содержат больше курсов с интенсивным общением.
В университете города Ольборга в Дании введена новая профилирующая
дисциплина “информатика”, содержащая и проектирование ПО, и навыки обще-
ния (Mathiassen, 1999). Глава факультета Ларс Матиассен сообщает, что разли-
чия в индивидуальности людей заметны: новый учебный план привлекает тех, кто
готов принять груз общения, а старый привлекает тех, кого менее интересует об-
щение.
Мы должны стать свидетелями повышения внимания к коммуникации в уни-
верситетских учебных планах до той степени, в которой разработка ПО действи-
тельно является игрой в изобретения и коммуникации.
Ускоритель игры
Не следует ожидать, что производительность программирования повысится на по-
рядок.
Насколько бы ни были усовершенствованы языки программирования, наша
способность продумать задачу и решение, проработать в деталях способы, какими
описанное решение может справиться с несметным числом возможных случаев,
будет ограничивать программирование. Это — науровское “программирование
как построение теорий” (приложение В).
Чтобы понять, почему экспоненциального роста производительности ожи-
дать не приходится, нужно лишь посмотреть на две другие области выражения
мысли: написание романов и написание законов. Вообразите себе беспокойство
из-за того, что юристы не ускоряют экспоненциально скорость создания конт-
рактов и законов!
, Иначе говоря, можно ожидать, что игра в изобретения и передача информа-
ции о соответствующих намерениях компьютеру будут и далее оставаться нелег-
кой деятельностью.
Метки и реквизит
Промежуточные рабочие продукты оказывают помощь в “построении теории” у Ha-
ypa и в “языковых играх” Эна, как напоминания о наших размышлениях. Они пре-
доставляют совместный опыт, на который можно сослаться или который служит
поддерживающей конструкцией для новых идей.
В первом случае этот опыт должен быть лишь достаточно полным, чтобы на-
помнить о мысли или решении из прошлого. Различным людям с различным об-
разованием и опытом подходят различные метки.
В другом случае опыт действует как реквизит, стимулирующий новые мысли.
36
Глава 1
Модель лазерного принтера
Команда Эна рассматривала ввод лазерных принтеров в группу, не
имевшую с ними опыта работы тогда, в 1982 г. Они сконструировали
картонные модели — не для напоминания участникам о том, что им
уже было известно, а чтобы помочь им представить себя в буду-
щем. Недорогая временная модель давала возможность увидеть бу-
дущую реальность.
Эти модели не стоит считать второсортными предметами, используемыми
лишь вследствие какого-то случайного отсутствия техники. Вернее будет относи-
ться к ним как к фундаментальному приему, помогающему людям обдумывать но-
вые ситуации. Уместен любой рабочий продукт, помогающий группе изобрести
способ ускорения игры. Нужно ли сохранять модель рядом как напоминание о про-
шлой дискуссии, зависит от того, как строится игра.
Сокращение отдачи
Поскольку типичный проект разработки ПО ограничен по срокам, исполнителям и
деньгам, то выделять дополнительные ресурсы, чтобы сделать промежуточный ра-
бочий продукт лучше, чем ему требуется быть для решения его задачи, расточите-
льно. Один коллега выразил то же самое следующим образом:
Сокращение отдачи
Когда я начал создавать варианты использования и объектные модели,
мне было ясно, что эта работа приносит какую-то пользу. Но в некото-
рый момент она перестает быть полезной, а становится нудной и пустой
тратой сил. Я не могу определить момент прохождения этой точки и ни-
когда не слышал, чтобы это обсуждалось. Это разочаровывает, посколь-
ку полезная деятельность превращается в непроизводительную работу.
Цель каждой деятельности состоит в продвижении игры вперед. Рабочие
продукты любого сорта полезны, пока они позволяют сделать следующий шаг.
Зная это, по степени сокращения отдачи человек может легче определить
критическую точку, достаточную для цели. Эта точку назвали “доставляющей
удовлетворение (satisficing)” (Simon, 1987, Bach URL).
Достаточность для главной цели
Промежуточные рабочие продукты не важны как модели реальности, и они не име-
ют внутренней ценности. Они ценны лишь тем, что помогают команде сделать ход в
игре. Таким образом, речь не идет об оценке промежуточных рабочих продуктов по
их точности и совершенству. Промежуточный рабочий продукт должен измеряться
по его достаточности: достаточен ли он, чтобы быть напоминанием или вдохнови-
телем для участвующей в работе группы?
Кооперативная игра в изобретения и коммуникации
37
Следующие три короткие истории иллюстрируют, кал быстро можно достичь
достаточности.
Достаточность на рабочей встрече
Когда я проделал часть работы над проектом "Winifred" (Cockburn,
1998), я был приглашен встретиться приблизительно с 40 участника-
ми проекта, чтобы провести обзор процесса, которого мы придер-
живались, и показать образцы рабочих продуктов. Это заседание
должно было состояться в кафетерии.
Я скопировал на прозрачную пленку для проектора образец каждо-
го рабочего продукта: варианта использования, диаграммы последо-
вательностей, диаграммы классов, определения экрана, фрагмента
Smaltalk-кода и т.д.
К счастью или несчастью, но лампочка в проекторе перегорела как
ч раз перед моей маленькой презентацией. Поскольку на мне была
белая рубашка, я попросил всех придвинуться поближе и показал об-
разец с вариантом использования, держа его перед рубашкой.
"Не могу прочитать!" — вскричал кто-то из последних рядов, что не
было удивительно.
"Вам и не нужно это читать, — сказал я, и группа засмеялась. —
Вам нужно только увидеть, что вариант использования представляет
собой несколько абзацев текста, примерно таких. Вы сможете найти
много таких примеров и рассмотреть их ближе. Мы их пишем как
требования..." — Ия рассказал, кто их пишет, кто их читает и как
они используются.
Затем я поднял к рубашке образец диаграммы классов.
"Не могу прочитать!" — снова вскричал кто-то.
"Вам и не нужно это читать. — (Группа снова засмеялась.) — Вам
нужно всего лишь увидеть, что это диаграмма содержит прямоуго-
льники и линии. Ее рисуют..." — Ия рассказал о роли диаграмм
классов в проекте.
Таким образом я прошел по всем рабочим продуктам. В каждом
случае группе нужно было увидеть визуальное представление данно-
го продукта и узнать, кто его пишет, кто читает и как он служит
проекту. Все реальные примеры были доступны on-line, и каждый
участник проекта мог их изучить.
Это было общение, достаточное для поставленной цели: чтобы каждый
продукт сохранился в зрительной памяти этих людей для закрепления информа-
ции о его использовании.
У нас был и рисунок, показывающий процесс, которому мы следовали, но,
насколько я знаю, никто другой, кроме менеджеров проекта и меня, никогда на
него не смотрел.
38
Глава 1
Достаточность рабочих продуктов
Проект “Winifred" имел фиксированные сроки и фиксированное фи-
нансирование. Он стоил около 15 млн. долларов, длился 18 месяцев,
в нем участвовало 45 человек, из них 24 программиста. Мы работали,
держа в уме принцип кооперативной игры (тогда еще этот принцип не
был определен, но мы знали, чего хотели), с настолько близким и не-
формальным общением, насколько это было возможно.
В то время варианты использования были не очень хорошо опреде-
лены, и поэтому их составители записывали только несколько абза-
цев обычного текста, описывающих, что должно происходить, и
несколько связанных с ними бизнес-правил.
Аналитик, отвечающий за вариант использования, обычно после каж-
дого совещания с конечными пользователями направлялся прямо к
проектировщикам-программистам и рассказывал о результатах со-
вещания. Проектировщики-программисты внедряли новые знания не-
посредственно в свои программы, основываясь на устном описании.
Эта процедура работала эффективно, поскольку от момента получе-
ния аналитиком информации до прояснения программистом влияния
этой информации на его программу проходило всего несколько часов.
Однако при этом наблюдался странный побочный эффект. Когда по-
ловина срока проекта осталась позади, один из ведущих программи-
стов заметил, что он не знает, зачем нужны варианты
использования. В них, конечно, не содержится никаких требований,
сказал он, поскольку он никогда их не читал.
Суть этой истории в том, что бессистемное ведение вариантов использова-
ния было “достаточным для задачи” хранения требований. Каналы обмена ин-
формации и общее понимание между авторами и читателями создавали
возможности, достаточные для переноса информации.
Сверхлегкая достаточность Крайслера
Проектом Chrysler's Comprehensive Compensation (СЗ, 1998) управ-
лять было еще легче, чем проектом Winifred. Все 10 программистов
сидели вместе в одном огромном зале, контролирующий менеджер
и три заказчика (эксперты по требованиям) располагались в смеж-
ной комнате, причем между ней и залом дверь отсутствовала.
Имея прекрасные возможности для общения внутри команды и по-
стоянный доступ к требованиям, эта группа писала варианты исполь-
зования, которые можно назвать сверхнесерьезными. Для каждого
необходимого поведения системы они записывали на учетной карточ-
ке несколько предложений и называли их "пользовательскими исто-
риями".
Когда приходило время начать работу над пользовательской исто-
рией, программисты просили заказчика объяснить, что необходимо
Кооперативная игра в изобретения и коммуникации
39
сделать, и приступали к проектированию. Как только им требовалась
дополнительная информация, они просили пояснений у заказчика из
соседней комнаты. Требования обсуждались между участниками и
помещались в хранилища одобренных требований и тестов програм-
мных блоков.
Внутри группы проектная документация также существовала главным
образом в устном виде. Проектировщики изобрели новый метод
проектирования с использованием сеансов CRC-карт (Wilkinson,
1995). Они писали названия возможных классов на индексных кар-
точках и затем передвигали их для иллюстрации выполнения систе-
мой ее задач. Карточки служили как для стимулирования новых
идей, так и для временного хранения состояния обсуждения.
CRC-карты можно было легко конструировать, откладывать в сторо-
ну, возвращать в игру, и поэтому они идеально подходили для разви-
тия игры в изобретения и коммуникации.
Изобразив возможный проект схематически при помощи карточек,
проектировщики пересаживались к рабочим станциям, писали про-
граммы, соответствующие этому проекту, и выдавали небольшую
часть функций системы.
Этот проект так и не был положен на бумагу. Он жил в карточках,
в воспоминаниях о разговорах вокруг карточек, в модульных тес-
тах, написанных для проверки детализованных требований, и в со-
вместной памяти людей, работавших вместе на вращающемся
фундаменте разработки проекта.
Эта группа оказалась в высшей степени приспособлена к принципам коопе-
ративной игры. Ее промежуточные рабочие продукты, несмотря на их абсолют-
ный минимализм, очевидно, были достаточными для задачи разработки ПО. Эта
команда разрабатывала новую функцию каждые три недели в течение трехлетне-
го периода.
Достаточность в наследстве
До сих пор темой обсуждения была главная цель игры: произвести работающее
ПО. Однако весь проект представляет собой лишь один шаг в более крупной игре.
Проект имеет две цели: произвести ПО и создать выгодную позицию для следую-
щей игры, которая будет изменять или замещать старую систему или создавать по-
хожую.
Если команде не удается достичь главной цели, следующей игры может не
быть, и, следовательно, эту цель следует защищать в первую очередь. Если
команда достигает главной цели, но слабо подготовилась к следующей игре, та
оказывается в опасности.
Таким образом, в большинстве случаев команды должны создавать некото-
рые метки, информирующие следующую команду о требованиях и замысле систе-
40
Глава 1
мы. Придерживаясь концепции Наура о программировании как построении
теорий и принципа кооперативной игры, эти метки следует создавать, чтобы в до-
статочной степени приблизить следующую команду к мышлению членов коман-
ды, разработавшей предыдущую систему. По-прежнему применимо все, что
относится к языковым играм, совместному опыту и условиям достаточности для
цели.
Обязательно нужно ответить на вопрос, когда же команда создает эти допол-
нительные рабочие продукты.
Наивные люди отвечают так: “По мере создания рабочих продуктов”. Другой
вариант ответа: “В самом конце”. Ни то, ни другое нельзя признать оптималь-
ным. Если требования или проекты часто изменяются, то постоянное изменение
рабочих продуктов обойдется очень дорого — часто цена их настолько велика,
что подвергает риску сам проект. С другой стороны, если конструирование меток
для будущего оставлено на конец проекта, то возникает серьезная опасность, что
они вообще не будут созданы. Вот для иллюстрации две истории о проектах.
Постоянное документирование
В проекте "Reel” участвовало 150 человек. Спонсоры, очень беспо-
коившиеся, что документация системы будет устаревшей и неточ-
ной, распорядились при любом изменении требований, проекта или
кода немедленно приводить в соответствие всю документацию, за-
тронутую этим изменением.
О результате вы, наверное, уже догадались. Проект полз вперед
невозможно медленно, поскольку члены группы проводили боль-
шую часть своего времени, обновляя документацию по каждому
изменению.
Скоро этот проект был аннулирован.
Спонсоры этого проекта не обратили должного внимания на экономическую
сторону разработки системы и проиграли.
Абсолютно никакого документирования
Спонсоры проекта Chrysler Comprehensive Compensation в конце кон-
цов прекратили его финансировать. Люди, уходившие из команды
разработки, не оставляли другой, помещенной в архив, документации
по требованиям и проекту, кроме пользовательских историй, состояв-
ших из пары предложений, тестов и исходных кодов программ.
В конечном счете, когда ушло достаточно много сотрудников, неза-
писанные сведения о проекте и групповая память были утрачены.
В ходе построения системы эта команда мастерски воплотила принцип ко-
оперативной игры, но упустила важный момент, не оставив наследства для сле-
дующей игры.
Кооперативная игра в изобретения и коммуникации
41
Наследство — это задача, от решения которой команда проекта не может
уклониться. Команда должна задать следующие два вопроса и сама же должна на
них ответить:
Как своевременно завершить этот проект?
Когда и какие виды меток создать для следующей команды?
Некоторые решают потратить больше денег заранее, чтобы создать защит-
ный буфер вокруг вспомогательной цели. Другие выбирают стратегию баланси-
рования на грани допустимого, стремясь быстрее достичь главной цели, создавая
настолько небольшое наследство, насколько возможно, и настолько поздно, на-
сколько возможно.
Чтобы ответить на эти вопросы, команда должна рассмотреть сложность зада-
чи и решения, характеристики следующей команды и многое другое. Участники
команды должны балансировать между излишними расходами и недостаточным до-
кументированием. Поиск этого баланса — до некоторой степени искусство, о ко-
тором рассказывается в этой книге.
Игра внутри игры
Хотя любой проект мы считаем кооперативной и конечной игрой, в то же время
игроки заняты в других конкурентных и бесконечных играх.
Каждый член команды играет в бесконечную игру, называемую карьерой.
Эти индивидуумы могут предпринимать действия, наносящие ущерб проекту как
игре, но рассматриваемые ими как выгодные для их собственной карьеры.
Точно так же компания играет в бесконечную игру — собственное разви-
тие. Для компании весь проект — всего лишь один ход в той, более крупной
игре. В некоторых конкурентных ситуациях директора компании могут обдуман-
но мешать или саботировать работы по проекту, чтобы причинить вред конку-
ренту или каким-либо иным способом создать для себя лучшую ситуацию в бу-
дущем.
Когда наблюдаешь за военными проектами, выполняемыми по субподряду,
иногда кажется, что компании тратят больше времени и денег, всеми средствами
добиваясь выгодного положения, а не разрабатывая ПО. Если думать изолиро-
ванно о любом проекте, такое поведение не кажется благоразумным. Если же
рассмотреть обширный набор конкурентных бесконечных игр, в которые играют
компании, то поведение игроков внезапно приобретает больше смысла. Всякий
отдельный проект они используют как игральную доску, на которой выстраивают
позицию для следующей части игры.
Концепция кооперативной игры не подразумевает, что конкурентные и бес-
конечные игры не существуют. Она, скорее, предоставляет слова, чтобы описать
происходящее между играми.
42
Глава 1
Разработка с открытыми исходными текстами
Наконец, рассмотрим проекты с открытыми исходными текстами. Они основаны
на иной финансовой структуре, чем коммерческие проекты, и не предполагают
ограниченности ресурсов.
Проект с открытыми исходными текстами не ограничен временем и исполь-
зует всех людей, присоединившихся к нему. Он не ограничен денежными сумма-
ми, поскольку никому за участие не платят. Он не ограничен людскими
ресурсами, поскольку любой человек может принять участие в игре. Он не огра-
ничен сроками, поскольку не имеет плана-графика. Такой проект требует столь-
ко времени, сколько ему понадобится.
Ходы, присущие игре, не ограниченной ресурсами, совершенно естественно
отличаются от ходов в игре с ограниченными ресурсами. Структура вознагражде-
ния также другая. Поэтому ожидается, что проект с открытыми исходными тек-
стами будет использовать для продвижения в игре другой набор ходов. Но
все-таки создание ПО остается кооперативной игрой в изобретения и коммуни-
кации.
Кто-то может возразить, что разработка с открытыми исходными текстами в
действительности не имеет цели. Линус Торвальдс (Linus Torvalds) не проснулся
однажды и не сказал: “Давайте-ка закончим переписывать операционную систе-
му UNIX, разойдемся и займемся какими-нибудь реальными делами”. Он рабо-
тал над этим проектом в первую очередь потому, что это доставляло ему
удовольствие (Torvalds, 2001), и еще, чтобы “сделать эту штуку немного лучше”.
Другими словами, это скорее напоминало детскую борьбу на ковре или игру му-
зыкантов, чем альпинистов, стремящихся покорить вершину.
Хотя до известной степени это справедливо, но все же эту игру направляет
цель, и человек, работающий над частью системы, стремится довести ее до “сле-
дующего полезного состояния”. Люди, работающие над этой частью системы, все
так же участвуют в кооперативной игре изобретения и коммуникации, чтобы до-
стичь этой цели.
Что все это означает?
Применяя этот новый словарь на практике в вашем текущем проекте, вы должны
увидеть новые способы своевременного завершения своей работы, соблюдая в то
же время свои интересы в будущих проектах. Далее приведены некоторые идеи,
которые помогут вам лучше воспринять мысли, изложенные в данной главе:
Прочитайте в приложении В статью “Программирование как построение те-
орий”. Затем проведите следующие наблюдения:
Как люди из команды проектировщиков строят свои теории?
Как люди, выполняющие последние отладочные операции или сопровожде-
ние программ, строят свои теории?
Кооперативная игра в изобретения и коммуникации
43
Как различается информация, доступная первой и второй группе?
Как их различные теории отражаются на различных создаваемых програм-
мах?
Как ваше понимание своей задачи изменяется со временем и как это изме-
няет ваше понимание решения, которое вы строите?
Окиньте взглядом проект, рассматривая его как кооперативную игру в изоб-
ретения и коммуникации с ограниченными ресурсами. Спросите:
Какие игроки участвуют в этой игре?
Кто из них играет в конечной, целенаправленной командной игре?
Кто вместо этого играет в свою собственную бесконечную игру?
Когда игроки команды изобретают вместе, а когда прокладывают тропы,
чтобы помочь другим присоединиться к ним? Тщательно проследите за этим
пять последовательных рабочих дней, чтобы увидеть, как они переходят от
одного поведения к другому.
Посмотрите на проектные решения как на “ходы” в игре. Представьте ее
другой разновидностью игры, переходом через болото:
Вспомните деятельность по учреждению проекта, представьте ее как пред-
варительный план атаки болота; этот план будет меняться с появлением но-
вой информации о характеристиках болота и возможностях членов
команды.
Понаблюдайте, как каждый человек вносит свой вклад в определение глу-
боких и безопасных участков и строит карту или дорожку для прохода других
людей.
Обдумайте заново рабочие продукты, произведенные вашей командой:
Кто собирается читать каждый из них?
Детализирован ли рабочий продукт более, чем требуется для данного лица,
или он недостаточно детализирован?
Каков минимальный набор внутренних рабочих продуктов, необходимых
вашей команде для достижения главной цели?
Какой минимальный набор окончательных рабочих продуктов необходимо
произвести вашей команде, чтобы облегчить жизнь следующей команде?
Обратите внимание на различие между двумя группами продуктов.
Рассмотрите выполнение проекта как двух отдельных подпроектов:
44
Глава 1
Первый подпроект производит работающее ПО наиболее экономным спо-
собом.
Второй подпроект, конкурируя за важнейшие ресурсы с первым, произво-
дит окончательные рабочие продукты для следующей команды.
Подумайте о разработке крупной, жизненно необходимой, критически важ-
ной системы:
Будет ли для этого проекта полезнее расширение изобретения и коммуни-
кации или изолирование людей?
Каким разновидностям проектов требуется оставить в наследство больше
окончательных рабочих продуктов, а каким нужно меньше рабочих про-
дуктов?
Наконец обратите внимание на более крупную игру, внутри которой нахо-
дится ваш проект. Заметьте:
Что отвлекает ваш проект от выполнения: демонстрацияГюсетителям, уча-
стие в показах и выставках или неисправность основных элементов?
Какой вклад эти “отвлечения” вносят в более крупную игру?
Как ходы в более крупной игре подвергают риску вашу игру?
Как можно сбалансировать ходы в игре с разработкой проекта и ходы в бо-
лее крупной игре?
Все эти наблюдения и обдумывания должны обострить ваше восприятие
“команды”, “кооперативной игры”, “ходов в игре”, “изобретения и коммуника-
ции”, “построения теорий” и “достаточности”.
Понаблюдав некоторое время за разработкой ПО, повторно рассмотрите ин-
женерную деятельность вокруг вас:
Определите, где эта деятельность также представляет собой игру в изобре-
тение и коммуникацию, а где она в большей степени состоит в поиске пре-
дыдущих решений в книгах по программированию.
Когда вы достигнете некоторой легкости в представлении протекающей во-
круг вас жизни как набора двигающихся игр, попробуйте на практике:
Укрепитьдисциплину в разработке вашего проекта, в ключевых его местах
Ослабить дисциплину в ключевых местах
Объявить: “Хватит! Этого достаточно!”
Глава 2_____
Индивидуумы
Тот факт, что именно люди проектируют ПО, абсолютно очевиден и в то же время
игнорируется. После того как Вейнберг в 1969 г. опубликовал исследование о че-
ловеческом факторе, наступила тишина, затянувшаяся на 30 лет. В конце концов
ее нарушила работа ДеМарко (DeMarko) и Листера (Lister)Peopleware (1999). За
этой книгой также последовало молчание. Нам не следует ждать еще 30 лет, чтобы
узнать, как характеристики людей влияют на разработку ПО.
В данной главе обсуждается человеческая оригинальность и непредсказуе-
мость, неудачи, успехи и общие методы работы людей. Глава разбита на следую-
щие разделы:
“Необычные люди" — Здесь рассматривается, насколько люди различны и
непредсказуемы. Основная мысль в том, что, хотя к людским ресурсам применяются
общие правила работы, любые обобщения ограничены разнообразием людей.
“Преодоление неудач" — В этом разделе обсуждаются человеческие сла-
бости. Создавая коллективы совместно работающих людей, мы не должны опи-
раться на те аспекты поведения, которые часто приводят к неудачам.
“Одни способы работают лучше, чем другие" — В разделе ставится во-
прос: “Каковы естественные методы работы людей?” Когда мы пытаемся приме-
нить эти идеи, мы должны принимать во внимание людское разнообразие.
“Использование сильных сторон" — Здесь поднимается вопрос: “Что по-
могает нам все-таки добиваться успеха, если столько путей ведут нас к неудаче?”
Ответы могут вас удивить своей туманностью поначалу и эффективностью в ко-
нечном счете. В конце этого раздела показано, как успешные методы комбиниру-
ются для усиления эффекта.
В последнем разделе эти идеи связываются с повседневной жизнью.
Необычные люди
В нашей отрасли существует некоторое сопротивление идее о преобладании чело-
веческого фактора в разработке ПО.
46
Глава 2
Участвуя в исследованиях по формальным спецификациям программ, разви-
тым средам программирования и новым процессам разработки, я все время об-
наруживал, что добивавшиеся успеха команды продолжали выпускать
программы, не используя наши последние энергосберегающие идеи.
Сначала это меня раздражало: “Почему эти люди никак не поймут, насколь-
ко состоятельнее они стали бы, если бы использовали наши идеи?!”
В конце концов моя досада сменилась любопытством.
А из него мало-помалу возникло открытие.
Я перевернул свои предположения и обнаружил, что имеется противопо-
ложная взаимосвязь: чисто человеческие факторы достаточно хорошо предска-
зывают траектории проекта, доминируя над выбором процесса или технологии.
Я не нашел интересных взаимосвязей в проектах, в которых я исследовал
влияние процесса, языка или инструмента на успех процесса. Я находил успехи и
неудачи при использовании всех видов процессов, языков и инструментов.
Хорошо работающая команда компетентных людей сможет завершить про-
ект почти независимо от процесса или технологии, которые им требуется исполь-
зовать (хотя процесс и технология могут помочь им или помешать).
Дейв Томас (Dave A. Thomas) основатель Object Thechnology International,
компании с длинным списком успешных проектов, однажды так резюмировал
свою формулу успеха: “Одни люди доводят программы до окончательного выпус-
ка, другие — нет. Я нанимаю тех, кто доводит”.
В поисках характеристической функции
Если мы собираемся строить человеческие системы, мы должны понять характе-
ристики работы людей.
С некоторыми усилиями за столетия мы создали математические модели
стержней, шарниров, пружин, резисторов, конденсаторов, проводов, транзисто-
ров и других устройств. Эти математические модели хорошо нам служили при по-
строении систем из этих устройств.
Если устройство ведет себя сложно, инженерам следует постараться и пере-
проектировать систему так, чтобы ее устройства работали лишь в зоне более
простого поведения. Например, транзисторы вырабатывают выходное напряже-
ние, нелинейно зависящее от входного. Это свойство делает их прекрасными уси-
лителями. Однако, если сложность проектируемой цепи растет, эта нелиней-
ность начинает мешать и математические зависимости становятся чересчур
сложными.
Перегруженные транзисторы имеют простой выход (есть сигнал, нет сигна-
ла). Это довольно бесполезно для усилителей, но очень удобно, если нужно объе-
динить миллионы компонентов, необходимых для цифрового компьютера. На
способности транзисторов находиться в двух простых состояниях построена
компьютерная индустрия. Она не могла бы существовать, если бы с транзистора-
ми можно было работать лишь как с нелинейными устройствами.
Индивидуумы
47
Если транзисторы ведут себя сложно в активной области, то люди — еще
сложнее. Они не просто нелинейны, их нелинейность даже нельзя назвать допус-
тимой.
Если бы люди вели себя линейно, мы могли бы удвоить отдачу человека, уд-
воив объем того, что подается на входе. Но сущность человека такова, что ни
двукратное вознаграждение, ни угроза наказания, ни даже используемое время
не оказывают надежного эффекта удвоения на его качество мышления, скорость
мышления, результаты программирования или мотивацию.
Человек, работающий в одну неделю 40 часов, может удвоить результаты, ра-
ботая на следующей неделе 60 часов, если &эти дополнительные 20 часов его ни-
кто не отвлекает. Маловероятно, чтобы он снова удвоил отдачу, работая 120 ча-
сов на следующей неделе. Маловероятно даже, чтобы он сделал ту же самую ра-
боту за следующую 60-часовую неделю, поскольку усталость даст себя знать.
Мы нисколько не приблизились к созданию модели человека, одновременно
простой и достаточно точной, чтобы ее можно было использовать при проектиро-
вании системы, состоящей из людей.
Элементы отличия
Люди проявляют себя спонтанно в хорошем и плохом. Каждое из этих событий мо-
жет произойти на любом этапе проекта, иногда с серьезными последствиями:
Совершенно случайно и без видимой причины Дженни удается заметить не-
что, требующее внимания, и она кладет начало действиям, позволяющим
спасти проект.
Рон, всегда ненавидевший тестирование, внезапно находит ошибку и начи-
нает обратное тестирование своих программ.
Рон говорит Дженни что-то, кажущееся безобидным, а Дженни взрывается
от гнева.
Рон внезапно уходит из проекта из-за внешне пустячного происшествия.
Люди находят счастье в противоречиях.
Дженни небрежно выполняет один вид работы и одержима изучением дета-
лей в другой работе.
Рон общителен в одной ситуации и держит рот на замке в другой.
Люди буквально наполнены индивидуальными свойствами и особенностями,
которые изменяются в зависимости от часа, дня, возраста, уровня развития, тем-
пературы, от того, с кем они находятся в одной комнате, и т.д. Личный стиль и
склад характера — важные вещи в общении между людьми.
Связанный почти со всем на свете, человек в один момент по отношению
к другому человеку может вести себя дружелюбно, а в следующий момент агрес-
48
Глава 2
сивно с этим же или с третьим человеком. Полный детей класс может хорошо
себя вести с одним учителем и буйствовать на уроках другого. То же самое спра-
ведливо в отношении менеджеров проекта.
Люди не всегда аккуратны и педантичны, когда решают свои проблемы. Вот
как это бывает:
Дженни заполняет кроссворды, начиная с первого ключа, и идет
по пунктам до конца.
Рон заполняет кроссворды в случайном порядке.
Оба разгадывают кроссворды полностью.
Некоторые программисты выводят свои программы математически
(Gries, 1981).
Некоторые, прежде чем начать кодирование, тасуют индексные
карточки, чтобы представить себе взаимодействия
(Beck, 1989; Wilkinson, 1995).
Некоторые люди пишут код, глядя на структуру с текстом.
Кто чаще, кто реже при выработке решения движется вперед и назад,
вверх и вниз, в прямом и в обратном направлении (Guindon, 1992).
Таким образом, попытки определить нормативно, как человек должен ре-
шать задачи, приведут в тупик.
Человек, не расположенный к кропотливой работе, будет обречен на затруд-
нения с повторными проверками спецификаций интерфейса из-за незначитель-
ных упущений. У человека, думающего конкретно, вполне вероятно возникнут
проблемы с созданием объектно-ориентированной программной архитектуры.
Некоммуникабельная личность может испытывать трудности после назначения
на руководство группой.
Личность индивидуума влияет на его способность выполнять определенные
задания:
Менеджер нескольких групп в большом проекте очень хотел понравиться
другим людям. Он отказывался от принятия жестких решений, нужных
группам, и тем самым наносил проекту ущерб.
Лучший программист был назначен главой команды новичков. Не обла-
дая терпением, чтобы научить своих подчиненных, он переписывал их
код по ночам! Хотя он создавал замечательные проекты, но его группа не
получала удовольствия от работы с ним и не научилась программировать
как следует.
Разработчик спецификаций был типичным посредником. Его отношения с
заказчиками были прекрасными, но он не мог заставить себя записать их
Индивидуумы
49
требования. Для записи требований ему был необходим помощник, кото-
рый занялся бы деталями.
В каждой из этих историй процесс был ни при чем. Просто характерные осо-
бенности отдельных лиц не соответствовали характеристикам, необходимым для
выполняемой ими роли.
Личный стиль индивидуума влияет на окружающих его людей.
Представьте себе руководителей двух хорошо работающих и стабильных
групп:
Первый ориентирован на формальности и использует командный стиль ру-
ководства. Его группа к этому привыкла.
Второй действует бессистемно, дает краткие инструкции и хочет, чтобы ре-
шения принимались после обсуждения. Его группа к этому привыкла.
Теперь вообразите, что эти два руководителя меняются местами. Каждая
группа, привыкая (или так и не сумев привыкнуть) к новому стилю руководства,
будет испытывать неудобство.
Стили совместной работы отличаются культурой. Преобладающие на данной
территории культурные стили так же влияют на совместную работу, как личности
ключевых исполнителей проекта. Я признателен Лоренсу Арчеру (Laurence Archer)
за этот пример неоднократного пересечения границ между культурными стилями.
Пересечение культур
Давным-давно я консультировал компанию в Англии, менеджеру ко-
торой пришлось начать проект без посторонней помощи. Он опре-
делил границы проекта, цели, стратегию, план и т.д., а затем
собрал группу и представил ей проект.
То же самое я пытался сделать в Италии. На совещании с группой
мне заявили: "Это ваш план, вот вы по нему и работайте. Если вы
хотите, чтобы мы работали вместе, нужно и план составлять вмес-
те". Веское заявление,
ч
Затем я отправился в Австралию, где преобладала такая культура
производства, согласно которой все ошибки делают менеджеры, а
остальные просто выполняют, что велено.
Первый проект я подготовил итальянским способом. Собрал группу
в одной комнате с чистыми белыми досками, описал область дейст-
вия и цели, а затем сказал: "Теперь давайте вместе решим, как мы
собираемся это сделать".
Ответ был такой: "Вы менеджер. Вы решайте, а мы будем делать,
что скажете".
Можете себе представить аналогичные расхождения при внедрении японской
методологии разработки в индийскую группу (или наоборот) или при использова-
50
Глава 2
нии методологии проектирования военного самолета в начинающей фирме, спе-
циализирующейся на электронной торговле (или наоборот).
Неминуемое разнообразие
В результате различий между людьми были изобретены многие технические подхо-
ды. Но для каждой модной философии находится ее противоположность, которую
где-то еще не менее усердно используют. Ни один подход не завоевал господства.
Скорее можно сказать, что каждый из них нашел поддержку у благожелательного
программиста, и с ростом численности программистов его использование также вы-
росло. Как число способов создания программ будет продолжать расти, так и раз-
личающиеся подходы будут укрепляться, находя свои группы поддержки.
Все это кажется очевидным — вплоть до приложения к конкретному проек-
ту. Однако люди склонны это забывать, когда предписывают проекту методоло-
гии разработки ПО и объявляют о “правильном” способе работы. Хуже того,
часто они надеются, что каждый участник проекта станет использовать этот
единственный подход.
Хорошо, когда в вашей группе собраны разные люди: думающие абстрактно
и конкретно, применяющие упорядоченные и бессистемные подходы, те, кто лю-
бит погрузиться во внутреннее устройство системы, и предпочитающие проекти-
ровать пользовательский интерфейс, документирующие системную структуру и
продающие конечный продукт. Имея в своей команде людей с различными осо-
бенностями, можно позволить им работать в тех областях, в которых они сильны.
То же самое разнообразие, которое ведет к сложностям в общении и трениям
между личностями, дает такую эффективность, что смешанные команды часто
превосходят однородные группы (Sully, 1998).
Существование различий между людьми не означает, что все общие утверж-
дения о людях ложны. Отдельные наши высказывания справедливы в широком
смысле и разнятся, главным образом, по количеству и составу людей, для кото-
рых это верно. Мы будем основываться на этих утверждениях, даже принимая
существующее людское разнообразие.
На что мы, однако, не можем рассчитывать, так это на предсказуемость и оди-
наковость людей.
Место технологии
Технология повышает эффективность при наличии любых из следующих четырех
условий:
Когда она позволяет людям легче выразить свои мысли. Языки высокого
уровня дают возможность более сжато выражать идеи. Некоторые языки
высокого уровня позволяют человеку мыслить в технологическом про-
странстве, приближенном к проблемному пространству, почти не отвлека-
ясь на мысли об ограничениях реализации.
Индивидуумы
51
Когда она выполняет задачи, невыполнимые вручную. Инструменты изме-
рения и анализа собирают данные, которые иначе собрать было бы невоз-
можно. Программисты говорят о них как об основных инструментах.
Когда она автоматизирует утомительные и подверженные ошибкам дейст-
вия. Компиляторы, электронные таблицы и средства управления конфи-
гурацией ПО настолько важны, что некоторые программисты даже не
упоминают о них как об инструментах, а просто предполагают их наличие.
Когда она облегчает общение между людьми. В мире распределенной раз-
работки ПО все виды инструментов обмена информацией помогают коман-
де работать.
Обратите внимание, что, за исключением компиляторов, все инструменты
позволяют людям принимать решения. Они обеспечивают обратную связь и дают
возможность обдумать результат.
Программисты десятилетиями жаловались на то, что компиляторы не могут
назначать регистры и строить последовательность команд так же хорошо, как
люди. Когда в конце концов стало ясно, что компилятор может это делать, люди
забыли о назначении регистров, повернувшись к проблемной области — работе
над алгоритмами и программной структуре.
Технология не повышает эффективность до такой степени, чтобы действовать
против характера культурных ценностей и познавательной способности человека.
Консультанты опытом не обмениваются
Консультирующая фирма, желающая усилить использование техни-
ческого опыта своих консультантов, установила программу Lotus No-
tes и поощряла консультантов обмениваться техническими
заметками и помогать друг другу.
Руководители фирмы забыли, что консультанты поддерживают свою
конкурентную ценность благодаря владению секретами. Для этих
консультантов знание было не просто силой — это был доход.
База данных Notes оставалась загадочно пустой, несмотря на посто-
янные призывы высших менеджеров к консультантам поделиться
секретами.
Противоречивые обобщения
Читая следующие разделы, имейте в виду, что, когда мы говорим о людях, начина-
ют проявляться идеи, кажущиеся противоречивыми.
Хотя люди различаются между собой, можно сделать несколько широких
обобщений, однако в то же время эти обобщения будут иметь исключения.
В этом разделе обсуждалась идея исключений. Теперь посмотрим на отдель-
ные обобщения.
52
Глава 2
Преодоление неудач
Трюгве Реенскауг (Trygve Reenskaug) предостерегал меня от обсуждения неудач.
‘Дурная слава, напомнил он мне старую поговорку, — накрепко пристает”.
Риск состоит в том, что некоторые люди будут пользоваться моим перечислением
неудач для оправдания своей плохой работы. Трюгве напомнил мне, как часто то,
что считают неудачей человека, в большей степени относится к рабочей среде. Это
иллюстрирует следующая рассказанная им история:
Магазин мелочей
Поблизости находился магазин мелочей и пуговиц, постоянно пребы-
вавший в ужасном состоянии. Там царила полная неразбериха, а
продавщицы или занимались своими ногтями или висели на телефоне
и не обращали на покупателей никакого внимания.
Это дело закрылось, и другой магазин мелочей и пуговиц открылся
на его месте. Замечательный магазин! Там было чисто, повсюду по-
рядок, и продавщицы вели себя с покупателями очень внимательно.
Только вот ... это были все те же две продавщицы!
Усовершенствования в СЗ
Проект Chrysler Comprehensive Compensation испытал несколько из-
менений, упомянутых в этой истории (СЗ, 1998).
Поначалу в команде ценились девизы: "думай наперед", "детальные,
но расширяемые проектные решения" и "мой код закрыт".
В значительной степени побуждаемая к этому Кентом Беком, коман-
да перестроилась, и ее главными ценностями стали "делай просто и
ясно", "ни к чему эти тонкости", "весь код открыт" и "любая пара
человек, сидящих рядом, может поменять все что угодно". После
этих изменений те же люди усвоили другой чрезвычайно дисциплини-
рующий набор правил.
С учетом сказанного выше замечу, что людям свойственны определенные
разновидности неудач. Я регулярно встречаю методологии и проекты, терпящие
крах, поскольку они не принимают во внимание эти человеческие особенности.
Если мы будем явно принимать их в расчет, то можем строить человеческие сис-
темы с меньшей вероятностью отказов.
Мы принимаем в расчет следующие пять видов неудач:
Люди совершают ошибки.
Люди предпочитают консервативное поведение, хотя бы и ведущее к неудаче.
Люди изобретают чаще, чем исследуют.
Люди — рабы привычек.
Люди непоследовательны.
Индивидуумы
53
Совершение ошибок
Нас не удивляет, что люди совершают ошибки. На самом деле именно поэтому
изобрели итерационную и инкрементную (пошаговую) разработку.
Итерационной называют стратегию планирования и тестирования, позволя-
ющую дорабатывать и переделывать части системы.
Итерационная разработка позволяет команде проанализировать требования
и построить проект системы. Гради Буч (Grady Booch) называет это “круговым
проектированием (round-trip design)” (1994), выражая в этом термине способ-
ность человека изучать, добиваясь совершенства.
Итерационные планы сложно готовить, поскольку заранее сложно предпо-
ложить, как много времени потребуется на анализ и проектирование. Чтобы пре-
одолеть это затруднение, некоторые составители планов просто фиксируют три
итерации: эскизное проектирование, детальное проектирование и проектирова-
ние с испытаниями.
Инкрементной называют стратегию планирования и тестирования, в которой
части системы разрабатываются с различной скоростью или в разное время и
объединяются, когда их разработка завершена.
Инкрементная разработка позволяет команде разобраться в собственном про-
цессе разработки, а не в проектируемой системе. После создания части системы
участники команды исследуют принятые соглашения и ищут, что следует улучшить.
Они могут изменить структуру группы, методы или выдаваемые результаты.
Инкрементный метод проще для освоения, поскольку разделить проект на
подпроекты легче, чем решить, когда прекратить улучшать продукт. Инкремент-
ная разработка — важнейший фактор успеха для современных проектов (Cock-
burn, 1998).
Истинной причиной применения инкрементной и итерационной стратегий
является желание относительно рано обнаружить неизбежные ошибки людей и
аккуратно их исправить.
Ошибки, совершаемые людьми, не должны быть для нас сюрпризом. Все
же некоторые менеджеры выглядят искренне удивленными, когда команда раз-
работки объявляет о плане работать по инкрементному или итерационному ме-
тоду. Я слышал о менеджерах, которые отвечают, например, так:
“Как это не знаете, какое нужно время?”
или
“Что значит — вы планируете сначала все сделать неправильно? Я
выйду на улицу и найму кого-нибудь, кто пообещает все сделать, как
надо, с первого раза”.
Иными словами, менеджер рассчитывает, что команда разработки не будет
делать серьезных ошибок и не преподнесет в проекте ничего нового.
54
Глава 2
Нетрудно найти людей, которые пообещают сразу все сделать правильно, но
маловероятно найти таких, кто действительно все сделает сразу. Люди ошибают-
ся в оценках, при подготовке требований, проектировании, вводе данных, прове-
рочном считывании, установке, тестировании ... и во всем остальном, что они
делают. Спасения нет. Мы должны принять как факт, что ошибки будут совер-
шаться, и использовать процессы, исправляющие ошибки.
При всей очевидности совершения людьми ошибок поразительно, что менед-
жеры по-прежнему отказываются использовать инкрементную и итерационную
стратегии. Я могу возразить, что такое поведение вполне объяснимо, поскольку
оно закреплено в двух видах неудач: предпочтительности консервативного пове-
дения, пусть даже ведущего к неудаче, перед риском не преуспеть на другом пути,
и трудности изменения привычек в работе.
Предпочтительность консервативной неудачи
Существуют доказательства, что люди, как правило, не расположены к риску, ког-
да они держат что-то в руках и могут это потерять, но считают риск приемлемым,
когда они что-то теряют и имеют шанс вернуть это себе (Piattelli-Palmarini, 1996).
Пиателли-Пальмарини описывает несколько экспериментов, касающихся
риска и вознаграждения. Интересно, что даже при математически тождествен-
ных исходах результаты различаются в зависимости от способа представления
ситуации.
Иллюзии выбора
Пиателли-Пальмарини ссылается на состоящий из двух частей экспе-
римент. В первой части людям дают по 300 долларов, а затем пред-
лагают сделать выбор: гарантированно получить еще 100 долларов
или получить 200 долларов с шансом 50 на 50.
Люди предпочитают взять гарантированные 100 долларов.
Во второй части эксперимента людям дают по 500 долларов, а затем
предлагают выбрать: вернуть 100 долларов или вернуть 200 долла-
ров с вероятностью 50 на 50.
Люди предпочитают рискнуть, чтобы не отдавать ничего.
(Piattelli-Palmarini, стр. 58)
Математически все исходы равны. Интересно различие результатов в зави-
симости от формулировки задачи.
Пиателли-Пальмарини делает вывод, имеющий отношение к менеджерам
проектов: мы не расположены к риску, когда можем выиграть.
Рассмотрим менеджера, столкнувшегося с заменой стратегии каскадного
подхода инкрементным или итерационным планированием. Каскадный подход
принят как обычный, консервативный способ ведения дела, пусть даже некото-
рые считают его ошибочным. Менеджер несколько раз использовал эту страте-
Индивидуумы
55
гию с переменным успехом. Теперь же сотрудники из его группы приходят к нему
с радикально иным предложением. В новом подходе он видит существенную
опасность. А от этого проекта зависит его репутация. Станет ли он использовать
обычную, консервативную стратегию или попробует рискованную новую?
Перевес на стороне обычной, консервативной стратегии, дающей “гаранти-
рованный” стандартный исход, а у той, которая может работать, а может и все
испортить, шансов меньше.
Эта характеристика, “предпочтительность консервативного поведения, пусть
даже ведущего к неудаче, перед риском преуспеть на другом пути”, соединяется с
боязнью неудачи и с трудностями приобретения новых рабочих привычек. Эти
три особенности совместно объясняют (для меня), почему менеджеры продолжа-
ют использовать однопроходный каскадный процесс разработки, который давно
ругают. Базируясь на этих рассуждениях, я полагаю, что люди будут продолжать
использовать каскадный процесс даже при росте числа свидетельств против него
и повышающейся поддержки инкрементной и итерационной разработки. Исполь-
зование каскадного процесса связано с неудачами.
В соответствии с разнообразием людей некоторые имеют противоположную
склонность. Однако часто к разряду авантюристов принадлежат люди, которые
лично теряют очень немного в случае неудачи проекта.
Можно сделать два вывода. Хороший вывод состоит в том, что существуют
две разновидности людей и каждая имеет возможность действовать. Плохой вы-
вод — и те и другие могут оказаться вместе в одном проекте.
Не исследование, а изобретение
Этот вид поведения, возможно, характерен исключительно для разработчиков ПО
в Америке и Европе. (У меня нет достаточного опыта работы с индийскими и други-
ми азиатскими разработчиками, чтобы я мог комментировать их привычки.) Он со-
стоит в стремлении уклониться от исследования предыдущих решений, чтобы
просто изобрести новое решение задачи.
Эту склонность обычно описывают как болезнь, синдром неприятия чужой
разработки (Not-Invented-Here, NIH). Я предпочитаю считать это поведение не
заболеванием, а естественным результатом культурного давления. Это можно
также назвать императивом собственной разработки (Invent-Here-Now). Он воз-
никает следующим образом.
Еще с начальной школы ученикам запрещают списывать с чужих работ, помо-
гать друг другу и требуют быть как можно более оригинальными во всем, кроме
механического запоминания некоторых фактов. Ученики получают положительные
оценки за оригинальность и наказываются за использование чужих решений. (Не-
давно учитель в четвертом классе велел своим ученикам не звонить друг другу для
обсуждения домашнего задания и даже не спрашивать, что задано!)
При обучении в университете студенты получают задания, оцениваемые не
за командную, а за индивидуальную работу. Своей кульминации этот процесс до-
56
Глава 2
стигает в диссертации на степень доктора философии, для которой главным тре-
бованием является оригинальность.
В процессе обучения некоторые люди выбирают профессию программиста,
т.е. человека, чья работа заключается в программировании и кто делает успехи,
разрабатывая более надежные и более уникальные, оригинальные программы.
В таких условиях неудивительно, что программисты усваивают императив
собственной разработки.
Однако, приступив к работе, те же самые люди получают указания от владе-
льцев бизнеса не писать новые программы, а искать готовые решения, созданные
в отрасли за всю историю ее существования. Они должны использовать как мож-
но больше существующих решений, не нарушая прав на интеллектуальную соб-
ственность.
За эту деятельность предлагается скудное вознаграждение. Люди продолжа-
ют получать низкие оценки за повторное использование кода вместо написания
нового кода. Поощряются те, кто больше и лучше программирует, а не те, кто
успешно соединяет существующие компоненты. Авторы технической литературы
по-прежнему называют таких людей “сборщиками компонентов”.
Фрейкс (Frakes) и Фокс (Fox) провели исследование и обнаружили, что обра-
зование и отношение, всего лишь дающие людям понять, что культура ценит по-
вторное использование выше разработки новых решений, показали наиболее
сильную взаимосвязь с повышением степени повторного использования (Frakes,
1995). Структура вознаграждения не оказала значительного эффекта, как и объек-
тно-ориентированные технологии, CASE-инструменты и масса других факторов.
Компания Texas Instruments боролась со своим синдромом неприятия чужой
разработки, присуждая необычную награду “А я все равно использую чужие раз-
работки” (“Not Inventend Here But I Did It Anyway”, Dixon, 2000). Эта награда
NIHBIDIA не только поощряет использовать предыдущие результаты, но в то же
время и подшучивает над теми, кто поражен синдромом NIH. Таким образом, она
создает социальный эффект того типа, о котором упоминали Фрейкс и Фокс.
Профессионалы в других областях эффективно практикуют повторное испо-
льзование. Обращаясь к компьютеру для выполнения серьезного задания в дру-
гой области, они формируют свое ощущение достижения не мастерством
программирования, а результатом выполнения программы для другой области.
У них, следовательно, имеется мотивировка объединять ПО, чтобы выполнить
основную работу. Они охотно принимают менее эффектную конструкцию, если
можно быстрее приступить к использованию ПО.
Непоследовательность рабов привычек
Попросить человека изменить привычки или быть последовательным в действи-
ях — это две самые трудные просьбы, которые приходят мне на ум. Мы рабски
следуем привычкам, сопротивляющимся изучению нового поведения, и в то же
время склонны быть непоследовательными.
Индивидуумы
57
Это суждение может показаться суровым, поэтому я проиллюстрирую его на
примере. Разговаривают четыре человека, каждый из которых был старшим ме-
неджером или доктором философии, т.е. это люди, от которых в наибольшей сте-
пени можно было бы ожидать последовательности или способности поменять
привычки.
Метод чистого стола
Один из четверых сказал: "Я страдаю от потока бумаг, наводняюще-
го мой кабинет. Ума не приложу, как с этим справиться".
Второй предложил: "Это просто. Содержи свой стол в абсолютной
чистоте. Поставь четыре корзины с одной стороны и положи неско-
лько папок в верхний ящик. Когда появится новая бумага, распоря-
дись ею сразу и положи в подходящее для нее место..."
Но он не успел высказаться полностью, поскольку остальные трое
вскочили с мест и прокричали: "Содержать стол в чистоте? Я не
могу этого сделать!"
Второму участнику разговора так и не удалось закончить объяснение своего
метода. Он высказал пожелание, чтобы люди действовали бережно и на 100%
последовательно. Не многие способны на это свершение. Большинство же людей
меняются каждый час, причем за хорошим временем следует плохое. Некоторые
люди даже знамениты своей непоследовательностью и неаккуратностью.
Второй участник разговора не просто просил их быть последовательными,
более того, он попросил их поменять привычки и быть последовательными в этом
изменении.
Эта история говорит мне как методологу, что, если даже мы найдем оптима-
льный процесс проектирования, люди сначала будут ему сопротивляться, а затем
станут использовать нерегулярно и небрежно.
Если бы только люди могли просто действовать последовательно...
Конечно, если бы они были на это способны, они содержали бы свои столы
в чистоте, пломбировали зубы, сбрасывали лишний вес, бросали курить, игра-
ли на музыкальных инструментах и, возможно, даже писали программы прави-
льно и в срок.
Нам уже известно несколько хороших методов:
Дэвид Грис (David Gries) подробно описал, как получить правильную про-
грамму, в книге The Science of Programming (1981).
Беки Каннигем (Beck & Cunningham, 1989) и Уилкинсон (Wilkinson, 1995)
описали использование CRC-карт в объектно-ориентированном проекти-
ровании.
Бек (2000) и Джеффрис (Jeffries, 2001) описали парное программирование
и проектирование с немедленным тестированием в контексте Extreme Pro-
gramming.
58
Глава 2
Тщательная проверка проектирования и статистическое тестирование по-
дробно изложены в методологии Cleanroom (Becker, 1996).
Хамфри (Humphrey, 1997) в своей работе Personal Software Process предо-
ставил детальные инструкции, помогающие программистам добиться боль-
шей эффективности при поиске внесенных ошибок.
Последовательное применение любой из вышеперечисленных идей могло бы
улучшить значительную часть проектов, с которыми я знаком. Как съязвил Карл
Вигерс (Karl Wiegers): “Мы не испытываем недостатка в практических методах,
но испытываем недостаток в практике их применения”.
Возражения против дисциплины и терпимости
Методологи имеют дело с общими слабыми местами человека — недостатком дис-
циплины и терпимости. Они:
Создают в методологии механизмы, придерживающиеся точных стандартов
поведения.
Проектируют методологию, терпимую к отклонениям отдельного лица.
Большинство выбирает дисциплину.
Поскольку непоследовательность в действиях — это слабость человека,
дисциплинирующие методологии характеризуются хрупкостью. Даже когда они
содержат хорошие методы, люди едва ли будут продолжать их применять в тече-
ние долгого времени. В разработке ПО ежедневное применение дисциплиниру-
ющего действия так же тяжело, как поддержание стола в чистоте по
упомянутой методике.
Чтобы дисциплинирующую методологию применяли, она должна содержать
специфические элементы поддержания дисциплины.
Рассмотрим вкратце три дисциплинирующие методологии: Cleanroom, Per-
sonal Software Process и Extreme Programming.
В Cleanroom промышленный код не разрешается компилировать до сдачи.
Опечатки и синтаксические ошибки считаются частью контролируемого стати-
стического процесса (новые языковые средства и системные вызовы изучаются
на непромышленном коде). Команда разработчиков, выполняющая компиляцию,
может затем определить темп появления ошибок во время ввода программ.
Это дисциплинирующее правило требует явной поддержки управления и про-
верки ошибок.
В методологии Personal Software Process практик должен записывать про-
должительность каждого действия и заносить в таблицу точки внесения ошибок.
По этим заметкам человек может определить, какие действия наиболее подвер-
жены ошибкам, и больше сконцентрироваться на них в следующий раз. Слож-
ность, безусловно, состоит в том, что для ведения журналов требуется
Индивидуумы
59
прикладывать дополнительные усилия и последовательно повторяющиеся дейст-
вия. Ненадлежащее их выполнение сводит действие PSP на нет.
PSP не содержит специфических механизмов для поддержания дисциплини-
рующих методов. Поэтому не слишком удивительно обнаружить нижеследующий
отчет об опыте работы, исходящий из весьма дисциплинированной группы разра-
ботки. Слова, посвященные PSP, были написаны группой военных, обучавшихся
применять PSP и достигших пятого уровня согласно модели SEI СММ (Software
Engineering Institute Capability Maturity Model) (Webb, 1999).
Отчет о PSP
“В течение лета 1996 г. небольшая группа специалистов по разработ-
ке ПО была ознакомлена с PSP.
Хотя обучение в целом было воспринято хорошо, использование PSP
начало снижаться, как только курс был завершен. Скоро никто из спе-
циалистов, обучавшихся приемам PSP, не применял их в своей работе.
Ответ о причине был практически единодушным: "PSP крайне стро-
гий инструмент, и когда никто не требует у меня данные, легче ра-
ботать по-старому".
Extreme Programming (ХР) — третья методология, содержащая дисципли-
нирующие приемы. Ей требуется парное программирование (с ротацией пар), ис-
черпывающее и автоматическое тестирование элементов, завершенное до
ежедневной сдачи кода, строгое соблюдение стандартов кодирования группы и
активная реорганизация (refactoring) базового кода.
Ориентируясь на приведенные выше обсуждения, я ожидал, что в большин-
стве групп приверженность методам ХР будет недолговечна. Однако результаты
моих бесед оказались до некоторой степени удивительными.
О парном программировании все говорили с удовольствием. Следовательно,
на программирование в паре люди идут довольно охотно, когда привыкают к чу-
дачествам друг друга. При парном программировании легче убедить друг друга
писать тестовые примеры и выполнять требования стандартов кодирования.
Основная часть ХР, требующая строгой дисциплины и не чувствительная
к парному программированию, относится к реорганизации кода. Все-таки ока-
зывается, что большинство членов команды не часто выполняют это действие,
в основном оставляя его старшему в проекте липу.
Однако, в отличие от PSP, Extreme Programming содержит специальный ме-
ханизм, помогающий следить за дисциплиной. Он требует, чтобы один человек
действовал в роли “наставника” и поддерживал в участниках команды восприим-
чивость к способу использования методологии.
Интересно отметить, что все эти три методологии были придуманы людьми,
которые сами последовательны в привычках и хотят привить это другим. Поэто-
му неверно, что методы со строгой дисциплиной нельзя использовать. Просто
они очень “хрупкие”.
60
Глава 2
Альтернативные методы не требуют соблюдения дисциплины — они толе-
рантны к разнообразию людей.
Adaptive Software Development (Highsmith, 2000) и семейство методологий
Crystal, описанное в этой книге, — вот лишь две известные мне методологии, явно
относящиеся к числу “толерантных к разнообразию”. Обе методологии требуют,
чтобы участники команды достигли согласия о минимальном соответствии рабочих
продуктов и технологических методов. Каждая методология предполагает исполь-
зование стандартов^ но не требует, чтобы они соблюдались обязательно.
Чтобы “толерантные” методологии работали, участвующие в проекте люди
должны обладать чувством долга и вообще гордиться своей работой. В таких
проектах в людях развивается личная заинтересованность в конечном результа-
те. Достичь этого не легче, чем следовать стандартам, и, хотя это не гарантирует-
ся, я сам бываю тому свидетелем регулярно. Об этом же сообщает Диксон
(Dixon, 2000, стр. 32).
Какая методология лучше — со строгой дисциплиной или с высокой толе-
рантностью?
Строгого выполнения жестких (и эффективных) методов труднее добиться,
но в конечном счете они могут быть более продуктивны.
Толерантные методы должны быть проще в усвоении, но могут быть менее
продуктивны.
Частично сложность выбора между двумя видами методологий объясняется
отсутствием в настоящее время согласия об их эффективности или неэффектив-
ности при различных обстоятельствах. Из-за этого руководители проектов могут
потребовать строгого следования методам, которые считают эффективными, и мо-
гут быть удивлены, получив негативный результат.
В истории о постоянном документировании в главе 1 был представлен при-
мер ошибочной приверженности дисциплине. Спонсоры требовали, чтобы каж-
дое изменение в любой части системы немедленно отражалось во всей
документации. Они, вероятно, думали, что это будет эффективная практика. Од-
нако в их ситуации она оказалась слишком дорогой, и от проекта отказались.
Другими словами, строгая приверженность эффективным приемам ведет к
эффективности команды, а строгая приверженность неэффективным приемам
ведет к неэффективности команды.
Если бы только знать, какие из них — какие.
Одни способы работают
лучше, чем другие
Напомнив себе, что люди различаются, что имеют место отдельные широкие обоб-
щения и что из каждого обобщения есть исключения, рассмотрим некоторые есте-
ственные способы работы людей.
Индивидуумы
61
Как правило, люди работают лучше, начиная с чего-то конкретного и осязае-
мого, с каких-нибудь примеров, скорее изменяя, чем создавая все с чистого лис-
та, наблюдая и получая ответную реакцию.
Одно из моих любимых высказываний исходит от Венгера и Лейва (Wenger,
Lave, 1993) и относится к силе конкретного:
“Мир несет свое строение, поэтому своеобразие всегда подразумевает
общность (и в этом смысле общность не следует приравнивать к абст-
рактности). Вот почему истории так убедительно могут передавать
идеи, часто более убедительно, чем произнесение самой идеи”.
Конкретное
Познавательное исследование поддерживает идею, согласно которой наше созна-
ние действует непосредственно на основе конкретных примеров (идею, в высшей
степени гармонирующую со свойствами нейронной сети).
Джонсон-Лейрд и Берн (Johnson-Laird, Вугп, 1991) предполагают, что люди
осуществляют логический вывод, не применяя в уме исчисления предикатов, а
воображая конкретные ситуации и конкретные контрпримеры. Например, в за-
даче о бильярдных шарах “можно выработать правила, объединяющие предполо-
жения, но кажется правдоподобным, что люди будут ее решать, воображая
расположение шаров”.
Эти авторы предполагают, что при выполнении логического вывода мы:
1. Строим внутреннюю модель состояния дел, которую описывают
посылки.
2. Формулируем краткое описание построенной модели — идеально
утверждающей что-то, неявно заявленное посылками.
3. Ищем альтернативные модели посылок, в которых предполагаемый вы-
вод ложен.
Заметьте, что даже третий, проверочный шаг включает построение конкрет-
ных примеров.
Роберт Гласс (1995, стр. 178) рассказывает об удивительно похожей версии
процесса разработки ПО. Цитируя других исследователей, он пишет, что люди,
составляя планы, выполняют следующие шаги:
1. Строят в уме модель предлагаемого решения задачи.
2. Мысленно выполняют модель, чтобы понять, действительно ли она ре-
шает задачу, обеспечивают для модели простые входные данные, чтобы
проверить, правильный ли получается ответ.
3. Когда достаточное число входных образцов проходит тест, решают, что
’ модель подходит для проекта, и приступают к его представлению.
62
Глава 2
Если люди действительно используют в своем мышлении конкретные ситуа-
ции, значит, мы должны найти такие артефакты среди рабочих продуктов програм-
мистов. Двумя такими артефактами являются популяции пользователей и ди-
аграммы взаимодействия.
Применяя прием популяции пользователей, команда разработчиков созда-
ет составную схему одного или нескольких фиктивных пользователей системы.
В идеале придумывают нескольких пользователей: один из них ленивый, другой
фанатично ориентирован на детали, третий является экспертом по всем сокра-
щенным клавиатурным командам, четвертый медленно обучается и т.д. Эти со-
ставные схемы составляются настолько конкретными и реальными, насколько
это возможно — воображаемые пользователи даже могут получать имена. Поло-
жив очень конкретные изображения будущих пользователей перед группой про-
ектирования, команда может легче себе представить их разнообразное
реагирование на систему и сможет создать системные возможности, приспособ-
ленные к этим разновидностям пользователей.
Диаграммы взаимодействия (двух видов: диаграммы кооперации и диаграм-
мы последовательности) рассказывают о контактах объектов во времени. В них
рисуются экземпляры объектов и стрелки, показывающие передачу сообщений
между ними. На диаграммах кооперации объекты размещаются на странице про-
извольно, а между ними изображаются стрелки и нумеруются, чтобы показать
упорядочение по времени сообщений. На диаграммах последовательности все
объекты помещаются сверху страницы как заголовки столбцов. Взаимодействия
показываются сверху страницы вниз стрелками от одного столбца к следующему.
Из этих двух видов диаграмм диаграммы последовательности рекомендуются
для многих методов объектно-ориентированного проектирования. Диаграммы ко-
операции, математически изоморфные диаграммам последовательности, так редко
упоминаются в методологических текстах, что лишь после нескольких лет препода-
вания я заметил, что начинающие часто показывали мне результаты их исследова-
ния не на диаграммах последовательности, а на диаграммах кооперации.
Я подозреваю, что диаграммы кооперации не упоминаются в методологиях,
поскольку являются временными артефактами. Они полезны при создании про-
ектов и при общении по поводу конкретных ситуаций, но не сохраняются в конеч-
ной, сильно очищенной документации проекта, которую команда разработчиков
должна выпустить.
Когда мы станем лучше сохранять записи о скоротечных обсуждениях, я
рассчитываю, что эти диаграммы будут чаще использоваться при проектирова-
нии и в документации.
Осязаемое
После конкретного создается что-то осязаемое, что можно потрогать руками.
В середине 1980-х годов Пелле Эн использовал прототипы на бумаге, чтобы
в союзе наборщиков узнали, как компьютерные системы могут им помочь. Он
Индивидуумы
63
пользовался картонными коробками и листами бумаги, представляющими экран
компьютера и его содержимое, чтобы понять, как еще пока невообразимая сис-
тема может работать. Люди медленно продвигались по их ежедневным операци-
ям, чтобы узнать, каким образом компьютер может быть им полезен. Им было
удобно манипулировать этим осязаемым, подвижным, выглядевшим незавер-
шенным реквизитом. Бумажные прообразы пользовательского интерфейса пре-
вратились в излюбленный материал профессиональных проектировщиков этих
интерфейсов (Hoffmann).
На ранних стадиях проектирования пользовательского интерфейса такие
“низкокачественные” прообразы считаются даже более эффективными, чем эк-
раны, тщательно имитируемые на экране реального компьютера. Они не только
осязаемы, но и как бы приглашают человека их изменить.
Черновые архитектурные наброски
Архитектор, проектирующий больницу, рассказал мне, что никогда
не показывает заказчикам нарисованный компьютером план строе-
ния. Заказчики не хотят портить такой красивый план, что бы им ни
говорили.
Поэтому он всегда рисует план карандашом, и в этом случае они не
стесняются на нем чертить.
Одну из реализаций низкокачественных приемов имитации называют инфор-
мансом (informance, Burns, 1994). Информанс, или интерактивное исполнение,
представляет еще не построенную систему в ее прогнозируемом будущем окру-
жении с помощью настолько конкретной имитации, что люди могут с ней взаимо-
действовать. Информанс позволяет пользователям-испытателям войти в жизнь
будущего пользователя в реалистичной будущей среде.
В одном известном информансе был показан стилист по прическам, исполь-
зующий предлагаемую систему во время стрижки волос. В другом группа создала
демонстрационную квартиру, где актеры играли роли пациентов, которые, оста-
ваясь в постелях, используют компьютеры для разговоров и общения.
Делая окружение информанса конкретным, каждый вовлеченный в разра-
ботку человек может видеть сильные и слабые стороны предложенной идеи.
Упомянутая ранее CRC-карта — популярная технология проектирования,
использующая преимущества осязаемости. В этой технологии на стол кладется
индексная карточка, представляющая специальный экземпляр объекта, который
предлагается использовать в проекте. Проектировщик берет карту и перемещает
ее, исследуя ее поведение по отношению к другим картам на столе.
CRC-карты служат конкретными и осязаемыми примерами, помогающи-
ми проектировщикам комбинировать конкретные ситуации. Они последовате-
льно сообщают, что перенос этих приемов в компьютер снижает их
эффективность.
Когда человек берет со стола пару карт и говорит: “Этот объект посылает ...
этому объекту ... запрос на выполнение АВС ... Нет, неверно, попробуем другой
64
Глава 2
вариант то включается эмоциональная и физическая реакция на качество
проекта.
Изменение
Копирование и изменение предыдущей работы — это стандартный метод работы
человека, используемый почти ежедневно во всех областях.
Приступая к созданию нового письма, накладной, заявки, документа, про-
граммы или плана проекта, человек находит выполненный раньше образец, ко-
пирует его в новую рабочую область и преобразует все частности, пока рабочий
продукт не станет таким, каким он должен быть. Повар будет копировать рецепт
и изменять лишь один его компонент. Менеджер проекта заимствует план преды-
дущего проекта и переделывает лишь несколько строк, чтобы отразить специфи-
ку текущего проекта. Аналогично копируются и изменяются документы о
требованиях и схемы баз данных. Дети (и взрослые) учатся программированию
гипертекстов, копируя чужую программу и наугад внося простые изменения.
Программа "Говорящий попугай"
Моей первой Smaltalk-программой был редактор диаграмм последо-
вательности.
Еще не зная Smal+alk, я скопировал из обучающей программы при-
мер "Говорящий попугай" и заменял каждую его строку, пока не
получил свой редактор. От первоначальной программы не осталось
ничего, кроме использования сложной архитектуры "модель-пред-
-ставление-контроллер" (Model-View-Controller, MVC), о которой в то
время я ничего не слышал.
Годом позже у моих коллег возникли проблемы, когда они изменяли
свои программы, чтобы получить ввод не с клавиатуры, а из сети, но
у меня никаких затруднений не возникало. Оказалось, что архитекту-
ра MVC, которую я нечаянно скопировал из “Говорящего попугая",
значительно облегчила мне жизнь.
Этот прием “копирования и изменения” применялся даже к завершенным
приложениям.
В конце 1990-х годов авиакомпании обменивались приложениями “frequent-
flyer” (программа присуждения бонусов частым путешественникам). Эти приложе-
ния сами по себе не давали авиакомпаниям значительного выигрыша в конкурент-
ной борьбе. Поэтому одна компания могла возместить расходы на разработку,
продав приложение своему конкуренту. Покупатель получал от предыдущей ком-
пании графическую модель, генерирующую код приложения, требующий настрой-
ки, а также фактический сгенерированный и настроенный код. Покупатель
понимал, что приложение не будет абсолютно корректным, но ему потребуется по-
тратить меньше усилий на изменения, чем на построение его с нуля.
Гласс (Glass, 1995, стр. 182) сообщает, что первая проектная модель
Индивидуумы
65
“вполне может использоваться повторно, а не создаваться проекти-
ровщиком для решения конкретной задачи. Виссер (Visser, 1987) об-
наружил, что для задач, с которыми проектировщики сталкивались ра-
нее, они применяют ’’примерную программу" как отправной пункт, и за-
метил, что проектировщики редко начинают с нуля".
Вы можете и должны использовать сильные стороны человека, копируя и из-
меняя рабочие образцы. Создайте небольшую библиотеку реальных образцов для
рабочих продуктов, произведенных в вашем (или в каком-либо предыдущем) про-
екте. Другие смогут просто скопировать один из образцов как базу для собствен-
ной работы. Копируя его, они позаимствуют из образца структуру и стиль, а под-
робности изменят так, чтобы они соответствовали их цели.
Конечно, имеет смысл коллекционировать относительно “хорошие” образ-
цы, со структурой и стилем, которые вы захотите копировать. От них не требует-
ся совершенства, но они должны быть “достаточно хорошими”.
В одной книге это уже сделано. Книга Developing Object-Oriented Software:
An Experience-Based Approach (IBM OOTC, 1997) представляет собой собрание
образцов рабочих продуктов, использованных в Центре объектно-ориентирован-
ных технологий (ООТС) компании IBM в различных проектах в середине 1990-х
годов. ООТС избежал борьбы из-за методологий, представив примеры различ-
ных рабочих продуктов и позволив любой команде проектировщиков выбирать
примеры, которые ей требовались.
Вы могли заметить, что во многих предшествующих историях используются
элементы на удивление низкоуровневых технологий, часто включающие бумагу и
картон. Об успешном опыте управления знаниями и их передачи в Международ-
ном банке реконструкции и развития О’Делл (O’Dell, 1998) написал соответст-
вующее наставление:
“Чтобы получить наилучшие результаты, возьмите одну столовую
ложку низких технологий и одну столовую ложку высоких технологий.
Перемешайте и выпейте”.
Наблюдать и слушать
Люди умеют учиться, как делая, так и наблюдая.
Венгер и Лейв (1993) рассматривают успех и неудачу в профессиях, осно-
ванных на ученичестве. Они подчеркивают ценность прямой видимости и непо-
средственной слышимости при обучении этим профессиям. Прочитав их книгу, я
пришел к следующему печальному открытию.
Обучение проектированию на прямой видимости
Войдя в нашу комнату программистов, я увидел, что все они устави-
лись на свои экраны! В этой комнате обучение на прямой видимости
отсутствовало полностью.
66
Глава 2
Через несколько недель у меня появился шанс изменить эту ситуа-
цию. Когда кто-либо задавал вопрос по проектированию, я старался,
чтобы мы его обсуждали у белой доски или громко высказывали
свои мысли.
Так продолжалось месяц-другой, но в конце концов я услышал, что
проектировщики, говоря о своих работах, пользуются словами и
идеями, накопленными за предыдущий месяц.
Обустройство этой комнаты является основой для стратегии “эксперт в пре-
делах слышимости” (Cockburn, 2001а), позднее переработанной в “конвекцион-
ные потоки информации” (см. главу 3).
Парное программирование относится к приемам, обеспечивающим обучение
на прямой видимости и слышимости. Ларри Константайн (Larry Constantine,
1995) нашел этот прием настолько эффективным, что прозвал парное програм-
мирование Брайена Кернигана (Brian Kernighan) “динамическим дуэтом”. Кроме
того, парное программирование было популяризовано через Extreme Program-
ming (Beck, 2000). Группы, практикующие парное программирование, сообщают
о более быстром изучении как приемов программирования, так и проблемной об-
ласти, а также о более быстром создании кода и снижении числа дефектов (Cock-
burn, 2001b).
Поддерживать концентрацию и коммуникацию
Разработка ПО, требующая как интенсивных размышлений, так и интенсивного
общения, представляет собой интересную дихотомию.
Программистам необходимо значительное время провести в тишине, чтобы
войти в спокойное и продуктивное состояние, или, другими словами, войти в про-
цесс. Если на вход в процесс требуется 20 минут, то нарушить его посторонний
разговор может всего за одну-две минуты.
Каждая команда проектировщиков должна найти способ обеспечивать тиши-
ну на время, достаточное для вхождения в процесс, и должна защищать это вре-
мя. ДеМарко и Листер (1999) предлагают выделять для тихого времени два часа
ежедневно, выключая все телефоны и запрещая проведение совещаний в это
время. Я наблюдал за одной организацией, принявшей эти правила. Они так вы-
соко ценились всеми, начиная от высшей администрации, что среди трех дюжин
предложений по улучшению организации работы в компании эти правила посто-
янно объявлялись самыми важными.
Методология ХР рекомендует планировать комнату по принципу “пещеры и
общая территория” (Auer, 2002). Центральная часть комнаты отводится для
групповой работы: столы с двумя-шестью рабочими станциями и пространство
для двух человек у каждой рабочей станции (рис. 3.13).
По краям комнаты устроены индивидуальные зоны, где сотрудники оставля-
ют свои вещи, разговаривают по телефону, отвечают на сообщения электронной
почти и т.д. С такой планировкой люди получают легкий доступ к своим колле-
Индивидуумы
67
гам, когда они занимаются проектированием, и располагают личным пространст-
вом для собственных ну>кд.
Я не обнаружил единодушия по поводу личных кабинетов и совместного ра-
бочего пространства. Постоянно я встречаю людей, говорящих, что лучшую свою
работу они выполнили, когда занимали кабинет совместно с кем-то другим или в
помещении, напоминавшем казарму. Некоторым нравится тишина их персональ-
ных кабинетов, но результат получается лучше, если они работают в общих по-
мещениях. Другие, однако, так сильно привязаны к своим личным кабинетам, что
предпочитают уволиться, чем перебраться в общее рабочее помещение. Это мо-
жет быть слишком высокая плата за общение.
Рабочие назначения, соответствующие личным
качествам
Для того чтобы люди работали так хорошо, как они могут, их рабочие назначения
должны ориентироваться не на слабые, а на их сильные личные качества. Методо-
логии называют роли, которые должны присутствовать в проекте, но не упомина-
ют о личных чертах, необходимых для каждой роли.
Вот три примера людей, чьи личные качества не соответствовали требовани-
ям ролей:
Социально настроенный менеджер
Однажды в крупном проекте, в котором участвовало несколько групп,
менеджером проекта был человек, который настолько большое значе-
ние придавал социальным вопросам, что не хотел никого обижать.
В результате он не принимал те тяжелые и приоритетные решения,
ради которых и была создана должность менеджера проекта для
объединения групп.
Немногословный руководитель команды
Человек, нанятый ведущим программистом и руководителем, ока-
зался типичным необщительным программистом.
Вместо того чтобы учить программистов-новичков и помогать им по-
вышать мастерство в программировании, он просто переписывал за
них код, когда их не было рядом!
Конкретно мыслящий разработчик
объектно-ориентированных проектов
Один участник нашего объектно-ориентированного проекта отчаянно
хотел научиться объектно-ориентированному программированию. Од-
нако оказалось, что он не способен заставить себя мыслить на до-
статочно абстрактном уровне, чтобы производить хорошие объект-
но-ориентированные проекты.
68
Глава 2
После шестимесячной подготовки он по-прежнему писал програм-
мы словно для реализации пользовательского интерфейса или рабо-
ты с реляционной базой данных.
Что можно было сделать с этими людьми? Человек из первого проекта стоял
слишком высоко на служебной лестнице, чтобы его можно было заменить, и поэ-
тому проект продолжал страдать. Во втором проекте героя в конце концов заме-
нили кем-то, кто имел хорошие навыки общения и стал учить
программистов-новичков основам объектно-ориентированного проектирования.
В третьем проекте нам повезло больше. Тот человек был впечатляюще си-
лен в определении требований, где его внимание к деталям и аккуратность в
мышлении сполна оплатили его долг. В обмен на согласие работать с требовани-
ями он получил возможность продолжать заниматься объектно-ориентирован-
ным проектированием и программированием тех частей системы, где качество
проекта не было критически важным. Выиграли все: он получал удовольствие,
занимаясь программированием, а проект стал более надежным благодаря высо-
кому качеству его работы с требованиями.
Способности
Лучшие программисты команды могут настолько превосходить остальных, что не-
сколько таких программистов могут производить больше, чем все остальные вмес-
те взятые.
eBucks.com начинает работать
Винсент Гетци (Vincent Goetzee), руководитель технического отдела
eBuck.com, рассказал, как их группа подготовила новую систему
eBucks всего лишь за три месяца.
Значительную ее часть разработали два лучших программиста.
Услышав это, я кивнул. “Старое решение. Усадите рядом двух луч-
ших программистов, и они сделают все. Иначе придется использовать
хитрую методологию, чтобы координировать работу 20 человек".
Но один вопрос остался открытым. Я знал, что у него много других
обязанностей и ему нужно посещать такое количество совещаний,
что не удается как следует сконцентрироваться на программирова-:
нии. Я спросил его об этом.
Он ответил: "Я присутствовал на совещаниях приблизительно до 17 ча-
сов, а затем каждый день писал код с 6 часов вечера до 2 часов ночи".
И еще одно слишком очевидное решение. Заставьте двух лучших
специалистов работать как каторжников несколько месяцев кряду.
Болезненно, но эффективно.
Это сочетание способностей и навыков практической работы я называю лич-
ной доблестью. Хотя менеджер может повысить квалификацию членов своей
Индивидуумы
69
команды, поощряя их обучение и посылая их на курсы, он не может изменить
уровень таланта в команде. Талантливый проектировщик все равно будет пре-
восходить среднего проектировщика, имеющего хорошие навыки.
Джон Вуден (John Wooden), успешный баскетбольный тренер, считает та-
лант настолько важным, что так сформулировал первый.секрет тренера: “Коман-
да, имеющая лучших игроков, почти всегда выигрывает” (Hill, 2001, стр. 63).
Вознаграждения, сохраняющие удовлетворение
Изобретать структуры вознаграждений — дело хитрое. Недавно я и сам споткнул-
ся на том, что считал простой ситуацией “работа-поощрение”.
Сбор одуванчиков
Одуванчики заполонили наш задний двор. Имея трех детей в возрас-
те до десяти лет, я сочинил блестящее решение: предложил им по
одному центу за желтый цветок и по десять центов за любой оду-
ванчик с семенами. Платя пять-десять долларов в год, подумал я, за
несколько лет мы совсем освободимся от одуванчиков.
Дети принесли сумки с одуванчиками, и я заплатил наличными.
На третий год я заметил моему теперь уже двенадцатилетнему сыну
Кэмерону, что вроде бы в этому году у нас стало больше одуванчи-
ков, чем было в прошлом.
Он ответил: "Само собой. В прошлом году я несколько раз пробе-
жал по двору, сшйбая все белые одуванчики и раскидывая их вокруг.
Когда Шон спросил меня, почему я не кладу их в сумку, я сказал:
"Сажаю деньги на следующий год!"
Если у меня возникли затруднения в такой простой ситуации, то насколько
сложнее найти соответствующее вознаграждение за создание программ? Что вы
станете поощрять:
Строки программного кода, отправленные в отдел тестирования?
Низкий уровень дефектов в коде, направляемом в отдел тестирования?
Число функциональных точек, разрабатываемых каждый месяц?
Число строк, повторно использованных из корпоративной библиотеки?
В карикатуре Дилберта менеджер предлагает вознаграждение, связанное с
числом обнаруженных программных ошибок. Один программист немедленно
объявляет: “Сегодня после ленча я заработал на целый мини-автобус”! (Ну точ-
но, как с одуванчиками!)
Даже если вы можете назвать подходящую структуру вознаграждений, за что
реально поощряет ваша организация? Не противоречит ли это тому, что наибо-
лее важно для компании?
70
Глава 2
Оплата по числу строк кода
Крупная компания, которую я не осмеливаюсь назвать, стала одоб-
рять повторное использование кода. Однако производительность
труда программистов оценивалась на основании числа строк кода,
отправляемого каждый месяц в отдел тестирования.
Одна известная мне сотрудница этой компании в соответствии с по-
желаниями включила компоненты из библиотеки компании для по-
вторного использования. Однако ей посчитали лишь те строки,
которые она написала сама, и не учли те, которые она скопировала
из библиотеки. В результате ее производительность программирова-
ния была оценена низко.
Программисты замечают несоответствия и иногда находят тонкие способы
отплатить.
Покрытие позолотой
Руководитель команды в небольшой начинающей компании пожало-
вался мне, что один из программистов излишне усложняет свое про-
ектирование — "покрывает его позолотой", чтобы сделать его для
себя более "интересным".
Когда мы вместе рассмотрели ситуацию, то увидели, что этот чело-
век получал небольшой фиксированный заработок на рискованной
должности в начинающей компании. Риск лишиться этой работы был
велик, а вознаграждение — низким.
Очевидно, что он выработал собственную схему самопоощрения и стал
сочинять "крутой" код, что могло сделать его жизнь более интересной и
расширяло для него возможность устроиться на новую работу.
Этот вид несоответствия подталкивает программистов вести себя так, что
это может наносить ущерб компании, как “инвестиционный” взгляд Кэмерона на
сбор одуванчиков нанес ущерб моим планам в отношении заднего двора.
Мне написал один человек, которому казалось, что опционы на акции явля-
ются формой вознаграждения, одинаково выгодной для компании и программи-
ста. Он писал, что работает теперь в службе сопровождения не потому, что эта
работа веселее, а потому, что так он может наилучшим образом защитить при-
надлежащие ему акции компании.
Схемы вознаграждения представляют собой даже более скользкий пред-
мет, чем я до сих пор пытался их представить. Алфи Кон (Alfie Kohn, 1999) пи-
шет, что вознаграждения на самом деле сокращают внутреннее удовлетворение
и качество результатов деятельности, в других обстоятельствах доставляющей
удовольствие.
“Маленькие дети, которых поощряют за рисование, делают это по
собственной инициативе гораздо реже, чем дети, рисующие ради удо-
Индивидуумы
71
вольствия. Подростки, которых вознаграждают за игру в слова, полу-
чают от игр меньше удовольствия и играют не так хорошо, как те, кто
играет просто так. Сотрудники, которых хвалят за то, что они соответ-
ствуют ожиданиям менеджера, испытывают снижение мотивации... В
одном исследовании говорится, что девочки пятого и шестого классов
наставляли детей младших классов гораздо менее эффективно, если за
хорошее обучение им обещали бесплатные билеты в кино. Исследова-
ние Джеймса Габарино (James Gabarino), в настоящее время прези-
дента Erikson Institute for Advanced Studies in Child Development в
Чикаго, показало, что наставникам в школе, работающим за возна-
граждение, для передачи идей требуется больше времени, они легче
разочаровываются и хуже выполняют работу в конце, чем те, кто не
получает вознаграждения”.
Если вознаграждение внутренне мотивированного поведения разрушает
внутреннюю мотивацию, то какие вознаграждения могут сохранить внутреннюю
мотивацию человека?
Гордость работой
Г ордость достижениями
Гордость вкладом в общее дело
Гордость работой
Гордость работой иллюстрирует реклама шотландского виски, которую я видел не-
сколько лет назад (жаль, что мне придется передать ее своими словами, но это
было довольно давно). Это объявление гласило что-то вроде: “Если вы хотите по-
лучить набор клюшек для гольфа ручной работы от Иена Макгрегора, вам придет-
ся ждать два года. Три человека стоят в очереди перед вами. (Хорошая вещь
требует времени)”.
Из этого объявления становилось ясно, что Иен Макгрегор гордится своей
работой, и в результате он создает выдающиеся изделия (как и производители вис-
ки в Шотландии). Клиентура может почувствовать разницу и готова подождать.
Только недавно я понял ту роль, которую гордость работой может сыграть
в проекте, а незадолго до этого слышал, как один программист сказал:
“Что ж, эта система в порядке... Я имею в виду, что она функциониру-
ет, но на самом деле я никак не могу гордиться моей работой. Хотелось
бы возвращаться домой с хорошим чувством к моей программе, но это-
го нет. Моя программа — просто сплошная неразбериха, которая едва
работает”.
В продолжение он сказал, что по-настоящему его не радует ничего из того,
что он делает, хотя все это “работает”.
72
Глава 2
Гордость достижениями
Победа — это великое вознаграждение. Завершая какое-то дело, мы создаем “ма-
ленькую победу”, мощный фактор мотивации (Weik, 2001).
В области создания ПО мы добиваемся скорой победы, когда быстро постав-
ляем работающий, протестированный, полезный программный код. Используя
принцип маленьких побед как мотивирующего вознаграждения, команда быстрее
производит наименьший продукт, который может считаться для команды побе-
дой. Эта первая поставка демонстрирует как спонсору, так и самой команде, что
эта команда может работать сообща и производить программный продукт. Это
поднимает моральное состояние и тех и других.
Чтобы держаться принципа маленьких побед Вейка, команда будет затем
продолжать производить следующие работающие, протестированные и полезные
функции через регулярные интервалы. Эта стратегия “быстрых и регулярных по-
ставок” лежит в основе инкрементных поставок, описанных в книге Surviving
Object-Oriented Software (Cockburn, 1998).
Стратегия быстрых и регулярных поставок ставит один важный вопрос о том,
что производить в первую очередь. С одной стороны, оставить самое сложное
напоследок кажется удачной мыслью — команда узнает практически все о систе-
ме, прежде чем начнет штурмовать самую сложную проблему. Это стратегия “са-
мое трудное в конце”. У нее на удивление плохой список успехов, поскольку
многие проекты просто невозможно выполнить с существующим распределени-
ем работы в команде. С постоянным откладыванием самой трудной части проект
со временем не становится более надежным, а остается все таким же нестабиль-
ным, пока не будет найдено последнее магическое решение... или пока у спонсо-
ров не закончатся деньги.
Противоположная стратегия предписывает убрать с дороги труднейшую
часть, т.е. выполнить “худшее сначала”. Эта стратегия лучше, но у нее есть одна
слабая сторона. Если команда тотчас же не сможет разрешить труднейшую проб-
лему, никто не сможет ответить, в чем заключается причина. Слишком сложная
проблема? Команда не справилась? Неверная методология? Инструменты вино-
ваты?
Уточненная стратегия рекомендует выполнить “во-первых, простейшую,
во-вторых, сложнейшую часть”. Конструируя “шагающий скелет” — едва свя-
занную версию системы, которая сможет обрабатывать лишь один простейший
тип действия, — команда учится работать вместе и добивается скорой победы.
Имея один триумф за своими коллективными плечами, команда оказывается
в более сильной позиции для атаки сложной проблемы. Если команда сможет до-
биться успеха, это будет двойное достижение: труднейшая часть проекта закон-
чена (план проектирования стабилизируется), и команда добивается главной
победы.
Если команда пока недостаточно сильна для штурма наихудшей проблемы,
тогда члены команды атакуют труднейшую проблему, которую, как они уверены,
Индивидуумы
73
можно решить. При этом они приобретают новый опыт, добиваются значительной
победы, поднимающей их боевой дух, и большей уверенности в своей способности
приступить к решению самой сложной проблемы. Таким образом они продолжают,
пока не решат сложнейшую проблему и проект не начнет упрощаться.
Гордость за свой вклад в общее дело
Третьим возможным внутренним вознаграждением является гордость за свой
вклад в общее дело. Желание людей внести свой вклад настолько сильно, что я ре-
гулярно вижу, как программисты наносят ущерб своему здоровью и личной жизни,
стремясь внести вклад в деятельность команды.
Вот история о ключевом разработчике, изменившем свое отношение к про-
екту, когда он понял, что значит для проекта и коллектива его вклад.
Переориентация обязательств
Этот программист работал по привилегированному контракту, вы-
полняя наиболее сложную и важную часть системы. Ему уже очень
хорошо платили за работу.
Действующий в этой истории администратор был очень проницатель-
ным человеком в том, что касалось отношений с людьми.
В некоторый момент у администратора состоялся разговор с про-
граммистом. Администратор ясно дал понять, как важен этот конк-
ретный программист для успеха всей корпорации, однако при этом
сумел показать, что построение по-настоящему умного, красивого и
совершенного, но трудного для использования решения пойдет во
вред всему их сообществу и что программист может внести очень
позитивный вклад в дело каждого участника, если создаст простое и
работающее решение, пусть даже оно будет менее эстетичным или
менее правильным математически.
Почти немедленно программист изменил свое поведение. Он пре-
кратил высмеивать компанию и технологию и проявил заинтересован-
ность в работе, вносящей ощутимый вклад в дело всей группы. Его
вклад и так уже был основным, но теперь он создавал осуществи-
мое решение и задержался в компании надолго, чтобы наблюдать за
ходом внедрения своего решения.
Для меня интересно, что администратор не использовал чувство гордости ра-
ботой программиста по отношению к совершенству его проекта, а затронул чув-
ство гордости за свой вклад в работу сообщества.
Комбинирование вознаграждений
Лобачер (Laubacher) и Мэлоун (Malone) из Sloan School of Management Массачу-
сетского технологического института выдвинули на первый план комбинирование
74
Глава 2
вознаграждений, необходимое для работников в сфере высоких технологий (Lau-
bacher, 2000). Они начали со следующего предупреждения:
“Стратегия ”мы получим лучших и удержим их" нежизнеспособна для
большинства компаний. Такой подход возможен для таких лидеров,
как Sun Microsystems и Cisco, способных предложить убедительный
пакет, состоящий из зарплаты, опционов на акции и многообещающей
работы. Но не каждой фирме доступны такие ресурсы".
Они улучшили положение следующим образом:
“Поскольку так много инженеров компании Cisco Systems стали мил-
лионерами благодаря опционам на ее акции, компания приравнивает
свою рабочую силу к добровольцам и обращается с ними соответст-
венно. Это крайний пример, но во многих областях, требующих высо-
кой квалификации, талант ищет чего-то большего, чем самый
большой пакет акций. Интересная, поощряемая работа или шанс при-
соединиться к выполнению захватывающего задания стали ценными
инструментами привлечения и удержания талантливых сотрудников”.
Проекты с открытыми исходными текстами, кажется, предлагают все три
возможные механизма внутреннего вознаграждения. Вовлеченные в них люди
отмечают удовольствие, получаемое от внесенного вклада в эту работу, гор-
дость, которую они испытывают в отношении своей работы, своих и чужих до-
стижений. Те, кто вносит вклад в разработку ПО с открытыми исходными
текстами, представляют собой очень преданную группу людей, производящих
чрезвычайно качественный код. В их случае создание ПО — это, безусловно,
кооперативная “игра”, выполняемая в большей степени ради удовольствия, чем
ради дохода.
Даже после всех вышеприведенных рассуждений нельзя утверждать, что для
всех людей будет работать единый механизм вознаграждения. Например, проек-
ты космических челноков получают пользу от людей, которые гордятся обнару-
жением мельчайшей ошибки и отдают свое время на тщательное рассмотрение
каждого рабочего артефакта. В подобном проекте может быть трудно найти под-
ходящее вознаграждение, если вовлеченные в него люди ищут проекты высокого
риска, которые позволили бы им быстро продвинуться и разбогатеть.
Это различие между людьми полезно, поскольку требуется создавать так
много разнообразных видов систем.
Обратная связь
Люди извлекают пользу из ясной и частой обратной связи. Как правило, чем она
быстрее, тем лучше ее влияние.
Индивидуумы
75
Сеймур Крей тратит время
Сеймур Крей (Seymour Cray), создатель компьютеров, несколько
десятилетий остававшихся быстрейшими в мире, прочитал несколько
лекций о своих старых приемах проектирования.
Только закончив университет, он уже был гордым автором принципа
особо крупного лучевого ползунка. Он немедленно его использовал
в первой же своей работе, посвятив несколько дней старательному
вычислению параметров.
Проходя однажды коридором, он встретил опытного проектировщи-
ка, который показал ему, что было бы проще применить несколько
эмпирических приемов и построить прототип. Тогда он мог бы его
протестировать, чтобы определить, где он не действует, внести в
проект несколько уточнений и перенести их в спецификацию.
Этим примером Сеймур Крей проиллюстрировал ту мысль, что немного об-
ратной связи может заменить большую аналитическую работу.
Из всех опубликованных методологий, возможно, Extreme Programming
(ХР) придает наибольшее значение обратной связи как на этапе проектирования,
так и в ходе всей работы.
ХР требует от программистов работать парами на стадиях проектирования и
программирования. Второе лицо замечает многие ошибки программирования
при вводе текста программы.
Программисты держат модульные тесты в автоматизированном тестовом
комплекте. После каждого изменения секции кода они запускают тестовый комп-
лект, чтобы немедленно обнаружить, не было ли нарушено что-либо, работав-
шее раньше.
Они производят работающий протестированный код каждые несколько не-
дель. Присутствующие на месте заказчики оценивают новые части системы и со-
общают о ее полезности, пока эта работа еще не стерлась из памяти
разработчиков.
Каждые несколько недель они оценивают порядок работы, размышляя о сте-
пени ее успешности на предыдущей итерации.
На самом деле каждая команда разработчиков должна пересматривать свои
привычки каждые несколько недель независимо от того, используют ли они пар-
ное программирование или ХР. “Разбор полетов”, который некоторые команды
проводят в конце проекта, оказывается запоздавшим и уже не может помочь
проекту. Проведение регулярных совещаний в ходе работы над проектом гораздо
более эффективно. Команда имеет шанс и время учесть обратную связь и прове-
сти необходимую работу, которая пойдет на пользу проекту.
Периодическое проведение в ходе работы над проектом совещаний с обсуж-
дением результатов — единственный прием, общий для всех методологий Crystal
(см. главу 6). Каждые две-шесть недель, в зависимости от продолжительности
цикла работ по проекту, команда собирается, чтобы обсудить, что идет хорошо,
76
Глава 2
что не удается и что можно попробовать сделать за время до следующего совеща-
ния.
Регулярно обдумывая обратную связь, команда может вводить другие мето-
ды, такие как совещания Хайсмита (2000) по обзору продукта, и извлекать таким
образом пользу из обратной связи.
Использование сильных сторон
Удивительно, какими расплывчатыми и немыслимыми кажутся случаи успеха. К ним
относятся:
Хорошее умение ориентироваться
Способность обучаться
Восприимчивость
Способность гордиться работой
Способность гордиться вкладом в работу
Способность испытывать чувство долга
Проявление инициативы
Действительно ли эти механизмы постоянно спасают проекты от провала?
В записях моих бесед один ответ проявлялся неоднократно, когда я спраши-
вал, что приводило проект к успеху:
“В решающие моменты вмешивались несколько человек и делали все
необходимое для завершения работы”.
В первые восемь лет этих бесед я полагал, что речь шла о провальном про-
екте, который удалось спасти лишь благодаря героическим усилиям отдельных
личностей.
Продолжая слышать этот ответ, я понял, что не могу объяснить, почему
люди это делали и какова общая роль действий такого рода для проекта. Только
исследовав это высказывание, я начал понимать мощное влияние только что упо-
мянутых факторов успеха, влияние, существенное как для строгого, так и для
свободного процесса.
Давайте рассмотрим эти факторы успеха.
Хорошее умение ориентироваться
Хорошее умение людей ориентироваться отражается в способах, которыми они
организуют бумаги в своей жизни: книги, отчеты, адреса и т.д. Общий для людей
способ сортировки — это использование сортировки по методу Шелла: мы созда-
Индивидуумы
ем кучки, упорядоченные по критерию сортировки (например, по алфавиту или по
дате), но оставляем их несортированными внутри кучки. Затем мы разбиваем каж-
дую кучку на более мелкие и повторяем этот процесс, пока каждая кучка не станет
достаточно маленькой, чтобы ее можно было разобрать рукой и взглядом. Прав-
да... мы часто не выполняем этого последнего шага сортировки. Когда кучка стано-
вится достаточно маленькой, чтобы ее можно было отсортировать глазами и
руками, мы часто оставляем ее в таком виде и находим любой интересующий нас
элемент, просто просматривая ее содержимое.
Стандартная адресная книжка служит тому идеальным примером. Она раз-
бита на разделы по начальной букве, но записи внутри разделов не отсортирова-
ны. Они просто занесены в книжку в произвольном порядке, и мы
просматриваем раздел в поисках интересующего нас адреса.
Более яркий пример — способ, которым многие люди сортируют бумаги у се-
бя на службе. Там у них есть полки с бумагами, и они находят нужные отчеты,
просматривая соответствующие полки.
Важно заметить, что отсутствие окончательной сортировки никого не беспо-
коит. Большинство людей даже не обращают на это внимания и работают в пред-
положении, что они могут достаточно быстро отыскать вещи, используя
просмотр и мысленные ассоциации.
Трюгве Реенскауг снабдил меня следующим примером хорошего умения
ориентироваться в проекте.
Проект морской нефтяной платформы
Трюгве пытался заинтересовать конструктора морских нефтяных
платформ системами автоматизированного проектирования. Он рас-
сказал, что эта система сможет помочь проекту, так как будет от-
слеживать все изменения в конструкции, затрагивающие любую
часть платформы.
Инженер ответил: "Пусть в ней просто хранятся телефонные номера
людей, работающих над каждой частью проекта. Я позвоню им и
все узнаю".
Еще один пример использования людьми их умения ориентироваться — это
способ сопровождения программного кода.
Поддержка текущего состояния проектных документов очень дорога и нена-
дежна (особенно, когда известно, насколько свойственна людям непоследовате-
льность). В большинстве проектов документация практически никогда не
соответствует коду.
Если бы синхронизация документации и кода была основным требованием,
команды проектировщиков не смогли бы продолжать работу, как только начина-
ется сопровождение. Однако те, кто сопровождает код, рассчитывают на это не-
соответствие и используют неправильную документацию просто как средство для
“приближения” к области, требующей изменений.
78
Глава 2
Как только они приблизились, их глаза и ум позаботятся обо всем осталь-
ном. Они просто осматриваются, пока не найдут секцию с кодом, который требу-
ется изменить.
Внутри теории кооперативной игры мы можем использовать эту способность
людей и запланировать сделать документацию “достаточно хорошей, чтобы мож-
но было приблизиться”, а затем применить способность человека ориентирова-
ться и находить нужное место для внесения изменений.
Третье место, где мы рассчитываем на умение людей ориентироваться, —
это роль технического руководителя.
Титул “технический руководитель” предполагает, что это лицо уже делало
что-то подобное раньше, что у него есть ощущение, когда в проекте все идет хо-
рошо, а когда он сворачивает на неправильный путь. Техническому руководителю
не дают инструкций, как это можно сделать. Предполагается, что он просто “ори-
ентируется и замечает”, если что-то не в порядке, а затем каким-то образом
изобретает способ возвращения в безопасную зону.
“Ориентироваться и замечать, когда что-то не в порядке” — это то, что де-
лает каждый участник проекта. Я встречал людей с самыми разными должност-
ными обязанностями, которые обнаруживали неполадки в каком-то аспекте
проекта — очень часто не имевшем к ним отношения — и сообщали об этом
лицу, который должен был устранить эту ситуацию. Или же они просто устраня-
ли ее сами, специально выходя за пределы своих должностных инструкций.
Люди обучаются
Новички не навсегда остаются таковыми. Будучи в начале проекта новичками, они
набираются опыта к моменту его завершения и часто становятся ведущими проек-
тировщиками, после того как выполнят еще несколько проектов.
Эта способность обучаться во время работы помогает многим проектам. Во
временных рамках одного проекта люди изучают новую технологию, новую проб-
лемную область, новый процесс, учатся работать совместно с новыми коллегами.
Часто команда с трудом пробивается через две первых итерации, становясь
все сильнее и сильнее, и успешное завершение проекта уже считается абсолютно
естественным. В долговременных проектах и в ситуациях, сопровождаемых
устойчивым потоком небольших инициатив, старшие сотрудники уходят, а млад-
шие — которые становятся старшими — занимают их места.
Мы используем способность людей обучаться, разбивая проект на подпроек-
ты (снова инкрементная разработка). Это не только обеспечивает маленькие
победы и обратную связь, но также возможность для сотрудников разобраться,
как работает этот процесс. “О, — могут сказать они, — вот почему мы должны
записывать поля с проверкой ввода структур данных в таблицу”. Они используют
способность ориентироваться, чтобы обнаружить потребности в улучшении и за-
тем придумывают новые способы работы, чтобы попробовать их на следующем
шаге.
Индивидуумы
79
Восприимчивость
Люди обладают замечательной способностью действовать по-разному, получая
новые мотивы и новую информацию. Об этом механизме рассказывают две исто-
рии о магазине мелочей и проекте СЗ (см. раздел “Преодоление слабостей”).
В истории о магазине мелочей не сообщается, почему продавщицы поменяли
свои рабочие привычки.
В истории о проекте Chrysler Comprehensive Compensation (СЗ) Кенту Беку
потребовалось поменять культурные ценности команды, перейти от создания
изощренного кода к простым решениям — решить хорошо известную и трудную
задачу.
В числе приемов, которыми он пользовался, был ритуал давления со сторо-
ны членов команды. В одном таком ритуале группа устроила шествие, водрузив
шапочку с пропеллером на голову человека, придумавшего чересчур умное реше-
ние. Пропеллер крутили на шапочке, комментируя “изощренность” решения.
Негативное отношение коллег заставило отказаться от умных решений, а высо-
кая оценка простых проектов привела их к простым решениям.
Поскольку все люди разные, не каждый человек в группе был достаточно
“восприимчивым”, чтобы принять ХР. Одному человеку не понравился новый
стиль работы с требованиями согласованности и тесного сотрудничества, и он
оставил этот проект.
Вклад в общую работу и проявление инициативы
В предыдущем разделе я рассматривал гордость от вклада в общее дело и гордость
своей работой как сильные внутренние мотиваторы. Теперь я высказываю мнение,
что эти чувства также вносят главный вклад в успех проекта.
Люди, гордящиеся своей работой, работают лучше других, и они с большей
вероятностью отойдут от своих должностных инструкций, чтобы устранить заме-
ченную проблему или сообщить о ее обнаружении. Даже если единственным воз-
награждением будет похвала за хороший поступок, для многих этого достаточно,
и я постоянно встречаю таких людей.
Итак, мы вернулись к спонтанному поведению, о котором я упоминал в на-
чале главы. В тот момент я посчитал спонтанность препятствием, затрудняю-
щим построение прогнозируемой модели людей, работающих в системе. Теперь
я включаю это поведение в число факторов успеха.
Начнем с гордости работой и чувства долга. Добавим полезное умение
осмотреться и действовать спонтанно. Кроме того, мы видим людей, проявляю-
щих инициативу во время ежедневной работы, и эта деятельность поддерживает
проект на пике формы.
Это не знак неудачи процесса. Даже самый лучший процесс не способен
учесть каждый сюрприз, случающийся при работе над проектом. Следовательно,
важно, чтобы люди находили проблемы, упоминали о них и разрешали их. Как
80
Глава 2
только в команде улучшается положение с гордостью работой, общением, чувст-
вом долга и инициативой, процесс может стать менее формальным, больше опи-
рающимся на способность заметить, что требуется сделать.
Комбинированные факторы успеха
Можно ли построить методологию разработки лишь вокруг гордости работой, чув-
ства долга, общения, умения ориентироваться и проявлять инициативу?
Да, возможно. В следующем отрывке (Hock, 1999, стр. 205-207) описывает-
ся, как за 60 дней была разработана первая программа клиринга VISA. Обратите
внимание на использование Ди Хоком (Dee Hock) выражения “самоорганиза-
ция”, синонимичного проявлению людьми инициативы в сообществе.
История Ди Хока о VISA
"Мы решили стать своим собственным генеральным подрядчиком,
передоверив часть работ целому ряду разработчиков ПО, а затем
приступив к согласованию и реализации их результатов. В соответст-
вии с обыкновенном здравым смыслом этот путь считался одним из
наиболее худших возможных путей построения компьютеризирован-
ных систем обмена информацией.
Мы арендовали дешевое помещение в пригороде и отказались от
всяких его усовершенствований в пользу медицинских штор в роли-
ковых рамах, чтобы разделить помещение...
Самоорганизация возникла быстро. Вся стена превратилась в комму-
тационную доску, а сверху нее были перечислены все оставшиеся
календарные дни. Кто-то схватил невымытую кофейную чашку и под-
весил ее на длинной леске, прикрепив к текущей дате. Каждая часть
работы, которую предстояло сделать, была записана на клочке бу-
маги с указанием необходимой даты завершения и фамилией чело-
века, взявшегося за нее. Каждый мог изменить список работ,
добавить новые работы или скорректировать даты при условии, что
они были согласованы со всеми, кого это касалось. Любой человек в
любой момент мог видеть всю картину в ее развитии. Он мог по-
нять, как работа в целом зависит от его части и как его работа свя-
зана с объемом работ, выполняемым каждым другим участником.
Перед доской постоянно стали собираться группы, непрерывным по-
током шли обсуждения, принимались решения, затем, договорив-
шись по всем вопросам, они расходились. По завершении каждой
работы соответствующий клочок бумаги убирался. И каждый день
леска с чашкой неумолимо передвигалась вперед.
Ежедневно каждый клочок бумаги, оказавшийся позади зловещей
лески, становился добычей энергичной группы добровольцев, желав-
ших взять на себя ответственность за выполнение этой работы. Су-
меть сделать собственную работу и помочь другим — вот к чему
стремились все. Но в то же время никто не чувствовал себя попро-
Индивидуумы
81
шайкой, принимая помощь. Такие объемы работ, достойные подвиг-
ов Геракла, означали, что в любой момент работа какого угодно
участника могла отстать и оказаться позади лески.
Лидеры спонтанно возникали и пропадали не ради контроля, а для
организации. Вырвалась наружу изобретательность. Процветали ин-
дивидуальность и разнообразие. Люди сами поражались тому, что
им удавалось сделать, и удивлялись, как они раньше не замечали
проявившихся в других талантов.
Должности перестали иметь смысл. Власть над другими ничего не
значила. Время не имело смысла. Возбуждение от желания совер-
шить невозможное возрастало, и возникло сообщество, основанное
на цели, принципе и людях. Развивались индивидуальность, чувство
собственного достоинства, изобретательность и творчество, и вмес-
те с тем росло ощущение принадлежности к чему-то более крупно-
му, чем собственная личность, к чему-то, находящемуся за
пределами сиюминутной выгоды и денежного вознаграждения.
Никто из нас никогда не забывал радости, с которой мы отдавали
работе единство разума, тела и духа, радости обнаружить в этом
процессе, что подобное единство невозможно без неразрывной свя-
зи с другими в масштабной задаче объединения усилий. Деньги со-
ставляли незначительную часть того, что происходило. Эти усилия
питались спонтанным ростом неденежного обмена ценностями...
НикГи так и не поменял грязную леску, и никто не помыл чашку...
Система BASE-I появилась вовремя, без превышения бюджета и пре-
взошла все запланированные характеристики".
В соответствии с традиционными методами разработки ПО этот проект сле-
довало бы назвать беспорядочным. Согласно теории кооперативной игры ясно,
почему он принес успех.
Повторяемый ли это процесс? Ответ зависит от того, насколько хорошо
группе удается поддерживать действие ключевых факторов.
Герои как обычные люди
Один момент я хочу подчеркнуть особо: в хорошо действующих проектах люди, за-
нимающие любые должности, могут заметить, когда что-то не в порядке, попра-
вить это или сообщить тому, кто может это сделать.
Хотя герои, работающие сверхурочно, могут потребоваться, чтобы спасти
плохо организованные проекты, гораздо интереснее рассмотреть другое явление:
обычные люди, выполняющие свою работу с чувством гордости и общности и за-
мечающие какую-то ошибку, передают информацию о ней кому-то, кто может
исправить проблему, или выходят за границы своих должностных инструкций,
чтобы справиться с ней самостоятельно. Это явление указывает не на плохой
процесс разработки, а на сообщество в действии. Заметьте сильную сторону это-
го эффекта сообщества в истории о VISA.
82
Глава 2
Гордость работой, чувство долга и общение имеют влияние даже в устояв-
шихся “инженерных” культурах. Вот один пример из области проектирования ап-
паратных средств.
Обнаружение ошибок в печатных платах
При проектировании аппаратных средств кто-либо должен с помо-
щью увеличительного стекла проверять фотонегативы, используе-
мые для изготовления печатных плат. Это лицо обязано найти
волосные трещинки, которые могут быть на негативах, и закрасить
их черной тушью.
Однажды женщина, выполнявшая эту работу, заметила странный
петлевидный узор на линии, которую она исследовала. Решив, что
это неправильно, она известила руководителя отдела.
Сначала руководитель отбросил мысль, что она действительно нашла
что-то существенное, но, так как она настаивала, ему пришлось за-
няться дальнейшим расследованием.
Как оказалось, ошибка при чертеже схемы привела к соединению
двух сигналов. Ошибка появилась в первоначальном проектировании
схемы. Каким-то образом она ускользнула от всех, кто проверял эс-
киз, чертеж и компоновку платы.
Из этой истории мне хотелось бы извлечь два вывода: во-первых, каждый
человек, участвующий в проекте, может обнаружить ошибку независимо от про-
ектируемой системы.
Второй вывод служит вступлением к главной теме следующей главы: после
обнаружения ошибки стоимость доставки информации о ней нужному человеку
начинает влиять на стоимость проекта.
Этот раздел я завершаю резюме из отчета NASA “Deorbit flight software les-
sons learned” (NASA, 1998, курсив добавлен мной для выделения).
“Возможно, наиболее важно, что за длительный срок в ходе создания
проекта появилось одаренное ядро команды, способной быстро разра-
батывать системы GN&C. Для этого потребовалось найти талантли-
вых участников команды, в достаточном объеме обучить их
инструментам, процессам, методологиям и сформировать сплоченный
коллектив.
Проработав вместе в RDL в течение года, участники команды приоб-
рели компетентность в методах, инструментах и проблемной области.
Деловая и дружелюбная атмосфера способствовала перекрестному
обучению. Готовность со стороны участников команды взяться за лю-
бую и каждую проблему проекта оказалась бесценной во многих
случаях... Эта команда может стать долговременным активом для от-
дела и всего агентства".
Индивидуумы
83
Что дальше?
Начните обращать внимание на сильные и слабые стороны, а также на странности
окружающих вас людей. Отметьте следующее:
Насколько некоторые люди подходят для своей работы, а другие не подходят.
Насколько некоторые люди последовательны, а другие нет.
Наличие любителей формализма и тех, кому не нравятся формальности.
Некоторые люди берут на себя излишний риск, но большинство ведет себя
более спокойно.
Что вам скажет начальник, когда вы внесете очередное предложение по
улучшению.
Когда вы начнете удивляться, каким образом что-то еще делается в вашей
компании с таким смешением соответствий и несоответствий, обратите внимание
на такие моменты:
Продолжение коллективной работы
Чувство долга, проявляемое сотрудниками
Инициативы, проявляемые спонтанно (какой процесс вы могли бы ввести,
чтобы исключить потребность в таких инициативах?)
Улучшите свою рабочую среду:
Соберите несколько рабочих примеров: пример удачного кода, хорошо на-
писанный комментарий к классу, вариант использования, план проекта,
протокол совещания, памятку о проектировании или пользовательский ин-
терфейс.
Привлеките к участию еще несколько человек и поместите на общий сервер
небольшую совокупность рабочих примеров, чтобы каждый человек мог их
скопировать.
Сократите перерывы в работе. Выделите небольшой период в течение каж-
дого дня продолжительностьюне более двух часов, во время которого вы не
будете прерываться. Посмотрите, станут ли большие группы в вашем офи-
се делать то же самое.
Сократите потребности в механизмах, ориентированных на слабые сторо-
ны людей.
Увеличьте использование механизмов, которые обращаются к сильным
сторонам людей и позволяют им использовать их таланты.
Глава 3
Коммуникация
и сотрудничество
в командах
Эта глава посвящена влиянию физической среды, модальностям коммуникации,
используемым для преодоления неизбежных разрывов общения, роли дружелю-
бия и конфликта, субкультурам в команде. Эти вопросы выдвигают на первый план
тот факт, что проекты нуждаются в людях, замечающих важные события, а также
склонных и способных сообщать другим то, что они замечают.
В разделе “Конвекционные потоки информации” перемещение информации
сравнивается с рассеянием тепла и газа. Это сравнение дает несколько полезных
ассоциаций: затраты энергии на передачу информации, осмотическая коммуни-
кация, излучатели информации и информационные сквозняки.
В разделе “Преодоление разрывов коммуникации” исследуется эффектив-
ность людей в передаче идей с использованием теплых и холодных каналов ком-
муникации. Здесь вводится идея снабжения информации “устойчивостью” и
рассматривается отношение этих двух тем к передаче информации во времени.
Раздел “Команды как сообщества людей” посвящен дружелюбию и конф-
ликту, роли маленьких командных побед в создании команды и разновидностям
субкультур, развивающихся в проекте. Мы увидим, что различные культурные
ценности могут одновременно быть полезными для организации, но создавать
проблемы для команды.
В разделе “Команды как экосистемы” команда разработчиков ПО рассмат-
ривается как экологическая система, в которой все физические структуры, роли
и отдельные индивидуумы с уникальными личными свойствами воздействуют друг
на друга. Каждый проект производит собственную уникальную экосистему, что
делает задачу проектирования методологии еще более сложной.
86
Глава 3
Конвекционные потоки информации
Из того факта, что разработка ПО — это кооперативная игра общения, вытекает
связь между темпами продвижения проекта и продолжительностью доставки ин-
формации из мозга одного человека в мозг другого. Если Ким знает что-то, нужное
Пэту, то продвижение проекта вперед зависит от следующих факторов:
Времени, необходимого Пэту, чтобы обнаружить, что Ким знает что-то по-
лезное
Совместных затрат энергии Пэта и Ким, обеспечивающих передачу знания
Пэту
Посмотрим, во что это обходится проекту.
Цена опозданий и упущенных возможностей
В наше время программист стоит компании приблизительно 2,1 доллара в минуту,
поэтому добавление одной минуты на получение ответа на вопрос увеличивает
стоимость проекта на 2,1 доллара. Эту минуту можно добавить, если встать со
стула и подойти к другому столу.
Предположим, что программисты, работающие парами, задают вопросы и
получают ответы 100 раз в неделю. Прибавление этой минутной задержки стоит
проекту 210 долларов на одного программиста в неделю. Для команды из 12 че-
ловек это составит приблизительно 2500 долларов в неделю на всю команду, что
увеличит на 50 тыс. долларов стоимость 20-недельного проекта.
Проект опаздывает почти на целую неделю и стоит больше на 50 тыс. долла-
ров из-за каждой минуты задержки, вызванной необходимостью получить ответ
на вопрос, при условии, что не допускается другой ущерб, который может понес-
ти проект, если вопросы потребуют для ответа больше времени!
Эта задержка составит порядка пяти минут, если человек должен пройти по
коридору. Если Ким не окажется на месте, то, вероятно, когда Пэт вернется в
свой кабинет, он потеряет ход мыслей и на восстановление ему придется потра-
тить дополнительное время и энергию.
Еще хуже, если в следующий раз, когда у Пэта появится вопрос, он решит не
подниматься снова по лестнице, думая, что Ким опять может не оказаться на ме-
сте. Чтобы не задавать вопрос, он делает предположение. Некоторая часть его
предположений будет неверной, и каждое неверное предположение ведет к появ-
лению ошибки в программе Пэта. Нахождение и исправление этой ошибки стоит
проекту от нескольких дополнительных минут до нескольких дней.
Таким образом, если Пэт не задает вопрос и не получает ответ, возникают
значительные затраты на упущенную возможность. В ходе выполнения проекта за-
траты на упущенную возможность существеннее выше затрат, связанных с подъ-
емом по лестнице.
Коммуникация и сотрудничество в командах
87
Думаю, что вы всерьез ощутите повышение затрат на разработку проекта в
следующих шести ситуациях:
1. Ким и Пэт программируют парой за одной рабочей станцией (фото 3.1).
Пэт вслух задает интересующий его вопрос, и Ким отвечает. Или Ким
произносит ответ мимоходом, продолжая разговор, и Пэт обращает на
него внимание как на полезную информацию. Эта ситуация требует от
каждого лица незначительной работы и минимального времени на раз-
решение.
Рис. 3.1. Парное программирование
(Фотография публикуется с разрешения
Evant Solutions Corporation)
2. Ким и Пэт сидят у отдельных рабочих станций, но рядом (программиро-
вание бок о бок). Периферическим зрением или в ходе обычной болтов-
ни, часто возникающей между соседями, Ким замечает, что Пэт что-то
ищет в Интернете, и спрашивает его, в чем состоит вопрос. Или Пэт
просто задает вопрос. Ким отвечает, возможно, не отводя взгляда от эк-
рана. Небольшая работа — требуется немного времени.
3. Ким и Пэт работают у противоположных стен комнаты, глядя в разные
стороны (рис. 3.2). Маловероятно, чтобы Ким заметила, что Пэт занят
поисками, но зато Пэт может легко определить, на месте ли Ким и есть
ли у нее возможность ответить на вопрос. В этот момент Пэт задает во-
прос и Ким отвечает.
4. Ким и Пэт сидят в смежных кабинетах, разделенных стеной. Ким не мо-
жет видеть, ищет ли Пэт что-то, а Пэт не видит, на месте ли Ким. Чтобы
увидеть это, Пэт должен встать, заглянуть в дверь и задать вопрос.
88
Глава 3
Рис. 3.2. Два программиста сидят
у противоположных стен комнаты.
(Фотография публикуется с разрешения Thoughtworks, Inc.)
5. Ким и Пэт сидят на разных этажах или в соседних зданиях. Пэт поднима-
ется по лестнице, чтобы только узнать, что Ким вышла! Теперь Пэт по-
терял время, энергию, ход своих мыслей во время работы и мотивацию
подниматься по лестнице при возникновении следующего вопроса. За-
траты на упущенную возможность начинают расти.
6. Ким и Пэт находятся в разных городах, возможно, в разных часовых
поясах. При таком размещении они не только не будут часто задавать
друг другу вопросы, им также придется пользоваться менее эффектив-
ными, менее мощными каналами коммуникации при обсуждении вопро-
сов и ответов. Чтобы достичь того же результата общения, они расходу-
ют больше энергии за более продолжительный интервал времени.
Если вы финансируете этот проект, то основной вопрос для вас звучит так:
какую рабочую конфигурацию вы хотели бы предоставить Ким и Пэту?
Мы видим, что даже незначительные различия влияют на скорость потока
информации.
Заметьте, что на рис. 3.3 одновременно возникают две различные ситуации.
Два человека слева программируют в паре. Им может нравиться маленькая заго-
родка, отделяющая их от женщины справа. Однако, если бы оказалось, что пере-
городка разделяет двух людей, которые должны работать вместе, она скоро
превратилась бы в проблему. Я спрашивал об этом двух человек, раньше рабо-
тавших через перегородку, но убравших ее. Как объяснял один из них: “Мне не
видно его глаз”.
Коммуникация и сотрудничество в командах
89
Рис. 3.3. Парное программирование и работа через перегородку.
Какая пара людей наиболее быстро обменивается информацией?
(Фотография публикуется с разрешения Thoughtworks, Inc.)
Эрг-секунды
Сравнение потоков информации и тепла или газа не так уж искусственно, как мо-
жет показаться на первый взгляд. Каждый раз говоря что-либо, Ким излучает в
окружающую ее среду и информацию, и энергию. Эту информацию или энергию
принимают люди, находящиеся в пределах видимости или слышимости. При каж-
дом произнесенном слове Пэт также излучает.
В рассматриваемом случае он излучает потребность получить информацию.
Раньше или позже либо Ким определит, что Пэту нужна информация, или Пэт
заметит, что Ким обладает этой информацией. Каким бы образом ни произошло
это открытие, они вступят в диалог (или Пэт прочитает документ Ким, если ее
информация содержится в письменном виде).
Одна из задач в области рассеяния газа анализирует расстояние, которое
преодолевают молекулы за определенный промежуток времени. Содержание мо-
лекул измеряется в молях, а расстояние — в метрах; следовательно, рассеяние
газа измеряется в моль-метрах в секунду (за какое время какое количество молей,
газа как далеко переместилось).
Мы можем анализировать передвижение идей — мемов (memes), если поза-
имствовать термин из книги The Selfish Gene (Dawkins, 1990), — используя со-
ответствующие названия. Нас интересует, сколько полезных мемов протекает
сквозь команду, занятую проектом, каждую минуту.
Однако метр не подходит нам как единица измерения, поскольку идеи пере-
мещаются не через пространство, а в большей степени через телефонные линии,
записки электронной почты и документы.
Нас больше беспокоит количество энергии, необходимое для перемещения
мема из одной головы в другую. Соответствующая единица измерения — эрг-се-
90
Глава 3
кунда. Эрг это единица работы (например, выполняемой при подъеме по лест-
нице), а секунды единицы времени (например, проведенного у телефонного
аппарата); следовательно, термин “эрг-секунда” фиксирует затраты на получе-
ние ответа на вопрос и в работе, и во времени.
(Бо Леуф замечает, что инверсия также полезна: “арг-минута” — мера стра-
даний, когда энергия расходуется, а передать идею не удается.)
Рис. 3.4. Перемещение энергии и информации
через комплекс преград
Используя эту метафору, посмотрим на расположение кабинетов, чтобы по-
нять, какие затраты энергии связаны с обнаружением необходимой информации
у кого-то другого.
Предположим, что Ким и Пэт занимают кабинеты на некотором расстоянии
друг от друга (рис. 3.4). Разделяющие их стены не позволяют Пэту видеть и слы-
шать Ким. Ким излучает информацию, находясь в различных частях здания во
время своих ежедневных перемещений. Люди, находящиеся в ее комнате, полу-
чают максимальное количество информации, а те, кто находится в пределах слы-
шимости от пути ее перемещения, получают соответствующее количество
информации. Информация достигает Пэта, если Ким входит в его кабинет, или
косвенно, через других людей.
Если их кабинеты расположены рядом, вероятность того, что Ким заглянет в
кабинет Пэта или наоборот, он к ней, возрастает (рис. 3.5, верхний). Точно так
же, как молекулы газа или тепло, информация проекта легче перемещается меж-
ду смежными комнатами.
Если Ким и Пэт работают в одном кабинете (рис. 3.5, средний), то Пэт не
только чувствует запах духов Ким раньше, чем кто-либо другой, находящийся
Коммуникация и сотрудничество в командах
91
вне стен кабинета, он также слышит, если Ким излучает полезную для него ин-
формацию.
Рис. 3.5. Газовые баллоны (или люди) в трех
различных конфигурациях
Информация перемещается с наибольшей скоростью, если Пэт и Ким сидят
бок о бок. Передача информации растет, если они работают над одной и той же за-
дачей, программируя парой, а не просто свдят рядом и работают над разными зада-
чами (это скорее имеет отношение к их концентрации внимания, чем к излучению).
Описание затрат на передачу информации, измеряемых в эрг-секундах,
включает влияние расстояния и методов коммуникации на затраты процесса.
Сравните общение лицом к липу в вашем кабинете с переходом на расстоя-
ние 50 м в кабинет коллеги. Переход по коридору требует работы (в эргах) и вре-
мени (в секундах). Энергия и затраты увеличиваются, а скорость передачи
информации снижается. Переместите людей ближе, за соседнюю от кабинета
дверь. По мере того как расстояние сокращается, работа, необходимая для визи-
та к коллеге, уменьшается. Вместе с ней уменьшаются энергия и затраты проек-
та, в то время как скорость передачи информации растет.
Точно так же описание идеи по телефону требует больше времени, чем описа-
ние ее при личном общении. В этом случае фактор времени увеличивается и растут
затраты проекта.
92
Глава 3
Формула эрг-секунд хорошо объясняет эти изменения. Конечно, эта форму-
ла не объясняет потраченную впустую энергию, например подпрыгивание на ме-
сте во время телефонного разговора или выбор длинного пути, ведущего в обход
здания к кабинету коллеги. Она также не гарантирует, что два человека, работа-
ющие в одной комнате, будут вообще понимать друг друга (см. раздел “Невоз-
можность коммуникации” во введении). В действительности она говорит лишь,
что затраты на проект возрастают пропорционально времени, необходимого лю-
дям, чтобы понять друг друга.
Осмотическая коммуникация
Когда мы пишем, читаем, вводим данные с клавиатуры или разговариваем, мы
улавливаем раздающиеся вокруг звуки, используя некоторый фоновый режим вы-
слушивания, даже если сознательно не обращаем на них внимание.
Если кто-то произносит что-либо интересное, мы можем оживиться и присо-
единиться к разговору. Иначе звуки проходят через некоторую фоновую обработ-
ку чуть выше или чуть ниже уровня нашего сознания.
В некоторых случаях мы отмечаем в разговоре достаточно, чтобы суметь об-
наружить все необходимое непосредственно в своей памяти. Иначе мы можем
вспомнить использованное выражение или только то, что определенное лицо об-
суждало определенную тему. В любом случае мы отмечаем достаточно, чтобы
спросить об этом.
Этот сбор информации, который происходит без непосредственного обраще-
ния на нее внимания, подобен процессу осмоса, в котором одно вещество проса-
чивается через перегородку из одной системы в другую.
Осмотическая коммуникация еще больше снижает затраты на передачу идеи.
Если Пэт и Ким работают в одной комнате, причем Пэт программирует, а
Ким участвует в обсуждении, то Пэт может получить достаточно информации и
узнать, что Ким говорит об этой идее. Если в комнате работает несколько чело-
век, Пэту становится известно, что у кого-то в комнате есть ответ.
Расположение кабинетов оказывает влияние на три аспекта затрат на обще-
ние в проекте:
Цена упущенных возможностей из-за незаданных вопросов
Общие затраты на обнаружение и передачу информации (в эрг-секундах)
Снижение затрат, когда люди обнаруживают информацию в фоновых зву-
ках (осмотическая коммуникация)
Все три эффекта отражают влияние расстояния между людьми в комнате.
Люди, сидящие рядом, получают выгоду во всех трех случаях; люди, сидящие в раз-
личных помещениях, теряют по всем трем пунктам.
Согласно этой теории, спонсоры должны хорошенько подумать, прежде чем
решаться на финансирование проекта, распределенного географически.
Коммуникация и сотрудничество в командах
93
Можно предположить, что теперь у нас появился простой ответ на задачку
о рассаживании нескольких человек: “Все ясно, поместите их в открытые и об-
щие рабочие помещения”. К сожалению, люди не настолько одинаковы и про-
сты, чтобы это решение работало во всех случаях.
Существуют еще три фактора, влияющие на ответ для каждого конкретного
размещения сотрудников по помещениям:
Разновидность совместно используемой информации
Личные предпочтения людей
“Сквозняки”
Участники команды обмениваются как деловой, так и технической информа-
цией.
Предположим, что бизнес-эксперта зовут Крис. Если Крис, Пэт и Ким сидят
вместе, то, как только у Пэта или Ким возникают вопросы из области бизнеса,
Крис может на них ответить. Он даже может увидеть, что делают Пэт и Ким, и
направить их в другом направлении. В любой момент они втроем способны объе-
динить свои умственные усилия, чтобы вместе изобрести что-нибудь лучше, чем
мог бы сделать один из них.
Эта разновидность радикального совместного размещения (radical colocati-
on) работает лишь для очень небольших команд. Как следует рассадить членов
группы, включающей двенадцать программистов и четыре бизнес-эксперта? Кто
с кем должен сидеть? Как их рассадить по комнатам, предназначенным для двух
человек каждая?
Наиболее общая организация рассаживания, которую я встречал, предпола-
гает размещение программистов в одной стороне здания, а бизнес-экспертов —
в другой.
При этом возникают две проблемы. Первая и очевидная проблема состоит в за-
тратах на общение по вопросам из области бизнеса, которые включают цену упу-
щенных возможностей из-за отсутствия вмешательства на ранних стадиях.
Вторая проблема возникает из-за формирования в двух этих группах двух
разных сообществ, каждое из которых обычно жалуется на другое. Разговоры в
осмотической коммуникации не обходятся без этих жалоб, препятствующих спо-
собности участников каждой группы работать друг с другом в дружелюбной ма-
нере.
Естественным для осмотической коммуникации образом этот эмоционально
окрашенный фоновый шум впитывается в подсознание каждой группы. В данном
случае он не только не развивает, но и негативно влияет на взаимоотношения ее
участников. Собираясь на совещание с “этими кретинами”, они не уделяют пол-
ного внимания тому, что говорят представители другой группы, а когда говорят
сами, не передают полной информации. Дружелюбие группы страдает со всеми
сопутствующими издержками, которые мы обсуждали.
94
Глава 3
В настоящее время я предпочитаю такую организацию размещения, чтобы один
или несколько бизнес-экспертов сидели рядом с двумя или большим числом про-
граммистов. Если это невозможно, я ищу другие деловые и социальные механизмы,
позволяющие довольно часто (а желательно ежедневно) привлекать бизнес-экспер-
тов к регулярной, содержательной совместной работе с программистами.
Создание групп, в которых для общей работы объединяются представители
различных профессий, рекомендуется многими авторами. Такие группы называ-
ют “целостным разнообразием” {Holistic Diversity, Cockburn, 1998), СА-
SE-командами (Hammer, 1994) и характерными командами (McCarthy, 1995).
Когда можно их создать, проект продвигается быстрее благодаря возрастанию
информационного потока и дружественных отношений между представителями
различных профессий.
Другая проблема связана с личными предпочтениями людей.
Когда я начал спрашивать специалистов о работе в общих комнатах по срав-
нению с личными кабинетами, всплыло несколько вопросов.
Некоторые люди действительно ценят свои спокойные личные кабинеты.
Ценят настолько, что при необходимости отказаться от них они чувствуют себя
обиженными, и некоторые могут даже уйти из компании. Если мы имеем дело
именно с таким случаем, то любой выигрыш в общении теряется частично, если
сотрудник остается, но чувствует себя обиженным, и теряется полностью, если
он уходит из компании.
Таким образом, на чисто теоретический довод в пользу рассаживания сотруд-
ников вместе с теми, с кем им нужно взаимодействовать, влияют личные предпоч-
тения. Несколько человек мне говорили: “Я предпочитаю работать в собственном
кабинете, но, принимая во внимание все проекты, в которых я участвовал, должен
сказать, что наивысшей продуктивности я достиг, когда у нас с коллегой по проек-
ту был общий кабинет”. Я сам так часто оставлял личные кабинеты, что в конце
концов обратил на это внимание как на образец. А когда заметил, что и другие
эксперты поступают так же, это стало стратегией управления проектами, кото-
рую я назвал “эксперт в пределах слышимости” (Cockburn, 2001а).
Третья проблема, затрагивающая организацию рассаживания сотрудников,
касается сквозняков.
“Сквозняки”
"Сквозистые" помещения
Однажды, когда я рассказывал об этом своеобразном понятии кон-
векционных потоков информации, один из слушателей вдруг вос-
кликнул: "Но вы должны остерегаться сквозняков!"
Он объяснил, что работал в одном месте, где у него и других програм-
мистов были расположенные рядом помещения с низкими стенами, и
они извлекали пользу от этого, так как могли слышать друг друга.
Коммуникация и сотрудничество в командах
95
С другой стороны их модуля сидели сотрудники центра обработки
заказов, весь день отвечавшие на телефонные звонки. Они также
выигрывали, оттого что могли слышать друг друга. Но, и в этом со-
стояла отрицательная сторона такого размещения, разговоры со-
трудников центра обработки (по его собственным словам)
"переливались через стены в зону программистов". Это был "сквоз-
няк" ненужной информации, дувший из чужой зоны.
В нашей расширенной по-новому метафоре “сквозняками” (drafts) называ-
ется ненужная информация.
Позднее два программиста обсуждали тонкость своих стен. Им нравилось
работать в общей комнате, но их донимали соседи, громко спорившие между со-
бой. В информационном плане их комната была “сквозистой”.
Теперь у нас есть славная парочка сил, которые нужно уравновесить: мы
должны так спланировать группы рабочих мест, чтобы увеличить поток инфор-
мации между людьми, сидящими в пределах слышимости, и сопоставить это уве-
личение с возникающими сквозняками — слышимостью информации, не
приносящей им никакой пользы. Сделав осмотр ваших помещений, вы можете
прояснить для себя это ощущение.
Осмос на расстоянии
Могут ли команды что-либо предпринять, чтобы улучшить общение, если по ка-
кой-то причине они не сидят вместе?
Чарльз Херринг (Charles Herring) из Австралии описывает применение тех-
нологий для имитации “присутствия и осведомленности”, если следовать выра-
жению, используемому исследователем в области компьютерной поддержки
совместной работы (Herring, 2001). Далее следует перефразированное краткое
описание его опыта.
Электронное присутствие и электронная осведомленность
Сотрудники сидят в различных частях здания. На их рабочих станциях
установлены микрофоны и web-камеры, а на экранах мониторов
имеется набор упорядоченных небольших окон, показывающих кар-
тинки от камер, установленных у других сотрудников.
Они хотели дать каждому человеку ощущение, что он работает в группе
(“присутствие”), и осведомленность о делах других сотрудников.
Пэт может лишь взглянуть на изображение Ким, чтобы решить, можно ли ее
отвлечь вопросом. Этот взгляд позволяет Пэту определить, то ли Ким что-то со-
средоточенно вводит в компьютер, то ли работает в расслабленном режиме, раз-
говаривает с кем-то или вышла из комнаты.
Затем Пэт может задать Ким вопрос, воспользовавшись микрофоном или
панелью для переписки, имеющейся на его экране. Они даже могут пересылать
в эти панели фрагменты программного кода из рабочей среды.
96
Глава 3
В этом исследовании сообщается о низкой степени отвлечения внимания.
Чарльз добавил, что, программируя, он мог без труда реагировать на запросы и
даже отвечать по проблемам программирования, не теряя основной ход мысли по
собственной работе.
Павел Кертис (Pavel Curtis) с коллегами из Xerox PARC смогли с помощью
видео- и аудиотехники сымитировать “шепот” (когда пользователь хотел бы по-
говорить лишь с одним лицом в комнате). Они также научили свои комнаты
on-line для бесед издавать фоновые звуки, сообщающие, когда люди входят и вы-
ходят (Curtis, 1995).
Поскольку мемы (идеи) перемещаются не по воздуху, а должны передавать-
ся через чувства — в первую очередь слух и зрение, то при использовании техно-
логии высокой пропускной способности мы должны быть способны подражать
эффектам конвекционных потоков информации. В этих технологиях, конечно, от-
сутствуют осязаемые и кинестетические отклики, которые могут быть так важны
для межличностного общения.
Излучатели информации
Излучатель информации отображает информацию в таком месте, где можно ее
увидеть, проходя мимо. Проходящий мимо сотрудник не должен задавать вопро-
сов — информация сама попадает к нему.
Для хорошего излучателя важнейшими являются две характеристики. Первая
— это изменяемость информации во времени. Эта характеристика делает излуча-
тель заслуживающим внимания для лица, видящего отображение информации. Та-
кая характеристика объясняет, почему излучатель информации с отображением
состояния полезен, а отображение процесса развития компании — нет.
Другая характеристика — осмотр не должен требовать больших затрат
энергии. Когда речь заходит об излучателях информации, важен размер — чем
он больше, тем лучше.
Коридоры оцениваются как в высшей степени удачные места для размеще-
ния излучателей информации. Web-страницы таковыми не считаются. Доступ к
web-странице требует от большинства людей больше усилий, чем они хотят при-
ложить, и поэтому информация остается скрытой. В следующей истории, кото-
рой поделился со мной Мартин Фаулер (Martin Fowler) из компании
Thoughtworks, говорится об одном исключении: команда посчитала, что конкрет-
ный отчет приносит больше пользы на web-странице.
Автоматически формируемый отчет
Программа автоматически формирует для команды информацию о со-
здании системы каждые 15 минут. После каждой выдачи она посылает
сообщения электронной почты каждому лицу, чьи тесты заканчиваются
ненормально, и отправляет статистику создания системы на web-стра-
ницу.
Коммуникация и сотрудничество в командах
97
Информация о системе обновляется на web-странице каждые 15 ми-
нут. Мартин сообщает, что число программистов, постоянно держа-
щих эту web-страницу на своем экране, растет, и периодически,
чтобы проверить недавнюю историю создания системы, они щелка-
ют по кнопке Refresh.
Первые излучатели информации я заметил в Thoughtwoks, когда беседовал с
Мартином Фаулером о применении в этой компании методологии ХР для нео-
бычно крупного (с 40 сотрудниками) проекта (рис. 3.6 и 3.7).
Рис. 3.6. Коридор с излучателями информации.
(Публикуется с разрешения Thoughtworks, Inc.)
Излучатели продвижения проекта
Мартин рассказал, что группа тестирования беспокоилась о состоя-
нии системы.
Чтобы уменьшить беспокойство тестировщиков, программисты по-
местили в коридоре этот плакат (рис. 3.6), показывающий их про-
движение.
На этой диаграмме было показано состояние работы с пользователь-
скими требованиями (историями — user stories, как это называется в
ХР) в рамках итерации, с пояснениями для каждой истории. Про-
граммисты передвигали пояснения по диаграмме, чтобы показать за-
вершенность и качество реализации пользовательских историй, над
которыми они работали. Они передвигали пояснение вправо, когда
история приближалась к завершению, и поднимали ее на плакате
выше, когда улучшалось ее качество. Пояснение могло приостано-
вить движение вправо на то время, когда оно смещалось вверх.
Тестировщики могли видеть состояние системы, не докучая програм-
мистам. В данном случае они видели, что работа продвигается значи-
тельно лучше, чем они думали, и скоро перестали беспокоиться о со-
стоянии проекта.
98
Глава 3
Самое лучшее было то, что они могли оценивать продвижение рабо-
ты ежедневно, не задавая вопросов программистам.
Рис. 3.7. Отображение состояния с показом уровня завершения
и качества реализуемых пользовательских историй.
(Публикуется с разрешения Thoughtworks, Inc.)
Точно так же, как теплопровод несет теплый воздух в коридор или нагрева-
тель излучает тепло в комнате, эти плакаты излучают в коридоре информацию на
проходящих мимо людей. Они изумительно справляются с задачей тихой переда-
чи информации, не создавая помех сотрудникам, о состоянии работы которых со-
общают.
Второе применение излучателей информации, подходящее для любого про-
екта, использующего итерации длиной в один месяц и менее, состоит в показе де-
композиции и распределения работ для следующей итерации (рис. 3.8). Данный
пример также получен из Thoughtworks.
Рис. 3.8. Широкая стена, служащая излучателем
информации, показывает итерационный план с отдельными
плакатами для разных пользовательских историй
(Публикуется с разрешения Thoughtworks, Inc.)
Коммуникация и сотрудничество в командах
99
Отображение декомпозиции работ
Команда создала по одному плакату для каждой пользовательской
истории. Участники команды помещали на плакате пояснительные
пометки к задачам, которые они должны были решить для данной
истории.
Они перемещали пояснения вниз плаката, чтобы показать задачи, вы-
веденные из области действия текущей итерации в соответствии с гра-
фиком выпуска.
ХР-команда компании Event также использовала белые доски и плакаты как
излучатели информации. На рис. 3.9 показаны задачи для итерации “Мэри-Энн”
(каждая итерация получила имя персонажа из телевизионного сериала Gilligan’s
Island).
Рис. 3.9. Детальная запись ХР-задачи и состояние
для одной итерации (названной Мэри-Энн)
(Публикуется с разрешения Evant Solutions Corporation)
Третье использование плакатов в качестве излучателей информации состоит
в показе результатов периодического рабочего семинара, посвященного проекту
(рис. 3.10). В ходе этих часовых (или двухчасовых) семинаров команда обсужда-
ет, что у них идет хорошо, а что следует изменить. Результаты обсуждения запи-
сываются на плакате, и он прикрепляется на видном месте, чтобы напоминать
сотрудникам об этих мыслях во время дальнейшей работы.
Формулировки на этих плакатах имеют значение. Одна ХР-команда объяви-
ла: “Вот что мы сделали неправильно в прошлом инкременте”. Другая команда
100
Глава 3
написала: “В этом инкременте нужно проработать следующие моменты”. Пред-
ставьте себе различие этих проектов. Первая формулировка излучает в комнату
разработчиков вину, и неудивительно, что сотрудники нечасто обращали на это
внимание. Вторая излучает обязательство. Члены второй команды, разговаривая
о проекте, часто смотрели на свой плакат.
Рис. 3.10. Результаты рабочего семинара
(Публикуется с разрешения Joshua Kerievsky,
Industrial Logic, Inc.)
Периодически проводимые рабочие семинары, подобные этим, используют-
ся в проектах, выполняемых по методологиям Crystal Clear и ХР.
Четвертое применение излучателей информации состоит в показе пользова-
тельских историй, уже реализованных в продукте или находящихся в процессе
разработки, а также числа приемочных тестов, написанных и выполненных, и
другой подобной информации (рис. 3.11).
Команда эксплуатации системы в eBucks.com придумала пятое использова-
ние излучателей информации, на этот раз, чтобы программисты ей не докучали.
Отображение состояния системы
Программисты то и дело спрашивают: "Система А работает? А сис-
тема В работает? А связь со вспомогательной системой есть?"
Команда сопровождения записала состояние каждой системы и свя-
зей между ними на белой доске и вывесила перед своим помещени-
ем. Каждый день они обновляли состояние. Это напоминает лыжную
базу, где вывешивают состояние подъемников и трасс (чтобы лыж-
ники не спрашивали это поминутно у персонала курорта).
Коммуникация и сотрудничество в командах
101
Количество приемочных тестов
Исправлено
□ Оттестировано
Рис. 3.10. Диаграмма, показывающая рост результатов работ
(Публикуется с разрешения Рона Джеффриса)
Группа из eBuck.com отличилась шестым использованием излучателей ин-
формации. На этот раз продемонстрировать состояние решили программисты.
Демонстрация продвижения работы
Каждые час или два у этих программистов кто-нибудь спрашивал о со-
стоянии их работы, что создавало им массу помех.
На белой доске, повешенной у входа в их помещение, они изложили
свои планы на текущую неделю. Работы тщательно подбирались, так
чтобы их объемы находились в диапазоне от полудня до двух дней.
Заканчивая каждую работу, они отмечали это на доске.
После того как такие доски были испробованы программистами, не-
сколько других групп начали их применять, чтобы оповещать о своих
ближайших планах и их выполнении.
Применение теории “горячего воздуха”
Теория “горячего воздуха” в разработке ПО применяется довольно давно.
Джеральд Вейнберг исследовал вредное влияние удаления автомата с гази-
рованной водой из компьютерного помещения (Weinberg, 1998). Томас Аллен
(Thomas Allen) из Sloan School of Management исследовал влияние проектирова-
ния зданий на научно-исследовательские организации (Allen, 1984). С конца
1970-х годов IBM и Hewlett-Packard используют такие исследования при строи-
тельстве задний для своих научно-исследовательских подразделений.
В результате этих и других работ вид белых досок в коридорах рядом с ко-
фейными аппаратами в научно-исследовательских подразделениях стал привыч-
ным. Однако мы давно не вспоминали, как важно участникам группы находиться
в пределах видимости и слышимости друг друга.
102
Глава 3
Вот несколько примеров. Первый относится к проекту, использовавшему
методологию Crystal Orange. Второй — к проекту, в котором безуспешно попы-
тались применить Crystal Clear. Далее последует обсуждение модели помещения
пещеры и общая территория”, рекомендованной в ХР. Заключительным приме-
ром будет история успеха группы Skunk Works компании Lockheed.
Обсуждение восстановительного проектирования
В проекте "Winifred" (Cockburn, 1998) ведущий программист перио-
дически объявлял, что проектирование абсолютно излишне и что
программный код просто вырастает под его пальцами.
Как можно было прогнозировать, молодые программисты, работаю-
щие с ним в одной комнате, также почувствовали ненужность проек-
тирования. Код программ выглядел соответственно.
В конце концов он бросил эту работу, а я занял его место. Чтобы
изменить ситуацию в корне, я организовал проектирование за об-
суждением у белой доски. Через какое-то время я начал получать
вопросы в таком духе: "Ты не взглянешь на обязанности (или образ-
цы взаимодействия) этих объектов?"
Установив слышимый тон в комнате, узаконив и оценив обсуждения вопро-
сов проектирования, программисты начали разговаривать о проектировании.
Совместное размещение сотрудников считается важнейшим элементом в
Crystal Clear — простой методологии, предназначенной для небольших команд
(см. раздел “Crystal Clear” в главе 6.) Правило Crystal Clear заключается в том,
что вся команда должна сидеть в одном единственном помещении или в смежных
комнатах, чтобы пользоваться конвекционными потоками информации и осмоти-
ческой коммуникацией.
Непонятная методология Crystal
Пэт попросил меня посетить его проект, в котором применялась ме-
тодология Crystal Clear. Когда я приехал, его не оказалось на месте.
Секретарша сказала, что он пошел к своему коллеге.
Я выразил готовность отправиться в другой кабинет, но она возрази-
ла: "Не получится. Там кодовый замок в коридоре у входа в их сек-
цию".
"!!...?"
Каждый раз, когда участник команды хотел задать вопрос, он должен был
встать из-за стола, пройти по коридору, набрать код на замке и пройти в каби-
нет другого участника команды. Ясно, что в этой команде не использовались
преимущества осмотической коммуникации или низких затрат на передачу ин-
формации. К счастью, организовать другое рассаживание команды было очень
просто.
Коммуникация и сотрудничество в командах
103
Пещеры и общая территория
Организация комнаты по модели “пещеры и общая территория”, рекомендуемая в
ХР, использует все три механизма обмена информацией. Она показана в действии
на рис. 3.12 и схематически изображена на рис. 3.13.
“Пещеры и общая территория” — очень эффективная модель, но, как спра-
ведливо предупреждает Том ДеМарко, ее легко испортить и превратить в поме-
щение, где царит потогонная система. Поэтому в данном разделе описывается не
только планировка такой комнаты, но и социальные предпосылки, сопутствую-
щие ее использованию: команда одного проекта, хорошая динамика команды и
обеспечение личного и общего пространства проекта.
Выражение “пещеры и общая территория” означает создание в комнате двух
зон. “Общая” территория организована для максимального увеличения осмоти-
ческой коммуникации и передачи информации. Чтобы это имело смысл, люди,
находящиеся в комнате, должны работать над одним и тем же проектом. Эта мо-
дель идеально подходит для одной ХР-группы, включающей не более двенадцати
человек, программирующих парами (рис. 3.12).
Рис. 3.12. Команда RoleModel Software за работой
(Публикуется с разрешения RoleModel Software)
Часть комнаты, представляющая собой “пещеры”, устроена так, чтобы пре-
доставить людям личное место для отправки электронной почты, телефонных
разговоров и удовлетворения их потребности в уединении. В помещении RoleMo-
del Software личные рабочие станции установлены вдоль одной стены (рис. 3.13).
В компании Evant столы расположены у стен с двух сторон комнаты.
Люди, работавшие в помещении, устроенном по этому принципу, говорят,
что в нем должно быть достаточное пространство на стене для белых досок и пла-
104
Глава 3
катов и еще два типа комнат общего использования: для приготовления пищи и
для проведения непродолжительных обсуждений.
Рис. 3.13. Планировка комнаты “пещеры и общая территория",
использованная в RoleModel Software
(Публикуется с разрешения RoleModel Software)
На рисунке видно, что, хотя комната “пещеры и общая территория” очень
эффективна для передачи информации, в ней также хорошо передается кашель и
насморк. Люди, работающие в комнатах такого типа, просят коллег оставаться
дома, если те чувствуют себя нехорошо, и появляться на работе после полного
выздоровления.
Заметим, что по этой комнате гуляют сквозняки (в информационном смыс-
ле): людям, сидящим в помещении с такой планировкой, просто приходится под-
слушивать друг друга.
Наконец, такое расположение очень эффективно, пока моральное состояние
группы хорошее. Если дружеская беседа вырождается в недружелюбное словоблу-
дие, то интенсивная осмотическая коммуникация вновь усиливает его эффект.
Кабинет скунса
Полезно сравнить приведенное выше изложение с примером одной из наиболее
эффективных авиастроительных групп, выполнявшей классическую инженерную
работу — командой “кабинета скунса” компании Lockheed. Эта команда добилась
славы благодаря быстрой разработке серии абсолютно новых конструкций само-
летов во второй половине 20 в. под руководством Джима Келли (Jim Kelly) и его
Коммуникация и сотрудничество в командах
105
последователя Бена Рича (Ben Rich). О своем опыте Бен Рич написал в книге
Skunk Works (1994).
Рич подчеркивает, что среди правил, существовавших в группе, Келли особо
выделял несколько. Он настаивал, чтобы люди брали на себя ответственность за
решения, от проектирования до испытаний, и чтобы они сидели рядом друг с дру-
гом. Следующий отрывок взят из этой книги.
Комнаты Skuns Works
"Келли держал тех из нас, кто работал над его самолетом, зажатыми
в одном углу нашего здания... Моя группа из трех человек, занимав-
шаяся термодинамикой и двигателем, делила помещение с людьми из
группы летных качеств и контроля прочности. В смежной комнате
ютились восемь человек из группы конструкции... Мы с Генри могли
добраться до рабочего места, пройдя через дверь и несколько протя-
нутых для пожатия рук.
... Соединительная дверь отделяла меня от кабинета, где четыре
парня, занимавшиеся конструкцией, рассчитывали по предваритель-
ным наброскам прочность, нагрузки и вес самолета... Группа аэро-
динамики из моего кабинета начала разговаривать с командой
конструкций о вычислениях центра давления на фюзеляже, когда
внезапно мне пришла идея снять с петель разделявшую нас дверь,
положить ее на пару столов, прикрепить на ней кнопками длинный
лист бумаги и приступить всем вместе к проектированию оптималь-
ной окончательной конструкции... На это ушло полтора дня...
Для него имела значение лишь наша близость к производственному
цеху: вроде бы совсем близко, но для него это было слишком дале-
ко, ему было нужно, чтобы мы действительно находились в несколь-
ких шагах от рабочих, могли быстро внести структурные или
частичные изменения и ответить на любой их вопрос".
Каждая команда, выполняющая проект, должна искать способы снизить об-
щие затраты энергии на обнаружение и передачу необходимых идей. Для этого
нужно обращать внимание на конвекционные потоки информации и улучшать их
течение, добиваться пользы от осмотической коммуникации и наблюдения за ис-
точниками “сквозняков”, а также использовать излучатели информации. Конечная
цель состоит в снижении числа эрг-секунд, необходимых участникам команды для
обмена информацией при любых ограничениях, накладываемых организацией на
их размещение, как с использованием, так и без использования технологии.
Преодоление разрывов коммуникации
Для того чтобы сделать общение как можно более эффективным, главное — повы-
сить возможность преодоления разрывов коммуникации, существующих всегда. От-
правителю нужно прикоснуться к высшему уровню совместного опыта с по-
лучателем. Два человека должны обеспечить друг /у1я друга постоянную обратную
106
Глава 3
связь в этом процессе, чтобы они могли определить степень, до которой им не удает-
ся осуществить свой замысел.
Моаольности в общении
Вообразите обычное обсуждение у белой доски. Сколько механизмов общения
включено в игру? Рассмотрим следующие одиннадцать.
Физическое соседство. Стоя приблизительно в метре друг от друга, люди за-
мечают мельчайшие видимые сигналы, незначительные движения глаз, связан-
ные с общим мышечным напряжением.
Говорящий может подойти ближе, показывая агрессивность или воодушевле-
ние. Слушатель может приблизиться, чтобы выразить интерес, согласие, желание
заговорить или наоборот — отступить дальше, демонстрируя опасение, несогла-
сие или необходимость немного подумать об услышанном. Говорящий и слушатель
управляют относительным расстоянием между собой для выражения различных
эмоций и уровней согласия, несогласия, агрессивности, доверия и сомнения.
Эти сигналы различаются между культурами и личностями, но они всегда
присутствуют и используются.
Трехмерность. Люди обращают внимание на видимый параллакс или трех-
мерную информацию. .
Сдвиг параллакса видимого изображения теряется, когда те же люди говорят
через видеоканал, даже если они так же близки к видеокамере и экрану.
Обоняние. Обоняние относится к чувствам, не существенным для некоторых
людей, очень важным для других и важным, но подсознательно, для очень многих.
Одна женщина сообщила, что часто ощущает сублимированный страх или
физическое страдание, вероятно, благодаря обонянию. Безусловно, это тот слу-
чай, когда подобные сигналы действуют у белой доски и теряются при дистанци-
онном общении.
Кинестетика. Многие люди применяют кинестетику (ощущение движения)
как средство, помогающее думать и запоминать. Говорящий может пользоваться
этими механизмами при построении нового объяснения или для улучшения фор-
мулировки вопроса.
Прикосновение. Когда один человек касается другого, это может означать:
“Не бойтесь этого обсуждения” или “Это действительно важно”, или “Мне нуж-
но что-то сказать”.
Прикосновение является частью управления близостью и личным простран-
ством. В некоторых случаях ощущение от прикосновения к отдельным объектам
важно для разговора.
Звук. При обычном использовании языка говорящий выделяет существен-
ные моменты красочными эпитетами, преувеличениями, метафорами и тому по-
добными приемами.
Коммуникация и сотрудничество в командах
107
Кроме простого использования языка, говорящий изменяет высоту тона,
громкость и делает ударение на мысли в предложении.
Визуальные сигналы. Люди общаются не только словами, но и жестами, ча-
сто подчеркивая суть особым способом, поднимая бровь или указывая куда-либо
при разговоре.
Люди могут размахивать руками, создавая в воздухе очертания предметов
или усиливая свою речь. Они могут поднять бровь для обозначения вопроса или
логического ударения.
Кроме того, они могут регулировать темп для различения или выделения
мыслей, например, быстро продвигаться по очевидным частям рисунка и замед-
ляться либо умолкать для большего эффекта в менее очевидных или более важ-
ных его частях.
Человек также рисует на белой доске, чтобы представить (особенно про-
странственно ориентированную) информацию, которую следует обдумать друго-
му человеку. Рисунки могут содержать стандартизованные обозначения, к при-
меру диаграммы классов или временные диаграммы. Они могут быть небрежными
набросками. Это даже могут быть символы, не имеющие конкретного значения,
единственная цель которых состоит в закреплении высказанной мысли в общем,
стационарном месте, чтобы ссылаться на нее позднее.
Синхронизация между модальностями. Одной из наиболее важных харак-
теристик двух человек у белой доски является синхронизированное соотношение
всех перечисленных механизмов.
Говорящий двигает лицевыми мускулами, делает жесты, рисует, продолжая
говорить и двигаться, выдерживает паузы в речи, чтобы подчеркнуть эффект ри-
сунка, тщательно выговаривает ключевые фразы в нужные моменты, соединяя,
скажем, линиями два очертания.
Синхронизированный акцент нескольких модальностей помогает закрепить
идею в памяти слушателя, расширяя ассоциации вокруг нее.
Нарисованные на доске, бессмысленные в других обстоятельствах, символы
при разговоре получают значение — значение, к которому говорящий и слуша-
тель могут позднее обратиться.
Низкое (краткое) время ожидания. Поскольку два человека, участвующие
в разговоре, стоят рядом, наблюдают друг за другом и слушают, время обмена
сигналом и ответом очень невелико. Благодаря этому можно в реальном времени
задавать вопросы, получать ответы и прерывать речь собеседника.
Вопросы и ответы в реальном времени. Получатель задает вопросы,
чтобы выявить неопределенность в объяснении говорящего. Выбор време-
ни для вопросов устанавливает образец общения между этими людьми.
Прерывания. Обладая очень быстрым временем обмена реакциями при
общении лицом к лицу, слушатель может прервать говорящего, попросив
108
Глава 3
пояснить непонятное место. В ходе беседы говорящий приспосабливает из-
ложение, чтобы оно соответствовало опыту получателя информации. Слу-
шатель может прореагировать на речь говорящего в середине выражения
идеи, возможно, подняв бровь или другой невербальной модальностью. По-
сле этого говорящий может по ходу скорректировать выражение.
Доверие и обучение. С помощью модальностей и быстрой ответной реакции
два человека, вероятно, смогут развить ощущение удобства и доверия в общении
между собой.
Это удобство и доверие такого вида: “Ага, когда он говорит таким тоном, он
вовсе не злится, а просто возбужден”. Оба собеседника находят способы не за-
деть друг друга и понять, что они не будут обижены при общении.
Они строят простые эмоциональные нормирующие ритуалы движения и вы-
ражения, чтобы, например, показать: “Начинаю чувствовать, что на меня напа-
дают” или “Ну и напрасно, эта атака направлена не против тебя”.
Такие ритуалы хорошо служат людям в ходе проекта, особенно когда они не
могут видеть друг друга при общении. В такой ситуации прикосновение к совме-
стному опыту этих ритуалов становится решающим.
Потребностью в таких нормирующих ритуалах можно объяснить частые пу-
тешествия на самолете.
Частые полеты ради личного присутствия
Женщина — руководитель фирмы, работающей в области видеосвя-
зи, вернулась в Сан-Хосе из Лондона. За десять дней это была ее
вторая поездка, и каждый раз она отправлялась в полет для од-
ной-единственной встречи.
Поскольку она, конечно, имела доступ к самым новейшим средствам
проведения видеоконференций, мы были изумлены, узнав, что она до
сих пор не может вести дела по видеоканалу. Ей по-прежнему требо-
валось во время встреч низкое время ожидания, самое насыщенное
общение, с использованием разнообразных модальностей, короче го-
воря, "личное общение".
Мы решили, что начинать переговоры по телефону или через Интер-
нет легко, но привести их к результату этим способом сложно.
Использование совместного устойчивого излучателя информации. Белая
доска хранит на месте информацию рисунков, в то время как слова растворяются
в воздухе. Все могут видеть доску, рисовать на доске и обращаться к ней через
несколько минут после состоявшегося разговора.
Влияние удаления модальностей
Что происходит, когда вы убираете некоторые из этих механизмов и переходите
к другим параметрам общения?
Коммуникация и сотрудничество в командах
109
Удалите только физическое соседство. Если люди находятся на противопо-
ложных концах видеоканала, визуальные и временные характеристики должны
бы оставаться очень похожими на личное общение.
Однако почему-то это не так, если принять во внимание свидетельство руко-
водителя фирмы видеосвязи, по-прежнему летающей в Лондон ради единствен-
ной встречи.
Мои коллеги в Лиллехаммере, а я в Осло часто убеждались, что существен-
но продвинуть проектирование мы можем лишь в совместных поездках на поезде.
Даже совместная прогулка до железнодорожной станции создает более благо-
приятную среду проектирования, чем разговор по видеоканалу.
Удалите визуальные модальности (используйте телефон). Удаление визуа-
льных механизмов также исключает синхронизацию между модальностями. Вы
теряете рисунки, жесты, выражения лица, вид мускульного тонуса, сигналы бли-
зости и способность связать речь с действием.
Удалите голос (электронная почта). В этом случае вы теряете голосовые ин-
тонации, возможность сделать паузу для большего впечатления, ускорить речь, за-
медлить ее, чтобы подчеркнуть важность фразы, повысить тон или усилить звук
для демонстрации удивления, скуки или очевидности передаваемой идеи.
Удалите возможность задавать вопросы (но с возможным восстановлени-
ем одной из прежних модальностей). Не получая вопросов, отправитель дол-
жен только догадываться, что получателю известно, что неизвестно, о чем он
хотел бы спросить, и каким мог бы быть соответствующий ответ на предполагае-
мый вопрос — и все это без обратной связи.
В данном случае отправитель не знает по-настоящему, что получателю нуж-
но услышать, где разрывы коммуникации слишком широки и где находится со-
вместный опыт. (Это, конечно, напоминает мне общение с вами. Сколько
слов — и каких — понадобится мне, чтобы выразить эту идею?)
Наконец, удалите почти все. Уберите визуальные механизмы, звук, время,
кинестетику, синхронизацию между модальностями, вопросы, ответы и вы полу-
чите ... бумагу.
Как это удивительно, обратившись к прошлому, обнаружить, что большин-
ство проектов требует наличия документации в наименее эффективном для об-
щения формате! Человек, пытающийся сообщить проектную идею, должен
предположить, что он будет работать для читателя и поэтому не сможет исполь-
зовать временные, голосовые интонации, не сможет выделить мысль жестом и
ни разу не получит никакой обратной связи.
Если иметь в виду это представление, то не удивительно, что наиболее деяте-
льные и лучшие руководители групп проектирования высказываются так:
“Поместите всех в одну комнату”.
110
Глава 3
“Не давайте мне более четырех человек. Если будет больше, я не смогу
их усадить в одной комнате и разговаривать со всеми”.
“Дайте мне белые доски с возможностью печати и заберите обратно
все ваши приспособления для рисования”.
“Позаботьтесь, чтобы по всему зданию были белые доски и кофейные
автоматы”.
Это стандартные рекомендации успешных руководителей проектов, рассчи-
тывающих использовать наивысший способ общения — людей, общающихся ли-
цом к лицу.
Обсуждение модальностей общения соответствуют данным исследователей,
например Маккарти и Монка (McCarthy, Monk, 1994).
Использование модальностей
График на рис. 3.14 служит для объединения и визуального представления приве-
денного выше изложения. На этом графике вы видите два набора ситуаций: тех, в
которых существует возможность вопросов и ответов, и тех, где такая возмож-
ность отсутствует.
На горизонтальной оси указывается “температура” канала общения. Более
теплые точки означают, что передача обладает большим эмоциональным и ин-
формационным насыщением. Электронная почта “холоднее” звукозаписи или ви-
деозаписи, а самым “горячим” каналом является общение лицом к лицу.
(холодно) (горячо)
Насыщенность (“температура”) канала коммуникации
Рис. 3.14. Эффективность различных способов общения
Коммуникация и сотрудничество в командах
111
На этом графике мы видим, что эффективность общения возрастает с насы-
щенностью (“температурой”) канала коммуникации. Два человека у белой доски
используют самую насыщенную форму.
Данный график подсказывает идею, как улучшить эффективность архивной
документации.
Архивная документация на видеокассетах
Убедите проектировщика вкратце (от пяти до пятнадцати минут) из-
ложить проект одному-двум коллегам, не знакомым с этой рабо-
той. Эти люди выступят представителями зрителей, которые затем
будут смотреть видеозапись. В то время как проектировщик излага-
ет материал, коллеги при необходимости прерывают его и задают
вопросы.
Запишите это обсуждение на видеокассету.
В конце соберите и напечатайте примеры и рисунки, использованные
при обсуждении, чтобы их можно было добавить для мнемониче-
ской привязки к обсуждению.
Вы можете опубликовать беседу на сайте, чтобы другие могли получать к ней
доступ с использованием гиперссылок.
Лизетта Веласкес (Lizette Velasquez) из Lucent Technologies не только сооб-
щила об успешном использовании этого приема, но и отметила, что я упустил
кое-что существенное.
По ее мнению, важно отмечать и вносить в указатель сайта места, в которых
“происходит нечто интересное”.
Хотя значительная часть обсуждения протекает в относительно медленном
темпе, изредка один вопрос дает начало вспышке важного обсуждения, и зрите-
лям потребуется обращаться к этим разделам записи.
Несколько человек сообщают, что записали на видеокассету обсуждения их
проектов, но нам не хватает экспериментальных сведений о фактическом исполь-
зовании этого приема: как устроить комнату, насколько долгим может быть бесе-
да, кто может представлять зрителей. Более всего я жду, чтобы кто-то выполнил
этот эксперимент, а затем, месяцев через шесть, поделился своими соображени-
ями о полезности этой идеи и возможности ее улучшения.
Если вы готовы попробовать провести этот эксперимент, пожалуйста, сооб-
щите следующие подробности: что вы сделали, что произошло и что вы об этом
думаете через несколько месяцев.
Для осмысления эксперимента по поводу полезности этого графика и записи
на видекассету рассмотрите книгу Design Patterns (Gamma, 1995). Это замеча-
тельная, но трудная книга. Я до сих пор испытываю сложности с теми момента-
ми, которыми еще не пользовался. Полагаю, что у других также возникают
подобные осложнения. Вообразите, что вы пытаетесь понять значения примеров
не по книге, а можете увидеть видеоклип, на котором один из авторов дает обра-
112
Глава 3
зец. При изложении идеи авторы, разумеется, будут полагаться на интонации,
жесты и паузы. Я убежден, что большинству зрителей будет легче понять эти
сложные образцы.
Урок состоит в том, чтобы попытаться передвинуть общение команды вверх
по кривой так далеко, как это возможно в существующей ситуации. Мы вправе
рассчитывать на неформальное общение лицом к лицу, а не просто его допус-
кать. Общение лицом к лицу должно стать центральной частью вашего процесса
разработки.
Есть и второй урок, на который стоит обратить внимание. Иногда более “хо-
лодный” канал общения работает эффективнее, поскольку наполнен менее эмо-
циональным содержанием.
Потребность в более холодном общении
Руководитель проекта рассказала мне, что участники ее команды
лучше общаются с ней по телефону, поскольку при личном общении
она слишком эмоциональна и кажется агрессивной.
Супружеская пара сообщила, что по телефону они общаются более
"ровно" и менее эмоционально, просто потому что размещение ли-
цом к лицу наполняет их визуальными и эмоциональными подсказками.
Ховенден (Hovenden, 2000) описывает совещание, первоначальный
план которого разрушил старший проектировщик — он встал и за-
владел белой доской до конца совещания. В этом случае из-за от-
сутствия анонимности сыграло свою роль различие в социальном
статусе, помешавшее намеченному совещанию.
Бордиа и Прашэнт (Bordia, Prashant, 1994) описывают, что "мозговой
штурм" проходит удачнее, когда информация о социальном статусе
скрывается от участников.
Маккарти и Монк (1994) напоминают нам о преимуществах элект-
ронной почты, позволяющей отправителю перечитать свое сообще-
ние, таким образом предоставляя ему шанс прояснить сообщение.
Итак, более “теплые” каналы общения более эффективны, для передачи
идей, но более “холодные” каналы по-прежнему имеют важное значение.
“Устойчивость” и преодоление разрывов
в пространстве
Теперь я покажу, как группа российских программистов добилась низких затрат на
каждую переданную идею (см. историю “Российские программисты” во ведении).
Сидя вместе в одной комнате, они получали конвекционные потоки информации,
осмотическую коммуникацию, общение лицом к липу, а также вопросы и ответы в
реальном времени.
Так зачем же им вообще понадобилось писать варианты использования?
Коммуникация и сотрудничество в командах
113
Ответ таков: чтобы придать разработке некоторую “устойчивость” (sticki-
ness). Информация, записываемая на бумаге, имеет разновидность “устойчиво-
сти”, или неизменности, которой информация, передаваемая в разговоре, не
обладает, и эта устойчивость иногда нужна.
Человек, приехавший в Россию с вариантами использования, старался не за-
быть вопросы, которые ему необходимо было рассмотреть во время его бесед. Он
хотел гарантировать, что после его объяснений вариантов использования русские
программисты смогут впоследствии читать эти варианты, понимать их и воскре-
шать в памяти информацию, не обращаясь к нему с повторными вопросами.
Рис. 3.15. Два человека, работающие у совместно используемого
излучателя устойчивой информации
(Публикуется с разрешения Evant Solutions Corporation)
Автор вариантов использования, зная, что это всего лишь метки в игре, на-
поминающие что-то уже известное или обсуждавшееся, мог уравновесить время,
потраченное на их написание, с временем, которое будет потрачено на обсужде-
ние другого материала. Он мог решить, как много деталей должно попасть в пи-
сьменный материал.
Обширные, устойчивые, изменяемые, совместно используемые излучатели
информации часто применяются людьми для достижения большего понимания и
выравнивания их общих целей. Рис. 3.15 и 3.16 показывают полезное смешение
белых досок (излучателей статической информации) и людей (излучателей дина-
мической информации).
И белые доски, и бумага представляют собой особенно хорошие излучатели
статической информации, на которых могут писать все участвующие лица, благо-
даря чему они становятся совместно используемыми излучателями устойчивой
информации.
До недавнего времени у белых досок существовали проблемы со способно-
стью к архивированию и переносимостью. Если обсуждение приводит к действи-
114
Глава 3
тельно ценной информации, помещенной на белую доску, никто не осмеливается
ее стереть, и группа не может поместить ее в архив. Это замедляет архивирова-
ние ценной информации и закрывает последующее использование доски. Как вы-
разился Рон Джеффрис: “Если никогда не стирать белые доски, с тем же успехом
можно писать на стенах”.
Рис. 3.16. Излучатели динамической и статической
информации за работой
(Публикуется с разрешения Evant Solutions Corporation)
Один из коллег, Мохаммад Салим (Mohammad Salim), отреагировал на эту
ситуацию так: он покрыл все стены и коридоры рулонами толстой бумаги для
упаковки мяса, поэтому люди могли рисовать на стенах буквально повсюду. Он
сказал: “Если требуется время, чтобы дойти до своей рабочей станции или найти
белую доску, вы просто потеряете идею. А когда лист заполняется, нужно просто
его скатать и проставить дату”. Таким способом все обсуждения архивируются, и
их можно достать для более позднего изучения. Говоря о поиске рулонов для бо-
лее позднего изучения, он воспользовался умением людей хорошо ориентирова-
ться, о чем мы говорили в предыдущей главе. Наряду с сохранением архивов для
более позднего использования, Салим также упорно работал, чтобы сократить
затраты на изобретение и коммуникацию.
Несколько человек сообщают, что они используют цифровые камеры с ПО,
чистящим изображение (“Whiteboard Photo” на www.pixid.com — программа, на
которую они ссылаются). Белые доски с возможностью печати продолжают оста-
ваться очень практичными. Часто люди начинают обсуждение, думая, что резуль-
тат не будет существенным, но в конце беседы обнаруживают на белой доске
ценную информацию. Имея печатающую белую доску, при желании юни просто
могут нажать кнопку Print.
Конечно, для групп разных размеров, участвующих в обсуждении, подходят
различные излучатели информации. Клочок бумаги работает для двух или трех
человек, белая доска подходит, наверное, для дюжины.
Коммуникация и сотрудничество в командах
115
Нам пригодятся эти различия в следующей главе, когда мы будем рассматри-
вать методологии для разных проектов.
“Устойчивые” мысли на стене
В одном проекте бизнес-аналитики были расстроены сложным поло-
жением, возникшим из-за того, что их работа становилась все более
и более взаимозависимой. В этот момент у них не было способа дер-
жать свои мысли на виду даже при планировании совместной работы.
У нас состоялось обсуждение кооперативных игр, игровых меток и
устойчивости. Они поняли, что создание обширного, устойчивого и
изменяемого устройства отображения их мысленной территории по-
может им выполнить их работу. Для начала один из них немедленно
вывесил картину их области деятельности на стене в коридоре.
Они работали над этим несколько недель, экспериментируя с пред-
ставлениями их деловых отношений, которые должны были отобра-
зить их общую взаимозависимость.
Об этой группе имеет смысл сделать интересное и значимое отступление,
имеющее отношение к ожиданиям и чувству долга. По причинам, в которые я не
хочу вдаваться, эта команда бизнес-аналитиков считала, что они обязаны рабо-
тать в ХР-стиле, а ХР запрещает что-либо записывать.
Обратите внимание на четыре момента в их ситуации.
1. Они неправильно поняли ХР. Эта методология ничего не запрещает за-
писывать.
2. Их чувство гражданского долга было таким сильным, что они предпочли
не быть плохими гражданами и не записывать свои мысли по модели
предметной области, а быть хорошими гражданами и не записывать
свою бизнес-модель совсем!
3. На самом деле они понимали, что проект не может закончиться успехом,
если они действительно не станут ничего записывать. Поэтому каждый
из них тайно писал псевдоварианты использования, делал другие замет-
ки и передавал программистам. Для себя они все еще не создали модель
предметной области.
4. Записывая эти заметки, они ниспровергали свою собственную (оши-
бочную) интерпретацию формального процесса. Я нахожу эту ситуацию
особенно интересной, поскольку они воевали сами с собой за то, чтобы
быть хорошими гражданами и следовать процессу (ценой проекта) или
быть хорошими гражданами и защитить проект (нарушив процесс).
В конце концов существенным было то, что они повесили излучатель инфор-
мации на стене в коридоре, на котором они царапали поодиночке и группой, что-
бы придать своим мыслям и решениям некоторую устойчивость.
116
Глава 3
Преодоление разрывов во времени
Наконец, давайте взглянем на общение через время и скрытое здесь надувательство.
Учитывая предыдущее обсуждение, вы могли бы считать, что для сохранения
информации в течение какого-то времени вам определенно придется отбросить на-
дежду на общение лицом к лицу в пользу бумаги, аудиозаписи или видеокассеты.
Однако в долговременных проектах оказывается крайне важным, чтобы
главный архитектор оставался поблизости! Вклад этого лица состоит в поддер-
жании памяти о ключевых идеях в меняющихся командах разработчиков. И снова
люди используются как средство хранения архивов!
Отдельные лица эффективно передают информацию через время и про-
странство. Как выразился один член совета директоров IBM: “Нельзя добиться
эффективной передачи технологии, передавая саму технологию, нужно передать
головы, хранящие эту технологию”.
Команды как сообщества людей
Мы рассмотрели, что требуется от человека, чтобы он мог заметить что-либо цен-
ное о проекте, и что нужно, чтобы сообщить это ценное. Настало время выяснить,
имеет ли человек желание что-либо замечать и сообщать.
В эффективной команде люди тянут проект приблизительно в одну и ту же
сторону. На самом деле все они тянут чуть в разные стороны в соответствии с их
личными целями, индивидуальными знаниями, упрямством и т.д. (рис. 3.17). Вре-
менами они работают вместе, временами — друг против друга. В более эффектив-
ной команде эти направления ориентированы лучше, чем в менее эффективной.
Вы можете значительно повлиять на проект, побуждая каждое лицо немного
изменить поведение. Это вмешательство “микрокасаний” — убедить людей на из-
менения, которые им нетрудно осуществить, действие которых на проект будет уве-
личено за счет общего числа участников команды. Поскольку каждый человек тянет
в направлении, близком к желаемому и общему, изменения, ощущаемые одним че-
ловеком незначительны, но в сумме они приносят существенный эффект (рис. 3.18).
Рис. 3.17. Средняя команда, работающая ради продвижения к цели,
находящейся справа
Коммуникация и сотрудничество в командах
117
Незначительные изменения происходят, когда люди узнают:
Дополнительную информацию о направлении, в котором они должны дви-
гаться
Дополнительную информацию о влиянии их действий, чтобы они заметили,
какие их действия направлены в другую сторону
Более подходящую причину, побуждающую тянуть в желаемом направлении
В результате люди начинают содействовать друг другу в работе, перестают
игнорировать коллег или непредумышленно им противодействовать.
После таких незначительных изменений люди видят, как при тех же затратах
энергии, без необходимости изучать серьезные технологии и доктрины, выход
проекта начинает расти. Заметив это, они начинают больше гордиться своей ра-
ботой и больше доверять друг другу. Обычно при этом улучшается моральное со-
стояние и команда становится более подходящим для жизни сообществом людей.
Диаграмма приоритетов проекта
Диаграмма приоритетов проекта — это простой механизм, помогающий ориенти-
ровать усилия участников команды, который следует использовать в каждой
команде, работающей над проектом.
Рис. 3.18. Команда с несколько лучшей ориентацией
Эта диаграмма также описана в книгах Adaptive Software Development (High-
smith, 2000) и Crystal Clear (Cockbum, готовится к печати).
В начале проекта руководители организаций спонсоров и разработчиков об-
суждают и записывают единственный аспект разработки, которому все должны
уделять внимание. Это может быть срок выхода на рынок, снижение числа де-
фектов, время реакции, легкость освоения для пользователей, быстрота приме-
нения, затраты памяти, расширяемость или простота сопровождения. Они могут
записать и второе требование, например срок выхода на рынок или простоту для
случайных пользователей.
Затем из всех других желаемых характеристик, к которым стремится коман-
да, они выбирают те три или четыре, которыми команда должна быть готова по-
жертвовать, чтобы достичь двух главных целей.
118
Глава 3
По полученному результату каждый человек видит, какие типы компромис-
сов разрешены в проекте и как расставить приоритеты в своих действиях. Если
между членами команды имеется малая толика доброй воли, то простая запись
решений на совместном совещании и периодическое возвращение к ним позво-
лят достичь достаточно близкой ориентации в направлении цели.
Договор о приоритетах проекта обращен к общей проблеме: спонсоры хотят
быстрого выпуска ПО (чтобы занять нишу на рынке), но программисты хотят
спроектировать его правильно (задерживая выпуск продукта, чтобы улучшить
эстетику конструкции). Или может быть верно обратное: программисты привык-
ли работать быстро, создавать сырые продукты, чтобы занимать рыночные ниши,
а спонсоры требуют от них не спешить и делать меньше ошибок. В этих случаях
вся организация страдает от отсутствия простой корректируемой информации о
желаемых приоритетах (предполагающей, что структура вознаграждения ориен-
тирована в соответствии с приоритетами).
Иногда приоритеты требуется изменить в разгар работы над проектом, на-
пример при появлении конкурента с новым продуктом. В этот момент может ока-
заться важным перевернуть приоритеты, перейти от скорости разработки к
отсутствию дефектов или наоборот. Если такое случается, спонсоры должны со-
брать участников команды и объявить об изменении приоритетов.
Дружелюбие и конфликты
Дружелюбие — это готовность и добрая воля людей прислушиваться к мнениям
других и разговаривать с ними без раздражения.
Дружелюбие родственно доверию, хотя и слабее его. Это замечательно, ког-
да существует доверие, и его нужно поддерживать, но дружелюбие внутри груп-
пы достигается проще, а оно также приносит пользу. Я всегда наблюдаю за
уровнем дружелюбия в организации, чтобы понять, до какого уровня информа-
ция открывается, а не скрывается в беседах.
Когда люди скрывают информацию от своих коллег, они понижают скорость
ее обнаружения, что поднимает цену упущенных возможностей, а также суммар-
ные затраты на проработку одной идеи.
Если проект переживает стрессовый период, дружелюбие позволяет успеш-
но разрешать конфликты. Люди, зная, что другие не намереваются причинить им
вред, устремляют взгляды мимо текущих разногласий навстречу поискам выхода
из трудной ситуации.
Можно подумать, что лучше всего было бы исключить все конфликты из
команды, работающей над проектом, но оказывается, что это неверно. Людям нужна
возможность возразить, чтобы обозначить проблемы в проектировании! Я был
удивлен, обнаружив одну организацию, страдавшую от недостатка конфликтов.
Недостаточно конфликтов
В одной церковной организации, которую я посетил, каждая служа-
щая работала так долго, как она хотела. В этой группе лелеяли доб-
Коммуникация и сотрудничество в командах
119
родетели смирения, миролюбия и дружелюбия. Неожиданным был
негативный эффект, накапливаемый из-за отсутствия инициативности
и разногласий!
Из-за боязни внести в группу раскол и разрыв каждая из них должна
была подумать дважды (или больше), прежде чем критиковать идею
другой. Чтобы не показаться алчущими славы или власти, они думали
дважды (или больше), прежде чем проявить инициативу.
Общим результатом было очень медленное продвижение проектов.
Прежде чем давать советы этой группе, вспомните о ее ценностях.
Они только улучшат выполнение разработки, когда найдут способ
возразить, не подвергая опасности свои ценности смирения и друже-
любия.
Шрейдж (Schrage, 1999) описывает намеренное использование конфликтов
в небольших дозах, чтобы убедить людей собираться и учиться разговаривать
друг с другом. Это похоже на инъекцию ослабленной формы вируса, чтобы орга-
низм мог найти пути борьбы с более сильным вирусом.
Преднамеренный конфликт
"Согласно некоторым отчетам, инженеры из групп проектирования и
построения модели 777 сознательно вносили в предлагаемые конст-
рукции конфликты с другими системами.
Хотя компания Boeing официально подтверждала лишь естественно
возникавшие конфликтные ситуации, но, как утверждает один инже-
нер-механик, некоторые из этих ситуаций были созданы намеренно.
Зачем? Инженеры из одной части компании могли использовать кон-
фликт, чтобы найти тех сотрудников в других ее подразделениях, с
которыми им требовалось обсудить вопросы будущего проекта...
Способность ПО уведомлять соответствующие стороны о противо-
речиях стала использоваться, по крайней мере в некоторых случаях,
как средство налаживания взаимодействия между разными группами
внутри компании Boeing.
... Последовавшие в результате беседы и переговоры разрешили
конфликты проектирования, прежде чем успели возникнуть более
серьезные проблемы".
Проявления чувства долга в рабочее время
Быть достойным гражданином означает действовать на благо других. Чувст-
во долга проявляют люди, которые:
Появляются на совещаниях вовремя
Отвечают на вопросы других
Беспокоятся о разрешении замеченных ими проблем
120
Глава 3
Следуют соглашениям о кодировании, принятым в группе
Пользуются библиотеками кода
Чувство долга позволяет программистам, не согласным со стилями кодиро-
вания, тем не менее создать для себя общий стандарт программирования. Как го-
ворили многие ведущие программисты: “Это не то, что мне может понравиться,
но я осознаю, что многие способы работают, и выбрать любой из них лучше, чем
не выбирать совсем никакого”.
Оказание помощи другим сотрудникам компании — характерный акт пове-
дения гражданина. Диксон (Dixon, 2000) сообщает, какой сильный эффект ока-
зывает желание потратить собственное время, чтобы помочь другим. Она
упоминает, среди прочих примеров, о женщине из Tandem Computers, которую
спросили, зачем она тратит свое рабочее время, отвечая на вопросы, вывешен-
ные на общих досках для обсуждения. Эта женщина сказала: “Отвечать на такие
вопросы — обязанность каждого достойного гражданина своей компании”.
Часто я обнаруживал, что сотрудники проявляют чувство долга и жертвен-
ность с самого начала своей работы, и администрация этим пользуется. Люди по-
ступают в новую компанию и работают сверхурочно, считая, что на их вклад и
дополнительную работу компания ответит соответственно, даст большее призна-
ние и больше свободного времени. Они не понимают — их боссы и коллеги по-
лагают, что они всегда будут работать так, как работают в первый месяц. В ре-
зультате они регулярно получают скверную оценку, когда снижают число рабо-
чих часов в неделю с 65 до всего лишь 50!
Боюсь, что менеджеры будут прикрываться чувством долга, чтобы принуж-
дать своих сотрудников работать еще больше. Прочтите Death March (Your-
don, 1997 — В русском переводе “Путь камикадзе”, ЛОРИ, 2000. — Прим.
пер.\ В этой книге вы найдете подтверждающие примеры.
Чувство долга следует поощрять в обычные рабочие часы, а не использовать
его как средство для увеличения продолжительности рабочего дня. Есть очень
много способов поощрения гражданских чувств в рабочее время.
Сравнение враждебной методологии ХР
с дружественной ХР
В завершение этого обсуждения рассмотрим последствия работы с проявлением
внимания к сообществу и без такого проявления. Я решил остановиться на Extre-
me Programming (ХР), поскольку, хотя общение и сообщество имеют центральное
значение в ХР, мне доводилось видеть использование этой методологии как с сооб-
ществом, так и без него: так сказать, “дружеская ХР” и “враждебная ХР”. Это аб-
солютно разные вещи.
В трех следующих ситуациях, как и в некоторых других, заказчики и про-
граммисты могут усилить свои разногласия и создать враждебную ХР-среду.
Коммуникация и сотрудничество в командах
121
Заказчики не вполне уверены в том, чего хотят. Программисты настаивают:
“Скажите, что мы должны создать”, и поэтому заказчики что-то говорят.
Программисты делают именно это и затем спрашивают: “Теперь скажите,
что делать дальше”.
В этой ситуации обе группы не представляют себе, что нужно делать дальше.
Программисты избегают давления ситуации, перекладывая всю ее тяжесть на за-
казчиков (что им позволяют сделать). Заказчики чувствуют тревожность ситуа-
ции: у них нет времени на размышления, исследования, эксперименты и
упорядочение вариантов.
В результате указания заказчиков, поступающие в ходе следующих итера-
ций, противоречат друг другу: “Сделайте это... Нет, теперь делайте это... Нет,
попробуйте теперь сделать это”. Обе стороны пребывают в подавленном состоя-
нии из-за отсутствия видимого продвижения вперед.
Программисты делают то, что говорят заказчики, даже если они уверены,
что идея глупая.
Как в истории о недостаточности конфликтов, проект страдает от того, что
разработчики не говорят о замеченных ими проблемах. Проект лишается творче-
ского воздействия думающих программистов, которые могли бы предложить свое
понимание, чтобы уточнить требования заказчиков.
Заказчики сообщают программистам, что конкретное свойство системы бу-
дет пользоваться большим успехом, и вежливо просят как можно тщатель-
нее отнестись к его реализации. Программисты в ответ цитируют набор
ХР-заклинаний: “Упрощайте”, “Вам это не понадобится”, “Мы будем де-
лать простейшую из возможных работающих программ” и игнорируют лю-
бые предложения о встраивании чего-либо нового в свое ПО.
В результате проектировщики проходят через последовательность проект-
ных решений, о которых всем известно, что они неверны, пока не появляются,
наконец, необходимые требования. К этому моменту время потрачено на неодно-
кратные переработки системы. В тех случаях, с которыми я сталкивался, про-
граммисты радовались возможности потренироваться, а спонсоры выглядели
несчастными.
В каждом из этих случаев программисты утаивали информацию. Скрыв свои
собственные мысли и опыт от обсуждения, они отказались от ответственности по
отношению ко всему проекту. Поступив таким образом, убрав из поля зрения
лучшие стратегии разработки, они разрушили проект.
В дружественной ХР-среде, поддерживаемой сообществом, эти три ситуации
разворачиваются иначе. В каждом случае программисты активно делятся своими
представлениями, опытом, оценками затрат и решениями.
В первой ситуации, не зная, как поступить дальше, программисты помога-
ют заказчикам формулировать их пожелания. Они могут это сделать, создав
122
Глава 3
небольшие рабочие прототипы, приспособленные для поиска желаемыхха -
рактеристик.
В случае глупой идеи программисты предлагают свою информацию в следу-
ющих дружеских выражениях: “Не уверен, что вам действительно нужна
эта штука, которую вы просите. Это будет чертовски сложно реализовать и
приведет к очень неприятному эффекту”. Заказчик может продолжать на-
стаивать на этом средстве, но очень часто он понятия не имеет об этом эф-
фекте и бывает счастлив, что ему о нем рассказали. Обычно заказчики
ценят способность понять существо дела независимо от того, меняют они
требование, или нет.
В ситуации с последовательными проектными решениями программисты
помогают заказчикам, найдя доводы, влияющие на решения по данному во-
просу. Затем они могут совместно рассмотреть порядок, в котором должен
выполняться проект. Ожидается, что новый порядок не просто потребует
иной функциональности, но и быстрее приведет к той системе, которая
нужна заказчикам.
Любая методология разработки, даже пропагандирующая дружелюбие и со-
здание сообщества, может быть применена без этого в ущерб проекту.
Создание “команды” с помощью побед
Некогда командный дух создавался через совместное распевание песен и посеще-
ние организованных компанией мероприятий. (Интересно, сохранился ли у ко-
го-либо из вас песенник IBM?) Когда пение на работе вышло из моды, никакой
другой замены ему не нашлось.
Некоторые компании начинают проекты, посвящая один или несколько дней
созданию команды вне рабочего помещения. Это хороший способ, поскольку со-
трудники видят, что компания прилагает усилия, чтобы показать, как важна
командная работа. Хотя не каждое такое мероприятие в действительности созда-
ет команду, но несколько успешных команд сообщили, что эти дни в начале про-
екта помогли им более эффективно работать совместно. В результате
руководители их компаний считают, что не зря потратили деньги, и планируют
продолжать эту традицию.
Программисты дают двойственные отзывы проведению вне работы меропри-
ятий, направленных на создание команды. Некоторые отвечают резко: “Меня не
интересует, сможем ли мы вместе жарить мясо на пикнике или взбираться на
стену. Меня волнует, сможем ли мы вместе создавать программы”.
Что же на самом деле создает команды? Люк Хоманн предлагает следующее
наблюдение:
“Лучший способ создать команду — добиться успеха в достижении ре-
зультатов. Маленьких или значительных. Это убеждение имеет эмпи-
Коммуникация и сотрудничество в командах
123
рическое обоснование (см., например, Brown, 1990). Мероприятия,
которые почему-то должны создать команду, по-моему, почти всегда
пустая трата времени и денег”.
Поддержку этому мнению можно найти в описании важности “маленьких
побед” (Weick, 2001), а также в интервью менеджеров успешных проектов.
Один из этих менеджеров рассказал о ключевом моменте, улучшившем мо-
ральное состояние и командный дух в проекте. В этой истории мы находим следу-
ющие элементы:
Сотрудники, сидящие в разных помещениях, встречаются лицом к липу.
Вместе они добиваются некоторого существенного результата, которого не
могли достичь, работая поодиночке.
В какой-то момент они подвергают себя некоторому социальному риску
(осмеливаясь на новые мысли или допуская заблуждения) и получают под-
держку от группы, когда могут подвергнуться нападению.
Вторая из этих характеристик говорит о достижении результатов, о чем упо-
минает Люк Хоманн. Первая и третья создают дружелюбие, позитивное отсутст-
вие страха и недоверия.
Культуры и субкультуры в команде
Сама команда проекта создает мини-культуру. Эта мини-культура является ча-
стью культуры, сформированной внутри более крупной организации и также внут-
ри окружающей господствующей национальной культуры.
Часто программный проект создает собственную культуру, отличную от на-
циональной или корпоративной культуры, в которую она внедрена. Сотрудники,
работающие над проектом, считают это полезным, поскольку им очень нужно об-
мениваться информацией о том, что работает, а что вот-вот выйдет из строя.
Иногда более крупная организация терпит эту непохожую культуру, а иногда
борется с ней. Один человек, испытавший подобное сопротивление, написал:
“Остерегайтесь организационных антител!”
Культуры и культурные ценности можно охарактеризовать многими способа-
ми. В одной характеристике (Constantine, 1995) социологи указывают четыре
типа культур — в зависимости от особенностей общения, власти и принятия ре-
шений (рис. 3.19).
Иерархические культуры имеют традиционную цепочку управления сверху
вниз. Обычно более старые и более крупные объединения имеют иерархическую
культуру. С возрастом многие люди усваивают ее как господствующую, естествен-
ную или подразумеваемую культуру объединения, и при переходе в другую куль-
туру им требуется обучение.
124
Глава 3
Иерархическая
Случайная
Сотрудничество
Синхронная
Рис. 3.19. Четыре организационных парадигмы
Случайная культура противоположна по характеру иерархической. Она
определяет группу, в которой отсутствует жесткое управление или управление
вообще. Так работают многие начинающие компании. Некоторые люди считают
случайную культуру интересным способом работы и сожалеют об утрате неболь-
шой неформальной группы, когда компания растет. Другие испытывают стресс в
этой культуре из-за отсутствия ясных пунктов управления.
Сотрудничающие группы работают, достигая единодушия. У меня была воз-
можность увидеть действующую группу такого рода в Lucent Technology.
Культура сотрудничества в работе
Кто-то в этой организации решил, что варианты использования будут
подходящим способом сбора требований, и попросил меня прочи-
тать курс лекций сотрудникам, участвующим в проекте.
Я встретился с руководителями группы (которых называли наставни-
ками, поскольку в культуре сотрудничества они не руководят, ко-
нечно, а наставляют).
Примерно через месяц меня еще раз пригласили прочитать лекции,
теперь уже для расширенного состава группы.
Прошло еще несколько месяцев, и меня попросили прочитать еще
одну лекцию для всего подразделения. Хотя наставник решил, что
варианты использования им подходят, группа отложила обращение к
этой технологии, пока все ее участники не получат шанс познакоми-
ться с ней.
На заключительной встрече наставник вел себя очень интересно.
Пока я читал, он программировал на своем ноутбуке. Физически он
Коммуникация и сотрудничество в командах
125
присутствовал в комнате, но и только. Совсем не почувствовав себя
оскорбленным, я нашел его действия полностью соответствующими
системе ценностей, действующей в его ситуации. Как старший раз-
работчик он показывал, что продолжает вносить свой непосредст-
венный вклад в работу команды. Как наставник он демонстрировал
поддержку представляемого материала, который он слушал уже
третий раз. Таким образом, это поведение было естественным вы-
ражением его места в двух профессиональных объединениях: разра-
ботчиков и наставников.
Синхронные, или “тихие”, группы являются полной противоположностью
сотрудничающих групп. Они координируют действия без словесного общения,
когда люди осуществляют свои роли, не пытаясь повлиять на стиль работы дру-
гих ролей.
Константайн дает два примера синхронной командной работы. Первый взят
из той сцены фильма Witness, в которой члены аманитской общйны строят новый
амбар за один день, почти не произнеся ни слова. Второй связан с несчастным
случаем, происшедшим в больнице, когда тяжелый стол рухнул человеку на ногу.
Не говоря ни слова, находившиеся в комнате люди предприняли согласованные
действия: двое подняли стол, третий держал ногу пострадавшего, четвертый по-
бежал звонить в рентгеновский кабинет, а пятый бросился за носилками.
В обоих случаях люди знали правила ситуации и участвующие в ней роли.
Они умели просто войти в нужную роль. Константайн указывает, что в синхро-
нной среде “участники команды ориентированы в направлении, установленном
общим видением и ценностями”.
Может оказаться, что программисты действуют в тихой, или синхронной, ку-
льтуре. Если это так, будет интересно увидеть, как кооперативная игра приобре-
тает новую форму, чтобы соответствовать этому культурному образцу.
Разумеется, катящийся в последнее время вал методологий разработки, включа-
ющих ХР и Crystal, требует гораздо больше вербального общения, чем раньше.
Или программисты изменят свою культуру, или методологиям придется приспо-
собиться.
Во многих организациях от программистов ждут серьезной сверхурочной
работы. Для меня было настоящим шоком оказаться после такой организации
в Центральном банке Норвегии, где личная жизнь ценилась чрезвычайно
высоко и сверхурочная работа не одобрялась.
Дежурное освещение в Norges Bank
В Центральном банке Норвегии официально рабочий день заканчи-
вался в 15:30.
В типичный день именно в это время я внезапно оторвался от своих
занятий и спросил себя, что мне действительно необходимо доделать
сегодня. В результате в 15:45 я оказался в коридоре, пытаясь "до
126
Глава 3
конца дня завершить какую-нибудь работу ", но не мог ни отправить
факс, ни получить подпись на документе, ни получить ответы на во-
просы. Весь персонал действительно разошелся по домам в 15:30!
Затем в 17:00 освещение автоматически погасло! Я узнал, как
включить "дежурное освещение", но испытал шок во второй раз,
когда в 19:00 погасло и это освещение. ("Сейчас вам действительно
следует отправиться домой".)
Культуры также различаются своим отношением к откровенности и вежли-
вости в речи. Японцы славятся своим стремлением сохранить лицо, в то время
как американцы считаются искренним народом. Откровенность доводится до
крайности в некоторых местах, таких как МТИ, Стэндфорд и Израиль. Один из-
раильский друг учил меня выражаться прямо. Увидев его, после того как он про-
пустил обзорное совещание, я сказал: “Мы по тебе скучали на совещании”. Он
ответил: “В Израиле мы бы спросили: ’’Почему тебя там не было?”
В других культурах, например в описанной ранее церковной организации,
даже мягкое несогласие или проявление инициативы считаются легкими про-
ступками, признаками непомерного самолюбия в человеке.
В результате разного восприятия откровенности в речи люди, пришедшие из
разных культур, иногда испытывают трудности в совместной работе. Слишком
откровенный человек поражает другого своей неосторожностью и резкостью, в то
время как чересчур вежливое лицо поражает отсутствием открытости и нежела-
нием сотрудничать.
Профессиональные субкультуры
Каждая профессия также создает собственную культуру со своими культурными
ценностями и нормами. У менеджеров проектов есть своя культура, как и у опыт-
ных проектировщиков, использующих объектно-ориентированные технологии,
проектировщиков реляционных баз данных, программистов на COBOL, агентов
по продажам, пользователей и т.д. Даже новички в каждой из этих групп имеют
собственные ценности и нормы, отличные от ценностей экспертов той же группы.
Вот некоторые культуры:
Менеджерам проектов нужно методично относиться к поддержанию дис-
циплины и прогнозированию сроков и затрат на выпуск продукта и к слож-
ным зависимостям внутри проекта.
Программистам, пишущим на объектно-ориентированных языках, нужна
тишина; они должны обладать способностью к абстрактному мышлению и
справляться е неопределенностью постоянно развивающихся интерфейсов
программирования.
Системные аналитики опираются на всестороннее обдумывание, просмат-
ривая требования и интерфейсы построчно в поисках ошибок.
Коммуникация и сотрудничество в командах
127
Сотрудники службы маркетинга извлекают преимущества из развитого во-
ображения, умения справиться с постоянными сюрпризами, которые рынок
(и программисты) им подбрасывают.
Рассмотрим теперь “необщительное и антиобщественное” поведение про-
граммистов. На самом деле, как сообщают некоторые из них в своих письмах ко
мне, они любят поговорить... о технических вещах. Они просто не любят разгова-
ривать о вещах, которые считают неинтересными (вроде бейсбольных матчей и
праздновании дней рождений). Но в действительности они не выносят, когда им
мешают работать. Оказывается, для этого имеется веская причина.
ПО включает связанные вместе сложные мыслительные процессы. Про-
граммист проводит значительную часть времени, подбирая и соединяя вместе на-
бор идей. Он начинает ввод с клавиатуры, держа в уме эту замысловатую
конструкцию, следя за связями между составными частями.
Если в этот момент его позовут на совещание, мысленная структура разру-
шится и ему придется повторно ее строить после совещания. Может потребова-
ться 20 минут на построение этой структуры и час, чтобы достичь успеха.
Следовательно, любой телефонный звонок, обсуждение или встреча, отвлекаю-
щие программиста более чем на несколько минут, приведет к потере до часа ра-
боты и огромного количества энергии. Неудивительно, что программисты
терпеть не могут совещаний. Антиобщественное поведение, в частности уклоне-
ние от совещаний — это защитная реакция их профессии.
Таким образом, ценности каждой группы способствуют ее надлежащему
функционированию, и различия необходимы для надлежащего функционирова-
ния всей организации, даже если они противоречат друг другу.
Было бы славно, если бы все эти ценности и нормы были конструктивны. Но
на самом деле это далеко не так.
Ранее мы рассматривали такой пример — императив требования собствен-
ной разработки. Он развивался как культурная ценность и норма в течение всего
времени обучения в колледже. Однако в большинстве организаций изобретение
новых решений, когда уже существуют старые, контрпродуктивно для целей ор-
ганизации. Идеальная норма должна разрешать в любых обстоятельствах поко-
паться в существующих решениях и что-то изобрести лишь в том случае, если
это позволяет организации обойти конкурентов.
Приспособление к субкультурам
Первоначальная реакция большинства людей состоит в попытке навязать одной
группе ценности другой.
Исследователи в области формальных методов разработки хотят, чтобы
в школе больше учили математике.
Менеджеры, неуютно себя чувствующие с итерационной разработкой, хо-
тят, чтобы их программисты создавали проект с первого раза.
128
Глава 3
Программисты, расстроенные невозможностью общаться со своими ме-
неджерами, хотят, чтобы менеджеры до начала управления проектом осво-
или объектно-ориентированное программирование.
В подходе “пусть меняются они” существуют две проблемы:
Менее серьезная проблема заключается в том, что людям очень и очень
трудно изменять свои привычки и подходы.
Более серьезная проблема в том, что мы еще не понимаем субкультуры. За-
ставлять других изменить свои ценности — это все равно, что выписывать
лекарства, не понимая защитных механизмов организма.
Несмотря на эту ситуацию, есть вещи, которые может сделать наша отрасль,
вещи, которые могут сделать некоторые отдельные лица, и вещи, которые может
сделать каждый.
Как отрасль мы можем:
Больше поощрять этнографические исследования групп разработчиков
ПО, как сделал Ховенден (2000)
Определять и понимать действующие нормы, показав организации вклад
каждой из них
Экспериментировать с культурными изменениями
Каждая консультирующая компания может выиграть от использования в шта-
те социального антрополога или этнографа. Такой специалист поможет консульти-
рующей команде понять социальные силы, действующие в их проектах, что
увеличит эффективность команды.
Люди, работавшие по нескольким специальностям, таким как программиро-
вание и проектирование баз данных, программирование и управление проектом
или преподавание и проектирование, могут исполнять роль переводчиков. Они по-
могают преобразовывать утверждения, выраженные одним нормативным набором
значений, в предложения, имеющие смысл в другом наборе значений. Несколько
человек, выполняющих эту функцию, написали мне, рассказав о сложности и на-
стоятельной потребности этой роли.
Наконец, каждый может научиться терпеливо и доброжелательно слушать.
Представьте, что высказывания другого человека, какими бы дикими они ни ка-
зались, имеют смысл в системе ценностей другой культуры. Выслушайте снача-
ла, а затем решайте, по-прежнему ли вам нужно конфликтовать.
Команды как экосистемы
Программный проект создает экосистему, состоящую из личностей, принадлежа-
щих к различным культурам. Мы видели несколько элементов экосистемы, в том
числе:
Коммуникация и сотрудничество в командах
129
Стены, действующие как преграды, и открытые пространства, действую-
щие как каналы
Людей, работающих в своих профессиональных сферах как взаимодейству-
ющие подвиды
Отдельных лиц с сильными личными качествами, изменяющих способ ра-
боты экосистемы
Все влияет на все: стулья, размещение сотрудников, очертания здания, на
одном ли языке говорят люди и даже кондиционеры.
Ящерицы и пингвины
В одной компании переезд из старого здания в новое чуть не привел
к драке.
В старом здании у каждого был личный кабинет с собственным тер-
мостатом. В новом здании всем так же предоставили отдельные ка-
бинеты, но там каждые два кабинета должны были обслуживаться
одним общим термостатом. В каждой паре смежных кабинетов
нужно было устанавливать одну и ту же температуру.
Внезапно рабочая сила поляризовалась на тех, кому нравились теп-
лые кабинеты ("ящерицы”), и тех, кому нравилось работать в холод-
ных кабинетах ("пингвины”). Сотрудникам пришлось маневрировать,
чтобы объединиться вокруг термостата с кем-то, имеющим анало-
гичные температурные предпочтения.
В некоторых ситуациях людям бывает тяжело уходить из компании. В других
ситуациях люди меняют место работы каждые несколько месяцев. Две ситуации
создают различное отношение и поведение в работе.
Каждая рабочая роль и каждый человек влияют на каждого другого челове-
ка. Ключевые личности играют в формировании экосистемы более значительные
роли, чем другие. Они фокусируют или более часто блокируют разговоры. Когда
они уходят, изменяется вся сеть взаимоотношений.
Экосистема любого проекта уникальна. В принципе невозможно сказать
что-либо конкретное и существенное об экосистемах всех команд.
И это действительно так.
Только участники команды могут сделать вывод и решить, что будет работать
в данной конкретной среде, и настроить среду, чтобы она их поддерживала.
Если участники команды понимают некоторые ключевые характеристики
людей и методологий, они могут сориентироваться, вникнуть в то, что они заме-
чают, и сконструировать наилучшую первую гипотезу о подходящих для них со-
глашениях и линиях поведения в соответствии со своими сильными и слабыми
сторонами.
Участники команды, естественно, готовы пересматривать и приспосабливать
свои соглашения периодически или когда значительные события изменят их эко-
130
Глава 3
систему (например, если особенно влиятельная личность примкнет к организа-
ции или ее покинет).
Набор соглашений и линий поведения я называю методологией команды.
Методология — это персональная вещь, “социальная конструкция”, если проци-
тировать Ральфа Ходжсона из IBM.
Полезно рассматривать методологию как собственное социальное сооруже-
ние команды. Это выдвигает на первый план идею, что никакая методология не
заработает сразу же идеально. Члены команды должны и сами приспособиться, и
методологию приспособить, чтобы вместе с ней создавать собственную местную
эффективную экосистему.
Экосистемы и методологии обладают интересной общей особенностью: если
участники команды создают для себя много сложных правил, они привязываются
к узкой экологической нише.
Однако узкие экологические ниши печально известны своей слабостью, а
рынок имеет обыкновение изменять территорию вокруг компании. Многие пра-
вила, обеспечивающие эффективное поведение в одном экологическом окруже-
нии, плохо подходят для использования в другом.
В биологии мы пользуемся термином “вымирать”. В бизнесе это называется
“прекратить деятельность”.
Если, с другой стороны, команда создает и периодически обновляет несколько
хорошо подготовленных норм, она может использовать ум, гордость за вклад в об-
щее дело, общение и спонтанность характеров своих участников. Люди приспосо-
бят эти нормы к своей ситуации, достигнув устойчивого поведения вопреки
технологическим, социальным и рыночным сюрпризам. Ди Хок, в 1960-70-е годы
конструктор в высшей степени децентрализованной системы VISA, выразился так:
“Простые, ясные цели и принципы дают начало сложному и умному
поведению.
Сложные правила и предписания порождают простое и глупое пове-
дение".
Что дальше?
Обойдите ваше рабочее место. Обратите внимание на:
Конвекционные потоки информации
Сквозняки
Излучатели информации
Отдельные установившиеся сообщества
Фоновые разговоры, восхваляющие или чернящие другие группы организа-
ции
Коммуникация и сотрудничество в командах
131
Посмотрите:
Как вы можете улучшить потоки информации и сократить количество
эрг-секунд, необходимых для обнаружения и передачи важнейшей инфор-
мации?
Можете ли вы разместить команду в одном помещении?
Что потребуется для такого разделения проекта, чтобы команды располага-
лись вокруг необходимых им для общения мест?
Попробуйте:
Удалить перегородки между людьми
Программировать в паре
Организовать ежедневные посещения программистов бизнес-экспертами
Применить микрокасания (люди незначительно изменяют поведение, что
не составляет для них труда, но в результате сближают направления)
Слушать представителя другой специальности в соответствии не со своими,
а с его культурными нормами
Выступить переводчиком между двумя субкультурами, используя их собст-
венные культурные термины
Понаблюдайте за взаимодействиями правил вашей методологии и экосисте-
мы проекта. Обратите внимание на соответствия, несоответствия и влияние не-
скольких ключевых личностей.
Подумайте, какие соглашения и линии поведения улучшат способ, с помо-
щью которого ваша группа достигает выполнения своих задач. Это могут быть
соглашения о размещении, инструментах, рабочем времени, процессе, освеще-
нии, совещаниях — все что угодно.
Сделайте это, и вы наполовину приспособите вашу методологию к вашей
организации.
Глава 4
Методологии
Цель данной главы — рассмотреть тему методологий с такой степенью конкрети-
зации, чтобы прояснить правила игры по созданию методологии и способы органи-
зации этой игры.
В разделе “Понятия методологии” приводится основной словарь и понятия,
необходимые для создания и сравнения методологий. Среди понятий есть такие
очевидные, как роли, методы и стандарты, а также менее очевидные, как “тя-
жесть”, формальность, точность, стабильность и толерантность. В терминах трех
уровней читателей (см. разделе “Три уровня понимания” во введении) этот мате-
риал в большей степени относится к уровню 1. Он необходим для более углуб-
ленных обсуждений, которые последуют далее.
В разделе “Принципы создания методологии” обсуждаются семь принципов,
которые можно использовать как руководство по созданию методологии. На пер-
вый план в этих принципах выдвигаются стоимость перехода к более серьезной
методологии и момент этого перехода. Они также показывают, как использовать
стабильность рабочего продукта, когда вы решаете, в каком объеме применять
параллельную разработку.
В разделе “ХР под микроскопом” эти принципы применяются для анализа
существующей методологии быстрой разработки. В нем также затронуты вопро-
сы использования принципов адаптации ХР к несколько иным ситуациям.
В разделе “Зачем вообще нужна методология?” этот вопрос снова рассмат-
ривается в свете предыдущего обсуждения и представляются различные приме-
нения методологий.
Экосистема, поставляющая программное
обеспечение
“Методология — это конструкция социальная”, сказал мне в 1993 г. Ральф Ходж-
сон. Прошло два года, прежде чем я начал это понимать.
134
Глава 4
Ваша “методология” — это все ваши действия, направленные на выпуск в свет
вашего ПО. Она включает следующее: каких сотрудников вы нанимаете, для чего
вы их нанимаете, как они работают вместе, что производят и как распределяется
вознаграждение. Методология — это комплексное описание работ, процедур и
соглашений для всех участников команды. Она является продуктом деятельности
конкретной экосистемы и, следовательно, уникальным созданием вашей органи-
зации.
Все организации имеют собственные методологии. Это просто способ выпол-
нения их работы. Даже у вошедшего в поговорку трио из гаража есть способ рабо-
ты — способ обмениваться информацией, разделять работу и снова ее
объединять, и все это основано на предполагаемых ценностях и культурных нор-
мах. Способ работы включает: на что люди решают потратить свое время, какой
способ общения они выбирают, как распределяются полномочия по принятию ре-
шений.
Только немногие компании дают себе труд все это записать (обычно лишь
крупные консалтинговые фирмы и военные организации). Немногие заходят так
далеко, что создают экспертную систему, которая полностью формирует необхо-
димую для проекта методологию, базирующуюся на возможности укомплектова-
ния персоналом, степени сложности, сроках и прочих параметрах. Мне не
известна ни одна компания, предусматривающая варианты для различных ценно-
стей и культур.
Если кратко сформулировать, что такое методология, то получится резюме,
состоящее из единственного предложения: “Методология — это соглашения, ко-
торые принимает ваша группа”.
“Соглашения, которые принимает ваша группа”, — это социальная конст-
рукция. Это также такая конструкция, которую вы можете и должны время от
времени пересматривать.
Понятия методологии
Слово “методология” я использую в значении, обнаруженном в словаре Merri-
am-Webster: “Набор взаимосвязанных методов и методик”. Методом называется
“систематическая процедура”, аналогичная методике.
(Читатели Oxford English Dictionary могут заметить, что некоторые издания
OED определяют методологию лишь как “науку о методах”, а другие содержат
оба определения. Это помогает объяснить расхождения по поводу термина “ме-
тодология”.)
Методологию полезно отличать от методов. Читая такие выражения, как
“метод выявления классов по вариантам использования” или “разные методы
подходят для решения разных задач”, мы понимаем, что автор рассматривает ме-
тодики и процедуры, не устанавливая правил и соглашений для команды. Это
освобождает слово “методология” от использования в более широких темах ко-
ординации деятельности людей в команде.
Методологии
135
Координация важна. Те же специалисты среднего уровня, которые, работая
в одиночку, производят средние проекты, при совместной работе часто создают
удачные проекты.
Процесс
AMW4I.J
IJWBIIWWI ..1ЫЩ ДЦДЦДЩкЩЩ
Контрольные!
точки !
Л
Ценности команды |
использования Продукты
4 Планирование '
Программирование
Качество
Регрессионные
тесты
Объектная модель
План проекта
Варианты —
Виды I
деятельности г
.м и пил i лл
Менеджер проекта
Разработчик
документации
Проектировщик
Тестировщик
MBWA
Варианты
использования
CRC-карты
I
Команды
i
Роли
Microsoft Project
Трехмесячные
итерации
UML/OMT
Методики I
Envy/Developer JAD
STP JAVA-программировани
Microsoft Project Моделирование
Стандарты ?
Инструменты г
Навыки
Специализация\
л». У9Ц.Л!. щ! та 'JWP
Рис. 4.1. Элементы методологии
Напротив, все самые умные люди, собравшись вместе, не достигнут успеха
в группе без координации, сотрудничества и общения. Большинство из нас сами
наблюдали такие группы или слышали о них. Успех команды тесно связан с со-
трудничеством, общением и координацией.
Структурные термины
Структура первой методологии, которую я видел, содержала приблизительно семь
элементов. Та, что я нарисовал теперь, содержит тринадцать элементов (рис. 4.1).
Эти элементы применимы к любому командному предприятию, будь то разработка
ПО, восхождение на гору или сочинение поэмы. Надписи рядом с прямоугольника-
ми будут изменяться, но названия элементов останутся неизменными.
Роли. Кого вы используете, с какой целью и каким умением они должны обла-
дать. В равной степени важны, оказывается, индивидуальные качества, ко-
торых ждут от человека. Менеджер проекта обязан уметь работать с
людьми, проектировщик пользовательского интерфейса — обладать при-
родными изобразительными талантами и пониманием поведения пользова-
136
Глава 4
теля, проек- тировщик объектно-ориентированной программы — иметь
способности к аб- страктному мышлению, а наставник должен уметь хоро-
шо объяснить предмет.
Для проекта плохо, если отдельные сотрудники не имеют качеств, необ-
ходимых в их работе (если, например, менеджер проекта не умеет принимать
решения, а наставник не любит общаться).
Навыки. Для выполнения ролей нужно умение. “Личная доблесть” человека в роли
является результатом его подготовки и талантов.
Программисты посещают занятия, чтобы научиться объектно-ориенти-
рованному программированию, языку Java и приобрести навыки модульного
тестирования.
Проектировщики пользовательского интерфейса учатся достигать удоб-
ства и простоты применения, создавать прототипы на бумаге.
Менеджеры приобретают навыки в проведении бесед, обсуждении мо-
тивации, подборе сотрудников и управлении в критических ситуациях.
Лучшие специалисты интенсивно используют свои природные таланты,
но в большинстве случаев достаточное умение можно получить через подго-
товку и практику.
Команды. Роли, работающие вместе при различных обстоятельствах.
Для небольшого проекта может быть лишь одна команда. В более круп-
ном проекте, вероятно, будут использоваться несколько команд, причем не-
которые из них будут нацелены на внедрение конкретных технологий, а
другие — на выполнение требований проекта или архитектуры системы.
Методики. Специфические процедуры, используемые людьми для выполнения
своих задач. Некоторые из них применимы для одного лица (написание вари-
анта использования, общий осмотр проекта, проектирование класса или тес-
тового варианта), в то время как другие адресованы группам людей (обзоры
проектов, сессии группового планирования). Вообще я использую слово
“методика”, если имеется предписывающее представление, как выполнить
задачу, используя известную совокупность знаний.
Виды деятельности. Как люди проводят свое рабочее время. Примеры видов
деятельности — планирование, программирование, тестирование и участие
в совещании.
Некоторые методологии особенно выделяют рабочие продукты, т.е. фо-
кусируются на создании необходимых рабочих продуктов. Другие ориентиру-
ются на деятельность, помещая в фокус то, что члены группы должны делать
в течение дня. Таким образом, если методология Rational Unified Process
ориентирована на инструменты и рабочие продукты, то Extreme Program-
ming ориентируется на деятельность. Эффективность последней методоло-
гии, в частности, достигается описанием деятельности людей в течение их
Методологии
137
рабочего дня (парное программирование, упреждающая разработка тестов,
реорганизация кода и т.д.)
Процесс. Как различные виды деятельности выполняются в комплексе, часто
с предварительными и последующими условиями (например, пересмотр про-
екта проводится через два дня после отправки материала участникам и при
этом создается список рекомендаций по улучшениям). Ориентированные на
процесс методологии фокусируются на потоке работы между участниками
команды.
Диаграммы процессов редко передают наличие циклов переработки.
Поэтому их обычно лучше представлять как диаграммы потоков работ, опи-
сывающие, кто, что и от кого получает.
Рабочие продукты. Это то, что кто-то создает. Рабочий продукт может быть од-
норазовым, как карты CRC-проектирования, или относительно устойчивым,
как пользовательское руководство или исходный код.
Я считаю полезным сохранить термин “конечный продукт” (deliverable),
обозначающий “рабочий продукт, передаваемый через границы организа-
ции”. Это позволяет применить этот термин на разных ступенях иерархии:
конечные продукты, передаваемые между двумя небольшими командами, яв-
ляются рабочими продуктами в более крупном проекте. Рабочие продукты,
которые передаются между командой проекта и командой, работающей над
следующей системой, являются конечными продуктами проекта и должны
прорабатываться более тщательно.
Рабочие продукты описываются в таких общих терминах, как “исходный
код” и “объектная модель предметной области”. Правила, которые должны
использоваться для каждого рабочего продукта, описываются в стандартах
на рабочие продукты. Примерами стандартов исходного кода служат Java,
Visual Basic и визуальные модели. Примерами стандартов диаграмм классов
могут быть UML или OML.
Контрольные точки. События, отмечающие продвижение или завершение ра-
бот. Некоторые контрольные точки просто утверждают, что задача была вы-
полнена, а другие включают публикацию документов или кода.
Контрольная точка имеет две важнейшие характеристики: она имеет
место в некий момент времени, и она или удовлетворена полностью, или не
удовлетворена совсем (она не может быть удовлетворена частично). Доку-
мент или опубликован, или не опубликован, код или поставлен, или не по-
ставлен, совещание или состоялось, или не состоялось.
Стандарты. Соглашения, принятые командой для конкретных инструментов,
рабочих продуктов и политики принятия решений.
Стандарт кодирования может объявлять: “Каждая функция имеет следу-
ющий комментарий заголовка...”
138
Глава 4
Стандарт языка может быть таким: “Мы будем использовать полностью
переносимый язык Java”.
Стандарт рисования диаграмм классов может быть следующим: “Пока-
зывать только общедоступные методы сохраняемых функций”.
Стандарт инструмента может выглядеть так: Мы будем использовать
Microsoft Project, Together/J, JUnit,..."
Стандарт управления проектом может быть таким: “Использовать конт-
рольные точки от двух дней до двух недель и инкрементный выпуск програм-
мы каждые два или три месяца”.
Качество. Качество может иметь отношение к видам деятельности или к рабо-
чим продуктам.
В ХР качество программы оценивается с помощью инспекции исходного
кода: “Весь зарегистрированный исходный код должен на 100% пройти мо-
дульные тесты при каждом испытании”.
Участники команды ХР также оценивают качество своей деятельности.
Проводят ли они оперативные совещания каждый день? Как часто програм-
мисты меняют партнеров по программированию? Насколько доступны за-
казчики для задания различных вопросов? В некоторых случаях качеству
присваивается числовое значение, в других случаях — неформальное значе-
ние (“Я недоволен моральным состоянием команды в последней итерации”.)
Ценности команды. Остальные элементы методологии управляются системой
ценностей команды. Агрессивная команда, которая ценит быстрый выпуск
продукта на рынок, будет работать абсолютно иначе, чем группа, ставящая
выше семейные ценности и расходящаяся по домам в постоянное время каж-
дый вечер.
Как любит подчеркивать Джим Хайсмит, группа, чья миссия состоит в
исследовании и обнаружении новых месторождений нефти, будет действо-
вать на основе других ценностей и создавать другие правила, чем группа, чья
задача — выкачать из известного месторождения нефти все до последнего
барреля при минимально возможных затратах.
Типы методологий
Майер и Ректин (Maier and Rechtin, 2000) распределяют сами методологии на сле-
дующие категории: нормативные, рациональные, партнерские и эвристические.
Нормативные методологии базируются на решениях или последовательно-
стях шагов, известных своим дисциплинирующим действием. Для внутренней
электропроводки в доме примерами являются электрические и другие строитель-
ные нормы и правила. В разработке ПО к этой категории можно отнести вери-
фикацию диаграммы состояний.
Рациональные методологии базируются на методах и методиках. Они могут
использоваться для системного анализа и инженерных дисциплин.
Методологии
139
Партнерские методологии базируются на интересах всех участников проек-
та и предусматривают обязательное вовлечение заказчиков в проект.
Эвристические методологии основаны на полученном опыте. Майер и Рек-
тин ссылаются на их использование в аэрокосмической промышленности (в кон-
струировании самолетов и космических кораблей).
По мере роста совокупности знаний разделы методологий перемещаются из
эвристической в нормативную категорию и кодифицируются как стандартные ре-
шения для стандартных задач. В программировании этой точки достигли алгорит-
мы поиска. Этого нельзя сказать о решении, как следует размещать сотрудников:
в общей комнате или личных кабинетах.
Разработка ПО в значительной степени все еще находится на той стадии,
когда уместно применять эвристические методологии.
Контрольные точки проекта
Контрольные точки отмечают моменты, когда в проекте происходят интересные
события. При достижении контрольной точки должны собираться для обсуждения
несколько человек, исполняющих некоторые конкретные роли (впрочем, это мо-
жет быть и один человек), чтобы повлиять на ход создания рабочего продукта.
В проектах используются три разновидности контрольных точек, и каждая
имеет свои особые характеристики. Эти разновидности следующие:
Рецензирование
Публикации
Объявления
При рецензировании несколько человек анализируют рабочий продукт. При
этом нас волнуют следующие вопросы: Кто выполняет рецензирование? Что они
рецензируют? Кто создал этот элемент? Каковы результаты рецензирования?
Немногие рецензирования приводят к остановке работ по проекту; по большей
части они заканчиваются перечнем предложений, которые, как предполагается,
должны быть внедрены.
Публикация происходит при любом распространении рабочего продукта или
его передаче для открытого обозрения. Рассылка протокола совещания, регист-
рация исходного кода в системе управления конфигурацией и размещение ПО на
рабочих станциях пользователя — все это различные формы публикации. По от-
ношению к публикациям нас интересуют такие вопросы: Что публикуется? Кто
это публикует? Кто это получает? Что вызывает эту публикацию?
Контрольная точка объявления — это устное уведомление одного или неско-
льких лиц другим лицом о достижении контрольной точки. Для объявления нет
объективного критерия — это просто извещение или обещание. Объявления ин-
тересны тем, что они создают паутину обещаний внутри социальной структуры
команды. Когда я впервые обнаружил эту форму контрольной точки, она явилась
для меня полным сюрпризом.
6 Зак-715
140
Глава 4
Обнаружение объявлений
Первую контрольную точку типа "объявление" я обнаружил во время
беседы с женщиной-менеджером группы технических писателей, уча-
ствующих в проекте на 100 человек. Я спросил ее, как она определя-
ет, когда назначить исполнителя, чтобы начать писать текст подсказки.
Она сказала, что это бывает, когда руководитель команды сообща-
ет, что раздел приложения для нее "готов".
Я спросил, что значит "готов", не означает ли это завершение про-
ектирования экрана.
Она ответила, что это всего лишь означает относительную стабиль-
ность спроектированного экрана. По сути, руководитель команды
давал ей следующее обещание:
"Мы надеемся, что изменения, которые мы все еще собираемся вно-
сить, будут незначительны по сравнению с работой, которую выполнит
технический писатель, а исправления, которые будет вносить писатель,
будут незначительны по сравнению со всем объемом работы. Поэто-
му сейчас наступил подходящий момент, чтобы начать писать текст".
Это утверждение изобилует социальными обещаниями. В нем содержится
обещание, данное подготовленным лицом, что, по его мнению, компромиссы
уравновешены и это подходящее время начать работу.
Объявление (“Готово!”^ часто представляет собой форму контрольной точ-
ки, в которой код передается от разработки к тестированию, поставке альфа-вер-
сии, бета-версии и даже внедрению.
Для меня, как исследователя, объявления интересны, поскольку я не встре-
чал их описаний в ориентированных на процесс методологиях, уделяющих особое
внимание критериям начала и конца процесса. Их проще обсуждать, когда мы
рассматриваем разработку ПО как кооперативную игру. В кооперативной игре
паутина взаимосвязей команды, работающей над проектом, и соединяющие их
обещания видны лучше.
Диаграмма “роль-конечный продукт-контрольная точка” (рис. 4.15) дает бы-
стрый способ представить методологию вкратце. Она имеет преимущество над
диаграммами процессов, поскольку довольно ясно показывает параллелизм в
проекте. Она также позволяет команде увидеть важнейшие стадии завершения,
через которые проходят артефакты. Она помогает команде управлять своими
действиями в соответствии с промежуточными состояниями артефактов, как ре-
комендуется в некоторых современных методологиях (Highsmith, 2000).
Область действия
Область действия методологии состоит из ряда ролей и видов деятельности, кото-
рые она пытается охватить (рис. 4.2).
В самых ранних объектно-ориентированных методологиях ключевая роль
отдавалась проектировщику и рассматривались методики, конечные продукты
Методологии
141
и стандарты деятельности по проектированию в этой роли. Эти методологии
были признаны неадекватными в двух отношениях:
Они не были столь широки, как необходимо. Реальный проект вовлекает
больше разнообразных ролей, а не только разработчика объектно-ориен-
тированного проекта, и каждая роль затрагивает большее число видов дея-
тельности, больше конечных продуктов и больше методик, чем
представлено в книгах.
Они слишком стесняли. Проектировщикам требуется иметь на своей инст-
рументальной панели более одной методики проектирования.
гОтдых и развлечения
Отпуск и основная работа
Специальное обучение
Обучение
Внедрение Изменение
Наставник
Секретарь
Снабженец
Ночной сторож
Вахтер
Замысел Продажа
Предложение Фор
ЖИЗНЕННЫЙ ЦИКЛ ПРОЕКТА
Рис. 4.2. Три измерения области действия.
Методология выбирает подмножество по всем трем.
Группы, имеющие долгую историю постоянного накапливания опыта, такие
как Министерство обороны США, Andersen Consulting, James Martin and Associa-
tes, IBM и Ernst & Young, уже обладали методологиями, охватывающими стан-
дартный жизненный цикл проекта, даже начинающегося с точки продаж и фор-
142
Глава 4
мирования проекта. Их методологии рассматривают каждое лицо, необходимое в
проекте: от помощника по кадрам до агентов по продажам, проектировщика, ме-
неджера проекта и тестировщика.
Суть в том, что и то и другое является “методологией”. Различаются области
их действия.
Область действия методологии можно характеризовать в пространстве трех
осей: оси жизненного цикла, оси ролей и оси видов деятельности (рис. 4.2).
Ось жизненного цикла показывает, когда в жизненном цикле проекта мето-
дология начинает и когда прекращает действовать.
Ось ролей показывает те роли, которые попадают в область обсуждения.
Ось видов деятельности определяет, какая деятельностьэтих ролей попада-
ет в область обсуждения. Методология может принимать в расчет заполне-
ние табелей (как часть деятельности менеджера проекта при мониторинге
проекта и разработке графика) и может пренебречь просьбами об отпуске
(поскольку это входит в процесс основной работы).
Разъяснение подразумеваемой области действия методологии несколько по-
нижает накал в спорах о методологиях. Часто несовместимые на вид методологии
имеют в качестве целей разные части жизненного цикла или разные роли. Дис-
куссии об их различиях ииЧсЧёму не приводят, пока не проясняются их намере-
ния в отношении области действия.
В этом свете старые методологии объектно-ориентированного проектирова-
ния имеют относительно небольшую область действия. Как правило, в них выби-
рается одна роль — проектировщика или разработчика модели предметной
области. Для этой роли представлена лишь деятельность по моделированию реа-
льной предметной области и только на стадиях анализа и проектирования. Внут-
ри этой довольно узкой области действия эти методологии охватывали одну или
совсем незначительное число методик и предоставляли стандарт для одного или
нескольких конечных продуктов. Неудивительно, что опытные проектировщики
чувствовали их недостаточность для разработки в целом.
Диаграмма области действия помогает увидеть, где фрагменты методологии
удачно объединяются. Примером служит естественное соответствие рекоменда-
ций по проектированию пользовательского интерфейса Константайна и Локвуд
(Constantine, 1999) методологиям, опускающим обсуждение деятельности по
проектированию пользовательского интерфейса (оставляющим этот аспект тем
авторам, которые больше знают об этом предмете).
Не имея этих осей области действия, вы могли бы спросить Ларри Констан-
тайна: “Как ваша методология соотносится с другими методологиями быстрой
разработки, имеющимися на рынке?” В лекции в Software Development в 2001 г.
Ларри Константайн признался, что не знал, что создавал методологию, он просто
рассматривал удобные способы проектирования пользовательских интерфейсов.
Методологии
143
£
мм
Спонсор
Координатор
Пользователь
(Проектировщик
пользовательского
интерфейса)
Проектировщик/
программист
Наставник
ЖИЗНЕННЫЙ ЦИКЛ ПРОЕКТА
Рис. 4.3. Область действия Extreme Programming
По диаграмме области действия методологии мы легко определим, как они
соответствуют. Область интересов ХР показана на^р^. 4.3. Заметьте, что ей не
хватает проектирования пользовательского интерфейса. Область действия мето-
дологии Design for Use показана на рис. 4.4. По этим рисункам мы видим, что две
методологии подходят друг другу. То же самое справедливо в отношении Design
for Use и Crystal Clear.
s
Мониторинг
* проекта
Разработка
приложений
(Спонсор)
(Координатор)
(Пользователь)
Проектировщик
пользовательского
интерфейса
(Проектировщик/
программист)
(Наставник)
ЖИЗНЕННЫЙ ЦИКЛ ПРОЕКТА
Рис. 4.4. Область действия фрагмента методологии
Design for Use Константайна и Локвуд
144
Глава 4
Концептуальные термины
Для того чтобы обсуждать создание методологии, нам требуются различные тер-
мины: размер методологии, формальность и “тяжесть”, размер задачи, размер
проекта, критичность системы, точность, правильность, значимость, толерант-
ность, прозрачность, масштаб и стабильность.
Размер методологии. Число управляющих элементов в методологии. Все конеч-
ные продукты, стандарты, ввды деятельности, меры качества и описания мето-
дик представляют собой элементы управления. Некоторым проектам и авторам
нужны небольшие методологии, другим — более крупные.
Формальность. Степень необходимой точности и толерантности в методологии.
Более формальная методология соответствует большему количеству и строго-
сти управляющих элементов (Booch, 1995). В одной команде варианты испо-
льзования могут писать на салфетках и просматривать их за ланчем. В другой
команде предпочитают заполнить трехстраничный шаблон и проводить рецен-
зирование каждые полдня. Обе группы пишут варианты использования, пер-
вая использует низкую, вторая — высокую степень формальности.
Количество формальностей в методологии зависит от критичности буду-
щей системы, а также от опасений и желаний автора методологии.
“Тяжесть” методологии. Произведение размера и формальности — это число
управляющих элементов, умноженное на степень формальности каждого из
них. Это абстрактное произведение (поскольку с размером и формальностью
числа не связаны), но, тем не менее, оно полезно.
Размер задачи. Число элементов в задаче и сложность их взаимосвязей.
У размера задачи нет абсолютной единицы измерения, поскольку чело-
век, обладающий другим знанием, вероятно, сможет упростить задачу и со-
кратить ее размер. Некоторые задачи существенно отличаются от других, что
позволяет говорить об относительных размерах (задача запуска космическо-
го челнока больше, чем печатание счетов компании).
Определение размера задачи часто затрудняется спорами о количестве
человек, необходимых для производства продукта, и соответствующей “тя-
жести” методологии.
Размер проекта. Число людей, усилия которых нужно координировать, — чис-
ленность персонала. В зависимости от ситуации можно координировать ра-
боту только программистов или всего подразделения с его многочисленными
ролями.
Многие применяют выражение “размер проекта” неоднозначно, пере-
ключаясь со значения “численность персонала” на значение “размер залами"
даже внутри одного предложения. Это приводит к большой путанице, в зет-
Методологии
145
ности потому, что небольшая энергичная команда часто превосходит много-
численную среднюю команду.
Взаимосвязь между размерами задачи, персонала и методологии обсуж-
дается в следующем разделе.
Критичность системы. Ущерб от невыявленных дефектов. В настоящее время
я классифицирую критичность просто как потерю удобства, потерю дискре-
ционных средств, потерю невозместимых средств или потерю жизни. Воз-
можна и другая классификация.
Точность. Как много вы можете сказать о конкретной теме. Число пи с точно-
стью до одного разряда после запятой равно 3,1, с точностью до четырех раз-
рядов — 3,1416. Исходный код имеет более высокую точность, чем
диаграмма классов; код на языке ассемблера содержит больше, чем соответ-
ствующий исходный код на языке высокого уровня. В соответствии с намере-
ниями автора методологии она может предусматривать более или менее
высокую точность.
Правильность. Насколько вы корректны, когда говорите о некоторой теме.
Сказать “Число пи с точностью до одного разряда равно 3,3” было бы непра-
вильно. Окончательная объектная модель должна быть правильнее первона-
чальной модели. Окончательное описание пользовательского интерфейса
правильнее низкокачественных прототипов. Методологии предусматривают
повышение правильности, так же как и точности.
Значимость. Стоит или нет говорить о данной теме. Прототипы пользователь-
ского интерфейса не рассматривают модель предметной области. Проект ин-
фраструктуры не имеет значения для сбора функциональных требований
пользователей. В методологиях обсуждаются разные области значимости.
Толерантность. Насколько разрешаются значительные отклонения. Стандарт-
ные соглашения команды могут требовать или нет, чтобы даты исправления
помещались в код программы. Положение может гласить, что дата должна
обеспечиваться или вручную, или включаться каким-либо автоматизирован-
ным средством. Методология может точно определять разрывы строк и отсту-
пы, оставлять их на усмотрение разработчика или устанавливать приемлемые
границы. Например, в стандарте возможна установка, что работающая версия
должна появляться каждые три месяца плюс-минус один месяц.
Прозрачность. Насколько легко постороннее лицо может определить, соблюда-
ется ли методология. Например, процессы, регламентированные ISO9001,
сосредоточиваются на вопросах прозрачности. Поскольку ее достижение по-
рождает накладные расходы (затраты времени, денег или и то и другое), вся
группа методологий быстрой разработки ослабляет акцент на прозрачности.
146
Глава 4
Как и в случае с формальностью, разным ситуациям соответствует разная
степень прозрачности.
Масштаб. Сколько элементов могут быть собраны вместе и представлены един-
ственным элементом. Давние “категории классов” Буча объединяли набор
классов. “Пакет” UML допускает группировку вариантов использования,
классов и блоков оборудования. Планы проектов, требования и проектные
решения могут представляться в различных масштабах.
Масштаб в некоторой степени взаимодействует с точностью. Плотность
растровых точек принтера или монитора ограничивает детальность, которой
можно добиться на экране и на странице. Однако, если даже все можно по-
местить на одной странице, некоторым людям не нужно видеть все детали.
Они хотят увидеть укрупненную или высокоуровневую версию.
Стабильность. Насколько вероятны изменения. Я использую лишь три уровня
стабильности: сильно изменяющееся состояние, как в самом начале работы
команды; изменчивое, как при такой активности разработки, когда появились
некоторые успехи; и относительно стабильное, как непосредственно перед ре-
цензированием требований/проекта/кода или перед поставкой продукта.
Состояние стабильности можно выяснить, спросив: “Если бы мне нужно
было задать одни и те же вопросы сегодня и через две недели, насколько ве-
роятно, что я получил бы одни и те же ответы?”
В сильно изменяющемся состоянии вы бы услышали в ответ: “Смеешь-
ся? Кто может сказать, что произойдет со всем этим через две недели!”
В изменчивом состоянии ответ может быть таким: “Что-то в этом духе,
но в деталях, конечно, изменения будут”.
В относительно стабильном состоянии возможен такой ответ: “Очень
вероятно, хотя кое-что все-таки может измениться”.
Другие способы определения стабильности могут включать измерения
количества изменений в тексте, диаграммах, основном коде, тестовых вари-
антах и т.д. (но я эти способы не пробовал).
Точность
Точность представляет собой важнейшее понятие, которым манипулируют в мето-
дологии. Каждая категория рабочего продукта имеет версии с низкой, средней и вы-
сокой точностью.
Далее представлены версии некоторых основных рабочих продуктов с низ-
кой, средней и высокой точностью.
План проекта. Карта проекта является представлением плана проекта с низ-
кой точностью (рис. 4.5). На ней показаны основные элементы, которые должны
быть выполнены, и их зависимости, а также отмечено, какие из них должны вне-
дряться вместе. На ней можно показать относительные величины необходимых
Методологии
147
для каждого элемента объемов работ. Не показывается, кто будет выполнять ра-
боту или как много времени займет эта работа (поэтому она называется не пла-
ном, а картой).
Профиль
клиента (2)
Инфраструктура
(2)
Полные счета
клиента (1)
Основные
счета
Инфраструктура
(D
Профиль
Версия 1
Версия 2
Версия 3
Рис. 4.5. Карта проекта: версия плана проекта с низкой точностью
Те, кто привык работать с PERT-диаграммами, узнают в карте проекта
укрупненную PERT-диаграмму, показывающую зависимости проекта и допол-
ненную отметками выпуска версий.
Такая карта проекта очень полезна до укомплектования кадрами и определе-
ния временных графиков. Я пользовался ею для выведения временных графиков
и планов укомплектования кадрами.
Среднеточная версия плана проекта — это карта проекта, расширенная так,
чтобы показать зависимости между командами и сроками выполнения.
Версия плана проекта с высокой точностью — это хорошо известная, осно-
ванная на задаче, диаграмма Гантта, показывающая время для задач, назначения
и зависимости.
Чем больше точность плана, тем более он хрупок; вот почему построение
диаграмм Гантта так опасно: их создание требует много времени, но при самом
незначительном неожиданном событии они перестают соответствовать действи-
тельности.
Проектирование пользовательского интерфейса. Низкоточное описание
пользовательского интерфейса — это диаграмма потока экранов, которая уста-
навливает только назначение и взаимосвязи каждого экрана.
148
Глава 4
Описание среднего уровня точности состоит из определений экранов с дли-
нами полей и различными правилами активизации полей и кнопок.
Высокоточное определение проекта пользовательского интерфейса — это
исходный текст программы.
Требования к поведению/варианты использования
Требования к поведению часто записываются с помощью вариантов исполь-
зования.
Низкоточное представление набора вариантов использования — это список
“действующие лица-цели”, т.е. список основных действующих лиц и целей, кото-
рые они имеют по отношению к системе (рис. 4.6). Низкоточное представление
полезно в начале проекта, когда вы уделяете первостепенное внимание вариан-
там использования и распределяете работу для команд. Оно также полезно все-
гда, когда необходимо общее представление о системе.
Действующее лицо
Цель
Клиент
Клиент
Отдел маркетинга
Менеджер
Купить продукт
Получить возмещение
Подготовить рекламу
Проверить статистику
Рис. 4.6. Список “действующие лица-цели’1: низкоточное представление
требований к поведению
Средний уровень точности состоит из краткого описания варианта использо-
вания размером в один абзац или заголовка варианта использования и основного
сценария.
Средневысокий уровень точности содержит расширения и условия ошибоч-
ных ситуаций, поименованные, но без описания их обработки.
Окончательный, самый высокий уровень точности включает и условия оши-
бок, и их обработку.
Эти уровни точности более подробно описаны в книге (Cockburn, 2001с).
Проектирование программ. Низший уровень точности в объектно-ориен-
тированном проектировании — это диаграмма “обязанность-сотрудничество”,
сильно укрупненная разновидность диаграммы кооперации объектов UML (рис,
4.7). Интересный момент с этим простым представлением проекта состоит'в
том, что его уже можно оценивать и комментировать распределение обязанно-
стей.
Средний уровень точности — это перечень основных классов, их назначений
и основных взаимодействий между ними.
Средневысокий уровень — это диаграмма классов, показывающая классы,
атрибуты и связи с кардинальными числами.
Методологии
149
Рис. 4.7. Диаграмма “обязанность-сотрудничество": низкоточное представление
объектно-ориентированного проекта
Высокий уровень точности — это список классов, атрибутов, связей с кар-
динальными числами и функций с сигнатурами функций. Зачастую все они пере-
числяются на диаграмме классов.
Наивысший уровень точности — это исходный код.
Эти уровни показывают естественное продвижение от “проектирования, управ-
ляемого обязанностью” (Responsibility-Driven Design, Beck, 1989, Wirfs-Brock,
1990), через объектное моделирование с помощью UML до окончательного исход-
ного кода. Эти три уровня не противоположны друг другу, как считают некоторые, а
скорее возникают в ходе весьма естественного повышения уровня точности.
Поскольку сгенерировать окончательный код удобнее по диаграммам, то к ним
проектировщики будут добавлять точность и комментарии генерации кода. В резу-
льтате диаграммы, снабженные комментариями-, станут “исходным кодом”. Про-
граммы на C++ и Java перестают быть исходным кодом, а становятся
сгенерированным кодом.
Работа с "точностью"
С помощью низкоточных представлений выполняется большая работа. На ранних
стадиях проекта люди планируют и оценивают. На более поздних стадиях они испо-
льзуют низкоточные представления для обучения.
В настоящее время я считаю, что уровень точности достигнут, когда есть до-
статочно информации, чтобы другая команда могла приступить к работе. Рис. 4.8
показывает развитие шести типов рабочих продуктов проекта: плана проекта,
вариантов использования, проекта интерфейса пользователя, модели предмет-
ной области, внешних интерфейсов и проекта инфраструктуры.
План Варианты Проектирование Моделирование
использования пользователь- предметной
ского интерфейса областиа
Внешние
интерфейсы
Внутренние
элементы
Do L1:
Действующие
лица-цели
Do L1: Устранение (разбиение на команды)
зависимостей
Do L2:
Основные
сценарии
Do L2:
Межкомандные
зависимости
Do L3:
Контрольные
точки
Рецензирование
Мониторинг
состояния
Do L3: '
Альтернативные
сценарии
Анализ
пользовательских
требований
Build L1:
Поток экранов
Анализ требований
предметной
области
Определение
общих моделей
Do L2: Начальная
модель предметной
области (CRC)
Рецензирование
<^модели^>
Do L2:
Внешние
интерфейсы
Определение
каркасов
Проектирование
каркаса
Пересмотр
проекта каркасов
Завершение
каркаса
Рис. 4.8. Использование точности низкого уровня для запуска других
видов деятельности
Методологии
151
Рис. 4.9. Объем работы увеличивается с увеличением уровня точности
(пример для вариантов использования).
Восстанавливающее действие
Условие неудачи
Восстанавливающее действие
Восстанавливающее действие
Восстанавливающее действие
Условие неудачи
Восстанавливающее действие
Восстанавливающее действие
Восстанавливающее действие
Условие неудачи
Восстанавливающее действие
Восстанавливающее действие
Восстанавливающее действие
Условие неудачи
Восстанавливающее действие
Восстанавливающее действие
Восстанавливающее действие
Условие неудачи
Восстанавливающее действие
Восстанавливающее действие
Восстанавливающее действие
Условие неудачи
Восстанавливающее действие
Восстанавливающее действие
Восстанавливающее действие
Условие неудачи
Восстанавливающее действие
Восстанавливающее действие
Восстанавливающее действие
Условие неудачи
Восстанавливающее действие
Восстанавливающее действие |
Глядя на рис. 4.8, мы видим, что наличие списка “действующие лица-цели”
позволяет составить предварительный план проекта. Он может состоять из кар-
ты проекта, дополненной заданием и оценками сроков и укомплектования кадра-
ми. Получив эти документы, можно разделить сотрудников на команды и
параллельно составить краткие изложения вариантов использования. Как только
краткие варианты использования или существенное их подмножество готовы,
152
Глава 4
все команды специалистов могут параллельно приступить к работе, разрабаты-
вая собственные рабочие продукты.
По поводу точности нужно отметить один момент: с повышением точности
объем работы резко увеличивается. Рис. 4.9 показывает увеличение работы по
мере того, как варианты использования растут от действующих лиц к действую-
щим лицам и целям, основным сценариям, различным условиям неудач и другим
дополнительным условиям и, наконец, к восстанавливающим действиям. Анало-
гичную диаграмму можно нарисовать для любого другого типа рабочего продукта.
Поскольку высокоточные рабочие продукты требуют больше энергии и, кроме
того, меняются чаще, чем их низкоточные двойники, общая стратегия проекта дол-
жна состоять в откладывании их создания и развития или, по крайней мере, в тща-
тельном управлении этим процессом.
Стабильность и параллельная разработка
Стабильность, или “вероятность изменений”, не постоянна в ходе выполнения
проекта (рис. 4.10).
| с> Ж
V * Рецензирование*
Нормальная Нормальные
начальная изменения
нестабильность проекта
Г отовность к
рецензированию
Устранение
замечаний
рецензента!
Рис. 4.10. Сокращение колебаний в ходе выполнения проекта
Команда начинает с ситуации “нестабильности”. Со временем члены коман-
ды сокращают колебания и с продвижением проектирования достигают “измен-
чивого” состояния. Наконец, непосредственно перед рецензированием проекта
или публикацией их работы, они добиваются “относительно стабильного” состо-
яния. В этот момент рецензенты и пользователи предоставляют команде разра-
ботки новую информацию, что снова делает работу на какой-то период менее
стабильной.
Во многих проектах нестабильность неожиданно резко подскакивает. Это
случается, когда поставщик внезапно сообщает, что не сможет выполнить заказ
вовремя, или продукт ведет себя не так, как предполагалось, или алгоритм не
масштабируется, как ожидалось.
Вы можете подумать, что следует добиваться максимальной стабильности
в своем проекте.
Методологии
153
Однако соответствующий уровень стабильности, к которому нужно стреми-
ться, меняется в зависимости от направления работ, приоритетов проекта и ста-
дии проекта. Различные эксперты дают различные рекомендации, как
справляться с колебаниями темпов изменений между выпусками рабочих продук-
тов и стадиями проекта.
Проще всего сказать: “Не приступайте к проектированию, пока требования
не станут Стабильными (с прописной буквы ”С"); не приступайте к программи-
рованию, пока результаты проектирования не станут Стабильными" и т.д. Это
последовательная разработка. Благодаря своим двум преимуществам она при-
влекает многих разработчиков. Тем не менее этому подходу сопутствуют серьез-
ные проблемы.
Первое преимущество заключается в простоте. Лицо, составляющее гра-
фик, просто выстраивает последовательность действий одно за другим, планируя
начало последующего действия в момент завершения предыдущего.
Второе преимущество в том, что, если никакие значительные сюрпризы не
вынуждают менять требования или проект, менеджер может минимизировать чис-
ло потраченных на проект рабочих часов, тщательно спланировав выход сотрудни-
ков на работу для выполнения конкретных задач. Однако существуют и три
проблемы.
Первая проблема связана с тем, что затраченное на проект время в точности
равно сумме времени, необходимого на разработку требований, проектирование,
программирование, тестирование и т.д.
Последова-
тельная
разработка
Требования |
Проектирование
Программирование
Тестирование
Затраченное время }
Требования
Проектирование
Тестирование
Затраченное время }
Рис. 4.11. Успешная последовательная разработка требует
больше времени (но меньше рабочих дней),
чем успешная параллельная разработка.
Это максимальное время, которое может потребоваться для проекта. При
самом тщательном управлении менеджер проекта получит самое большое затра-
ченное время при минимальных затратах на оплату труда. Для проектов, в кото-
154
Глава 4
рых сокращение затраченного времени считается главным приоритетом, это
неудовлетворительный компромисс.
Вторая проблема связана с тем, что во время работ по проекту, как правило,
возникают сюрпризы. Если такое происходит, появляется необходимость пере-
смотреть требования или проект и увеличиваются затраты на разработку. В кон-
це концов, менеджеру проекта не удается минимизировать ни оплату труда, ни
время разработки.
Третья проблема — в отсутствии обратной связи между последующей и пре-
дыдущей деятельностью.
В редких случаях люди, выполняющие работу выше по течению, могут доби-
ться высококачественных результатов, не получая обратной связи от команды,
занятой своей деятельностью ниже по течению. В большинстве проектов те, кто
создает требования, чтобы скорректировать и придать окончательную форму
своим запросам, должны увидеть работающую версию, выполняющую их заказ.
Обычно, увидев систему в действии, они пересматривают свои запросы. Это
вынуждает вносить изменения в проектирование, кодирование, тестирование и
т.д., что увеличивает затраченное на проект время и общие расходы на проект.
Выбор стратегии последовательной разработки имеет смысл лишь тогда,
когда есть уверенность, что команда способна сформулировать удачные оконча-
тельные требования и спроектировать систему с первого подхода. Не многим
командам такое по плечу.
Рис. 4.12. Последовательная разработка. Каждая рабочая группа,
прежде чем начать, ждет, пока группа, выполняющая
предыдущую работу, достигнет полной стабильности результатов
Другая стратегия — параллельная разработка — сокращает затраченное
время и обеспечивает возможность обратной связи ценой роста объема доработ-
ки и переделок. Это иллюстрируется на рис. 4.11 и 4.13, а “Принцип 7. Потеря
эффективности в некритических видах деятельности вполне допустима” (см.
ниже) продолжает этот анализ.
Методологии
155
Требования
Проектирование
пользовательского
интерфейса и объектов
Программирование
Тестирование
Рис. 4.13. Параллельная разработка. Каждая группа начинает
сразу, как только появляется возможность для коммуникации
и доработки. По мере того как разработка продвигается,
каждая группа передает обновленную информацию следующей
группе в потоке работ (пунктирные стрелки).
В параллельной разработке каждый вид деятельности, выполняемый ниже
по течению, начинается в момент, признанный подходящим по отношению к за-
вершенности и стабильности работы команды, выполняемой выше по течению
(конечно же, разные группы могут приступать к работе в разные моменты време-
ни, зависящие от предыдущих групп выше по течению). Нижняя команда начина-
ет работать с доступной информацией, а так как верхняя команда продолжает
действовать, то она продолжает снабжать нижнюю команду новой информацией.
В той степени, в которой нижняя команда верно угадывает направление дви-
жения верхней команды, а верхняя команда не сталкивается со значительными
сюрпризами, нижняя команда выполнит свою работу приблизительно верно. По
ходу дела, по мере появления новой информации, ей придется кое-что перераба-
тывать.
Ключевым в параллельной разработке является вопрос оценки завершенно-
сти, стабильности, возможности доработки и эффективности коммуникации
команд.
Параллельная разработка имеет преимущества — парные и в точности про-
тивоположные недостаткам последовательной разработки:
Верхние команды получают обратную связь от нижних команд. Проектиров-
щики могут указать, что заданные требования реализовать очень трудно.
Программисты могут довольно быстро написать код, чтобы группа требова-
ний получила обратную связь относительно желательности требований.
156
Глава 4
Хотя каждый вид деятельности ниже по течению занимает больше време-
ни, чем при последовательной разработке, когда верхняя команда не изме-
няет своих решений, нижняя команда приступает к работе гораздо раньше.
Чистый эффект заключается в том, что нижняя команда завершает работу
раньше, чем могла бы, возможно, всего лишь через несколько дней или не-
дель после завершения деятельности выше по течению.
Такая параллельная разработка описана в книге Surviving Object-Oriented
Projects (Cockbum, 1998) как стратегия “золотой лихорадки”. Эта стратегия
предполагает хорошие возможности коммуникации и доработки. Она приспособ-
лена для таких ситуаций, в которых прогнозируется, что сбор требований будет
продолжаться дольше, чем допускает план проекта, и поэтому для должного про-
ектирования просто может не хватить времени, если следующая команда ждет,
пока не утрясутся все неясности с требованиями.
На самом деле многие проекты соответствуют этому профилю.
Стратегии типа “золотой лихорадки” не свободны от риска. Существуют три
ловушки, которых следует остерегаться:
Первая ловушка ждет тех, кто будет пользоваться этой стратегией чересчур
усердно, позволяя, например, команде проектирования обгонять команду
требований (рис. 4.14). Одна такая команда однажды объявила, что ее про-
ект уже стабилен и готов к рецензированию. Команде оставалось только до-
ждаться, когда группа требований поторопится и выработает требования!
Рис. 4.14. Верхняя деятельность должна поддерживаться
в более стабильном состоянии, чем нижняя деятельность.
Волнистые линии показывают нестабильность рабочих продуктов
в требованиях и проектировании. В нормальной ситуации (слева)
оба вида деятельности колеблются одновременно,
но колебания требований меньше, чем колебания при проектировании.
В ненормальной ситуации проектирование уже стабилизировалось,
прежде чем колебания требований начали успокаиваться!
Методологии
157
Вторая ловушка подстерегает вас, когда путь коммуникации между коман-
дами недостаточно широк. Например, если команды географически разде-
лены, верхней команде сложнее передавать свою изменяющуюся
информацию. С возрастанием затрат на коммуникацию в конечном счете
более эффективно дождаться большей стабильности в работе выше по те-
чению, а потом уже подключать нижнюю команду.
Третью ловушку создает ошибка в оценке возможностей по доработке, име-
ющихся у команды. Если возможности команды невелики или их резерв от-
сутствует, она должна начинать работу с гораздо более стабильной входной
информацией.
16 Smalltalk-программистов
и 2 проектировщика баз данных
В одном проекте работали 16 программистов на языке Smalltalk и толь-
ко 2 проектировщика баз данных.
В этой ситуации мы могли разрешить программистам приступить к ра-
боте, как только начали вырисовываться требования. В то же время мы
не могли позволить себе подключить проектировщиков баз данных,
пока объектная модель не получит позитивной оценки экспертов при
рецензировании.
Только после того, как объектная модель была признана "достаточ-
но стабильной для дальнейшей работы” и действительно прошла про-
верку администраторов базы данных в группе рецензирования,
работа по проектированию была начата.
Полное обсуждение условий применения параллельной разработки пред-
ставлено в разделе “Принцип 7. Потеря эффективности в некритических видах
деятельности вполне допустима”, изложенном далее в данной главе.
Сейчас важно понять, что стабильность играет важную роль в создании ме-
тодологии.
И ХР, и Adaptive Software Development предлагают максимально использо-
вать параллелизм (Highsmith, 2000). Это объясняется тем, что обе методологии
предназначены для ситуаций с высоким приоритетом быстрого выпуска продукта
на рынок и с требованиями, изменяющимися с высокой вероятностью после вы-
хода на рынок.
Контракты с фиксированной стоимостью часто извлекают пользу из смешан-
ной стратегии: в этих ситуациях полезно, чтобы требования в значительной сте-
пени стабилизировались, прежде чем команда могла углубиться в проектирова-
ние. Смесь будет меняться в зависимости от проекта. Иногда компания, предла-
гающая заявку, может выполнить некоторую работу по проектированию и даже
кодированию, чтобы подготовить свое предложение.
158
Глава 4
Контрольные
Рис. 4.15. Методология в представлении “роль-продукт-контрольная точка"
Публикация методологии
Опубликованная методология имеет два компонента: наглядное представление и соб-
ственно текст.
Наглядное представление
Один из способов представления методологии состоит в показе взаимодействия
ролей через рабочие продукты (рис. 4.15). В таком представлении “роль-про-
дукт-контрольная точка” время течет слева направо, роли представлены широки-
ми полосами, нарисованными поперек страницы, а рабочие продукты показаны
отдельными линиями внутри этих полос. Линия рабочего продукта показывает
важнейшие события в его жизни: событие возникновения (что вынуждает кого-то
создать продукт), события рецензирования (кто его рассматривает) и событие ис-
чезновения (в какой момент он становится несущественным, если такой момент
вообще наступает для этого рабочего продукта).
Хотя представление “роль-продукт-контрольная точка” является удобным
способом показать зависимости рабочих продуктов внутри методологии, оно так-
же вполне подходит для усыпления читателя.
Диаграмма методологии как снотворное средство
Однажды я создал пресловутый учебный плакат для методологии к
крупному проекту, дотошно показав несколько сот взаимосвязанных
частей методологии группы и использовав для обобщения информа-
ции представление "роль-продукт-контрольная точка".
Методологии
159
Многие люди просили показать методологию целиком, поэтому я
напечатал диаграмму, несколько футов в ширину и несколько футов
в высоту, и повесил ее на широкой стене.
Было интересно наблюдать, как глаза слушателей покрывались пово-
локой, когда я указывал на временную линию для следующей роли
проекта, будь то менеджеры проекта или технические писатели, и
снова фокусировались, когда я переходил к их собственной секции.
Оказалось, что большинство сотрудников на самом деле хотели
лишь увидеть ту секцию методологии, которая имела отношение к
ним, и вовсе не интересовались, чем занимается в их организации
каждый сотрудник.
Наглядному представлению не хватает способов, стандартов и других форм
взаимодействия, столь важных для группы. Они не имеют подходящего графиче-
ского изображения и должны перечисляться текстуально.
Текст методологии
В опубликованной форме методология — это текст, описывающий методики, виды
деятельности, критерии качества и стандарты для всех рабочих ролей. Примеры
можно найти в книгах Object-Oriented Methods: Pragmatic Considerations (Mar-
tin, 1998) и The OPEN Process Specification (Graham, 1997). Методология Rational
Unified Process имеет собственный web-сайт с тысячами web-страниц.
Тексты методологий очень объемны. На некотором уровне спастись от этих
объемов невозможно. Даже крошечная методология с четырьмя ролями, четырь-
мя рабочими продуктами для каждой роли и тремя контрольными точками для
каждого продукта имеет 68 (4 -I- 16 + 48) взаимодействующих частей, которые
нужно описать, не говоря уже о технических обсуждениях. И даже ХР, которая
поначалу занимала лишь 200 страниц (Beck, 2000), теперь, включив дополните-
льные руководства по каждой из своих частей (Jeffries, 2001, Beck, 2000, Auer,
2002, Newkirk, 2001), приближается по объему к 1 тыс. страниц.
Существуют две причины, почему большинство организаций не выпускает
тысячестраничный текст с описанием своих методологий для каждого нового со-
трудника.
Первая причина в том, что Джим Хайсмит четко зафиксировал, объясняя
отличие “документирования от понимания”.
Настоящая методология находится в умах сотрудников, в их привычках дей-
ствовать и разговаривать. Документировать методологию вовсе не то же самое,
что дать понимание, а понимание не прёдполагает наличия документации. Пони-
мания можно добиться быстрее, поскольку оно возникает через обычное приоб-
ретение опыта работы новыми сотрудниками.
Вторая причина в том, что потребности организации постоянно меняются.
Поддерживать соответствие тысячестраничного текста текущим нуждам
160
Глава 4
команд, работающих над проектом, если не утопично, то, во всяком случае,
непрактично.
Как показывают новые технологии, чтобы справиться с ними, команды дол-
жны изобретать новые способы работы, а их нельзя описать заранее.
Организации нужны способы развития по ходу новых вариантов методологий
и передачи полезных навыков команды следующей команде.
Сокращение объема методологии
Существует несколько способов сокращения физического размера публикуемой
методологии:
Предоставить примеры рабочих продуктов. Предоставляйте рабочие при-
меры, а не шаблоны. Используйте рассмотренные ранее сильные стороны чело-
века при работе с осязаемыми примерами.
Подберите достаточно хорошие примеры различных рабочих продуктов: пла-
на проекта, перечня рисков, варианта использования, диаграммы классов, тесто-
вого варианта, заголовка функции и образца кода.
Поместите их в общедоступное место, поощряйте их копирование и измене-
ние. Вместо написания документа по стандартам для пользовательского интер-
фейса поместите образец подходящего экрана, чтобы другие могли его
копировать и работать с ним. Вам может потребоваться прокомментировать при-
мер, показать, какие его части наиболее важны.
Поступив таким образом, вы сократите объем усилий, необходимых для фор-
мирования стандартов, и снизите преграды для их использования в команде.
Одна из немногих книг, показывающая конечные продукты и их стандарты —
Developping Object-Oriented Software (IBMOOTC, 1997), — была подготовлена
и опубликована в конце 1990-х годов Центром объектно-ориентированных техно-
логий IBM.
Удалить методические руководства. Вместо попыток научить техническим
приемам, описывая их детально в документе по методологии, оставьте лишь назва-
ния рекомендуемых методик и укажите известные книги и учебные курсы по ним.
Применение методик предполагает их знание. Дайте сотрудникам возмож-
ность учиться у экспертов или на практическом курсе, в котором они освоят нуж-
ные приемы в обучающей среде.
По возможности, вместо обучения методикам как части методологии проекта
во время работы над ним, организуйте быструю подготовку сотрудников, прежде
чем они приступят к работе над проектом. Затем эти методики станут навыками
их работы, и они будут просто делать свою работу наиболее естественными спо-
собами.
Организовать текст по ролям. Можно написать низкоточный, но описатель-
ный абзац для каждой роли, рабочего продукта и контрольной точки, связывая
Методологии
161
эти описания с диаграммой “роль-продукт-контрольная точка”. Примерные опи-
сания ролей могут выглядеть следующим образом:
Примерные описания ролей
Спонсор-администратор Лицо, имеющее полномочия для поддержки и мониторинга продвижения утвержденного проекта. Отвечает за область действия, приоритеты и финансирование на уровне проекта.
Руководитель объединения команд Лицо, ответственное за работу нескольких команд, объединение их усилий, определение приоритетов и распределение ресурсов (людских) между командами.
Руководитель команды Лицо, отвечающее за управление одной командой и за результаты ее работы.
Разработчик Специалист, разрабатывающий программный продукт. Этим продуктом может быть пользовательский интерфейс, классы предметной области, инфраструктура или данные.
Технический писатель Лицо, публикующее техническую информацию на различные темы с помощью таких посредников, как руководство, официальные документы, общие носители данных, интранет или Интернет.
Группа внедрения Одно или несколько лиц, поддерживающих контакты со специалистами отрасли и представителями заказчиков, координирующие их взаимодействие и внедряющие разработанные продукты.
Внешний тестировщик Одно или несколько лиц, выполняющих, независимо от групп разработки, функции тестирования, связанные с контролем качества.
Специалист по сопровождению Лицо, вносящее необходимые изменения в продукт после его поставки.
Для рабочих продуктов нужно зафиксировать, кто их пишет, кто их читает и
что они содержат. Более полная версия может содержать образец, отмечающий
допустимые отклонения от стандарта, и контрольные точки. Далее приведено не-
сколько простых описаний.
Общий план проекта
Технический писатель
Читатели
Содержание
Руководитель объединения команд
Спонсор-администратор, руководители команд, новички
Для всех команд — планируемое содержание
следующих нескольких версий, зависимости между
командами, планируемые сроки разработки
162
Глава 4
Таблица зависимостей
Технический писатель Руководитель команды
Читатели Руководители команд, руководители объединений команд
Содержание Что нужно получить данной команде от каждой из всех остальных команд и срок, к которому нужен каждый элемент. Может включать резервный план на случай, если элементы не получены вовремя.
Таблица состояния команды
Технический писатель Руководитель команды
Читатели Руководитель объединения команд, разработчики
Содержание Текущее состояние команды: краткий перечень задач,
над которыми работает команда. По каждой задаче:
следующая контрольная точка, возникшие проблемы и
уровень стабильности.
Для контрольных точек рецензирования фиксируйте, что рецензируется, кто
проводит рецензирование и каков его результат. Например:
Рецензирование предложений по выпуску версии
Рецензенты Руководитель команды разработки приложений, руководитель объединения команд, спонсор-администратор
Цель В основном анализ области действия (границ) проекта
Анализируются Сводка вариантов использования, варианты использования, действующие лица, описание внешних систем, план разработки
Результат Изменения области действия проекта, приоритетов, дат, возможные корректировки перечня действующих лиц или внешних систем
Рецензирование проекта приложения
Рецензенты Руководитель команды, соответствующие руководители
объединений команд, наставники объединений команд,
бизнес-эксперты
Цель Проверить качество, корректность и соответствие
проекта приложения принятым стандартам
Методологии
163
Рецензирование проекта приложения
Анализируются Варианты использования, действующие лица, диаграмма
классов предметной области, последовательности
экранов, таблицы классов (если есть), диаграммы
взаимодействия (если есть)
Результат Корректировка модели предметной области,
параметров экранов; предложения или требования по
улучшению пользовательского интерфейса или проекта
приложения, основанные на соображениях качества или
соответствия стандартам
Когда эти краткие описания оказываются на месте, методологию можно рас-
писать по ролям (как показывают следующие два примера). Письменная форма
методологии в разрезе ролей состоит из контрольных таблиц для каждого лица,
каждую из которых можно поместить на одном листе бумаги и прикрепить на ра-
бочем месте данного сотрудника. Эти листы не содержат неожиданностей (после
первого чтения), а только служат напоминанием участникам команды о том, что
им уже известно.
Вот несколько сокращенный пример для программистов:
Проектировщик-программист
Пишет Еженедельно таблицу состоянияИсходный
кодПримечания по версии(и т.д.)
Читает Описания действующих лицРуководство по стилю
пользовательского интерфейса(и т.д.)
Рецензирует Проект приложения(и т.д.)
Публикует Конфигурацию приложенияТестовые варианты(и т.д.)
Объявляет Пользовательский интерфейс Стабильным
Видно, что такая методология не сдерживает творчества. Для новичка этот
перечень определяет его роль в команде. Для опытного разработчика — это на-
поминание.
Использование процесса в миниатюре
Публикация методологии не передает интуитивного понимания, формирующее не
выраженное словами знание. Она не передает жизнь методологии, заключенную во
множестве мелких действий, сопровождающих командную работу. Людям требуется
увидеть или лично разыграть участие в процессе в соответствии с методологией.
Я предпочитаю передавать методологию посредством приема, который я на-
зываю процессом в миниатюре.
164
Глава 4
В таком процессе за очень короткий промежуток времени участники ра-
зыгрывают один-два варианта процесса.
В одной команде, с которой я беседовал, новичкам предлагали в первую неде-
лю пройти весь путь разработки небольшого фрагмента программы от требований
до выпуска. Цель этого упражнения продолжительностью в неделю состояла в
знакомстве нового сотрудника с командой, ролями, стандартами и с физическим
расположением различных вещей в компании.
Питер Мирель (Piter Merel) изобрел одночасовую миниатюру процесса для
Extreme Programming, назвав ее “экстремальный час” (Extreme Hour). Цель эк-
стремального часа — дать интуитивный опыт общения с ХР, чтобы новички мог-
ли обсуждать его понятия, опираясь на почти реальный опыт.
В экстремальном часе одна группа людей назначается “заказчиками”. В пер-
вые 10 минут они представляют свои запросы разработчикам и прорабатывают
сессию планирования.
Следующие 20 минут разработчики набрасывают свой проект и тестируют
его на предмет прозрачности накладных расходов. Общая продолжительность
времени первой итерации составляет 30 минут.
Следующие 30 минут весь цикл повторяется, поэтому два ХР-цикла осуще-
ствляются всего лишь за 60 минут.
Обычно ведущие экстремального часа выбирают забавное задание, например
спроектировать устройство для ловли рыбы, которое сохраняет рыб живыми до
момента их доставки на кухню в конце дня и в то же время весь день сохраняет
пиво холодным. (Да, им приходится ограничивать область действия во время ите-
раций!)
Мы использовали 90-минутный процесс в миниатюре, чтобы помочь штату
компании, состоящей из 50 человек, испытать новый предлагаемый нами про-
цесс разработки (ср. с информансом, описанным в главе 2).
В данном случае нас в первую очередь интересовало выражение правил про-
граммирования и тестирования, которые мы предлагали для применения. Поэто-
му мы не могли использовать такую задачу с рисунком, как силок для рыбы, но
должны были выбрать реальную задачу программирования, которая позволяла
бы создать работающий протестированный код для web-приложения.
Опыт с процессом в миниатюре
За 90 минут мы хотели продемонстрировать две полные итерации
процесса.
Мы планировали показать переговоры о требованиях, а затем созда-
ние и тестирование кода с использованием пятиуровневой архитекту-
ры, базы данных, системы управления конфигурацией, экранов в
web-стиле и полностью автоматизированных комплектов регрессион-
ных тестов.
Таким образом, мы должны были выбрать небольшое приложение.
Мы предпочли сконструировать простой реверсивный счетчик, кото-
Методологии
165
рый должен был останавливаться на 0 и на 20, а также мог быть
сброшен в 0. Счетчик должен был использовать стандартный интер-
фейс web-браузера и хранить свое значение в базе данных компании.
Чтобы удовлетворить 45-минутному ограничению на итерацию, мы
поставили маленькое представление. Аналитики по маркетингу полу-
чили задание запросить больше, чем команда могла произвести за
30 минут программирования. ("Не могли бы мы получить для счетчи-
ка графический круговой циферблат, выполненный в трех цветах?")
Мы это сделали, чтобы дать аудитории возможность приобрести
опыт переговоров об области действия, с которыми она столкнулась
бы в реальной жизни.
Мы также подробно показали, какое время могли запросить про-
граммисты для завершения первой итерации и как они могли урезать
область действия в середине итерации, чтобы аудитория увидела это
в ходе работы.
Такие сценарии для пьес пишутся с целью дать всей компании пред-
ставление о том, что мы хотели установить в качестве социальных
соглашений для нормальных переговоров относительно области дей-
ствия.
Реальное программирование мы тоже включили в этот спектакль.
Хотя участники команды знали задание, они все равно должны были
вводить код в реальном времени как часть опыта. Аудитория, выси-
девшая до конца стадии программирования, смогла оценить объем
работы, необходимый для создания даже такой тривиальной системы.
Какую бы форму процесса в миниатюре вы ни использовали, планируйте ра-
зыгрывать ее время от времени, чтобы подкреплять социальные соглашения
команды. Многие из этих соглашений, например правила ведения переговоров
относительно области действия, не найдут места в документации, но частично мо-
гут быть зафиксированы в игре.
Принципы создания методологии
Создание методологии не во всем напоминает проектирование ПО, аппаратуры,
мостов или фабрик. В частности, в этом виде деятельности появляются четыре
особенности:
Изменения в составе сотрудников. Люди — не такие надежные компоненты,
как те, на которые рассчитывает проектировщик, планируя свои системы.
Вариации в проектах. Соответствующая методология изменяется в зависи-
мости от проекта, страны и местной культуры.
Длительные циклы отладки. Циклы тестирования и отладки для методоло-
гии имеют порядок нескольких месяцев и лет.
166
Глава 4
Изменение технологий. К тому времени, когда проектировщик завершает
отладку одной методологии, изменяются технологии, методики и культура и
проект требует обновления.
Общие ошибки создания методологии
Люди, впервые получившие задание создать методологию, делают стандартный
набор ошибок.
Единый размер для всех проектов
Вот разговор, который я слышу очень часто уже несколько лет:
“Здравствуйте, Алистер. Мы разрабатываем проекты с помощью раз-
личных технологий по всему миру. Нам ужасно нужна общая методо-
логия для всех этих проектов. Вы не могли бы сделать ее для нас?”
“Боюсь, это было бы непрактично: разные технологии, культуры и
приоритеты в проектах требуют разных способов работы”.
“Это точно, я понял. А теперь, расскажите, какой будет наша общая
методология”.
Эта просьба настолько распространена, что значительную часть следующей
главы я посвящаю адаптации методологии.
Потребности в локализованных методологиях могут быть ясны для вас к это-
му моменту, но они не будут ясны вашему новому коллеге, который получит зада-
ние создать общую методологию для всей корпорации.
Интолерантность
У новичков, взявшихся за создание методологий, возникает идея, что они владеют
ответом, как нужно разрабатывать программы, и все должны работать только та-
ким способом.
Разработка ПО — изменчивый вид деятельности. Он требует, чтобы люди за-
мечали небольшие отличия, в чем бы они ни заключались, и разрешали их наиболее
практичным способом. Разные люди преуспевают, работая разными способами.
Методология является как бы смирительной рубашкой. Это на самом деле
набор соглашений и линий поведения, которые люди договорились выполнять —
смирительная рубашка такого фасона и размера, какие они выбрали сами.
Имея в виду различные характеристики разных людей, мы понимаем, что
смирительная рубашка не может быть даже чуть-чуть уже, чем ей абсолютно не-
обходимо быть.
Методики представляют собой конкретный раздел методологии, который
обычно можно сделать толерантным. Многие методики работают довольно хоро-
шо, и в разное время разным людям подходят разные методики.
Методологии
167
Степень, в которой толерантность присуща методологии, должна стать те-
мой обсуждения при создании вашей методологии.
Тяжеловесность
За несколько лет укоренилось предположение, что более “тяжелая” методология с
более тщательным мониторингом процесса и значительным числом артефактов
почему-то будет для проекта “надежнее”, чем легкая методология с небольшим
числом артефактов.
На самом деле имеет место обратное, как видно из принципов, излагаемых
в этом разделе. Однако первоначальное предположение продолжает действо-
вать и проявляется в большинстве методологий.
Предположение “чем тяжелее, тем надежнее”, вероятно, происходит от
страха, который испытывают менеджеры проекта, когда они не могут посмотреть
на код и определить состояние проекта собственными глазами. Чем дальше от
кода, тем больше страх. Поэтому совершенно естественно, что они требуют бо-
льше отчетов, суммирующих состояние дел, и больше точек координации. Аль-
тернатива в том, чтобы... доверять людям. В ходе работ над проектом эта мысль
под сильным давлением поистине может привести в ужас. Программируя на
Smalltalk, я испытал это страх на себе, когда должен был координировать проект
с программированием на COBOL.
Хоть бойтесь, хоть не бойтесь, увеличение “тяжести” методологии вряд ли по-
высит шансы команды произвести конечный продукт. Во всяком случае, вероятность
выпуска продукта командой только уменьшается, поскольку сотрудники будут боль-
ше времени уделять составлению отчетов, чем своей непосредственной работе. За-
медление разработки часто приводит к потере рыночной ниши, ухудшению
морального состояния команды и повышению шансов на полный провал проекта.
Искусство управлять проектом частично состоит в том, чтобы научиться оце-
нивать, когда и как доверять людям и когда им не доверять. Искусство создания
методологии частично состоит в том, чтобы научиться понимать, какие ограниче-
ния увеличивают не надежность, а бремя. Некоторые из подобных ограничений
исследуются в данной главе.
Излишества
Каждая без исключения методология, которую я когда-либо видел, была без всякой
необходимости наполнена лишними правилами, процедурами, идеями. Иногда они
даже не имели отношения к методологии. Это также справедливо в отношении мето-
дологий, созданных мной. Пытаясь бороться с этими коварными недостатками, на сте-
не перед собой я повесил большой плакат: “Излишества — западня для методолога”.
Излишества в методологии
Эту склонность я в себе открыл, создавая свою первую методо-
логию.
168
Глава 4
Я попросил коллегу-программиста, очень практичного человека, толь-
ко что закончившего работу над проектом, дважды проверить, по-
править и урезать мою методологию. В самом деле он нашел изли-
шества, о которых я беспокоился. Однако затем он добавил к моей
методологии одну главу, требующую обязательного заключения конт-
ракта на проектирование и выпуск продукта, о чем он только перед
этим прочитал.
Я позвонил ему. "Конечно, это не значит, что все это ты использо-
вал в своем последнем проекте?" — спросил я.
"Ты знаешь, нет, в этом не использовал. Но это действительно хоро-
шая идея, и я думаю, нам следовало бы это обдумать".
Из этого опыта я узнал, что слова “следовало бы”, “следует” означают изли-
шества. Если кто-либо говорит, что вам “следовало бы” что-то сделать, это, ве-
роятно, означает, что сами они еще никогда этого не делали, они и без этого
успешно производили ПО, и, возможно, нет никакого шанса кого-нибудь убедить
воспользоваться этим в будущем.
Вот примерная история на эту тему.
Открытие слова "следует"
ТЕСТИРОВЩИК: "А затем разработчики провели совещание с тести-
ровщиками, на котором они описали основной проект"
Я: "Неужели? Они это сделали?"
ТЕСТИРОВЩИК: "На что вы намекаете? Конечно, сделали".
Я: "Ага. Что, они и правда это сделали?"
ТЕСТИРОВЩИК: "Они должны были это сделать, иначе тестировщики
не смогли бы выполнить свою работу!"
Я: "Верно. Гм... В таком случае, если было такое совещание, я могу
опросить этих людей и узнать, что там произошло. Можете ли вы
мне назвать дату совещания и кто на нем присутствовал?"
ТЕСТИРОВЩИК: "Ну, мы собирались его устроить. Я хочу сказать,
что вам действительно следует провести такое совещание, это весь-
ма полезно..."
Дальше можно не продолжать. Разумеется, не было этого совещания. Более
того, очень сомнительно, чтобы мы могли обеспечить проведение такого совеща-
ния в той компании в то время, каким бы полезным оно ни казалось.
В этом деле с излишествами есть и другая сторона. Обычно владелец про-
цесса имеет искаженное представление о реальной деятельности разработчиков.
В моих беседах я редко встречал команду людей, работающих таким образом,
чтобы владелец процесса называл это работой. Это так широко распространено,
что я должен был отмечать как недостоверную любую информацию о проекте,
полученную лишь в беседах с менеджером и проектировщиком процесса.
Методологии
169
Далее приведен примерный и типичный фрагмент из одной моей беседы. В то
время я занимался поиском успешных реализаций метода Object Modeling Tech-
nique (ОМТ). Человек, являвшийся одновременно руководителем процесса и
команды, сказал мне, что у него есть успешный проект на ОМТ, который я могу
посмотреть, и поэтому я полетел в Калифорнию, чтобы побеседовать с его
командой.
Сокращения в процессе
Я: "Это образцы рабочих продуктов? ... Это диаграмма состояния?"
РУКОВОДИТЕЛЬ: пНу, на самом деле не совсем. Это скорее диаграм-
мы потоков. Я должен научить людей правильно строить диаграммы".
Я: "Но это же реальные примеры рабочих продуктов. Вы использо-
вали итерационный и инкрементный процесс?"
Разработчик кивает.
Руководитель: "Мы использовали модификацию спиральной модели
Боэма".
Я: "О'кей. А менялись ли требования или проект на второй итерации?"
РАЗРАБОТЧИК: "Конечно".
Я: "О'кей. ... Как вам удалось изменить все эти диаграммы на вто-
рой итерации?"
РАЗРАБОТЧИК: "Ха, мы их не меняли. Мы просто модифицировали
код..."
Extreme Programming отличается от обычных методологий, базирующихся
на конечных продуктах. ХР базируется на действиях людей. Строгость этой мето-
дологии связана с надлежащим выполнением людьми их действий.
Еще не понимая как следует различий между методологиями, базирующими-
ся на конечных продуктах, и тех, которые базируются на действиях, я не был уве-
рен, как мне лучше выполнять мой первый ХР-проект. В конце концов, раз
команда не располагает диаграммами, в которых она должна отображать состоя-
ние работы, значит, невозможно обнаружить рабочие продукты, соответствую-
щие текущему состоянию!
Базирующаяся на действиях методология опирается на постоянно выполняе-
мые действия. ХР опирается на программирование парами, разработку модуль-
ных тестов, реорганизацию кода и другие действия.
Когда я знакомлюсь с проектом, претендующим называться ХР-проектом, я
обычно обнаруживаю слаженно работающие пары программистов (в противном
случае они не называли бы это ХР-проектом). Кроме того, программирующие в
паре сотрудники, как правило, пишут модульные тесты, и поэтому обычно я на-
блюдаю процесс программирования тестов.
Наиболее распространенное отклонение от ХР состоит в отсутствии реорга-
низации кода, и в результате в базовом коде возникает беспорядок, невозмож-
ный в правильно разрабатываемом ХР-коде.
170
Глава 4
Вообще говоря, ХР требует соблюдения незначительного числа правил, а боль-
шинство излишеств из него удалены. ХР — это особый случай методологии, и я
проанализирую его отдельно в конце главы.
Что касается меня, то я склонен к излишествам, связанным с рецензирова-
нием результатов проектирования и тестированием. По-видимому, я не могу
устоять, чтобы не подбросить тихонько дополнительную оценку или тестирование
через дверь, открываемую словом “следует”. (“Конечно, им следует выполнить
эти тесты!” — слышится крик. Так уж и следует?!)
Есть один способ обнаружить излишество — предложить его людям, кото-
рых оно непосредственно касается. Внимательно наблюдайте за их лицами. Вы
обнаружите: они знают, что не будут этого делать, но боятся об этом сказать.
Непроверенные предложения
Большинство методологий никто не испытывал. Многие из них — это просто пред-
ложения, высосанные из пальца. Вот уж где пресловутое “следует” расцветает
пышным цветом: “Пожалуй, это действительно следует использовать”.
Проверив за последние десять лет множество методологий, я пришел к за-
ключению, что в создании методологии нет ничего очевидного. Многие вещи не
работают, хотя на первый взгляд кажется, что их следует применять (например,
тестирование и поддержание документации в актуальном состоянии), а другие
вещи, которыми, казалось бы, уж точно пользоваться не следует, на самом деле
работают (например, парное программирование и упреждающая разработка те-
стов).
Покойному Уэйну Стивенсу (Wayne Stevens), создавшему в начале 1990-х
годов в IBM Consulting Group методологию Information Engineering, хорошо
было известно об этой ловушке.
Когда бы и кто бы ни предлагал нам включить в нашу библиотеку методологий
новую объектно-центрическую/объектно-базированную/объектно-гибридную ме-
тодологию, он слышал в ответ: “Попробуйте ее на проекте, а потом расскажете
нам, как она работает”. Обычно разработчик протестует: “Но на это же уйдут
годы! Ведь очевидно, что это замечательная вещь!” На моей памяти ни одна из
этих очевидных новых методологий никогда не использовалась ни в одном проекте.
С тех пор я применяю подход Уэйна Стивенса и вижу ту же самую картину.
Как создаются новые методологии? Когда меня привлекают к проекту, я ра-
ботаю следующим образом:
Я подбираю, настраиваю и придумываю все необходимое, чтобы привести
проект к успеху.
После завершения проекта я извлекаю то, что мог бы повторить в анало-
гичных условиях, и пополняю этим мой набор тактик и стратегий.
Я выслушиваю другие команды, когда они рассказывают о своем опыте ра-
боты над проектом и о полученных ими уроках.
Методологии
171
Но когда кто-либо присылает мне предложение использовать его методоло-
гию, я прошу разработчика сначала попробовать ее на проекте, а потом сооб-
щить о результатах.
Методологии, использованные один раз
Следом за “неопробованными” методологиями идут “использованные один раз”.
Создатель методологии, обнаружив один проект, в котором его детище работает,
объявляет его общим решением. Однако реальность такова, что различные проек-
ты требуют различных методологий, и поэтому любая методология имеет ограни-
ченные возможности применения в другом проекте.
Через эту фазу я прошел с моей методологией Crystal Orange (Cockburn,
1998); то же самое можно сказать о создателях ХР. К счастью, каждый из нас об-
ладал достаточным здравым смыслом, чтобы создать этикетку “добросовестная
реклама”, описывающую область применимости нашей методологии.
К этой теме мы будем возвращаться еще не раз. Как определить область
применимости методологии и как заранее приспособить методологию к проекту,
чтобы это пошло ему на пользу?
Методологически успешные проекты
Возможно, вас заинтересовали эти беседы о проектах, о которых я постоянно упо-
минаю. Моя работа базируется на поиске “методологически успешных” проектов.
Такие проекты имеют три отличительные черты:
Проект завершился выпуском продукта. Я не спрашиваю, был ли он завер-
шен в срок и уложился ли в бюджет, важно, что ПО выпущено в свет и нача-
ло использоваться.
Руководство проектом сохранилось. Руководителя не уволили за то, что он
натворил.
Команда, работавшая над проектом, собирается таким же образом рабо-
тать снова.
Первый критерий очевиден. Для него я опустил пданку пониже, поскольку
существует так много удивительных сил, влияющих на то, как люди оценивают
“успешность” проекта. Если ПО доведено до выпуска и стало использоваться,
значит, методология, по крайней мере, не слишком плохая.
Второй критерий был добавлен, после того как я побеседовал с людьми, ра-
ботавшими над проектом, “успешность” которого широко рекламировалась. По-
пав в эту организацию, я узнал, что менеджер проекта был уволен через год
работы над проектом, поскольку за это время не было разработано никакого
кода, несмотря на произведенные командой горы отчетов. Это был не крупный
военный или жизненно важный проект, где такой подход можно было бы считать
172
Глава 4
уместным, а вполне ординарный программный проект, над которым работал штат
из восемнадцати сотрудников.
Третий критерий наиболее сложен. Чтобы методологию можно было при-
знать успешной, главное — понять, что команда добровольно готова работать
предписываемым способом. Разработчики легко могут заблокировать методоло-
гию. Обычно им достаточно лишь сказать: “Если я буду это делать, дата поставки
программы задержится на две недели”. Впрочем, обычно они бывают правы.
Не саботируя методологию непосредственно, разработчики могут ее ниспро-
вергнуть. Обычно в ходе беседы я узнаю, что команда разрушила процесс или
вытерпела его однажды, но не стала бы снова работать таким образом.
Иногда команда следует методологии, потому что ее создатель участвует в про-
екте. Я должен применить тот же критерий к самому себе и отвергнуть некоторые из
моих собственных проектов. Если участники проекта пользовались моими предло-
жениями, только чтобы мне потакать, я не уверен, что они стали бы их выполнять,
не будь меня рядом с ними.
Уместно спросить: “Будут ли разработчики продолжать работать таким же
образом, если автор методологии не будет стоять у них над душой?”
До сих пор я обнаружил три методологии, которые люди охотно используют
дважды подряд. Это:
Responsibility-Driven Design (Wirfs-Brock, 1990);
Extreme Programming (Beck, 1999);
Crystal Clear (Cockbum, готовится к печати).
(Из этого перечня я исключил Crystal Orange, поскольку сам был проекти-
ровщиком процесса и ведущим консультантом. Кроме того, эта методология име-
ет дело со специфической конфигурацией технологий и поэтому требует
повторной оценки в другой, новой среде.)
Даже если создание методологий не является основным вашим занятием, из
этого раздела о беседах по поводу проектов вы можете извлечь один урок. Значи-
тельную часть знаний об удачных традициях в разработке я приобрел, общаясь с
командами, работавшими над проектами. Эти интервью настолько информатив-
ны, что я продолжаю их проводить.
Такое средство усовершенствования доступно и для вас. Начните вести
собственное досье бесед и откройте в опыте других людей полезные для себя
вещи.
Восприимчивость автора методологии
Принципы методологии не появляются согласно формальному алгоритму, а возни-
кают из личного опыта ее создателя. Можно перефразировать выражение из
“Волшебника из страны Оз”: “Особое внимание обращайте на человека, спрятав-
шегося за занавеской”.
Методологии
173
Каждый человек имеет опыт, формирующий его представления и служащий
отправной точкой. Создатели методологий не отличаются от других людей.
Понимая это, Джим Хайсмит начал расспрашивать авторов методологий об
их опыте. В книге Agile Software Development Ecosystems он представил не толь-
ко конкретные методологии, но и биографические данные их создателей.
Убеждения человека, вообще говоря, недоступны для обсуждения. Они фор-
мируются в детстве, в опытах первых проектов или личной философией. Хотя мы
можем обсуждать словарь и область действия проекта, но не можем сделать того
же в отношении личных убеждений. Нам остается или принять их, или не согла-
ситься с ними.
Когда Кент Бек съязвил: “Все методологии базируются на страхах”, я снача-
ла подумал — он решил от меня отделаться. Со временем я понял, что это в зна-
чительной степени справедливо. Вам по силам почти угадать прошлый опыт
автора методологии, знакомясь с его творением. Каждый элемент методологии
можно рассматривать как предупреждение повторения неудачного опыта, испы-
танного ее создателем.
Боитесь, что программисты делают слишком много мелких ошибок? Про-
водите рецензирование кода.
Боитесь, что пользователи не знают, что они на самом деле хотят? Созда-
вайте прототипы.
Боитесь, что проектировщики уйдут в середине проекта? Заставьте их по-
стоянно документировать их работу.
Разумеется, как говорит старая поговорка, если вы параноик, это не значит,
что вас не преследуют. Некоторые из ваших страхов могут быть достаточно обо-
снованы. Именно это произошло в одном проекте, о чем нам рассказал склонный
рискнуть руководитель команды. Вот его история, услышанная нами в дискусси-
онной группе:
Не трогайте мои закрытые переменные
Руководитель команды хотел упростить сложный объектно-ориенти-
рованный проект, в котором использовались частично закрытые ме-
тоды, изменяющие некоторые локальные переменные.
Кто-то в нашей группе предложил сделать все методы открытыми.
Это решение чрезвычайно упростило бы проект.
Руководитель команды немного подумал и признался, что действо-
вал из страха, что программисты не станут следовать необходимым
программным соглашениям, позволяющим поддерживать безопас-
ную работу программ. Он хотел, чтобы программисты использовали
эти открытые методы лишь в конкретной трудной ситуации.
Он боялся, что при таких безумных сроках программисты будут вез-
де пользоваться этими методами, которые вызовут проблемы с со-
174
Глава 4
провождением. Он хотел попробовать для эксперимента сделать
методы открытыми и написал на белой доске очень простое прави-
ло, ограничивающее их применение.
Я сказал: "Возможно, ваши страхи были действительно обоснованы.
А что если все-таки вам не только полагаться на хорошее поведение
ваших сотрудников, но также написать маленький сценарий, постоян-
но проверяющий фактическое использование этих методов? Тогда вы
узнаете, достаточно ли обоснованы ваши страхи.
Руководитель команды согласился.
Затем он на две недели уехал в отпуск.
Вернувшись на работу, он запустил сценарий и обнаружил, что про-
граммисты действительно используют новые, открытые методы, иг-
норируя замечание, написанное на белой доске.
(Здесь к разговору подключился еще один слушатель: "Ясно, что
это были единственные документированные методы!)
Приведенная здесь история поднимает интересный вопрос о доверии: как бы
я ни хотел доверять людям, но им суждено быть беспечными. Иногда важно наде-
яться на людей, но иногда нужно установить механизм, чтобы выяснить, можно
ли им доверять в конкретном вопросе.
Последнюю часть личного багажа создателей методологии представляет их
индивидуальная философия. Одни придерживаются философии невмешательст-
ва, другие — военного контроля. Философия идет вместе с человеком, формиру-
ет его опыт, и сама она формируется его опытом, страхами и желаниями.
Интересно было бы посмотреть, насколько философия автора методологии
применяется в его личной жизни. Какую форму Personal Software Process исполь-
зует Уоттс Хамфри (Watts Humphrey), когда подводит баланс по своей чековой
книжке? Действительно ли Кенту Беку просто получать результаты итераций и об-
ратную связь так быстро, как он только может? Путешествую ли я налегке и тер-
пим ли к привычкам других людей?
Вот несколько важных сведений обо мне, которые или управляют стилем
моих методологий, или, по крайней мере, ему не противоречат.
Как вы могли догадаться, я путешествую налегке. Я пользуюсь небольшим
ноутбуком, небольшим телефоном, вожу небольшую машину и вижу, как мало
багажа мне нужно в поездках. В упорной конкурентной борьбе между подвижно-
стью и броней, вне всяких сомнений, я выбираю подвижность.
Я жил во многих странах среди разных культур и обнаружил, что везде можно
работать. В этом, наверное, источник моей восприимчивости к культурам, и по-
этому я одобряю толерантность в методологиях.
Мне нравится долго размышлять о последствиях, поэтому я могу себе позво-
лить небрежность. Так, своей чековой книжкой я начинаю заниматься, когда это
уже абсолютно необходимо, делаю это как можно быстрее, пока еще чеки не на-
чали возвращать. Абсолютная аккуратность меня не волнует. Лишь однажды,
Методологии
175
когда я делал книжные полки, я обрабатывал как раз те немногие места, где нуж-
но было проявлять аккуратность со стружкой, стараясь создать ровные и крепкие
полки.
Начиная проводить беседы с командами об их проектах, я приготовился об-
наружить, что секрет успеха заложен в точности процесса. Узнав, что это не так,
я был действительно удивлен. Но, узнав об эффективности использования легких
методологий, коммуникации и терпимого отношения, естественно, я должен был
нажить капитал на этих результатах.
Остерегайтесь автора методологии. Ваш опыт с методологией может сильно
зависеть от того, насколько хорошо ваши личные привычки совмещаются с его
привычками.
Семь принципов
За несколько лет я установил семь принципов, полезных при создании и оценке
методологий:
1. Интерактивное общение лицом к лицу — это самый дешевый и быст-
рый способ обмена информацией.
2. Избыточная “тяжесть” методологии стоит дорого.
3. Более многочисленные команды требуют более “тяжелых” методологий.
4. Большая формальность подходит для проектов с большей критичностью.
5. Возрастание обратной связи и коммуникации сокращает потребность
в промежуточных конечных продуктах.
6. Дисциплина, умение и понимание противостоят следованию инструкци-
ям, формальности и документированию.
7. Потеря эффективности в некритических видах деятельности вполне до-
пустима.
Далее обсуждается каждый из этих принципов.
Принцип 1. Интерактивное общение лицом к лицу — это самый
дешевый и быстрый способ обмена информацией.
В предыдущей главе обсуждалось относительное преимущество и соответствую-
щее использование теплого и холодного каналов общения. Вообще говоря, в раз-
работке ПО мы должны предпочесть использовать более теплые каналы общения,
поскольку заинтересованы в сокращении затрат на обнаружение и передачу ин-
формации.
Принцип 1 утверждает, что люди, сидящие рядом друг с другом, с помощью
частого удобного контакта легче смогут разрабатывать программы и эта разра-
ботка будет дешевле. По мере того как растут объемы проекта и становится
176
Глава 4
труднее организовать интерактивное общение лицом к лицу, затраты на общение
повышаются, качество общения падает и сложность разработки ПО растет.
Этот принцип не утверждает, что качество общения падает до нуля, и не
предполагает, что все программы могут разработать несколько человек, сидящих
в одной комнате. Он предполагает, что если производительность и затраты прио-
ритетны, то создатель методологии может придать особое значение небольшим
группам и личным контактам. Этот принцип подтверждается исследованиями в об-
ласти менеджмента (Plowman, 1995, Sillince, 1996 и др.).
Мы использовали принцип 1 в главе 3 в истории об архивной документации
на видеокассете, где описывается, как с помощью видеозаписи документируется
обсуждение проектирования, которое ведут у белой доски два разработчика.
Этот принцип ставит один конкретный вопрос: “Как формы общения связа-
ны с затратами на обнаружение и передачу информации?”
Насыщенность (“температура”) канала коммуникации
Рис. 4.16. Эффективность различных каналов коммуникации
Можно задать другие вопросы, чтобы вывести другие связанные принципы.
Например, было бы интересно открыть принцип, отвечающий на такой вопрос:
“Как формы общения влияют на оценку спонсором соответствия команды конт-
ракту?” Этот вопрос ввел бы в методологию проблему прозрачности. Он произ-
вел бы совершенно другой результат, возможно придающий значение
письменным документам.
Принцип 2. Избыточная "тяжесть” методологии стоит дорого.
Представьте себе шесть человек, работающих в комнате с осмотическим общени-
ем и рисующих на белой доске с возможностью печати. Их общение эффективно,
гнет бюрократизма невелик. Значительную часть своего времени они проводят в
разработке ПО, руководства по эксплуатации и других документальных артефак-
тов, необходимых для конечного продукта.
Методологии 177
Теперь потребуйте от них поддерживать дополнительные промежуточные
рабочие продукты, записанные планы, диаграммы Гантта, документы о требова-
ниях, аналитические документы, документы по проектированию и планы тестиро-
вания. В воображаемой ситуации они по-настоящему не нужны команде для
разработки. Они отнимают время у разработки.
В таких условиях производительность снижается. Включая в методологию но-
вые элементы, вы нагружаете команду дополнительной работой, тянущей ее в сто-
рону от сути разработки ПО.
Иными словами, маленькая команда может успешно справиться с более се-
рьезной задачей, используя более легкую методологию (рис. 4.17).
Новые элементы добавляются к методологии быстрее, чем рассчитывают
люди. Проектировщик процесса или менеджер требует проведения нового рецен-
зирования, выполнения бумажной работы, которая должна “отнимать лишь полча-
са время от времени”. Сложите несколько таких заданий, и вот уже проектиров-
щики теряют дополнительные 15-20% своей и так уже сжатой рабочей недели.
Дополнительная работа разрушает нормальный ход процесса проектирования.
Очень скоро проектировщики начинают обдумывать свои проблемы, выделяя на
это по часу или два в день, что, как вы видели ранее, не дает хорошего результата.
Это я часто наблюдал в проектах: проектировщики не могут получить необ-
ходимое спокойное время для выполнения работы из-за обилия отчетов и частого
отвлечения внимания.
Однако этот принцип содержит ловушку. Если вы попытаетесь повысить про-
изводительность, удаляя все больше и больше элементов методологии, вы в конце
концов уберете те элементы, которые способствуют качеству кода. В некоторый
момент эта стратегия приводит к обратным результатам, и команда начинает тра-
тить больше времени на исправление ошибок, чем на продвижение вперед.
Задачу какого размера может штурмовать
заданное число людей, используя
методологии с разной “тяжестью”?
“Тяжесть” методологии
Рис. 4.17. Влияние увеличения “тяжести” методологии
на работу небольшой команды
178
Глава 4
Ключевым, конечно, является слово “избыточный”. Разные разработчики
методологий дают разные рекомендации по поводу определения, где начинается
“избыточная” методология. Я полагаю, что команды, опирающиеся на сильные
стороны человека — общение и чувство долга, — могут обойтись гораздо мень-
шей методологией, чем считает большинство менеджеров. Джим Хайсмит выска-
зывается по этому поводу более определенно. Он предлагает начинать с еще
более легкого варианта, чем допустимо на ваш взгляд!
Из этого обсуждения можно извлечь два вывода:
Добавление в проект “небольшого” объема бюрократической нагрузки
значительно увеличивает затраты.
Некоторая часть методологии должна способствовать качеству результатов.
Принцип 3. Более многочисленные команды требуют более
"тяжелых" методологий.
Если команда насчитывает всего лишь четыре-шесть человек, имеет смысл по-
местить их вместе в одну комнату, снабдить печатающей белой доской и предо-
ставить конвекционным потокам информации возможность завязать постоянный
диалог в кооперативной игре изобретения и коммуникации.
Однако, если численность команды превысит 8-12 человек, эта стратегия
потеряет свою эффективность. Когда численность достигнет 30-40 человек,
команда будет занимать весь этаж. При 80-100 участниках команда распростра-
нится по нескольким этажам в нескольких зданиях или в нескольких городах.
С увеличением численности растут затруднения, которые испытывают
люди, чтобы узнать, чем заняты другие и как избежать пересечений, дублирова-
ния или вмешательства в работу друг друга. С ростом численности растет и по-
требность в какой-то форме координации и коммуникации.
Задачу какого размера может штурмовать
заданное число людей, используя
методологии с разной “тяжестью”?
“Тяжесть” методологии
Рис. 4.18. Влияние увеличения “тяжести" методологии
на работу большой команды
Методологии
179
На рис. 4.18 показано, как утяжеление методологии влияет на деятельность
большой команды. Если методология очень легкая, координация в команде отсут-
ствует. Когда команда начинает координировать свою работу, ее эффективность
повышается (это левая половина кривой). В конце концов для любой численности
группы отдача сокращается и на бюрократическую деятельность начинает уходить
больше времени, чем на разработку системы (правая часть кривой).
Правая часть кривой описывается принципом 2 — “Избыточная ’’тяжесть"
методологии стоит дорого". Принцип 3 описывает левую часть кривой: “Более
многочисленные команды требуют более ’’тяжелых" методологий".
Принцип 4. Большая формальность подходит для проектов
с большей критичностью.
Этот принцип обращается к формальности и толерантности (см. второй раздел на-
стоящей главы).
Портфель проектов
В IT-департаменте Центрального банка Норвегии мы работали над
многими видами проектов.
Один проект должен был позволить сотрудникам, работающим в ве-
чернее время, заказывать обеды из кафе.
Другой проект должен был обеспечить поддержкой SQL-программи-
рования сотрудников банка, изучающих инвестиции.
Третий проект был направлен на мониторинг всех межбанковских
транзакций в стране.
Четвертый должен был преобразовать всю систему Банка Норвегии,
чтобы защитить ее от "проблемы 2000".
Цена пропущенной ошибки в третьей и четвертой системах значительно от-
личается от цены ошибки в первых двух. Для обозначения этих отличий я исполь-
зую термин “критичность”. Добиться корректной работы в двух последних
проектах критически более важно, чем в первых двух.
Так же, как и объем коммуникации, критичность влияет на выбор соответст-
вующей методологии. В соответствии с потерями, вызываемыми дефектами в си-
стеме, я разделил критичность на четыре категории.
Потеря удобства.
В кафе вместо пиццы приготовят лазанью. В худшем случае сотрудник купит
сэндвич в автомате.
Потеря дискреционных средств
В эту категорию обычно попадают системы выставления счетов. Если в счет
телефонной компании вкрадывается ошибка, клиент перезванивает в компанию
и улаживает проблему со счетом.
180
Глава 4
Многие менеджеры проектов хотели бы представить, что их проекты причи-
няют более значительный ущерб, но на самом деле большинство систем облада-
ют подходящими дополнительными неавтоматическими процедурами и ошибки
обычно устраняются одним телефонным звонком. Я был удивлен, когда обнару-
жил, что транзакция отслеживания межбанковских операций подходит к этой ка-
тегории. Хотя используемые в ней цифры кажутся мне слишком длинными,
банковские служащие имеют с ними дело постоянно и для исправления компью-
терной ошибки могут подключить неавтоматические механизмы.
Потеря невозместимых средств
Из-за определенных ошибок в программе ваша компания станет банкротом.
На этом уровне критичности невозможно на скорую руку исправить ошибку од-
ним телефонным звонком.
На самом деле очень малая доля проектов действуют на этом уровне. Недав-
но мне удалось обнаружить два таких проекта, чему я был очень удивлен.
Первая система предоставляла возможность выполнять финансовые опера-
ции через Web. Каждую транзакцию можно было бы скорректировать по телефо-
ну, но у системы насчитывалось 50 тыс. подписчиков (по оценкам, их число
должно было достичь 200 тыс. на следующий год), и набор услуг продолжал рас-
ширяться. Темп поступления вызовов увеличивался стремительно. Затраты вре-
мени на устранение ошибок уже полностью поглотили рабочий день одного
бизнес-эксперта, в обязанности которого входили совсем другие вещи, и заняли
почти половину времени другого бизнес-эксперта. Эта компания решила, что так
продолжаться не может и что ошибки исправляются просто.
Вторая система должна была управлять многотонным автономным транс-
портным средством. В этом случае ошибки также не устранялись чем-то вроде
телефонного звонка или небольшой суммы денег. В значительной,степени каж-
дая ошибка в транспортном средстве могла привести к весьма реальному, посто-
янному и болезненному ущербу.
Потеря жизни
Под эту категорию подпадает ПО, контролирующее движение стержней в
ядерном реакторе, а также кардиостимуляторы, управление АЭС и космические
челноки. Вообще говоря, участники команд, чьи программы могут уничтожать
человеческую жизнь, знают, над каким проектом они работают, и готовы к боль-
шей осторожности.
По мере того как степень потенциального ущерба растет, легко оправдать
увеличение затрат на разработку защиты против ошибок. Согласно второму
принципу, наращивание методологии увеличивает затраты, но в данном случае
затраты того стоят. Эти затраты уходят не на дополнительное общение, а на со-
кращение дефектов.
Принцип 4 обращается к степени формальности для проекта. Вспомним, что
формальность имеет отношение к количеству управляющих элементов, исполь-
Методологии
181
зуемых в разработке, и к допустимой толерантности. Более значительная форма-
льность соответствует большему количеству управляющих элементов и меньшей
толерантности.
Рассмотрим создаваемое командой ПО для районной лиги игры в боулинг.
Команда пишет несколько предложений для каждого варианта использования на
бумаге или в текстовом процессоре. Рецензирование вариантов использования
происходит в комнате, где собирается несколько человек, и каждый высказывает
все, что он об этом думает.
Для сравнения рассмотрим другую команду, разрабатывающую ПО для
электростанции. Сотрудники применяют определенные инструменты, заполняют
очень специфические поля в общем шаблоне, сохраняют версии каждого вариан-
та использования и твердо придерживаются соглашений о стиле программирова-
ния. Они рецензируют варианты использования, проводят анализ, контролируют
внесение изменений и заканчивают их проработку на нескольких шагах жизнен-
ного цикла проекта.
Разработка второго набора вариантов использования обходится дороже. Но
все-таки команда идет на это, рассчитывая, что при таком способе работы она
сделает меньше ошибок. Меньшую толерантность к отклонениям эта команда
оправдывает повышенной надежностью окончательного результата.
Принцип 5. Возрастание обратной связи и коммуникации сокращает
потребность в промежуточных конечных продуктах.
Вспомним, что конечные продукты — это рабочие продукты, передаваемые через
границы принятия решений. Промежуточным конечным продуктом является такой
рабочий продукт, который передается через границы принятия решений внутри
команды. В их число могут входить детальный план проекта, усовершенствованные
документы о требованиях, аналитические и проектные документы, планы проведе-
ния тестирования, внутрикомандные зависимости, перечни рисков и т.д.
Я называю их также “долговыми обязательствами”, поскольку их можно
представить так:
“Я обязуюсь, что система будет выглядеть, как описано в этих требо-
ваниях”.
“Я обязуюсь, что эта аналитическая модель будет служить ядром для
проектирования системы”.
“Я обязуюсь, что этот проект будет хорошо работать в течение долгого
времени”.
Существуют два способа сократить потребности в долговых обязательствах:
1. Достаточно быстро создать работающую часть системы, чтобы спонсор
определил, правильно ли команда понимает требования.
182
Глава 4
Демонстрация работающей части системы быстро приносит следующие по-
лезные результаты:
Разработчики требований могут сказать, удовлетворят ли написанные ими
требования потребности пользователей.
Команде требуется проводить меньше рецензирований требований, а зача-
стую удается упростить процесс работы с требованиями и в других отноше-
ниях.
Проектировщики раньше видят влияние их решений и не строят многие
другие решения, опираясь на ошибочное понимание.
Планирование тестирования становится гораздо проще. Иногда другой
промежуточный рабочий продукт, план тестирования, заменяется работаю-
щими тестовыми вариантами.
2. Сократить численность команды, разместив сотрудников достаточно
близко, чтобы они вместо составления внутренних документов просто
могли рассказывать друг другу, что они делают.
Обратите внимание на слово “внутренние”. Нуждающиеся в коммуникации
спонсоры по-прежнему могут требовать письменную документацию различного
вида.
Принцип 6. Дисциплина, умение и понимание противостоят процессу,
формальности и документированию.
Когда Джим Хайсмит говорит: “Не путайте документацию с пониманием”, он име-
ет в виду, что значительная часть знания, цементирующего проект, остается знани-
ем, не выраженным словами где-нибудь на бумаге, а хранящимся в головах людей.
База знаний проекта огромна, и значительная ее часть относится к знанию
ритуала проведения переговоров в команде, к тому, кто из сотрудников какой ин-
формацией владеет, кто внес наибольший вклад в последнюю версию, какое об-
суждение необходимо для принятия определенных решений по проектированию и
т.д. Даже получив лучшую документацию в мире, новая команда не обязательно
сможет просто подхватить работу там, где ее оставила предыдущая команда. Но-
вая команда не начнет двигаться вперед, пока ее участники не построят свою
базу знаний, которую невозможно выразить словами.
Говоря о “документации” проекта, отдавайте себе отчет, что знание, ставшее
документацией, — лишь малая часть того, что можно узнать о проекте. Людям,
специализирующимся в передаче технологий, это известно. Как выразился один
член совета директоров IBM: “Нельзя добиться эффективной передачи техноло-
гии, передавая саму технологию, нужно передать головы, хранящие эту техноло-
гию” (см. главу 3).
Методологии
183
Хайсмит продолжает: “Процесс — это не дисциплина”. Дисциплина предпо-
лагает, что человек выбирает такую манеру работы, которая требует последова-
тельности. Процесс же — это выполнение человеком инструкций. Дисциплина
мощнее процесса; человек, решающий действовать последовательно и аккурат-
но, окажет на проект гораздо лучшее влияние, чем человек, просто следующий
инструкциям.
Думать, что процесс каким-то образом придаст работе дисциплину, — рас-
пространенная ошибка.
Третье утверждение Хайсмита гласит: “Не путайте формальные процедуры
с умением”.
Страховые компании находятся в необычной ситуации. Мы заполняем фор-
мы, посылаем их в страховую контору и получаем полисы страхования. Это ве-
сьма удивительно. Возможно вследствие того, что они живут в этом необычном
царстве, ко мне несколько раз обращались из страховых компаний с просьбами
разработать формы для вариантов использования и объектно-ориентированно-
го проектирования. Их цель, как мне сообщали в каждом случае, — получить
простые, рассчитанные на непрофессионалов методы построения высококаче-
ственных вариантов использования и объектно-ориентированных проектных
решений.
К сожалению, наш мир устроен не так. Хороший проектировщик прочитает
набор вариантов использования и сразу создаст объектно-ориентированный про-
ект, который будет со временем улучшаться. Однако никакой объем работы по
заполнению форм не заменит этого умения. Точно так же хороший проектиров-
щик пользовательского интерфейса создает гораздо лучшие программы, чем про-
ектировщик средней руки.
На рис. 4.19 показан результат объединения наших с Хайсмитом мыслей по
этому поводу.
Хайсмит различает поисковую, или адаптивную, деятельность и оптимизирую-
щую деятельность. Первая разновидность, говорит он, иллюстрируется разведкой
новых месторождений нефти. При поиске нового месторождения нельзя предска-
зать, что произойдет. Однако после того, как нефтяная скважина начал функцио-
нировать, задача состоит в сокращении затрат в предсказуемой ситуации.
В разработке ПО мы превращаемся в оптимизирующую нефтяную компа-
нию, когда ближе знакомимся с проблемой, которую нужно решить, с командой и
с используемыми технологиями. Когда нам об этом ничего не известно, мы боль-
ше похожи на поисковую компанию, работающую в адаптивном режиме.
В большей степени, чем документирование, процесс и формальные процеду-
ры, “легкие” методологии используют понимание, дисциплину и умение. Следо-
вательно, они особенно хорошо подходят для поисковых ситуаций. Типичные
“тяжелые” методологии, опирающиеся на документацию, следование инструкци-
ям и формальные приемы, предназначены для ситуаций, в которых команда не
должна приспосабливаться к изменяющимся ситуациям, а может оптимизиро-
вать свои затраты.
184
Глава 4
Процесс, формальности, документация
Рис. 4.19. Документация не есть понимание, процесс — не дисциплина,
а формальности — не умение.
Из числа известных мне проектов почти все соответствуют профилю поиско-
вых ситуаций. Это может объяснить, почему я лишь однажды встретил удавший-
ся проект, использующий оптимизирующий стиль методологии. В этом
исключительном случае компания работала в той же самой проблемной области
и использовала те же самые базовые технологию, процесс и архитектуру в тече-
ние нескольких десятилетий.
Характерные особенности поисковой и оптимизирующей ситуации противо-
речат друг другу. Оптимизирующие проекты пытаются сократить зависимость от
подразумеваемого знания, персонального умения, дисциплины и, следовательно,
больше полагаться на документацию, процесс и формальности. С другой сторо-
ны, поисковые проекты позволяют людям уменьшить их зависимость от бумаж-
ной работы, инструкций, формальностей, в большей степени полагаясь на
понимание, дисциплину и умение. Эти две ситуации уводят в разные стороны.
Мы с Хайсмитом выдвинули гипотезу, что любую методологию можно обна-
ружить на линии, изображенной на рисунке, и она будет тяготеть к одной или
другой ситуации, но никак ни к обеим вместе.
Принцип 7. Потеря эффективности в некритических видах
деятельности вполне допустима.
Принцип 7 является руководящим для параллельной разработки и ключевым при
адаптации методологий Crystal для разных команд в разных ситуациях. Он тесно
связан с идеями Элиху Голдратта (Elihu Goldratt), выраженными в книгах The Goal
(Goldratt, 1992) и The Theory of Constraints (Goldratt, 1990).
Методологии
185
Для начала представьте себе проект с пятью аналитиками, пятью Small-
talk-программистами, пятью тестировщиками и одним проектировщиком реляци-
онных баз данных (DBA), которые все хорошо знают свою работу. Предположим
для этого примера, что группа не имеет возможности принять на работу других
DBA. На рис. 4.20 показана существенная часть этой ситуации — пять програм-
мистов поставляют работу одному DBA.
Рис. 4.20. Пять Smalltalk-программистов снабжают работой одного DBA.
Ясно, что один DBA не сможет справиться с пятью программистами. И дело
не в его умении, а в перегруженности работой. В терминах Голдратта деятель-
ность DBA является узким местом. Скорость работы этого DBA определяет ско-
рость выполнения всего проекта.
Чтобы добиться хорошего' темпа работы, команда должна постараться как
можно лучше снабжать DBA информацией. Каждое торможение, каждая незна-
чительная переделка, которую ему приходится выполнять, непосредственно ска-
зываются на затратах проекта.
Для Smalltalk-программистов все выглядит в точности наоборот. По сравне-
нию с DBA они имеют огромный резерв производительности.
Столкнувшись с такой ситуацией, менеджер проекта может сделать одно из
двух:
Отослать четырех Smalltalk-программистовдомой, чтобы оставшийся про-
граммист и DBA сравнялись по производительности
Использовать дополнительные ресурсы программистов
Если в первую очередь его интересует экономия денег, тогда он отправляет
четырех программистов домой и его проект продвигается со скоростью двух соль-
ных разработчиков.
Если он заинтересован как можно быстрее выполнить проект, он не станет от-
сылать четырех программистов. Он воспользуется их резервными возможностями.
186
Глава 4
Прежде чем передать свои результаты DBA, менеджер заставит программи-
стов по нескольку раз их переделывать, показывая пользователям. Таким обра-
зом, они получат обратную связь, позволяющую изменить проектные решения не
после, а до того, как DBA выполнит свою работу.
Он также убеждает программистов раньше подключиться к процессу сбора
требований, чтобы они уже на ранних стадиях смогли показать промежуточные
результаты пользователям и получить обратную связь. Он их заставляет тратить
больше времени на графическое изображение своих проектных решений, чтобы
DBA мог легко их прочитать.
Менеджер знает, что вынуждает программистов работать дополнительно.
Он использует их резервную производительность.
На рис. 4.21 графически представлена вторая стратегия работы. Здесь вы
видите только одного сотрудника, занимающегося требованиями, который пере-
дает информацию одному Smalltalk-программисту, а тот передает свою работу
одному DBA. Две верхние кривые используются пять раз для пяти разработчиков
требований и пяти программистов.
На рис. 4.21 показано, что Smalltalk-программист приступает к работе сразу
же, как только разработчик требований может что-либо ему передать, но DBA не
начинает работать, пока программист почти полностью не завершит свою работу
и не добьется ее стабилизации.
Рис. 4.21. Критический пункт начинает работать в более высокой точке на кривой
завершенности и стабильности, чем некритические пункты.
Заметьте, что DBA завершает работу быстрее других. Это отражает тот
факт, что другие группы выполняют более значительные переработки и, следова-
тельно, медленнее достигают завершенности и стабильности. Это необходимо,
потому что четыре другие группы передают работу DBA. В сбалансированной си-
туации DBA доходит до завершения в пять раз быстрее, чем остальные группы
сотрудников.
Методологии
187
Люди, занимающиеся критической деятельностью, должны работать как
можно более эффективно и не могут себе позволить многочисленных перерабо-
ток. (Я говорю “многочисленные переработки”, поскольку в разработке ПО без
переработок обойтись нельзя, а цель состоит в сокращении объема перерабо-
ток.)
Принцип 7 имеет три следствия.
Следствие 1. Делайте все возможное, чтобы ускорить работы для крити-
ческого вида деятельности. Этот результат довольно очевиден, но люди часто
его не замечают.
Каждый проект имеет узкое место. В ходе проекта оно перемещается, но в
каждый момент это всегда один вид деятельности. В приведенном примере такой
деятельностью является работа DBA. Улучшить критическую деятельность мож-
но четырьмя способами. Принцип 7 обращается к четвертому из них.
1. Добиться, чтобы эту работу выполняли лучшие специалисты.
2. Добиться, чтобы эту работу выполняло большее число сотрудников.
3. Создать лучшую инструментальную базу для сотрудников, выполняю-
щих эту работу.
4. Обеспечить, чтобы работа, питающая эту деятельность, передавалась
в более завершенном и стабильном состоянии.
Следствие 2. Сотрудники, занимающиеся некритической деятельностью,
могут работать неэффективно, не нанося ущерба общей скорости выполнения
проекта! Это уже не так очевидно.
Конечно, люди могут работать неэффективно, устраивая долгие перекуры,
путешествуя по Интернету или проводя время у кондиционера. Это все не слиш-
ком интересно для проекта и создания методологий.
Более интересна идея о растрачивании эффективности в обмен на стабиль-
ность.
Люди, занимающиеся некритической деятельностью, могут потратить часть
своих дополнительных ресурсов, раньше начиная работать, раньше получая ре-
зультаты, выполняя больше переработок и делая это быстрее, выполняя таким
образом другую работу, помогающую сотруднику, который занимается критиче-
ской деятельностью.
Расходование дополнительных ресурсов на переработку существенно для
разработки ПО, поскольку из-за переработок программные проекты выполня-
ются так долго. Пользователи видят результаты и изменяют свои требования;
проектировщики видят свой алгоритм в действии и меняют проект; тестировщики
“ломают” программу; программисты переписывают код. В приведенном примере
все эти действия заставили бы DBA переделывать его работу.
Применив принцип 7 и график параллельной разработки (рис. 4.13) к задаче
с пятью Smalltalk-программистами и одним DBA, менеджер проекта может ре-
188
Глава 4
шить, что Smalltalk-программисты могут работать “неэффективно”, т.е. “выпол-
нять больше переработок, чем они могли бы делать в иной ситуации”, добиваясь,
чтобы их работа быстрее стала более стабильной. Это означает, что DBA, кото-
рому переработка обходится дороже, с самого начала будет получать более ста-
бильную информацию.
Принцип 7 предлагает стратегию, определяющую, когда и где параллельную
разработку нужно начинать раньше, а когда и где ее можно задержать. Большин-
ство проектов выполняются при заданной стоимости и с имеющимся в наличии
составом сотрудников. Принцип 7 помогает участникам команды отрегулировать
свою работу, чтобы наибольшее число сотрудников приносили пользу.
Принцип 7 применим в любом проекте, а не только в тех, которые не сбалан-
сированы в той же степени, как в примере. В каждом проекте есть критическая де-
ятельность. Даже когда узкое место перемещается, принцип 7 можно отнести к
новой конфигурации критического и некритических видов деятельности.
Следствие 3. Применение принципа потери эффективности приводит раз-
ные методологии к разным ситуациям, даже если все остальные принципы со-
блюдаются. Вот первая история, иллюстрирующая это следствие.
Проект Winifred и принцип 7
Проект Winifred напоминает приведенный выше пример. Именно на
этом проекте я учился применять данный принцип.
В середине проекта в нем участвовали около дюжины Smalltalk-npo-
граммистов, четыре программиста на COBOL и два DBA. Програм-
мисты, писавшие на Smalltalk, могли перерабатывать свои програм-
мы быстрее, чем кто-либо из остальных членов команды. Два DBA
были перегружены работой, как в истории из примера.
Мы организовали для Smalltalk-программистов очень тесное взаимо-
действие с разработчиками требований, и они могли приступать к
работе сразу же, как только для них появлялась исходная информа-
ция. Применяя осмотическое общение и обмен информацией лицом
к лицу вместо обмена документами, программисты изменяли свои
проектные решения, услышав от разработчиков требований новую
информацию.
DBA и программисты, работавшие на COBOL, начинали действовать
лишь после того, как программисты Smalltalk добивались "относите-
льно стабильных" проектных решений, прошедших рецензирование.
Использование этого принципа я описал как стратегию “золотой лихорадки”
в книге Surviving Object-Oriented Projects (Cockburn, 1998). В этой книге также
описывается использование стратегии “целостного разнообразия” (Holistic Di-
versity) и более тщательно исследуется проект Winifred.
Но вот и вторая история, с иным исходом.
Методологии
189
Проект eBucks.com и принцип 7
В компании eBucks.com было 15 разработчиков и 12 бизнес-экспертов.
У них накопилось отставание по шести дюжинам рабочих проектов.
Каждый день по нескольку раз программистов отвлекали от рабо-
ты, и поэтому движение вперед по ликвидации отставания было
медленным.
В данной ситуации использование стратегии "золотой лихорадки"
было неоправданным. У программистов не было резерва. На самом
деле программирование было узким местом.
В первую очередь мы предприняли несколько шагов, чтобы сокра-
тить действия, отвлекающие программистов от работы. С учетом
имеющегося отставания этого все еще было недостаточно.
Тогда мы решили, что для помощи программистам бизнес-эксперты
должны писать варианты использования, бизнес-правила и описания
данных.
Эта стратегия на первый взгляд кажется противоречащей основной идее на-
шей книги — максимальному развитию общения лицом к лицу. Однако в данной
ситуации программисты не могли хранить информацию в голове. Информация
должна была попадать к ним в “устойчивой” форме, чтобы они могли к ней обра-
щаться после разговоров.
После того как программисты справятся с отставанием, критическая деятель-
ность переместится и компания может посчитать уместным перейти к параллель-
ной разработке.
От того, что они предпримут, будет зависеть, где проявится следующее узкое
место.
Есть еще и третья история.
Проект Udall и принцип 7
Проект Udall, выполняемый большим количеством разработчиков,
застрял на больших и неработоспособных проектных решениях.
Четверо из старших разработчиков решили игнорировать всех оста-
льных и просто начали работу заново. Они постепенно включали в
свою закрытую рабочую группу новых людей, приглашая присоеди-
няться к ним лишь самых лучших специалистов.
Они рассуждали (как оказалось, совершенно верно), что два крити-
ческих вида деятельности придадут решениям проекта правильную
ориентацию и будут способствовать передаче информации от стар-
ших проектировщиков к другим.
Они решили, что смогут работать более эффективно, если не будут
тратить ключевые ресурсы проектирования на убеждение и обуче-
ние остальных сотрудников, а просто предоставят им заниматься лю-
бой другой работой, кроме программирования системы.
190
Глава 4
Это было наиболее удивительное и эффективное применение принципа по-
тери эффективности.
Во время беседы с одним из руководителей команды я спросил: “А как же
все остальные сотрудники? Что они делали?”
Руководитель команды ответил: “Мы позволили им делать все что угодно.
Некоторые ничего не делали, некоторые разрабатывали небольшие проекты, по-
вышая свою квалификацию. Это не имело значения, поскольку они не могли по-
мочь проекту больше, делая что-либо еще”.
Начатый заново проект оказался успешным. Он предсказал компании пре-
красное будущее.
Следствия принципов
Вышеназванные принципы работают вместе и помогают выбрать для данной зада-
чи подходящую численность команды, а для данной команды подходящую методо-
логию. Рассмотрим некоторые следствия сочетания этих принципов:
Следствие 1. Пополнение команды проекта новыми сотрудниками стоит
дорого. Иногда кажется, что люди, которые должны были бы это знать, ни о
чем таком не подозревают, поэтому имеет смысл рассмотреть это положение
еще раз.
Представьте себе 40 или 50 человек, работающих вместе. Для организации их
работы вы создаете несколько команд и добавляете совещания, менеджеров и сек-
ретарей.
Хотя менеджеры и секретари повышают производительность программиро-
вания отдельных разработчиков, их зарплата увеличивает затраты проекта. Кро-
ме того, появление этих людей увеличивает потребности в коммуникации, что
требует дополнительных элементов методологии и снижает производительность
группы в целом (рис. 4-22).
Рис, 4.22. Сокращение эффективности с ростом потребности в коммуникации (размера
методологии)
Методологии
191
Следствие 2. Численность команды возрастает большими скачками. Эф-
фекты от добавления людей и увеличения “тяжести” методологии объединяются,
поэтому увеличение численности на “несколько” человек не так эффективно, как
может показаться. В самом деле, мой опыт подсказывает, что для удвоения про-
изводительности группы может потребоваться квадратичное увеличение числа
сотрудников проекта! Вот одна история для иллюстрации.
Еще раз о мифическом человеко-месяце
Фред Брукс (Fred Brooks) в книге Mythical Man-Month пишет, что
возможен такой проект, который не смогут выполнить в срок десять
даже самых лучших специалистов в мире. В результате, пишет он,
может понадобиться от 200 до 300 человек.
Он объясняет, что для набора новых сотрудников может быть два
стимула. Во-первых, больше людей требуется, чтобы справиться с
коммуникацией в проекте. Во-вторых, нереально набрать 200 чело-
век, обладающих теми же достоинствами, что и предложенные де-
сять. Перегрузка коммуникации усугубляется уменьшением таланта.
Вот еще вторая, более современная история с аналогичным результатом.
От 6 до 24 программистов
Начиная один проект с фиксированной стоимостью, мы надеялись,
что его смогут выполнить шесть хороших программистов, пишущих
на Smalltalk.
Однако этого не получилось. В то время мы не сумели заполучить
шесть хороших Smalltalk-программистов. Еще более ухудшило поло-
жение то, что нам дали десять новичков для обучения и только двух
экспертов-программистов, которые должны были их учить и одно-
временно создавать код.
В ходе оценки проекта мы пришли к заключению, что нам потребу-
ется 24 программиста смешанной квалификации.
По мере продвижения работ над проектом в конце концов мы полу-
чили четырех экспертов и 20 других программистов с разным опы-
том. У нас стало, таким образом, 24 программиста.
Мы несколько раз пересматривали нашу оценку в ходе выполнения
проекта и по его завершении. Да, шести хороших Smalltalk-програм-
мистов было бы достаточно, а двенадцати и даже шестнадцати про-
граммистов с разным уровнем опыта не было достаточно.
Верный шаг заключался в переходе от шести хороших программи-
стов к 24 программистам с различными возможностями.
Следствие 3. Команды следует совершенствовать, а не расширять. Вот
общая задача: пусть у менеджера есть команда из десяти человек, сидящих ря-
192
Глава 4
дом и достигающих высоких темпов коммуникации с небольшими затратами
энергии.
Менеджеру требуется увеличить отдачу команды. У него есть два варианта:
добавить людей или сохранить численность и сделать что-либо другое внутри
команды.
Если менеджер увеличивает численность с десяти до пятнадцати человек, то
нагрузка и протяженность коммуникации, обучение, совещания и объем доку-
ментации должны возрасти. Значительная часть средств, потраченная на эту но-
вую группу, уйдет на накладные расходы, связанные с коммуникацией, и не
принесет роста отдачи.
Эта группа, вероятно, увеличится снова до 20 человек (что сделает еще тя-
желее груз коммуникации, но, по крайней мере, покажет улучшение в конечном
результате).
Вторая стратегия, поначалу менее очевидная, состоит в сохранении числен-
ности команды на уровне десяти человек (максимальное число людей, работу ко-
торых можно координировать естественным образом) и повышении уровня
участников команды.
Для того чтобы поднять уровень команды, менеджер может использовать не-
которые (или все) из следующих способов:
Послать сотрудников на курсы повышения квалификации
Разместить их плотнее, чтобы уменьшить затраты на коммуникацию
Способствовать повышению дружелюбия и улучшению командной работы
Заменить некоторых сотрудников более способными (и более высокоопла-
чиваемыми) специалистами
Время от времени повторяя эту стратегию, менеджер получит все более хо-
роших сотрудников, которые будут работать вместе все лучше и лучше.
Обратите внимание, что во втором сценарии нагрузка коммуникации остается
той же, в то время как команда становится более продуктивной. За повышение
вклада сотрудников организация может позволить себе платить им больше.
Она может даже удвоить их зарплату, считая, что эти десять человек заменяют
20! В этом есть смысл. Если оплата хорошая, при этом бюрократическое бремя
невелико и участники команды гордятся своими результатами, они с удовольстви-
ем будут работать на эту организацию, т.е. делать именно то, что ей от них нужно.
Меньше да лучше
Кент Аретт, исполнительный директор компании The Popcorn Factory,
выпускающей каталоги подарков, годами применяет вышеизложен-
ную стратегию. Он успешно пользовался ею в Фингерхате и Сирсе.
Когда он появился в Фингерхате, то обнаружил проблемы с мораль-
ным состоянием и текучестью кадров ("просто вращающаяся дверь
какая-то", как он это описывал). Приблизительно 80 человек в отде-
Методологии
193
ле информационных систем, который ему достался, занимались иск-
лючительно поддержкой старых приложений и не могли найти
времени для новых разработок.
Он сделал две вещи. Сократил штат примерно на 25%, оставив только
лучших людей, и поднял им зарплату. После этого их отдача возросла
достаточно, чтобы лишь пятнадцать человек справлялись с поддерж-
кой, а остальные могли разрабатывать новые приложения. В этот мо-
мент он еще больше поднял зарплату сотрудникам, которые
занимались поддержкой!
Однако более всего он гордился тем, что из этих программистов в бу-
дущем вышли несколько руководителей отделов.
Как вице-президент по эксплуатации в Сирсе, он за пять лет превра-
тил 800 млн. долларов ежегодных эксплуатационных потерь в 100
млн. долларов дохода. Он говорит, что ключевым для этого успеха
было одновременное сокращение и улучшение состава сотрудников.
Он оставил лишь 80 лучших разработчиков из 300 и в то же время
поднял их зарплату.
Он добавил: “Есть еще один момент: приукрашивайте, что видите. При-
украшивайте, принимайте на работу энтузиастов — и дело в шляпе".
Следствие 4. Разным методологиям нужны разные люди. На рис. 4.23 по-
казан способ оценки проектов для выбора подходящей методологии. Достоинство
изображенной на рисунке сетки в том, что она построена на довольно объектив-
ных показателях:
Приоритет - юридические обязательства
потерю ...)
Приоритет - производительность и толерантность'
Критичность
(дефекты вызывают 4 Г
Жизни
(L)
Дискреционных
средств
(D)
Невозместимых
средств
(Е)
Удобства
(С)
1-6 -20 -40 -100 -200 -500
Численность сотрудников ± 20 %
Рис. 4.23. Характеристика проекта на основе коммуникационной нагрузки, критичности
и приоритетов
194
Глава 4
Число координируемых сотрудников
Критичность системы
Приоритеты проекта
Вы можете просмотреть место разработки проекта, пересчитать сотрудников,
которых нужно координировать, узнать критичность системы и приоритеты проекта.
На этом рисунке обозначение в каждой клетке указывает характеристики про-
екта. Проект “С6” располагает шестью исполнителями и может вызвать потерю
удобства, проект ”D20" располагает 20 исполнителями и может привести к потере
дискреционных средств.
Используя эту сетку, обратите внимание на несколько моментов:
Нагрузка коммуникации повышается с ростом численности. В некоторых
точках управлять проектом по-старому становится невозможно: 6 человек
могут работать в одной комнате, 20 — в непосредственной близости, 40 —
на одном этаже, 100 — в одном здании. Механизмы координации проекта
небольшого размера уже не подходят для более крупных проектов.
Проект, ведущий к разорению компании или к потерям человеческих жиз-
ней, требует более тщательного контроля, чем проект, дефекты в котором
приводят всего лишь к потере удобства или дискреционных средств.
Проекты, где особое значение придается юридической ответственности,
потребуют больше внимания и мониторинга.
Вот как я однажды пользовался этой сеткой.
Изменение ячеек сетки в середине проекта
Проект из области банковской деятельности, который меня попросили
координировать в Центральном банке Норвегии, начинался с трех со-
трудников, делавших предыдущую систему. Я присвоил проекту тип D6
и планировал просто более или менее положиться на то, что програм-
мисты хорошо выполнят свою работу.
Приблизительно через месяц стало ясно, что мы обрабатываем боль-
шие суммы денег и, вероятно, должны быть более внимательны к
ошибкам, которые могли от нас ускользнуть. Я поменял рейтинг про-
екта на Е6, и неделю-другую мы провели за исправлением проекта в
том, что касалось отказоустойчивости и восстановления после сбоев.
После того как архитектор и ведущий программист ушли в отпуск, мы
приняли двух новых программистов и двух тестировщиков. Нас стало
семеро: двое в Лиллехаммере, остальные в Осло — двое на первом
этаже и по одному на втором, третьем и четвертом этажах (помните о
затратах на коммуникацию между этажами?) Оказалось, что эта систе-
ма разрабатывалась двумя компаниями, и наша команда координиро-
вала свою работу с группой из 35 разработчиков, находившихся в раз-
ных районах Осло и использовавших другую (каскадную) методологию.
Методологии
195
В этот момент сетка пригодилась. Я снова изменил классификацию
нашего проекта на Е20 (учтя сочетание численности с географиче-
ской распределенностью).
Учитывая принципы методологии, я не увеличил объемы бумажной
работы, но расширил персональное общение с использованием теле-
фонных переговоров и видеосвязи, а также персональное изучение
вопросов, затрагивающих результат проекта.
Характеристики сетки могут иметь противоположное применение — помочь
обсуждению ряда проектов, для которых выбрана конкретная методология.
Именно это я и делаю с семейством методологий Crystal в главе 6. Я строю
одну методологию, применимую для проектов из категории D6 (Crystal* Clear),
другую, подходящую для проектов из диапазона D20 (Crystal Yellow), еще одну
для проектов категории D40 (Crystal Orange) и т.д. Рассматривая методологии
таким образом, вы могли бы сказать, что Extreme Programming подходит для
проектов из категорий С4 и Е14.
Следствие 5. “Легкие” методологии лучше, пока хватает их возможностей.
Небольшая команда с “легкой” методологией иногда может решить ту же за-
дачу, что и более многочисленная команда с более “тяжелой” методологией. С точ-
ки зрения стоимости проекта решение задачи 10 сотрудниками в одной комнате
более эффективно, чем расширение штата.
Тем не менее в какой-то момент даже лучшие в мире десять специалистов не
сумеют вовремя выработать необходимое решение, и тогда численность команды
может радикально увеличиться. “Тяжесть” методологии также должна сущест-
венно возрасти (рис. 4.24).
Рис. 4.24. Небольшие методологии хороши, но их возможности ограничены.
196
Глава 4
Более крупные проекты требуют более “тяжелых” методологий, и от этого
факта спасения нет. Однако можно избежать использования “тяжелой” методо-
логии в небольшом проекте. Для определенного проекта и конкретной команды
вполне можно использовать как можно более “легкую” и гибкую методологию.
Методология быстрой разработки — это разумная цель, пока вы осознаете,
что для многочисленной команды она должна быть “тяжелее”, чем для неболь-
шой группы.
Следствие 6. В целях адаптации методологии следует “растягивать”. По-
смотрите на “легчайшую” методологию, в наибольшей степени опирающуюся на
общение “лицом клицу”, которая будет работать для некоторого проекта. Затем
растяните ее. Джим Хайсмит резюмирует это так: “Немного меньше, чем доста-
точно, лучше, чем немного больше, чем достаточно”.
У менеджера проекта с 50 сотрудниками и с потенциальной опасностью на-
несения “дорогостоящего” ущерба имеется два варианта выбора.
1. Он может выбрать методологию из более значительной категории (ска-
жем, Е100) и удалить из нее излишнюю “тяжесть”. Некоторых менедже-
ров привлекает такой подход, поскольку он дает им право похвастаться:
“Да, для нашего проекта пришлось воспользоваться методологией
Е100!”. Однако маловероятно, чтобы команда удалила все, что можно
удалить, и поэтому проект будет выполняться медленнее и обойдется до-
роже, чем требуется.
2. Он может выбрать методологию из меньшей категории (например,
D40) и адаптировать ее к проекту путем “растягивания”. Хотя в этом
случае менеджер не получит возможности хвастаться, но команда, на-
верное, добавит к проекту меньше ненужных элементов, и, как следст-
вие, проект выполнится быстрее и будет стоить дешевле.
Методология ХР сначала применялась для проектов типа D8. Со временем
нашлись способы добиться ее успешного использования для более многочислен-
ных команд. В результате теперь я ее рассматриваю для проектов типа Е14.
Другие принципы
Мы должны уметь открывать другие принципы.
Одна из наиболее интересных моделей, с которой я недавно столкнулся, —
это модель “оценки реального выбора” (Sullivan, 1999).
Рассматривая использование теории финансовых опционов в разработке
ПО, Салливен и его коллеги выдвигают на первый план “ценность информации”
(ЦИ) по сравнению с “ценностью гибкости” (ЦГ).
ЦИ имеет дело со следующим выбором: “Плати, чтобы узнать, или не
плати, если думаешь, что знаешь”. Понятие ЦИ применимо к ситуациям, в ко-
торых, заплатив больше, можно получить информацию раньше.
Методологии
197
Понятие ЦИ применяется для принятия решения о прототипах, которые
нужно построить для проекта.
ЦГ имеет дело с таким выбором: “Плати, чтобы не решать, или не пла-
ти, потому что достаточно уверен в правильности решения или потому,
что цена изменения решения невелика”. Понятие ЦГ используется в ситуаци-
ях, когда невозможно обнаружить информацию раньше.
Понятие ЦГ применяется для принятия решения об отношении к конкуриру-
ющим (потенциальным) стандартам, например к СОМ и CORBA.
Второе применение, которое Салливен с коллегами обсуждает в их статье,
заключается в оценке использования спирального процесса разработки. Они пи-
шут, что спиральная разработка дает возможность спрогнозировать будущее.
Если к концу первой итерации условия улучшаются, проект продолжается. Если
условия ухудшаются, работу над проектом можно прекратить.
Пока я не наблюдал, чтобы кто-то явно пытался использовать эти понятия,
но они, безусловно, хорошо подходят к идее о разработке ПО как кооперативной
игре с ограниченными ресурсами. Они могут послужить руководством для проек-
тировщика процесса и предоставить новый принцип создания методологий.
ХР под микроскопом
Extreme Programming(ХР) — это методология быстрой разработки, оченьхорошо
иллюстрирующая идеи данной книги. Она эффективна, хорошо документирована,
но вызывает массу споров. Таким образом, она представляет прекрасный пример
для исследования. Теперь у нас наконец-то появился достаточный набор понятий,
чтобы поместить ее под методологический микроскоп.
В области своей применимости ХР ценится очень высоко. При использова-
нии вне зоны наилучшего действия она (как и все другие методологии) требует
дополнительной адаптации.
Коротко об ХР
Об ХР имеет смысл рассказать очень коротко, хотя о ней накоплено достаточно
много информации (Beck, 2000, Jeffries, 2001, ХР URL).
Далее приведено изложение этой методологии (насколько возможно краткое)
в виде инструкций, которые можно давать по телефону или электронной почте.
Используйте от трех до десяти программистов. Договоритесь с одним или не-
сколькими заказчиками, чтобы они были на месте и обеспечивали текущую экс-
пертизу. Все работают в одной комнате или в смежных комнатах, желательно
вокруг установленных вместе компьютеров, которых вдвое меньше, чем про-
граммистов, с мониторами, повернутыми наружу из круга.
Разрабатывайте программы трехнедельными периодами, или итерациями.
На каждой итерации производится работающий протестированный код, готовый
сразу к использованию заказчиками. Собранная система переправляется к ко-
198
Глава 4
нечным пользователям в конце каждого периода выпуска версий, который может
занимать от двух до пяти итераций.
Единицей собираемых требований является “пользовательская история”,
описывающая функциональность с точки зрения пользователя и разработанная
за одну итерацию. Заказчики записывают истории для каждой итерации на про-
стых индексных карточках. Заказчики и программисты договариваются о планах
на следующую итерацию таким образом:
Программисты оценивают время для завершения работы с каждой кар-
точкой.
Заказчики расставляют приоритеты, изменяют и пересматривают при не-
обходимости область действия, чтобы самые ценные истории с наибольшей
вероятностью были приняты во внимание в выделенный период времени.
Для каждой задачи программисты пишут задания на висящих на стене плака-
тах или на белой доске, оценивая время, необходимое для каждого задания. Со
временем заказчики и программисты могут изменить приоритеты или область
действия заданий или историй.
Разработка истории начинается с ее обсуждения программистами и экспер-
том-заказчиком. Поскольку это обсуждение проходит в обязательном порядке,
текст, записанный на карточке этой истории, должен быть очень кратким, доста-
точным лишь для напоминания, о чем пойдет разговор. Понимание требований
растет благодаря этим разговорам и любым картинкам или документам, которые
участники сочтут необходимыми.
Программисты работают парами. Они следуют строгим стандартам кодиро-
вания, установленным ими в начале проекта. Они создают модульные тесты для
всего, что пишут, и добиваются, чтобы эти тесты выполнялись стопроцентно
каждый раз, когда они сдают свой код на обязательный контроль версий и в сис-
тему управления конфигурацией. Они наращивают разработку понемногу, по-
рциями продолжительностью от пятнадцати минут до нескольких часов,
интегрируя свой код несколько раз в день. В конце каждой такой интеграции они
добиваются, чтобы весь основной код прошел все модульные тесты.
В любое время любые два программиста, сидящие рядом, могут изменить
любую строку кода системы. На самом деле это их обязанность. Каждый раз, ког-
да два программиста обнаруживают секцию кода, которая кажется трудной для
понимания или чрезмерно сложной, они должны ее переработать, чтобы упрос-
тить и улучшить. Каждый раз общий проект должен поддерживаться как можно в
более простом состоянии, а код быть как можно более ясным. Эта постоянная
реорганизация становится возможной благодаря всестороннему модульному тес-
тированию на имеющихся тестовых комплектах. Она также возможна, поскольку
назначения пар программистов чередуются примерно раз в день, и поэтому зна-
ние об изменениях в структуре кода передается через группу благодаря измене-
нию партнерства.
Методологии
199
В то время как программисты работают, заказчики занимаются тремя веща-
ми: они посещают программистов, чтобы прояснять идеи, пишут приемочные те-
сты системы для прогона во время итерации и в ее конце и выбирают истории для
реализации в следующей итерации. Они могут участвовать в проекте полное ра-
бочее время или только часть времени.
Каждый день команда проводит оперативные совещания, на которых обсужда-
ется кто над чем работает, что продвигается хорошо, и в чем требуется помощь. На
этих совещаниях все стоят, чтобы не затягивать разговоры. В конце каждой итера-
ции проводится другое совещание, на котором оценивается, что было сделано хо-
рошо и над чем желательно поработать в следующий раз. Этот перечень
вывешивается, чтобы все могли его видеть во время следующей итерации.
ХР ценит четыре вещи: коммуникацию, простоту, тестирование и смелость,
что подразумевает смелость идти вперед и постоянно совершенствовать систему.
Один человек в команде назначается “наставником”. Вместе с участниками
команды он оценивает использование ими основных приемов: парного програм-
мирования и тестирования, ротации пар, поддержания простоты проектных ре-
шений, коммуникации и т.д.
Препарирование ХР
Команда ХР интенсивно использует осмотическое общение, общение лицом к лицу,
конвекционные потоки информации и излучатели информации на стенах.
Постоянная доступность экспертов означает, что путь от вопроса до ответа
невелик. Затраты времени и энергии на обнаружение необходимой порции ин-
формации низки, а скорость рассеивания информации высока.
Обратная связь возникает достаточно быстро. Заказчики получают ее в от-
ношении последствий реализации их требований, представленных в ходе сеанса
планирования. Через несколько дней они видят работающий код и могут соответ-
ственно скорректировать свои представления о том, что в действительности сле-
дует программировать. Программист немедленно получает поправки по коду,
который он вводит, потому что другой человек, сидящий рядом, наблюдает за
тем, что он вводит, и потому что для каждой функции, которую он пишет, имеют-
ся модульные тесты. Изменяя проект, программисты получают быструю обрат-
ную связь благодаря модульному и приемочному тестированию. Они получают
реакцию на процесс разработки каждые несколько недель благодаря итерацион-
ным циклам.
ХР использует общение — сильную сторону людей. Парная работа и скорая
ответная реакция компенсируют склонность людей к совершению ошибок.
ХР — методология с высокой дисциплиной. Она требует приверженности
строгому кодированию и стандартам проектирования, многочисленным комплек-
там модульных тестов, которые должны регулярно выполняться, качественному
приемочному тестированию, постоянной работе в парах, бдительности при под-
держании простоты проектных решений и постоянной реорганизации.
200
Глава 4
Эта дисциплина защищена двумя механизмами и представлена в трех ситуа-
циях.
Оказывается (к огромному удивлению очень многих), что люди любят рабо-
тать парами. Это дает им право гордиться своей работой, поскольку они добива-
ются большего за меньшее время с меньшим числом ошибок и обычно достигают
лучшего результата, чем в случае работы в одиночестве. Им это нравится. В ре-
зультате они это делают по собственному желанию. В парах они помогают друг
другу писать тесты и следовать стандартам кодирования. Таким образом, парное
программирование помогает проводить модульное тестирование непосредствен-
но на рабочем месте.
Наличие наставника способствует поддерживанию других видов дисциплины.
Отчеты от различных групп показали мне, что даже лучше, чем наставник, на
команду действует наличие нескольких практиков, больших энтузиастов ХР.
Дело в том, что наставник — это внешняя сила, в то время как полные энтузиаз-
ма коллеги создают равноправное давление — внутреннюю и, следовательно,
более мощную силу.
Ситуации, в которых ХР представляется в высшей степени дисциплинирую-
щей методологией, — это стандарты кодирования, приемочное тестирование и
реорганизация. Из всего перечисленного реорганизация, вероятно, будет остава-
ться наиболее сложным приемом, поскольку требует последовательности, энер-
гии, смелости, и никакие другие приемы в методологии ее не подкрепляют.
Есть несколько стандартов с высокой степенью формальности (низкой толе-
рантностью). Технические стандарты включают использование итераций. Проек-
тирование и программирование выполняются мелкими шагами от нескольких
часов до нескольких дней. Циклы планирования и разработки длятся от двух до
четырех дней; между выпусками версий проходит от одного до четырех месяцев.
Стандарт тестирования требует, чтобы все модульные тесты выполнялись сто-
процентно для всего сданного кода. Другой стандарт утверждает, что команда
должна размещаться в одном помещении, и настоятельно рекомендует организо-
вать размещение по принципу “пещеры и общая территория” (Auer, 2002).
ХР включает набор приемов и методик, которые команде нужно освоить:
игра планирования, ежедневное оперативное совещание, реорганизация и опе-
режающая разработка тестов.
ХР предназначена для небольших компактных команд, нацеленных на полу-
чение как можно более высокого качества и продуктивности. Методология до-
стигает этого посредством насыщенной неформальной коммуникации, придания
на персональном уровне особого значения умению и навыкам, дисциплине и по-
ниманию, сводя к минимуму все промежуточные рабочие продукты.
Адаптация ХР
Две особенности ХР вызывают дискуссии: отсутствие документирования и ограни-
ченность сферы ее применения небольшими командами.
Методологии
201
Отсутствие документирования
Мы можем исследовать вопрос документирования в терминах кооперативной
игры. ХР стремится к успеху в главной цели — в производстве и поставке ПО.
Эта методология намеревается добиться успеха и во вспомогательной цели,
в подготовке к следующей игре, единственно благодаря неформальным знаниям,
накопленным командой, выполнявшей проект.
Знание, связывающее группу с проектом, невозможно выразить словами:
это сумма знаний всех людей, составляющих команду. Это знание передается че-
рез осмотическое общение, ротацию пар программистов, ясный, простой код и
исчерпывающие модульные тесты. Сотрудники, присоединяющиеся к команде,
приобретают неформальное знание от опытных специалистов в парном програм-
мировании с ротацией.
Конечно, внимание к неформальному знанию полезно, но спонсоры иногда
хотят, кроме работающей системы, получить еще и другие конечные продукты.
Им могут потребоваться руководства по эксплуатации или техническая докумен-
тация, описывающая проект системы. Даже если заказчикам этого не нужно, ру-
ководство организации, наверное, вправе защититься от возможного
исчезновения неформального знания команды.
Вообще-то маловероятно, что вся команда оставит работу одновременно, одна-
ко после завершения основного периода разработки проекта сокращение ее числен-
ности вполне возможно. В этот момент неформальному знанию грозит опасность:
если несколько человек уйдут один за другим, у новых сотрудников не будет доста-
точно времени, чтобы впитать в достаточной мере детали проекта. И проект окажет-
ся без документации и без неформального знания.
Однако ХР имеет средство, чтобы справиться с этой ситуацией. Оно называ-
ется игрой планирования. Просто оказалось, что до настоящего времени ХР-про-
екты не пользовались игрой планирования в этих целях.
В игре планирования спонсоры могут писать на карточках истории, требую-
щие вместо новых программных возможностей разработать документацию. В ходе
игры планирования разработчики оценивают время, которое понадобится для на-
писания документации, а заказчики устанавливают для этих историй приоритеты
относительно определения новых функциональных возможностей.
Используя игру планирования таким образом, спонсоры могут, по существу,
разыгрывать две конкурирующие игры: быстрое создание ПО и защиту знания,
которым обладает группа.
Вышеприведенное обсуждение является чисто гипотетическим. Я не видел,
чтобы такой прием где-то использовался. Причина, по-видимому, заключается в
том — и это источник опасности для всей схемы, — что заказчики новой функ-
циональности очень заинтересованы в текущем проекте и мало интересуются бу-
дущими возможными проектами. Иными словами, у них отсутствует
ответственность в перспективе, которая позволила бы им должным образом сба-
лансировать приоритеты новой функциональности и документации. Разрешить
эту проблему, вероятно, будет непросто.
202
Глава 4
Команда ХР может рассмотреть менее общие и менее дорогостоящие пути до-
кументирования проекта системы, например видеодокументирование (см. главу 3).
«
Ограничение численности команд
Многие восклицают: “ХР не масштабируется!”
В таком случае вернитесь к рисункам, характеризующим зависимость чис-
ленности команды от размера задачи.
Хорошо структурированная команда из десяти программистов, используя
ХР, может решить более обширную задачу, чем команда из 30 человек, использу-
ющая более серьезную методологию. На самом деле в первом официально изве-
стном ХР-проекте команда из восьми человек за один год произвела продукт,
который не смогла создать в предыдущем году команда из 26 человек. Поэтому
отдавайте себе отчет в том, что в действительности означает утверждение “ХР не
масштабируется”. ХР прекрасно масштабируется по размеру задачи (до ее пре-
дела), но в то же время она не масштабируется по численности команды.
Методология ХР была продемонстрирована на проектах, в которых участ-
вовало до 12 программистов. Она может вызвать проблемы в более много-
численных командах вследствие зависимости от неформального знания.
Всестороннее неформальное знание сложно построить без хорошего осмо-
тического общения, а оно затруднительно, если вся команда не может удоб-
но разместиться в одной комнате. Более многочисленным командам,
решившим попробовать ХР, придется отрегулировать командные структу-
ры, интерфейсы и использование документации так, чтобы приноровиться к
необходимости значительной координации более крупной группы и к более
тонким каналам коммуникации.
Оставляю это как упражнение для изобретательного практика, желающего
поэкспериментировать с модификациями ХР.
Зачем вообще нужна методология
Поскольку методологии вызывают столько споров и разочарований по всему миру,
здесь уместно снова рассмотреть причины, побуждающие тратить так много энер-
гии на методологии вообще.
К чему обращена методология
Методология обращается к способам нашей совместной работы. По существу, для
нее можно найти несколько применений.
/. Знакомство новых сотрудников с процессом
“Привет, и как же мы здесь работаем?” — это естественный вопрос, задаваемый
новыми участниками команды. Полезно иметь в наличии что-то, благодаря чему
они могли бы понять свое место в организации.
Методологии
203
Методология в ящике стола
В моем первом проекте, связанном с аппаратурой, руководитель
команды сказал мне:
Мы рисуем логические элементы и интегральные схемы на этих ли-
стах бумаги размера D, название ставим внизу слева. Мы пользуем-
ся только симметричными тактовыми генераторами, запускаемыми
на нарастающем фронте импульсов. Наши схемы мы складываем в
кабинете чертежного отдела, во втором ящике сверху. Но все же,
прежде чем ты что-то сделаешь, дай мне знать, и мы запланируем
рецензирование проекта...”
Даже опытным сотрудникам, пришедшим в проект, нужно узнать, как дейст-
вовать в выполняющемся процессе.
2. Замена сотрудников
Хотя замена сотрудников не похожа на замену оборудования, тем не менее их часто
приходится заменять.
Методология в работе
Одного моего коллегу наняла не известная ему компания-подрядчик
для выполнения некоторой неизвестной работы в неизвестной облас-
ти для неизвестного клиента.
Руководитель работ по договору два дня просидел с ним, делая об-
зор методологии этой компании: кто что производит, какую структу-
ру имеют рабочие продукты, какие нужны стандарты, каковы
должны быть его приоритеты, с кем он должен переговорить.
Я считаю это впечатляющим примером использования методологии. В резуль-
тате мой коллега войдет в проект и приступит к работе менее чем через четыре
часа, даже если работа в такой значительной мере ему неизвестна. Компании-по-
дрядчики в наибольшей степени пользуются этим аспектом методологий.
3. Очерчивание круга обязанностей
Методология определяет, что не относится к непосредственным обязанностям со-
трудника. Так, ХР констатирует, что решения о приоритете истории принимает не
программист, а заказчик; количественная оценка проектных решений выполняет-
ся не заказчиками, а программистами.
4. Привлечение спонсоров
Эта сила движет составлением толстых руководств по методологиям.
Рассмотрим две компании, предлагающие выполнить для вас работу. Первая
заявляет: “Мы тщательно все обдумали, и наш процесс много раз нами прове-
рен. Документация на него находится в этих коробках”.
204
Глава 4
Вторая компания утверждает: “Мы садимся рядом и обмениваемся замечани-
ями, ничего не записывая. Нам и не нужно записывать нашу методологию, в част-
ности потому, что все мы люди ответственные”.
Которой из них вы поручите заказ?
Естественно предположить, что более “тяжелая” и более точно описанная
методология “надежнее”. Это немаловажный фактор при заключении договоров,
даже если используемый для выполнения задания процесс значительно отличает-
ся от того, который описан в руководствах.
5. Наглядная демонстрация продвижения
Вышеописанное назначение методологии позволяет исполнителям показать спон-
сорам свою работу.
В методологии, которую освоил один мой коллега, ключевым было создание че-
го-либо ощутимого каждый день, чтобы спонсоры знали, что “дело продвигается”.
Упражнение для читателя: обдумав заново ХР в этом свете, спросите себя,
что могла бы каждый день показывать ХР-команда для демонстрации спонсорам
ощутимого продвижения.
6. Программа обучения
После того как методология предложит технологии и стандарты, которые должны
использоваться командой, можно найти или создать курсы обучения, позволяю-
щие повысить квалификацию в отношении этих технологий и стандартов.
Например, в соответствии с должностными обязанностями сотрудники на-
правляются приобретать навыки в написании вариантов использования, прове-
дении помогающих в работе совещаний, в семантическом моделировании,
программировании и использовании различных инструментов.
Сотрудники могут изучать стандарты, которые будут использоваться в про-
екте. Возможно создание учебного класса по тому.подмножеству UML, которое
организация предполагает применять, например для моделирования систем реа-
льного времени.
Как оценить методологию
В свете всего вышеизложенного как можно оценить методологию?
В первую очередь вы должны выяснить, откуда взялась эта методология и в ка-
кую игру вы играете. Затем, на основании полученных ответов, вы оцениваете мето-
дологию по следующим характеристикам:
Как быстро можно заменить или обучить сотрудников?
Как велико ее влияние на процесс продажи?
Насколько большую свободу дает она команде (или насколько
ограничивает)?
Методологии
205
Как быстро она позволяет людям реагировать на изменившуюся ситуацию?
Насколько хорошо она защищает вашу организацию от судебных исков
и другого ущерба?
Несомненно, вы заметили, что принципы, представленные в этой главе, ори-
ентированы на создание методологий, для которых приоритетны продуктивность
и способность реагировать на перемены.
В качестве упражнения для другого автора методологии я предлагаю обозна-
чить принципы, способствующие росту числа продаж, взаимозаменяемости со-
трудников и защищенности от судебных исков.
Что дальше?
Никакое единственное определение методологии, вероятно, не подойдет ко всем
проектам. Даже не думайте, что Rational Unified Process, просто Unified Process
или какая-то другая методология окажется идеальной для вашего проекта. Если вы
будете скрупулезно следовать методологии, вы получите процесс, подходящий для
некоего существующего в мире проекта, но, вероятно, это будет не ваш проект.
Оцените, насколько семь принципов создания методологии соотносятся с ва-
шим проектом:
Выясните, в чем ваша команда может выиграть при использовании более
теплых каналов общения и где нужны более холодные каналы.
Определите критические виды деятельности в вашем проекте:
— Отслеживайте их изменения.
— Придумайте способы использования излишних возможностей
какой-либо другой группы, чтобы рационализировать работу,
являющуюся узким местом, или сократить неопределенность.
Сократите потребность во внутренних конечных продуктах в вашем проекте:
— Организуйте между разработчиками каналы коммуникации с
высокой пропускной способностью, благоприятные возможности
для быстрой обратной связи, и вы обнаружите, что некоторые
“долговые обязательства” на самом деле больше не нужны.
— Найдите критические виды деятельности и посмотрите, можете ли
вы увеличить производительность в узком месте за счет снижения
эффективности другой работы.
Найдите место, в котором “облегчение” методологии могло бы действите-
льно причинить ущерб. Подумайте об альтернативе.
Пересмотрите перечень целей методологии. Оцените цель методологии ва-
шей группы, н зятем спатнееи^е ее .«ффектиинасггь р »тпй целью,
206
Глава 4
Потренируйтесь в именовании области действия и элементов вашей мето-
дологии и других методологий. Исследуйте степень их отличия, связанного с
разными областями действия и разными приоритетами.
Посмотрите на разные методологии, используемые в разных проектах,
и оцените их, ориентируясь на размеры проектов.
Поэкспериментируйте с различными размерами задач и размерами
проектов.
Можете ли вы вспомнить проект, в котором участвовало больше человек,
чем было нужно?
Можете ли вы вспомнить сложную задачу, оказавшуюся простой после
применения какой-то особой точки зрения?
Для читателей уровня 2:
Добавьте эти идеи в ваш интеллектуальный багаж.
Разберитесь, где их можно применить, адаптировать или отказаться от них.
Для читателей уровня 3:
Попробуйте объяснить эти идеи кому-либо другому.
Глава 5
Быстрота и адаптируемость
Теперь все части мозаики на месте. К настоящему моменту мы рассмотрели:
Разработку ПО как кооперативную игру изобретения и коммуникации
Людей, отличающихся между собой, но умеющих ориентироваться и прояв-
лять инициативу, умеющих общаться, особенно неформально, лицом к лицу
Методологию как набор соглашений, принятых командой, и разные согла-
шения, подходящие разным видам проектов
“Легкие” методологии, позволяющие быстрее произвести продукт, кото-
рые должны “утяжеляться” вместе с разрастанием команды
Проекты как уникальные экосистемы и потребность в методологии, соот-
ветствующей экосистеме проекта
Все части аккуратно совмещены, вот только остается вопрос: какая “лег-
кость” правильна для любого проекта и как нам ее добиться для нашего
проекта?
В разделе “Легкая, но достаточная” рассматривается, какая “легкость” пра-
вильна для любого проекта, и, в частности, что для методологии значит — быть
слишком “легкой”. Нужно сбалансировать “легкость” с достаточностью.
В разделе “Быстрота” рассматривается значимость отдельных “зон наиболь-
шего благоприятствования” в проекте: совместного размещения, близости к по-
льзователю, опытных разработчиков и т.д. Если проект отодвигается дальше от
этих “зон”, то должны применяться менее “быстрые” механизмы. В частности,
виртуальные команды лежат далеко от них, и поэтому сделать распределенную
разработку быстрой сложнее.
В разделе “Добиться адаптируемости” описывается методика, позволяющая
довольно быстро, с пользой для проекта создать и развить “легкую”, но достаточ-
ную, индивидуальную для проекта методологию. Основная идея заключается в том,
208
Глава 5
чтобы каждые несколько недель анализировать, что работает хорошо, а что следу-
ет изменить.
Легкая, но достаточная
До сих пор теория, кажется, заявляет, что для связывания воедино огромного объ-
ема информации, порожденного внутри проекта, мы должны поддерживать глав-
ным образом устную традицию.
Здравый смысл подсказывает, что одной устной традиции недостаточно.
Поиски документации
Один программист рассказал, что в его компании переписали основ-
ной в то время продукт, поскольку не было документации, не оста-
лось людей, знающих, как была построена система, и в компании
просто не смогли внести в продукт очередные изменения. Он выра-
зил надежду, что на этот раз после проекта документация останется.
Другой человек сообщил о трех проектах, каждый из которых стро-
ился на базе предыдущего. Все три проекта разрабатывались в раз-
ных местах. Они не могли работать, опираясь только на устную
информацию.
Имеющаяся информация может обладать небольшой “устойчивостью”.
Пора мысленно вернуться к принципу кооперативной игры. Он гласит: первона-
чальная цель состоит в производстве и поставке ПО, вспомогательная цель за-
ключается в подготовке к следующей игре.
Достижение основной цели понятно: если вы не поставите продукт,
то не будет иметь значения, как безупречно вы подготовились к следую-
щей игре.
Если, с другой стороны, вы поставите ПО и плохо подготовитесь к следую-
щей игре, вы подвергнете ее опасности.
Эти два вида деятельности конкурируют между собой. Достижение равнове-
сия между ними опирается на два вида искусства.
Первое заключается в том, чтобы правильно распределить ресурсы между
двумя целями. В идеале разработку документации откладывают до последнего, а
затем делают ее как можно более краткой. Избыточная документация, подготов-
ленная слишком рано, задержит поставку ПО. Если же слишком краткая доку-
ментация разрабатывается слишком поздно, то сотрудник, который знает что-то,
необходимое для следующего проекта, может уже исчезнуть.
Второе искусство состоит в том, чтобы определить, какую часть информации
можно доверить закреплению в устной традиции группы и какую — зафиксиро-
вать в архивной документации. Вспомните, что после некоторого момента не
имеет значения, полны ли модели и другая документация, корректно ли они отра-
жают “реальный” мир (каким бы он ни был) и соответствуют ли текущей версии
Быстрота и адаптируемость
209
кода. Имеет значение только одно: окажется ли документация полезной для кон-
кретных потребностей получивших ее людей.
Правильный объем документации — это точно такой объем, который нужен
получателю документации, чтобы суметь сделать следующий ход в игре. Любые уси-
лия, направленные на достижение полноты, правильности и актуальности с превы-
шением этого объема, — пустая трата денег.
Обычно специалисты, с которыми я беседовал об удачных проектах, счита-
ли, что достигли успеха “несмотря на очевидную неполноту документов и не-
брежный процесс” (это они говорят, а не я). Однако в свете наших настоящих
знаний можно предположить, что они преуспели именно потому, что был сделан
правильный выбор и работа была остановлена сразу же по достижении достаточ-
ности и прежде, чем доход стал уменьшаться. Они сделали адекватную докумен-
тацию и не стали доводить ее до совершенства.
Адекватная документация — это замечательно, если команда участвует
в гонке, чтобы успеть к конечной цели, и испытывает недостаток в ресурсах.
Вспомним программиста, который сказал:
“Когда я начал создавать варианты использования и объектные моде-
ли, мне было ясно, что эта работа приносит какую-то пользу. Но в не-
который момент она перестает быть полезной, а становится нудной и
пустой тратой сил. Я не могу определить момент прохождения этой
точки и никогда не слышал, чтобы он где-то рассматривался. Это разо-
чаровывает, поскольку полезная деятельность превращается в непро-
изводительную работу”.
Мы ищем эту точку, ту, за которой полезная работа превращается в расто-
чительную. Это второе искусство.
Едва достаточная методология
Не думаю, что нужно приводить примеры слишком “тяжелых” или слишком “лег-
ких” методологий. Почти все их видели или наслышаны о них.
С другой стороны, “чуть-чуть чересчур легкие” методологии отыскать труд-
но, хотя они очень информативны. Эти методологии позволяют понять, что зна-
чит “едва достаточная” методология.
Две истории о таких проектах были представлены в книге раньше: в разделах
“Абсолютно никакого документирования” главы 1 и “Устойчивые” мысли на сте-
не” главы 3. В каждой из них в общем-то хорошо поставленный проект в важней-
ший момент опустился ниже уровня достаточности.
Абсолютно никакого документирования
(пересказ)
Эта команда следовала всем приемам ХР и периодически поставляла
ПО восприимчивому заказчику. Через несколько лет руководители
210
Глава 5
фирм-спонсоров притормозили и в конечном счете остановили но-
вые разработки.
После того как участники команды разошлись, не осталось ни архив-
ной документации по системе, ни команды специалистов, хорошо
знакомых с ее структурой. Когда-то достаточной устной культуры
стало не хватать.
В этой истории команда достигла первой цели игры, поставляя работающее
ПО, но провалилась в подготовке следующей игры, в поддержке и развитии.
Используя против меня мою же собственную логику, кто-то может возра-
зить, что документация была точно и идеально достаточна для целей компании:
проект закрыли, его так и не запустили заново, и поэтому правильный минималь-
ный объем документации был нулевым!
Однако, рассматривая “программирование как построение теорий” Наура,
можно заметить, что в ходе создания ПО участники команды успешно воздвигли
собственную “теорию”, но для следующей команды оставили недостаточно путей
извлечения пользы из вынесенных ими уроков.
"Устойчивые" мысли на стене
(пересказ)
Аналитики не могли мысленно охватить предметную область, насто-
лько сложной она была. Однако они только что переключились с
"тяжелого" процесса на ХР и считали, что им запрещено заниматься
документированием.
По мере того как проходили месяцы, им становилось все труднее
решать, что разрабатывать дальше, и определять последствия своих
решений. В своей части игры они действовали ниже границы доста-
точности. На самом деле, чтобы проект заработал, им требовалось
больше документации.
В конце концов они разобрались в ситуации и начали изобретать
приспособления для хранения информации, которая помогла их об-
щению стать достаточным.
Мы должны понять, что “недостаточность” заключена не в методологии, а в
адаптации методологии к проекту как экосистеме. То, что едва достаточно для од-
ной команды, может быть чрезмерно достаточным или недостаточным для другой.
Недостаточность возникает, когда одни участники команды общаются с другими
не настолько хорошо, чтобы те могли выполнить свою работу.
Идеальный объем, “едва достаточный”, колеблется в зависимости от време-
ни и места внутри одного проекта. Та же самая методология может быть чрез-
мерно достаточной в один момент и недостаточной в другой.
Это второе искусство, упомянутое выше, находит “едва достаточную” точку и
щат/жчвает ее снова, когда она перемещается.
Быстрота и адаптируемость
211
Рекомендации по документированию
Вот мы и пришли к набору рекомендаций:
Не просите, чтобы требования были идеальными, проектная документация
соответствовала фактическому коду, а план проекта — его состоянию.
Вместо этого настаивайте, чтобы специалисты по сбору требований фикси-
ровали лишь то, что достаточно для общения с проектировщиками. Попро-
сите их по возможности заменить ввод текстов более быстрыми средствами
общения, в том числе личными посещениями или короткими видеоклипами.
Если проектированием у вас занимаются только высококвалифицирован-
ные специалисты, сидящие близко друг от друга, попросите их обойтись без
иной проектной документации, кроме набросков на белых досках, фиксиру-
емых на фотопленке или с помощью принтеров.
Помните, что после этой команды проектировщиков придут другие люди,
которым, несомненно, понадобится больше проектной документации.
Вместо разработки документации в рамках последовательного процесса
разработки проекта запустите ее как параллельный и конкурирующий по
ресурсам поток проекта.
Будьте более изобретательны в выборе путей адекватного достижения обе-
их целей, уклоняясь от непрактичного стремления к совершенству.
Найдите (применяя гиперболизированные эпитеты) наилегчайшую, наибо-
лее небрежную возможную методологию для своей ситуации. Обеспечьте
такую ее точность, чтобы коммуникация была абсолютно достаточной.
Быстрота
Быть быстрым — значит быть эффективным и маневренным. Быстрый процесс —
и легкий, и достаточный одновременно. Легкость — средство сохранения манев-
ренности. Достаточность нужна, чтобы оставаться в игре.
Об использовании “быстрых” методологий не спрашивают: “Можно ли в
этой ситуации использовать ’’быструю" методологию?" Задают другой вопрос:
“Как нам сохранить быстроту в этой ситуации?”
Команда из 40 человек не будет работать так же быстро, как разместившаяся
в одной комнате группа из шести специалистов. Однако каждая команда может до-
биться максимального использования принципов методологии быстрой разработки
и работать настолько легко и ускоренно, насколько позволяют обстоятельства.
Команда из 40 человек будет применять более “тяжелую” методологию, а команда
из шести человек — более “легкую”. Каждая команда сконцентрируется на ком-
муникации, сообществе, частых победах и обратной связи.
212
Глава 5
Если они станут обращать на это внимание, они будут периодически раз-
мышлять о соответствии методологии их экосистеме и следить за перемещением
точки, в которой методология “едва достаточна”.
Наиболее эффективные участки
Чтобы добиться быстроты, в числе прочего нужно распознать эффективные уча-
сткидля результативной разработки ПО и насколько возможно приблизить про-
ект к ним.
Команда, которая сможет организовать высадку на любом из этих эффектив-
ных участков, начинает пользоваться преимуществами некоего особо действенного
механизма. Пока команде не удается оказаться на каких-либо из этих эффектив-
ных участков, она должна использовать менее результативные механизмы. Она
должна творчески искать пути попадания на эффективные участки и бороться за
использование этих путей.
Существует пять наиболее эффективных участков:
От двух до восьми человек в одной комнате
На этом эффективном участке информация движется наиболее быстро.
Сотрудники задают друг другу вопросы, даже не повышая голоса. Они знают,
когда их коллеги готовы ответить на вопросы. Они прослушивают имеющие от-
ношение к делу разговоры, не прерывая своей работы. Они хранят идеи по про-
ектированию и планы проекта на доске у всех на виду.
Мне неоднократно говорили, что, хотя такая среда может быть шумной, наи-
более эффективные проекты выполнялись небольшой командой, расположив-
шейся в одной комнате.
Когда вы покидаете этот эффективный участок, затраты на перемещение ин-
формации возрастают очень быстро. Каждая дверь, каждый угол и лифт сущест-
венно увеличивают эти затраты.
В главе 3 я рассказал об одной команде, не сумевшей расположиться на этом
эффективном участке. Они использовали на своих рабочих станциях web-камеры,
чтобы в каком-то смысле присутствовать в одной комнате. Они применяли панели
для переговоров, чтобы получать ответы на многочисленные мелкие, постоянно
возникающие вопросы. В этой команде творчески подошли к имитации эффектив-
ного участка в совершенно “неэффективной” ситуации.
Собственные эксперты-пользователи
Постоянное наличие доступного эксперта-пользователя означает, что время обрат-
ной связи от возникшего в воображении решения до его оценки так коротко, как то-
лько возможно; часто оно исчисляется минутами и не превышает нескольких часов.
Такая быстрая обратная связь означает, что команда разработки получает
более глубокое понимание потребностей и привычек пользователей и, размыш-
Быстрота и адаптируемость
213
ляя о новых идеях, делает меньше ошибок. Сотрудники пробуют большее число
идей, что способствует улучшению конечного продукта. Благодаря хорошему со-
трудничеству программисты тестируют идеи экспертов-пользователей и высту-
пают с контрпредложениями. Все это углубляет представление заказчиков о том,
как должна выглядеть новая система.
Отсутствие этого эффективного участка обойдется снижением вероятности
реализации действительно полезного продукта и значительным увеличением за-
трат на выполнение всех экспериментов.
Существует много альтернативных, хотя и менее действенных механизмов,
которые вы сможете выбрать, если не сумеете обосноваться на этом эффектив-
ном участке. За последние годы они были хорошо описаны: еженедельные сове-
щания-интервью с пользователями, этнографическое изучение сообщества
пользователей, исследования, группы альфа-тестирования. Конечно, найдутся и
другие.
Отсутствие этого эффективного участка не освобождает от необходимости
получить хорошую обратную связь с пользователями. Просто это значит, что
придется затратить больше усилий.
Итерации продолжительностью в один месяц
Ничем нельзя заменить быструю обратную связь как в отношении продукта, так и
самого процесса разработки. Обратная связь идеально обеспечивается в итераци-
онной разработке. Короткие итерации помогают обеспечить быструю корректи-
ровку требований и самого процесса. Вопрос в том, насколько долгими они
должны быть.
Правильные ответы различны, но опрошенные мной команды голосовали за
срок от одного до трех месяцев, с возможным сокращением до двух недель и воз-
можным расширением до четырех месяцев.
Кажется, люди способны сконцентрировать свои усилия приблизительно на
три месяца и ненамного дольше. Мне говорили, что при более долгих периодах
люди склонны отвлекаться, терять интенсивность работы и напористость. Кроме
того, итерации предоставляют команде возможность вносить корректировку в
процесс. Чем дольше итерация, тем дальше отстоят друг от друга точки коррек-
тировки.
Если бы это соображение было единственным, то идеальный период мог бы
составлять одну неделю. Однако нужно учитывать затраты на внедрение продукта
в конце итерации.
Этот эффективный участок я определяю приблизительно в один месяц, но
наблюдал успешное использование двух- и трехмесячных итераций.
Если команда не может по каким-то причинам поставлять продукт конечно-
му пользователю каждые несколько месяцев, она должна в этот период подгото-
вить полностью законченный продукт с готовностью к его поставке (поскольку
заказчик внезапно может потребовать его поставить). Суть такой организации
214
Глава 5
работы заключается в том, чтобы пробовать все части процесса разработки и си
вершенствовать все части процесса каждые несколько месяцев.
Полностью автоматизированное регрессионное тестирование
Полностью автоматизированное регрессионное тестирование (модульные тесты,
функциональные тесты или те и другие) предоставляет два преимущества:
Разработчики могут модифицировать код и заново его протестировать на-
жатием кнопки. Специалисты, имеющие такие тесты, сообщают, что они
свободно заменяют и усовершенствуют громоздкие модули, зная, что тесты
не позволят им внести неуловимые ошибки.
Специалисты сообщают, что, когда у них есть процедура регрессионного
тестирования, они лучше отдыхают за выходные. Они запускают тесты по
понедельникам и могут узнать, изменил ли кто-либо их систему, не поста-
вив их в известность.
Иными словами, автоматизированное регрессионное тестирование улучшает
не только проект системы, но и качество жизни самих программистов.
Для некоторых частей системы (и некоторых систем) трудно создать автома-
тизированные тесты.
Одна из таких частей — графический пользовательский интерфейс. Опыт-
ные разработчики это знают и прилагают особые усилия, чтобы минимизировать
части системы, не подчиняющиеся автоматизированному регрессионному тести-
рованию.
Когда сама система не имеет автоматизированных регрессионных тестов,
опытные программисты находят способы создать автоматизированные тесты для
их собственной части системы.
Опытные разработчики
В идеальной ситуации на эффективном участке команда состоит только из опытных
разработчиков. Такие известные мне команды сообщают о совершенно иных и луч-
ших результатах по сравнению со смешанной командой.
Поскольку хорошие, опытные специалисты могут работать в 2-10 раз эф-
фективнее своих коллег, то при наличии в команде только опытных разработчи-
ков ее численность можно радикально сократить.
В проекте Winifred как до начала, так и после завершения работ мы оценива-
ли, что шесть квалифицированных Smalltalk-программистов могли бы разрабо-
тать систему, уложившись в установленные для проекта временные рамки. Не
имея в то время возможности получить шесть хороших программистов, мы испо-
льзовали 24 человека. Четыре опытных программиста построили значительную
часть наиболее сложных элементов системы и, кроме того, посвятили много вре-
мени помощи неопытным программистам.
Быстрота и адаптируемость
215
Если вы не можете приземлиться на этом эффективном участке, попробуйте
пригласить на полставки или в штат инструктора или наставника, чтобы с его по-
мощью повысить квалификацию неопытных сотрудников.
Проблемы с виртуальными командами
Эвфемизм “виртуальные” означает “не сидящие вместе”. Этим популярным в на-
стоящее время словом спонсоры проекта оправдывают установление чудовищных
барьеров для общения внутри своих команд.
Мы видели убытки, которые терпит проект, из-за того что участники коман-
ды сидят порознь. Скорость разработки связана с временем и затратами энергии
на передачу идеи; затраты на передачу существенно повышаются с увеличением
расстояния между людьми, а важный незаданный вопрос приводит к значитель-
ным затратам из-за упущенных возможностей. Разделить команду на части —
это просто напрашиваться на дополнительные затраты.
Я группирую географически распределенные группы в три категории, из ко-
торых некоторые наносят больший ущерб, чем другие. Для этих категорий я ис-
пользую термины многоузловая (multisite), офшорная (offshore) и распре-
деленная (distributed) разработка.
Многоузловая разработка
Этот вид разработки связан с многочисленной командой, работающей в относите-
льно немногих местах, когда каждое место содержит полную группу, разрабатыва-
ющую подсистему, и подсистемы относительно независимы.
Многоузловая разработка успешно выполнялась в течение десятилетий.
Для многоузловой разработки важно иметь укомплектованные компетентные
команды в каждом месте и гарантировать, чтобы руководители всех групп доста-
точно часто встречались и делились своим видением и пониманием проблем.
Хотя при многоузловой разработке некоторые вещи могут развиваться в не-
верном направлении, она работала много раз, и существуют довольно стандарт-
ные правила, позволяющие добиться ее выполнения (в отличие от остальных
двух моделей виртуальных команд).
Офшорная разработка
Если “проектировщики” из одного места посылают спецификации и тесты “про-
граммистам” в другое место, обычно в другую страну, это называется офшорной
разработкой.
Поскольку офшорному подразделению не хватает архитекторов, проекти-
ровщиков и тестировщиков, эта ситуация значительно отличается от многоузло-
вой разработки.
Вот как выглядит офшорная разработка с использованием терминов из ко-
оперативных игр и конвекционных потоков.
216
Глава 5
Проектировщики в одном месте должны передать их идеи через тонкий ка-
нал общения людям, которые имеют другой словарь и находятся от них на рас-
стоянии нескольких часовых поясов. У программистов возникают тысячи
вопросов. Когда они находят в проекте ошибки, они должны выполнить три доро-
гостоящие вещи: во-первых, дождаться следующей телефонной или видеоконфе-
ренции; во-вторых, передать свои замечания; в-третьих, убедить проектиров-
щиков в возможной ошибке в проекте. Затраты в эрг-секундах на один мем пора-
зительны, задержки чудовищны.
Тестирование офшорного кодирования
Один проектировщик рассказал мне, что его команда должна была
специфицировать программу до самого уровня написания кода и
разработать тесты, чтобы убедиться, что программисты корректно
реализовали каждую строку. Проектировщики выполнили всю бу-
мажную работу, скучную для них, так как они не награждались за
нее возможностью писать программы.
За то время, которое они потратили на специфицирование и тести-
рование, они могли бы сами написать код и обнаружили бы свои
ошибки проектирования гораздо быстрее.
Я не смог обнаружить методологически успешных внешних проектов. Они не
проходят третьего теста; люди, с которыми я беседовал, божились больше никог-
да в этом не участвовать.
К счастью, некоторые офшорные фирмы-разработчики ПО преобразуют
свои проекты в нечто более напоминающее многоузловую разработку с архитек-
торами, проектировщиками, программистами и тестировщиками в том месте, где
выполняется программирование. Хотя канал общения по-прежнему длинен и то-
нок, участники команды, по крайней мере, могут получить какую-то обратную
связь и преимущества общения из многоузловой разработки.
Распределенная разработка
Разработка называется распределенной, если команда разбросана по сравнитель-
но многим местам, в каждом из которых работает относительно немного чело-
век — часто лишь один или двое.
Распределенная разработка становится типичным случаем, но не приобретает
от этого дополнительную эффективность. Расходы на передачу идей огромны, а за-
траты из-за невыясненных вопросов еще больше. Модель распределенной разра-
ботки может дать результат, если она подражает многоузловой разработке с
имеющими ясные цели подкомандами, состоящими из одного-двух человек. В этом
сценарии задание для каждого лица ясно и содержательно.
Однако более распространенная ситуация демонстрируется в следующей ис-
тории:
Быстрота и адаптируемость
217
Перекрестное распределение
Некоторая компания разрабатывала четыре связанных продукта в че-
тырех разных местах, причем каждый продукт содержал несколько
подсистем.
Эффективный вариант должен был бы включать разработку всех сис-
тем одного продукта в одном месте или одной подсистемы для всех
продуктов. В обоих случаях сотрудники компании находились бы по со-
седству от людей, с которыми им нужно обмениваться информацией.
Вместо этого множество вовлеченных в работу сотрудников компа-
нии, работающих в одном городе, занимались разными подсистемами
разных продуктов. Они были окружены людьми, чья работа почти не
имела отношения к их заданиям, и были отделены от тех, с кем им
требовалось общаться!
Изредка можно услышать рассказ об эффективной разработке ПО в несколь-
ких различных местах. Это показывает, что можно обнаружить нечто новое. Что
позволяет этим людям хорошо общаться через такую тонкую линию связи? Только
ли счастливое совпадение их личных качеств и стилей мышления? Не построили
ли они небольшую многоузловую модель? Или они делают что-то такое, что боль-
шинство из нас не научилось пока обозначать?
Успешная распределенная разработка
Однажды я провел вечер в разговорах с парой специалистов, удачно
использовавших в работе четыре-пять человек, никогда не работав-
ших вместе одной группой.
Они рассказали, что тщательно разделили задачу на части и много
времени проводили на телефоне, соединяясь с каждым участником
группы по нескольку раз каждый день.
В дополнение к этой очевидной тактике женщина — координатор
команды особенно напряженно работала над поддержанием очень
высоких уровней доверия и дружелюбия. Она посещала каждого раз-
работчика каждые несколько недель и старалась, чтобы для них эти
визиты были полезными и не вызывали нареканий.
Координатор была заинтересована в повторении успешной модели
разработки.
К концу вечера мы пришли к заключению, что ей нужно было найти
другого такого же координатора разработки — кого-то с похожим
талантом к развитию в людях доверия и дружелюбия.
Два аспекта этой разработки меня поразили:
Внимание к созданию атмосферы доверия внутри группы
Огромное количество энергии, вложенное в ежедневное общение, чтобы
учиться приспосабливаться и добиваться доверия и обратной связи
218
Глава 5
Разработка с открытыми исходными текстами
Хотя разработка с открытыми исходными текстами внешне похожа на распреде-
ленную разработку, она отличается философской, экономической и структурной
моделями.
В отличие от кооперативной игры с ограниченными ресурсами, которая ра-
зыгрывается в большинстве проектов разработки ПО, проект с открытыми ис-
ходными текстами — это кооперативная игра с неограниченными ресурсами.
Промышленный проект направлен на достижение цели в заданных времен-
ных рамках и имеет заданный объем финансирования. Ограничения по времени и
стоимости определяют то количество человек, которое может участвовать в про-
екте, а также его продолжительность. В этих проектах мы слышим три фразы:
“Завершите, пока не закрылась рыночная ниша!”
“Ваша работа — найти компромисс между качеством и временем!”
“Поставляйте!”
С другой стороны, проект разработки с открытыми исходными текстами
основывается на том, что, имея достаточное количество глаз, голов, пальцев и
времени, можно получить действительно полезные проекты и действительно ка-
чественный код. В принципе неограниченное число людей заинтересовано внести
свой вклад в его разработку, и нет никакой конкретной рыночной ниши, которую
требуется занять. Такой проект живет своей собственной жизнью. Каждый чело-
век усовершенствует систему там, где она слаба, с любым темпом, допустимым
при его свободном времени и энергии.
Структура вознаграждения также отличается, базируясь на внутренних —
в противоположность внешним — поощрениях (см. раздел “Индивидуумы” гла-
вы 2). В таком проекте люди разрабатывают код ради удовольствия, оказывая
услугу сообществу, о котором они заботятся, и ради признания коллег. Мотива-
ционная модель обстоятельно обсуждается в материале “Homesteading the No-
osphere” (Raymond URL).
Промышленный разработчик может стремиться стать следующим Биллом
Гейтсом. Для разработчика в проекте с открытыми исходными текстами соответ-
ствующая цель — стать следующим Линусом Торвальдсом.
Наконец, отличается и структура команды, работающей с открытыми исход-
ными текстами. Каждый может внести свой код, но назначенный “сторож” защи-
щает центр — основной код. От него не требуется быть самым лучшим
программистом, он должен быть хорошим программистом с хорошей квалифика-
цией и очень хорошим пониманием качества. Со временем несколько лучших
специалистов, внесших больший вклад в разработку, занимают центр, становясь
интеллектуальными собственниками проекта. Вокруг этих нескольких человек
собирается неограниченное число людей, которые предлагают вставки и фраг-
менты кода, обнаруживают ошибки и сообщают о них, пишут документацию.
Быстрота и адаптируемость
219
Предполагалось, и это похоже на правду, что одним из ключевых аспектов
разработки с открытыми исходными текстами является прозрачность общения
для всех. Рассмотрим следующее сравнение с промышленными проектами.
В промышленном проекте с расположенной в одном месте командой затруд-
нения возникают, когда команда эволюционирует в общество с высшим и низ-
шим классами. Если аналитики сидят с одной стороны здания, а
программисты — с другой, легко возникает разделение “мы-они”, порождающее
враждебность между группами (можно было бы назвать их “фракциями”). Одна-
ко в хорошо сбалансированной команде есть только “мы”, и нет разделения
“мы-они”. Основную роль в наличии или отсутствии этого расщепления играет
природа фоновых разговоров внутри группы. Когда размещение создает анклавы
неквалифицированных сотрудников, в этих разговорах почти неизбежно содер-
жатся комментарии о “них”.
В разработке с открытыми исходными текстами равнозначная ситуация мог-
ла бы возникнуть, если бы по поводу одной подгруппы, расположенной в одном
месте, создалось мнение, что в ней проводятся обсуждения, в которых не могут
участвовать другие. У членов распределенной группы могло бы развиться ощу-
щение принадлежности к людям второго сорта, оторванным от ядра сообщества
и лишенным интересных обсуждений.
Когда все общение происходит on-line, когда оно видимо ка>вдому, нет и ес-
тественного места для скрытого распространения слухов; в этом случае сущест-
вует только “мы”.
Хотелось бы когда-нибудь увидеть результаты серьезного исследования это-
го аспекта разработки с открытыми исходными текстами или самостоятельно
провести такое исследование.
Добиться адаптируемости
Если вы читаете эту книгу с самого начала, к этому моменту для вас должна остава-
ться нераскрытой одна загадка.
Все люди различаются между собой, различаются все проекты, и внутри каж-
дого проекта различаются предметные области, подсистемы, команды и сроки.
Каждой ситуации требуется своя методология (набор групповых соглашений).
Загадка в том, как для каждой ситуации строить другую методологию, причем
потратить на ее разработку столько времени, чтобы у команды его оставалось до-
статочно много для разработки ПО. Кроме того, желательно, чтобы каждому уча-
стнику проекта не требовалось становиться экспертом по методологии.
Надеюсь, вы уже догадались, о чем пойдет речь.
Остановиться и подумать
Средство, с помощью которого можно приспособить соглашения к постоянно из-
меняющимся потребностям, состоит в выполнении двух вещей — индивидуально и
всей командой вместе:
220
Глава 5
1. Подумать о том, что вы делаете.
2. Попросить команду собираться раз в неделю на час, чтобы вмес-
те поразмышлять о пристрастиях в работе.
Если вы это делаете, значит, можете добиться, чтобы ваша методология
была эффективной, “быстрой” и приспособленной к вашей ситуации. Если вы не
можете этого делать, что ж, тогда вы останетесь на том же самом месте.
Хотя наш магический ингредиент в высшей степени прост, получить резуль-
тат весьма трудно из-за человеческой природы. Люди обычно сопротивляются и
неохотно участвуют в совещаниях. В некоторых организациях уровень недоверия
настолько высок, что сотрудники не хотят высказываться на таких собраниях.
В этом случае остается единственная возможность
Сделайте это однажды, объявите результаты, а затем посмотрите, сможете ли вы
это повторить.
Вам надо найти кого-то в своей организации, кто имеет личный опыт прове-
дения совещаний. Первые несколько раз, возможно, потребуется выйти за пре-
делы вашей организации и найти людей с подходящими персональными
навыками, которых каждый обитатель вашей комнаты готов принять.
Способ выращивания методологии
Далее излагается способ оперативного создания и настройки методологии. Я пред-
ставляю его для пяти различных моментов времени:
Прямо сейчас
В начале проекта
В середине первой итерации
После каждой итерации
В середине каждой из последующих итераций
После этого я опишу примерный часовой рабочий семинар, посвященный
размышлению о рабочих привычках.
Прямо сейчас
Узнайте сильные и слабые стороны вашей организации в коротких беседах о проекте.
Этим можно заняться в начале проекта, но можно сделать и прямо сейчас,
независимо от состояния работ по проекту. В любом случае эта информация бу-
дет вам полезна, и вы сможете заложить основы вашей собственной коллекции
бесед о проекте.
В идеальном варианте беседы проводят несколько человек и каждый из них ин-
тервьюирует несколько других человек. Начните свою коллекцию с шести-десяти
отчетов о проведенных беседах. Полезно, но не критично интервьюировать более
Быстрота и адаптируемость
221
одного человека по одному проекту. Например, вы можете поговорить с любыми
двумя специалистами из следующего перечня: менеджер проекта, руководитель
группы, проектировщик пользовательского интерфейса и программист. Их различ-
ные взгляды на один и тот же проект дадут вам много информации. Еще более ин-
формативными будут общие ответы о нескольких проектах.
Важно держать в уме, что любые слова интервьюируемого существенны. В ходе
беседы я не даю собственных мнений ни по каким вопросам, но использую свои
сужения для выбора следующего вопроса.
Предлагаю и вам систематизировать ваши беседы в следующей последовате-
льности:
1. Попросите показать по одному экземпляру каждого рабочего продукта.
2. Попросите вкратце рассказать историю проекта.
3. Спросите, что нужно изменить в следующий раз.
4. Спросите, что не нужно менять в следующий раз.
5. Определите приоритеты.
6. Найдите существующие изъяны.
Шаг 1. Попросите показать по одному экземпляру каждого рабочего продукта.
Глядя на них, вы можете определить возможные размеры бумажной работы в про-
екте и понять, какие вопросы нужно задать о рабочих продуктах.
Поищите дублирующую работу, места, в которых поддержка рабочих про-
дуктов в актуальном состоянии может быть затруднена.
Спросите, применялась ли итерационная разработка, и если использова-
лась, то как обновлялись документы в последовательности итераций.
Определите, в частности, как использовалось неформальное общение, что-
бы ликвидировать непоследовательность при разработке документов.
Избыточность рабочих продуктов
В одном проекте руководитель команды показал мне 23 рабочих
продукта.
Я заметил, что они в значительной степени перекрываются между
собой, и поэтому спросил, не генерируются ли последние рабочие
продукты на основе более ранних продуктов.
Руководитель команды ответил отрицательно, он сказал, что сотруд-
ники создают их "с чистого листа".
Тогда я продолжил, спросив, как к этому относятся сотрудники. Он
сказал, что они действительно ненавидят эту работу, но он все равно
заставляет их это делать.
Шаг 2. Попросите вкратце рассказать историю проекта. Запишите дату
начала, изменения в штате (рост и сокращение), структуру команды, эмоциона-
льно высшие и низшие моменты в жизни проекта.
222
Глава 5
Сделайте это, чтобы проверить размер и тип проекта и определить темы дру-
гих интересных вопросов.
Обнаружение итерационной разработки
Вот как я узнал замечательную историю проекта, который я назвал
"Ingrid" (Cockburn, 1998).
В ходе начальной фазы проекта команда столкнулась с большинст-
вом известных мне в то время неудач. То, что их первая четырехме-
сячная итерация закончилась провалом, не стало для меня
сюрпризом. Я даже спрашивал себя, стоило ли предпринимать столь
долгое путешествие, чтобы услышать о таком очевидном провале.
Сюрпризом для меня стало то, что они сделали после этого.
После этой первой итерации они поменяли почти все в проекте. Рань-
ше я такого никогда не видел.
Четырьмя месяцами позднее они снова перестроили проект — не
так кардинально, но достаточно, чтобы заметить различия.
Каждые четыре месяца они производили работающее, протестиро-
ванное ПО, а затем собирались и анализировали, что они делают и
как можно работать лучше (как я предлагаю поступать и вам).
Больше всего поразило меня, что они не просто говорили об измене-
нии способов своей работы, они действительно изменяли эти способы.
Ценность беседы состояла не в обсуждении конечных продуктов, а в том, что я
услышал об их феноменальной решимости добиться успеха и готовности изменять
каждые четыре месяца все, что было необходимо для достижения желанного успеха.
Услышав историю проекта и познакомившись с проведенными интересными
исследованиями, переходите к следующему шагу.
Шаг 3. Узнайте, что нужно поменять в следующий раз. Спросите: “Какие
важные вещи вы делали неправильно и не хотели бы это повторять в следующем
проекте?”
Запишите все, что они расскажут, и поищите родственные темы, которые
можно было бы исследовать.
После того как вы услышите рассказ о неприятных для них вещах, переходи-
те к следующему шагу.
Шаг 4. Узнайте, что не нужно менять в следующий раз. Спросите: “Какие
важные вещи вы делали правильно, и вам, конечно, хотелось бы их сохранить в сле-
дующем проекте?”
Запишите, все, что они скажут. Если кто-нибудь скажет: “Знаете, волейбол
по четвергам — это действительно здорово”, запишите и это тоже.
Как следует напиться вместе
Однажды, когда я задал этот вопрос (в Скандинавии), один человек
ответил: "Как следует напиться вместе".
Быстрота и адаптируемость
223
Мы вышли с работы и в тот же вечер проверили это на практике, а на
следующий день я действительно заметил улучшение командной ра-
боты,
В ответ на этот вопрос люди называют все что угодно: от места, где они си-
дят, до еды в холодильнике, общественной деятельности, каналов коммуникации,
программных инструментов, программной архитектуры и моделирования пред-
метной области. Что бы вы ни услышали, запишите это.
Шаг 5. Определите приоритеты.Спросите: “Каковы ваши приоритеты по
отношению к вещам, которые вам нравятся в проекте? Что наиболее важно со-
хранить, а о чем можно вести переговоры?” Запишите это.
Полезно узнать: “Было ли что-то такое, что удивило вас в проекте?”
Шаг 6. Найдите существующие изъяны. Наконец поинтересуйтесь, есть ли
что-то еще, о чем вам стоит послушать, и посмотрите, что произойдет.
В одной компании мы соорудили двухстраничный шаблон бесед, в который
нужно было вносить результаты, и поэтому легко могли ими обмениваться. Этот
шаблон содержал следующие секции:
1. Название проекта, работа интервьюирующего лица
(интервьюируемые остаются анонимными)
2. Данные о проекте (даты начала/конца, максимальная
численность, целевая проблемная область, используемая
технология)
3. История проекта
4. Сделано неправильно/не повторится
5. Сделано правильно/будет сохранено
6. Приоритеты
7. Другое
Выполните это упражнение, соберите заполненные шаблоны и просмотрите
их. В зависимости от ситуации вы можете попросить каждого интервьюера рас-
сказать об интервью или просто прочитайте их записи.
Ищите общие темы для нескольких проектов.
Тема общения
В компании, где мы создали этот шаблон, для всех проектов прояви-
лась одна тема:
“Когда у нас была возможность хорошо общаться со спонсорами
заказчиков и внутри команды, результаты удавались. Когда общение
было плохим, нам не удавалось достичь хороших результатов".
224
Глава 5
Хотя это может показаться тривиальным, но это редко записывают, и редко
уделяют внимание общению. На самом деле через год в той же компании прои-
зошла следующая история:
Тема общения в действии
Я участвовал в одном из трех проектов, разрабатываемых одновре-
менно; в каждом из них работали небольшие команды, разместив-
шиеся в разных городах.
Как и следовало ожидать, я тратил много энергии на общение со
спонсорами и программистами.
Все три проекта были завершены приблизительно в одно время. Ру-
ководитель отдела разработки спросил меня, в чем могла быть раз-
ница — почему проект, в котором я участвовал, оказался
успешным, в то время как остальные два, выполнявшиеся в то же
время, были неудачными.
Вспомнив интервью о проектах, я предположил, что это могло
как-то быть связано с качеством общения между группами разра-
ботки и финансирующими группами, а также с общением внутри
команды.
Он сказал, что это интересная идея. И программисты, и спонсоры
в других проектах рассказывали о проблемах общения с руководите-
лями своих проектов. И программисты, и спонсоры чувствовали себя
в изоляции. С другой стороны, спонсоры моего проекта были очень
довольны общением.
Эта же тема прозвучала иначе в другой компании. Вот что мне сообщил один
интервьюируемый:
Тема культурного разрыва
Все наши проектировщики пользовательского интерфейса имеют
докторские степени по психологии, они сидят вместе несколькими
этажами выше программистов.
Между ними и программистами существует образовательный, куль-
турный и физический разрыв.
Мы испытываем некоторую трудность, связанную с иным подходом
проектировщиков и расстоянием между нашими помещениями.
Этой компании потребуются дополнительные механизмы, для того, чтобы
развить контакты между своими группами, и дополнительное рецензирование их
работы.
Приведенные здесь истории показывают, что в беседах вы можете узнать то,
что может оказаться существенным в вашем следующем проекте. Обращайте
внимание на предупреждения, появляющиеся в беседах о проектах.
Быстрота и адаптируемость
225
В начале проекта
Рассчитывайте, что вам придется выполнить адаптацию стандартной методологии
компании. Это потребуется сделать независимо оттого, какая методология приня-
та за базовую — ISO9001, ХР, RUP, Crystal или местная смесь.
Стадия 1: Базовая методология для адаптации. Если возможно, попросите
двух человек совместно подготовить предложения по базовой методологии про-
екта. Дело пойдет быстрее — они будут замечать друг у друга ошибки и способ-
ствовать возникновению новых идей.
Они должны пройти четыре шага:
1. Определить, работу какого числа сотрудников нужно координировать, и
узнать их географическое распределение (см. сетку на рис. 4.23). Ре-
шить, какой уровень правильности ПО ожидается получить и какой уро-
вень ущерба оно может причинить. Определить и записать приоритеты
для проекта: время поставки на рынок, правильность или что-то другое.
2. Используя принципы создания методологии из главы 4, выбрать базо-
вые параметры методологии: насколько строгими должны быть стан-
дарты, объем необходимой документации, формальность оценок,
продолжительность итерации (интервал времени до поставки работаю-
щего кода реальным, хотя бы и специально выбранным пользователям).
Если итерация занимает больше четырех месяцев, команда должна найти не-
который способ создания протестированной работающей версии системы каж-
дые четыре месяца или чаще, чтобы сымитировать настоящие итерации.
3. Выбрать такую базу для методологии, чтобы она не слишком отлича-
лась от способа, которым они хотели бы работать.
Вспомните, что легче изменить существующую методологию, чем изобрести
новую с самого начала. Команда может выбрать стандарт компании или опубли-
кованные Unified Process, ХР, Crystal Clear, Crystal Orange, или методологии по-
следнего проекта.
4. Сжать методологию до основного рабочего процесса — кто, что и кому
передает — и соглашений, которые, по их мнению, группа должна при-
нять.
Выполнение этих шагов потребует от одного до нескольких дней для проек-
тов небольшого и среднего размера. Если складывается впечатление, что они не
укладываются в неделю, выделите еще двух человек из команды, сформирован-
ной для проекта, и доведите работу до конца не более чем за два дня.
Стадия 2. Стартовая методология. Проведите совещание команды для об-
суждения рабочего процесса и соглашений по базовой методологии, отрегули-
руйте ее и сделайте стартовой методологией. Для крупных проектов, когда
226
Глава 5
собирать всю команду непрактично, вызовите основных представителей ролей
для каждой задачи.
Цель совещания состоит в следующем:
Обнаружить излишества
Отыскать пути рационализации процесса и способы менее затратного об-
щения
Определить другие вопросы, не включенные в эскиз базовой методологии
Рассмотрите на совещании следующие вопросы:
Какой продолжительности должны быть итерации и инкременты (и в чем
разница)?
Как будут размещены сотрудники?
Что можно сделать для поддержания на высоком уровне коммуникации
и морального состояния?
Какие рабочие продукты и рецензирование потребуются и на каких уровнях
формальности?
Какие стандарты для инструментов, диаграмм, тестов и кода обязательны
для исполнения, а какие просто рекомендуются?
Как будут составляться отчеты?
Какие другие соглашения должны быть установлены с самого начала, а ка-
кие могут появиться со временем?
Важный пункт повестки дня совещания — выбрать для команды способ ре-
шения моральных проблем и проблем с коммуникацией.
Результаты совещания будут включать:
Базовый рабочий процесс
Критерии передачи работы между ролями, в частности включающие пере-
крытие разработки и контрольные точки
Черновые варианты стандартов или соглашений, которые должны выпол-
няться
Особенности видов коммуникации, которые будут применяться на практике.
Это ваша стартовая методология.
Совещание может длиться полдня, но не дольше одного рабочего дня.
В середине первого инкремента
Независимо от продолжительности вашего инкремента — будь это хоть две неде-
ли, хоть три месяца — проведите короткую беседу с участниками команды (инди-
Быстрота и адаптируемость
227
видуально или на групповом совещании) приблизительно в середине инкремента.
Отведите на это от часа до трех.
Нужно ответить на единственный вопрос:
"Выполним ли мы проект, продолжая работать так же?”
В первом инкременте вы не можете себе позволить полностью изменить
процесс работы группы, если он не отказывает катастрофическим образом. Бла-
гополучно дойти до первой поставки — вот что вам нужно. Если стартовая мето-
дология продержится до конца инкремента, вы получите больше времени и
лучший момент для ее адаптации, после того как успешно выполните первый вы-
пуск продукта.
Следовательно, на этих беседах или на этом совещание нужно определить,
есть ли какие-то критические ошибки в процессе и может ли провалиться первая
поставка.
Если вы обнаружите, что используемый группой процесс не работает, в пер-
вую очередь обдумайте сокращение области действия первой поставки.
Большинство команд завышают свои возможности, когда планируют произ-
водство первого варианта продукта. Это нормально, и не методология в этом ви-
новата. Такие планы появляются в результате чересчур амбициозного
менеджмента, порождающего нереалистичное планирование, и чересчур оптими-
стичных разработчиков, не учитывающих необходимое обучение, проведение со-
вещаний и обычные ошибки, которые они вносят в код. Эти планы возникают от
недооценки потребностей в изучении новой методологии и обучении новых со-
трудников. Завышение объемов выработки после первого инкремента в самом
деле абсолютно естественно.
Следовательно, на первом подходе вы должны сузить область действия.
Однако одного сокращения области действия бывает недостаточно. Может
оказаться, что требования непонятны программистам или что архитекторы не за-
кончат подготовку своих спецификаций вовремя.
В этом случае придется реагировать быстро и найти новый способ работы.
В сочетании с кардинально сокращенной функциональной областью действия
этот способ позволит вам выдержать срок первой поставки.
Можно ввести перекрывающуюся разработку или физически переместить
сотрудников ближе друг к другу, понизить уровень амбиций для начальной архи-
~ уры или повысить использование неформальных каналов коммуникации.
Может потребоваться экстренно изменить штат или временно привлечь настав-
ников, консультантов и опытных разработчиков.
Ваша цель — после первого инкремента поставить нечто, небольшой объем
работающего протестированного кода. Для всего проекта это важный фактор
успеха (Cockburn, 1998). После поставки первой версии у вас будет время при-
остановиться и обдумать, что происходит.
228
Глава 5
После каждого инкремента
После каждого инкремента проводите рабочий семинар команды с обсуждением
результатов.
Остановиться и полумать — критический фактор в оценке успешной методо-
логии, так же как инкрементная разработка критически важна для успеха в раз-
работке ПО.
Продолжительность семинара может колебаться в зависимости от компании
и страны. Американцы любят постоянно заниматься делом, зарабатывать деньги,
быть в движении. Я понимаю американцев, выделяющих на этот семинар лишь
от двух до четырех часов. В других частях мира этому семинару могут уделить
значительно больше времени.
Однажды я участвовал в двухдневном выездном варианте такого совещания,
сочетавшем критику, формирование команды и планирование следующего инк-
ремента. Не удивительно, что семинар проходил в Европе.
Основная причина откладывания семинара до завершения первого инкре-
мента состоит в том, что, лишь поставив пользователю работающее протестиро-
ванное ПО, вы сможете правильно оценить влияние каждого элемента вашей
методологии. Только тогда вы поймете, в чем перестарались, а что недоделали.
Но есть и вторая причина, почему этот семинар откладывается до конца инк-
ремента: отправив программы в мир, люди часто чувствуют утомление. Совещание
предоставляет им возможность перевести дыхание и поразмышлять. Проводимое
регулярно, оно становится частью ритма проекта. После каждого инкремента чле-
нам команды полезно немного изменить мыслительные и социальные механизмы.
Независимо от того, выберете ли вы два часа или два дня, вам потребуется
поставить два вопроса:
1. “Чему мы научились?”
2. “Что мы можем улучшить?”
Ответы могут пересекать каждую границу проекта, начиная от вмешательст-
ва руководства до карт контроля времени, общения в группе, размещения со-
трудников, обзоров проекта, стандартов и структуры команды.
Очень часто после первого инкремента команды уплотняют стандарты, вво-
дят дополнительное обучение, рационализируют рабочий поток, увеличивают
объемы тестирования и реорганизуют структуры команд.
Эти изменения будут гораздо меньше после второго и последующих инкре-
ментов, поскольку к тому времени команда создаст уже несколько версий про-
дукта.
В середине каждого из последующих инкрементов
После первого инкремента команда установила (едва-едва) один успешный способ
работы. К этому варианту методологии при необходимости можно вернуться.
Быстрота и адаптируемость
Располагая этим планом отступления, можно проявить больше предприим-
чивости в предложениях на совещаниях, которые вы будете проводить в середине
второго и последующих инкрементов.
В этих совещаниях середины инкремента и, в частности, после второй
успешной поставки попробуйте изобрести новые лучшие способы производства
программ.
Подумайте, можете ли вы предпринять что-либо из следующего:
Исключить из методологии целые секции
Больше распараллелить разработку
Больше использовать неформальное общение для закрепления информа-
ции о проекте
Ввести новую улучшенную схему тестирования
Ввести улучшенный порядок написания тестов
Добиться более тесного сотрудничества между основными группами проек-
та: экспертами предметной области и экспертами-пользователями, про-
граммистами, тестировщиками, наставниками и центром обслуживания
заказчиков
Для этих уточнений в середине инкремента можно использовать интервью
или рабочие семинары. К этому времени ваша команда приобретет довольно зна-
чительную практику таких совещаний и получит представление о том, как ей
нужно поступать.
Допустимо пропускать семинары в середине инкремента, если его продол-
жительность не превышает трех недель.
Зачем нужно беспокоиться о рецензировании в середине инкремента, если
поставка версий в проекте уже происходит и вы уже проводите рецензирование
после инкрементов?
В середине цикла разработки то, что не работает должным образом, хорошо
известно участникам команды. Через четыре-шесть недель на совещании после
инкремента детали проблем не будут так же ясны. Следовательно, в середине ин-
кремента вы можете собрать больше деталей, немедленно получить обратную
связь на идею и попробовать новую идею в тот же день, вместо того чтобы ждать
несколько недель или месяцев.
Что если новая идея не приведет к успеху?
Иногда команда пробует новую идею во втором или третьем инкременте и об-
наруживает, что она просто не работает как следует.
Изменения структуры команды в середине проекта
В одном проекте в ходе третьего инкремента мы прошли через три
различные структуры команды.
230
Глава 5
Только начав третий инкремент, мы решили, что структура нашей
команды слаба. Поэтому для третьего инкремента мы выбрали но-
вую структуру.
Она оказалась чудовищно плохой. Через две недели мы поняли, что
ее нужно менять немедленно.
Вместо возврата к прежней, довольно громоздкой, но успешной
структуре, мы подготовили новое предложение и сразу же его
опробовали.
Эта структура оказалась удачной, и мы сохранили ее до конца про-
екта.
Придумывая новые способы работы в этих более поздних инкрементах, вы
создаете возможность для существенного улучшения вашей методологии. Эту
возможность нельзя упускать.
Рецензирование после проекта
При наличии рабочих семинаров в середине и в конце инкрементов я придаю мень-
ше значения проведению рецензирования после проекта. Я считаю, что нужно ис-
пользовать время для размышлений в ходе проекта, когда размышления и
обсуждения принесут проекту какую-нибудь пользу. Делать это после проекта уже
слишком поздно.
Обычно я обнаруживаю, что команды, проводившие рецензирование после
проекта, не побеспокоились остановиться и поразмыслить в ходе выполнения про-
екта и вдруг захотели узнать, как лучше организовать работу в следующем проекте.
Если вы окажетесь на таком совещании, предложите в следующий раз использовать
инкрементную разработку и проводить рецензирование в конце инкрементов.
Тем не менее может так случиться, что рецензирование после проекта — это
единственное время, когда вы можете сделать заявления об укомплектовании
кадрами и руководстве проектом. Для этого случая я предлагаю использовать
книгу Project Retrospectives (Kerth, 2001), в которой описано, как проводить
двухдневное рецензирование после завершения проекта.
Если вы проводите рецензирование после завершения проекта, подумайте, кто
собирается использовать эту информацию и что действительно можно использовать
в следующем проекте. Можно набросать короткий (двухстраничный) набор заметок
для команды следующего проекта, очертив уроки, вынесенные из этого проекта.
Конечно, одностраничные меморандумы об “уроках” можно писать после
каждого из инкрементов по результатам проведения рабочих семинаров.
Техника проведения рабочих семинаров
Осязаемым результатом рабочих семинаров, проводимых в середине и в конце ин-
крементов, является плакат, вывешиваемый на стене в каком-либо заметном мес-
те, где его могут увидеть участники проекта, проходя мимо по своим делам.
Быстрота и адаптируемость
231
Мне нравится писать непосредственно на вывешенном плакате. Он несет на
себе память группы. Другие предпочитают копировать перечень с исчерканного и
испещренного каракулями плаката на новый лист и вывешивать уже его. Те, кто
создавал плакат, показанный на рис. 3.10, решили не писать на самом плакате,
а воспользоваться “устойчивыми” записками.
Примерная методика проведения рабочего семинара
Существуют различные форматы проведения семинара, посвященного обсужде-
нию работы и совместного использования его результатов. Я склоняюсь к прове-
дению наиболее простого варианта. Это происходит приблизительно так:
Рабочий семинар
Здравствуйте, добро пожаловать на этот семинар, где мы подума-
ем, как улучшить производство ПО.
Цель этого собрания не в том, чтобы указывать пальцами, осуждать
людей или защищаться от осуждения. Нам нужно уяснить, на чем
мы застряли, и предложить идеи, которые помогут преодолеть эти
затруднения.
В результате этого семинара появится единственный плакат. На нем мы
напишем идеи, которые намереваемся опробовать в ходе следующего
инкремента, и то, что мы хотим держать в голове во время работы-
Давайте разделим этот плакат на три части.
С левой стороны зафиксируем вещи, которые идут хорошо и которых
мы ни в коем случае не хотим лишиться в следующем инкременте.
С правой стороны зафиксируем новые вещи, на которых мы хотим
сконцентрироваться в ходе работы.
Предполагая, что перечень того, что мы делаем правильно, будет
короче, запишем основные проблемы, с которыми мы боремся, на-
чиная с середины левой стороны (см. рис. 5.1).
Это сохранить Изолированное тестирование Тихое время Ежедневные совещания Это попробовать Парное тестирование Штрафы за помехи Помощь программистов тестировщикам
Проблемы Слишком много помех Поставка кода с ошибками
Рис. 5.1. Примерный плакат с рабочего семинара
232
Глава 5
Начнем с того, что мы делаем правильно. Что же мы делаем правиль-
но и хотим обязательно сохранить на следующий инкремент?
В этот момент возникает некоторое обсуждение. Возможно, кто-то вместо
сильных областей начинает называть проблемные области. Если эти вопросы
значимы, записывайте их в разделе “Проблемы”. Дайте людям какое-то время на
размышление и обсуждение.
Направляйте обсуждение дальше:
Хорошо, каковы основные проблемы, с которыми мы столкнулись в
последнее время, и что мы можем сделать для улучшения ситуации?
В разделе “Проблемы” пишите как можно меньше и старайтесь объединять
проблемы. Смысл этого плаката в том, чтобы объявить предложения по улучше-
ниям, а не концентрироваться на проблемах.
Соберите предложения. Если список становится чересчур длинным, спроси-
те, сколько новых методов и приемов группа действительно хочет взять на воору-
жение в следующем интервале. Иногда вид огромного списка напоминаний
действует угнетающе. Эффективнее сконцентрироваться на более кратком пере-
чне. Ведение записей на единственном плакате жирным плакатным пером —
подходящий способ, накладывающий ограничения на размеры перечней.
Периодически интересуйтесь, не подумал ли кто-либо о других правильных
приёмах группы, которые нужно сохранить.
Ближе к концу семинара сделайте обзор всего списка. Узнайте, действитель-
но ли все согласны попробовать новые идеи или некоторые сотрудники просто
молчаливы от природы.
После семинара вывесите перечень на видном месте.
На следующий семинар можно принести плакат предыдущего семинара и
сначала спросить, эффективен ли такой способ объявления результатов или
нужно попробовать что-то другое.
Проведение таких семинаров каждые две-шесть недель поможет команде
следить за развитием своей культуры и создавать собственную методологию бы-
строй разработки.
Ценность размышлений
Статью о Shu-Ha-Ri (см. введение) можно продолжить следующим очень умест-
ным размышлением:
“По мере того как вы изучаете прием, и по мере того как он асимптотически
приближается к вашей мысленной модели этого приема, возникшей при виде его
применения другими, вы можете начать о нем размышлять. Важно ответить на
следующие вопросы:
1. Как работает этот прием?
2. Почему работает этот прием?
Быстрота и адаптируемость
233
3. Как этот прием связан с другими приемами, которые я практикую?
4. Каковы необходимые предусловия и постусловия эффективного приме-
нения этого приема в боевой ситуации? ...
По мере развития рационального набора приемов вам потребуется встрети-
ться с как можно более широким кругом практиков. Пока вы будете наблюдать
за другими, задайте себе по крайней мере три вопроса и ответьте на них:
1. К каким другим практикам я испытываю чувства уважения и восхище-
ния?
2. Чем их действия отличаются от моих?
3. Как я могу изменить свое исполнение (мысленную модель и попытки
ей соответствовать) в свете отличий, которые я считаю наиболее важ-
ными? ...
После такого соревнования спросите себя:
1. Удалось ли вам контролировать темп и действия ваших противников?
2. Удалось ли вам сохранять спокойствие и применять приемы эффектив-
но и без суеты?
3. Выглядели ли вы в состязании как те практики, которыми вы восхищае-
тесь? ...
На всем протяжении этого времени вы должны честно оценивать результаты
каждого “испытания”. Циклически возвращайтесь к Shu через На и затем Ri,
если окажетесь на тупиковом пути".
Я бы не смог сказать лучше.
Что дальше?
Рассматривайте быстроту не как формулу, а как позицию. В этом умонастроении
посмотрите на свой текущий проект и спросите: “Как в этой ситуации мы можем
работать быстрее?”
Посмотрите, как далеко до эффективных участков вашей команде разра-
ботчиков. Подумайте, насколько творчески вы сможете к ним приблизиться
или их сымитировать.
Поищите, где ваша команда способна облегчить свою методологию, а где
она еще недостаточна.
Проведите одну беседу по проекту, следуя описанию.
Убедите нескольких человек провести одну беседу о проекте и поделитесь
результатами. Найдите общую нить в результатах бесед.
234
Глава 5
Проведите часовой рабочий семинар внутри вашего проекта. Столкнув-
шись с трудностями, подумайте, какие стороны сотрудников при этом проя-
вились, сравните их со списком из главы 3. Поищите противодействующие
средства и расширьте список. Вывесите плакат рабочего семинара и пона-
блюдайте, многие ли обращают на него внимание.
Подумайте, что потребуется для проведения второго рабочего семинара.
Научитесь убеждать людей меньше жаловаться и больше вносить позитив-
ных предложений на этих семинарах.
Совершенствуйтесь и станьте разработчиком методологий уровня 2. Да, это
ведь часть вашей профессии.
Глава 6
Методологии семейства Crystal
В данной главе описывается, как я разрешил дилеммы, связанные с созданием ме-
тодологии: сложность коммуникации, потребность учитывать человеческий фак-
тор и необходимость в нескольких методологиях.
Я решил построить семейство методологий наряду с определением принци-
пов их адаптации. Это не набор компонентов методологии, из которых вы можете
собрать свою собственную, а набор образцов, которые вы можете регулировать
согласно вашим обстоятельствам.
Crystal — это имя семейства методологий. Все члены семейства, словно гео-
логические кристаллы, имеют разные цвета и разную твердость, соответствую-
щие размеру и критичности проекта: Clear (прозрачный), Yellow (желтый),
Orange (оранжевый), Orange Web (оранжевый Web), Red (красный), Magenta
(пурпурный), Blue (синий) и т.д. Каждая из этих методологий:
Построена вокруг людей и коммуникации
Адаптируется, чтобы соответствовать конкретным параметрам
Исходя из уровня толерантности и критических видов деятельности
проекта, вырабатывает решение, соответствующее
экосистеме проекта
В данной главе описаны три члена семейства Crystal, которые использова-
лись в реальных проектах: Crystal Clear, Crystal Orange и Crystal Orange Web.
Для каждого из них я:
Описываю характеристики проекта, для которых подходит данная
методология
Описываю саму методологию
Размышляю о структуре методологии '
9 Зак.715
236
Глава 6
Эта глава включена в данную книгу, чтобы показать один из способов реше-
ния проблем, возникающих при создании методологий, и дать образцы для созда-
ния вашей собственной методологии.
Формирование семейства Crystal
На вопрос о необходимости нескольких методологий можно дать два вполне убеди-
тельных ответа. Это нужно для того, чтобы:
Создать набор компонентов, из которых разрабатывающая проект команда
собирает методологию
Создать семейство специфических методологий, которые можно путем ко-
пирования и изменения адаптировать для каждого проекта
Компания Rational Software использовала такой подход к созданию набора
компонентов в первом поколении своей методологии Rational Unified Process
(RUP) (Kruchten, 1999). RUP — это каркас, на базе которого можно создавать
методологии для отдельных проектов. Он построен вокруг процессов, рабочих
продуктов, инструментов и включает совокупность “лучших методов”, направля-
ющих практика по пути создания методологии.
Сборка корректной методологии для RUP-проекта тесно связана с формиро-
ванием так называемого “варианта разработки” (development case) и последую-
щей сборки частей из набора компонентов RUP, соответствующих варианту
разработки (Larman, 2002).
Обычная ошибка менеджеров состоит в том, что они не выполняют эту сбор-
ку и настройку. Они бросают библиотеку рабочих продуктов команде разработ-
чиков и говорят: “Делайте так, как здесь предписано”. Разработчики делают одно
из двух:
Осознают, что создание всех этих рабочих продуктов разрушит проект, поэ-
тому игнорируют распоряжения менеджера.
Делают, как велено, и создают все эти рабочие продукты (и, соответствен-
но, разрушают проект).
Нельзя сказать, что методология RUP несовместима с принципами, изло-
женными в этой книге, но она не ведет людей естественным путем к концентра-
ции на двух основных факторах успеха: коммуникации и сообществе.
Я надеюсь, что, прочитав эту книгу, менеджеры, приобретающие RUP, будут
выделять время для адаптации методологии под свои проекты. Кроме того, я на-
деюсь, что люди, выполняющие эту адаптацию, оставят как можно меньший на-
бор требуемых рабочих продуктов и дополнят RUP внимательным отношением к
коммуникации, сообществу, параллельной разработке и прочим важным вещам.
Альтернативный подход к созданию методологии для проекта состоит в фор-
мировании набора конкретных образцовых методологий, уже использовавшихся
Методологии семейства Crystal
237
в проектах, и в предоставлении выполняющей проект команде возможности на
ходу адаптировать методики, описанные в последней главе.
Этому подходу следуем мы с Джимом Хайсмитом. Мы собираем примеры
“быстрых” методологий, базирующихся на коммуникации и сообществе, которые
могут использоваться участниками проектов как отправные пункты.
Видя уже разработанную методологию, команда, выполняющая новый про-
ект, может понять, как коммуникация и сообщество используются в реальной си-
туации. Имея набор примеров на выбор, команда может подобрать тот, который
наиболее близко соответствует ее проекту.
Методологии, которые я создаю, я называю Crystal.
Слово Crystal служит двум целям.
Во-первых, оно просто красиво звучит. В книге Crystal Clear главный герой
по имени Crystal олицетворяет методологию и приводит доводы в ее пользу.
Во-вторых, оно дает метафору, поддерживающую первые два измерения, по-
казанные в сетке проектов на рис. 4.23.
Движение по сетке вправо означает координацию большего числа людей,
что требует более “тяжелой” методологии. Используя метафору кристалла, дви-
жение вправо соответствует более темному цвету (прозрачный кварц, топаз, ру-
бин, сапфир).
Движение по сетке вверх соответствует большему возможному ущербу от
системы и использованию большей строгости и формальности. Оно также озна-
чает увеличение “твердости” (по шкале твердости минералов алмаз — самый
твердый камень — получает значение 10).
Таким образом, в соответствии с метафорой кристалла два человека, про-
граммирующие обеденное меню для тех, кто работает сверхурочно, выполняют
проект, требующий “мягкой” методологии прозрачного кристалла. Два человека,
программирующих движение бористых стержней в ядерном реакторе, работают
над проектом, требующим методологии категории алмаза.
Из этих двух измерений цвет мне кажется более полезным показателем про-
екта. Твердость проще определить на рабочих семинарах, посвященных адапта-
ции методологии.
Поэтому я индексирую методологии Crystal по цвету: Clear, Yellow, Orange,
Red, Magenta, Blue, Violet и т.д. (рис. 6.1).
На рис. 6.1 я не учел критические для жизни системы, расположенные в за-
тененных областях. Дело в том, что я не работал в таких проектах и не ин-
тервьюировал участвовавших в них людей, поэтому не обладаю достаточной
информацией, чтобы точно сказать, как выглядит критический для жизни проект.
Клетка Е6, расположенная вне области Crystal Clear, указывает, что эта мето-
дология не рассчитана на проекты с “невозместимыми средствами”, но у команды
есть возможности “растянуть” Crystal Clear до такой ситуации.
Другое ограничение методологий Crystal в том, что они рассчитаны лишь на
команды, размещенные в одном месте. Как говорилось ранее, ни один из проек-
238
Глава 6
тов распределенной или офшорной разработки, которые я наблюдал, не может
считаться методологически успешным. Единственная рекомендация, которую
я могу дать таким проектам, — собрать команду в одном месте.
Рис. 6.1 Методологии Crystal именуются по цветам.
Методологии Crystal не стремятся к совместимости снизу вверх или сверху
вниз. В сфере аппаратных средств компьютеров замена оборудования связана с
существенными финансовыми последствиями, и поэтому вопросы совместимости
являются важнейшими. Таких же последствий от перемещения вверх и вниз по
шкале методологий я не вижу. Команда из четырех человек начинает работать
над проектом, который разрастается и становится проектом для 20 человек. Они
не станут спрашивать: “Как нам сохранить прежние рабочие соглашения?” Они
должны сказать: “Покажите нам полезный способ совместной работы для 20 че-
ловек”.
Основные элементы методологий
Crystal
Основная философия Crystal заключена в том, что разработку ПО полезно рас-
сматривать как кооперативную игру изобретения и коммуникации, имеющую глав-
ной целью поставку полезного работающего ПО, а вспомогательной целью —
подготовку к следующей игре.
Из этой философии следует, что разные проекты нужно выполнять по-раз-
ному, а объем моделирования и коммуникации, необходимый разработчикам, —
i это просто тот объем, который им требуется, чтобы совместными усилиями про-
двигать игру к цели.
Методологии семейства Crystal
239
Члены семейства Crystal имеют общие:
Ценности и принципы
Способы адаптации по ходу выполнения проекта
Методологии Crystal обладают двумя ценностями:
Они построены вокруг людей и коммуникации.
Они в высшей степени толерантны.
Первая ценность означает, что инструменты, рабочие продукты и процессы
нужны лишь для поддержки человеческого фактора. Вторая ценность признает
многообразие человеческой культуры.
Впрочем, в пределах толерантности семейства Crystal команда может вы-
брать работу с высокой степенью формальности или с высокой степенью дисцип-
лины (например, заимствуя части PSP или ХР).
В главе 4 обсуждалось семь принципов, которые можно резюмировать при-
мерно следующим образом:
Команда может сократить число промежуточных рабочих продуктов, чаще
производя работающий код и используя более насыщенные каналы комму-
никации между людьми.
Поскольку любой проект отличается от других и развивается со временем,
набор соглашений, который принимает команда, также должен быть при-
способлен к проекту и должен эволюционировать.
Перемещающиеся узкие места в системе определяют использование пере-
крывающихся работ и хранителей “устойчивой” информации.
Для всего семейства Crystal есть два общих правила:
Проект должен использовать инкрементную разработку с инкрементами
продолжительностью в четыре месяца или меньше (и настоятельно реко-
мендуются инкременты от месяца до трех).
Команда должна проводить рабочие семинары до и после инкрементов (на-
стойчиво рекомендуется проводить также рабочие семинары в середине ин-
кремента).
Базовыми для семейства Crystal являются следующие два приема:
Адаптация методологии — использование проектных интервью и рабочих
семинаров для преобразования базовой методологии в стартовую методо-
логию проекта
Проведение рабочих семинаров для обсуждения хода выполнения проекта
240
Глава 6
Если у вас есть другой способ достижения этих целей, вы можете заменить
эти два приема другими.
Внимание к названным вопросам создает особое ощущение. Как кто-то напи-
сал, можно сделать, чтобы другая методология производила такое же впечатление,
как проект Crystal, не добившись от нее ощущения проекта Crystal. Посторонний
человек заметит в проекте Crystal коммуникацию и сообщество в действии, будет
наблюдать прагматизм в достижении двух целей кооперативной игры.
В следующих трех разделах описываются три методологии Crystal, создан-
ные мною и используемые до сих пор.
Структурные различия между ними очевидны. Попробуйте заметить в них
общее.
Crystal Clear
Crystal Clear — это методология для проектов категории D6. Можно расширить
Crystal Clear до категорий Е8 и D10, обратив некоторое внимание на коммуника-
цию и тестирование. Мне кажется, что расширить Crystal Clear за эти категории
довольно сложно, поскольку она не содержит структур коммуникации для больше-
го числа людей, чем может работать в хороших условиях в одной комнате, и в ней
отсутствуют элементы проверки, необходимые для критичных систем.
Краткое описание Crystal Clear
У нас имеется одна команда, сидящая в одной комнате или в смежных комнатах.
Для определения обязанностей отдельных людей используются следующие
роли:
Спонсор
Старший проектировщик-программист
Проектировщик-программист
Пользователь (присутствует хотя бы часть времени)
Один из этих людей может быть координатором проекта. Кто-то будет биз-
нес-экспертом, и один или несколько человек будут исполнять роли специали-
стов по сбору требований.
Старший проектировщик-программист — главная фигура в команде. В чис-
ле остальных проектировщиков-программистов могут быть новички и специали-
сты среднего уровня, в зависимости от потребностей старшего проектиров-
щика-программиста и решаемой задачи. Помогает наем сотрудников, хорошо
знающих свое дело.
Стандарты проекта заключаются в следующем:
Программное обеспечение поставляется по инкрементам и регулярно,
каждые два-три месяца.
Методологии семейства Crystal
241
Продвижение проекта отмечается контрольными точками, в которых про-
изводятся конечные продукты или принимаются важные решения.
Применяется автоматическое регрессионное тестирование функциональ-
ных приложений.
Пользователи непосредственно привлекаются к участию в проекте.
Пользователи дважды просматривают каждую версию.
Деятельность ниже по течению рабочего процесса начинается сразу же, как
только продукт выше по течению становится “достаточно стабильным для
рецензирования”.
Семинары по адаптации продукта и методологии проводятся в начале и в се-
редине каждого инкремента.
Эти стандарты обязательны, но разрешается эквивалентная замена, как мог-
ло бы быть в случае использования рабочего планирования в методологии Scrum
(Schwaber, 2002), использования стандартов ХР или Adaptive Software Develop-
ment (Highsmith, 2000).
В число рабочих продуктов входят:
Последовательность версий
График пользовательских обзоров и поставок продукта
Описания вариантов использования или функциональных возможностей
системы, снабженные комментариями
Проектные схемы, при необходимости снабженные примечаниями
Эскизы экранов
Работающий код
Переносимый код
Тестовые варианты
Руководство пользователя
На усмотрение команды оставлены следующие вопросы, которые считаются
“частными”:
Шаблоны для рабочих продуктов
Стандарты кодирования и пользовательского интерфейса
Стандарты и детали регрессионного тестирования
Методология Crystal Clear требует обязательного создания документации
проекта. Но составные части документации не раскрываются. Этот вопрос оста-
242
Глава 6
ется на усмотрение разработчиков. Команда должна сообща решить, в каком
виде представить проектные решения своим будущим участникам.
Помимо компилятора, команде могут принадлежать следующие важные ин-
струменты:
Система управления версиями и конфигурациями
Печатающая белая доска
Вы должны суметь оправдать приобретение нескольких печатающих белых
досок для любого проекта, основываясь лишь на экономии того времени, которое
было бы потрачено на подготовку проектных документов, отчетов по совещаниям
и копирование содержимого белой доски.
Приемы, используемые отдельными ролями, полностью оставлены на усмот-
рение отдельных лиц.
Допускается замена элементов компонентами аналогичных методологий.
Например, команда могла бы решить использовать политику ограничения вре-
менными рамками (timeboxing) или динамического назначения приоритетов
Scrum или DSDM, ежедневные оперативные совещания из Scrum, парное про-
граммирование из ХР и т.д.
Размышления о Crystal Clear
Crystal Clear — это методология с низкой степенью формальности, предназначен-
ная для небольших команд и наиболее толерантная из известных мне работающих
методологий.
Она содержит следующие элементы, послужившие, как подтвердили мои со-
беседники, причиной ее успеха:
Особое внимание к близкому размещению и тесному общению
Частые поставки продукта
Обмен информацией с реальными пользователями
Средства контроля версий кода
Печатающая белая доска показала себя более ценным инструментом, чем
любые ее высокотехнологичные замены, возможно, исключая новейшее поколе-
ние фиксирующих содержимое белой доски программ (www.pixid.com). Обычно
люди приступают к обсуждению, думая, что его не имеет смысла записывать. По-
сле обсуждения они обнаруживают, что было бы хорошо иметь его запись.
Crystal Clear предоставляет место для отступления, если вы попробуете
ХР, но решите от нее отказаться. Каждую часть ХР можно заменить на Clear,
поскольку ХР соответствует всем стандартам Crystal Clear, кроме документа-
ции. Если вы переходите от ХР к Crystal Clear, вам придется добавить докумен-
тацию. Не думаю, что вы можете найти методологию, более небрежную, чем
Методологии семейства Crystal
243
Crystal Clear, но все-таки дающую вполне приличный шанс завершить проект
успешно.
Crystal Orange
Crystal Orange — это методология для проектов категории D40: до 40 человек, си-
дящих в одном здании, работающих над созданием системы, сбои которой могут
вызвать потерю дискреционных денег.
Crystal Orange требует больше командных структур и более значительной
координации команды, чем необходимо для проекта, в котором участвует 20 че-
ловек. Этой методологии недостает структур создания подкоманд, требующихся
для проекта на 80 человек, и в ней отсутствуют виды деятельности по контролю
проекта и кода, обязательного для критических систем.
Методологии Crystal Orange посвящены восемнадцать страниц описания в кни-
ге Surviving Object-Oriented Projects (Cockbum, 1998). Там она характеризуется
как полезная “для проекта среднего размера в промышленном окружении. Такой
проект имеет следующие характеристики:
Его штат составляет суммарно от 10 до 40 человек.
Его выполнение занимает от года до двух.
Время поставки на рынок существенно.
Есть потребность в коммуникации с настоящим и будущим персоналом,
а также потребность в сокращении срока и затрат.
Система не критична для жизни.
Это распространенный вид проекта, требующий компромиссов между дета-
льными конечными продуктами и быстрыми изменениями в требованиях и проек-
те. Число конечных продуктов я оставляю небольшим, чтобы сократить затраты
на их поддержку, но достаточным для общения в командах. Я приспособил рас-
пределение заданий и команды к изменениям, обычно неизбежным в проектах
такого типа. Многим другим видам проектов также требуется гибкость, и они мо-
гут воспользоваться преимуществами этой методологии”.
С учетом того, что методология тем лучше, чем она “легче” (до определен-
ных пределов), команда из 50 человек вместо применения Red-методологии,
предназначенной для 80 человек, может расширить Crystal Orange, добавив не-
сколько дополнительных элементов верификации и тестированйя.
Краткое описание Crystal Orange
В проекте определяются следующие роли:
Спонсор
Биснес-эксперт
244
Глава 6
Эксперт-пользователь
Специалист по техническим вопросам
Бизнес-аналитик/проектировщик
Менеджер проекта
Архитектор
Наставник по проектированию
Ведущий проектировщик-программист
Другие проектировщики-программисты
Проектировщик пользовательского интерфейса
Специалист по повторному использованию
Разработчик документации
Тестировщик
Они организованы в команды:
Системного планирования
Мониторинга проекта
Архитектуры
Технологии
Функций
Инфраструктуры
Внешнего тестирования
Самая крупная функциональная команда разбита на межфункциональные
группы с использованием стратегии “целостного разнообразия” (Cockburn,
1998). Каждая такая группа включает бизнес-аналитика/проектировщика, про-
ектировщика пользовательского интерфейса и от одного до трех проектировщи-
ков-программистов. Каждая группа также содержит проектировщика баз данных
и представителей других технологий (если они используются в проекте). В каж-
дую группу может входить тестировщик.
Структура команд должна регулироваться с учетом возможной нехватки от-
дельных специалистов. Сущность межфункциональных групп в том, чтобы сокра-
тить число конечных продуктов и расширить локальную коммуникацию.
Сотрудники оцениваются как одна группа, поэтому каждый видит свою цель в
том, чтобы вносить вклад при необходимости, а не только в соответствии с дол-
жностной инструкцией.
Методологии семейства Crystal
245
Рабочие продукты включают:
Документ с описанием требований
Последовательность версий
Календарный график
Отчеты о состоянии проекта
Проектный документ по пользовательскому интерфейсу
Общую объектную модель
Межкомандные спецификации
Руководство пользователя
Исходный код
Тестовые варианты
Переносимый код
Каждый рабочий продукт разрабатывается, пока не станет понятным колле-
гам, до уровня точности и стабильности, позволяющего представителям той же
специальности выполнять его экспертную оценку.
Стандарты проекта идентичны соответствующим стандартам в Crystal Clear,
не считая того, что интервал инкрементной поставки может быть расширен до
трех-четырех месяцев.
Как и в случае Crystal Clear, стандарты обязательны, но допускается эквива-
лентная замена, например при использовании стандартов Scrum, ХР или Adapti-
ve Software Development.
Шаблоны рабочих продуктов, стиль кодирования, стандарты пользователь-
ского интерфейса и особенности регрессионного тестирования оставлены как ло-
кальные стандарты на усмотрение команды. Приемы, используемые отдельными
ролями, целиком оставлены на усмотрение отдельных лиц.
Размышления о Crystal Orange
Crystal Orange — не такая структура, чтобы ее можно было навязать группе из де-
сяти человек. Она слишком “тяжела” для этого. Однако для 40 человек, работаю-
щих в трех или четырех технологиях, это очень “легкая” методология. Она
поддерживается за счет тесного общения внутри функциональных групп и посто-
янного участия пользователей в проекте.
Эта методология успешно использовалась. Опыт ее применения описан в от-
чете о проекте “Winifred” в книге Surviving Object-Oriented Projects (Cockburn,
1998).
Хотя я охотно использовал бы основные принципы этой методологии снова,
но технология изменилась, и поэтому специалисты, появляющиеся в настоящее
246
Глава 6
время, отличаются от тех, что были тогда; их рабочие продукты и потребности во
взаимодействии стали другими. Кроме того, узкие места в следующем проекте,
вероятно, будут не такими, как в проекте “Winifred”.
В новом проекте я стал бы использовать Crystal Clear как базовую методо-
логию, приспособив ее и используя описанные ранее приемы адаптации мето-
дологии.
Crystal Orange Web
Crystal Orange Web — методология, созданная нами для eBucks.com, компании,
поставляющей код в Web. Она отличается от Crystal Orange тем, что имеет дело не
с одним проектом, а с непрерывным потоком проектов, требующих программиро-
вания, и с результатами каждого проекта, которые объединяются с растущим
основным кодом, доступным для всеобщего использования.
Эта методология все еще проходит пробное использование. Я ее включаю
сюда по следующим причинам:
Все возрастающее число компаний оказываются в подобной ситуации.
Она представляет собой самое последнее применение идей этой книги.
Ее форма отличается от Crystal Orange.
Ситуация с компанией eBucks.com была интересна и по другой причине (пер-
вое — это постоянный поток запросов от различных групп клиентов). Эта компа-
ния уже упрочила свое присутствие в Web. На нее больше не давит необходимость
быстрее попасть на рынок, но она начинает испытывать давление от затрат, свя-
занных с устранением дефектов. Запросы от клиентов, число которых растет экс-
поненциально, легко могли бы свести на нет всю прибыль. Таким образом,
компания изменила свой главный приоритет от продуктивности к бездефектности.
В данном случае нужно координировать работу приблизительно 50 человек:
руководителей, специалистов по бизнесу, менеджеров, аналитиков, программи-
стов и тестировщиков. Этой ситуации я присвоил категорию Е50.
Это сравнительно новая группа, поэтому необходимо было прояснить опре-
деления некоторых процессов: кто и какие решения принимал, кто кому и какую
информацию передавал. Во всем остальном люди обычно знали, с кем им нужно
переговорить, чтобы их работа была сделана.
Как предусматривает адаптация методологии, я провел несколько интервью.
Я беседовал с людьми в каждой рабочей роли, начиная со службы маркетинга до
тестирования и эксплуатации. Эти интервью выявили следующие факты:
* Конвекционные потоки информации были довольно хорошими. Вся коман-
да размещалась на одном этаже. Их места разделялись подвижными стеклянны-
ми перегородками и белыми досками, поэтому они могли видеть друг друга,
обмениваться знаками и в то же время имели некоторую возможность для уеди-
нения.
Методологии семейства Crystal
247
Постоянные отвлечения лишали сотрудников тихого времени, необходимо-
го для выполнения своих заданий (во всех рабочих ролях). Каждый сотруд-
ник работал над несколькими проектами, но был вынужден постоянно
прерывать работу.
Отношение, дружелюбие и моральное состояние были все еще вполне хоро-
шими, но ухудшались из-за частых перерывов и недостаточного продвижения
в работе. Кроме того, программисты сидели с одной стороны здания, а специ-
алисты по бизнесу — с другой. Это означало, что разговоры в каждой из этих
групп не обходились без негативных комментариев о другой группе.
Компания существовала менее года, и это означало, что старые привычки
еще не укоренились в ней, а люди были открыты к изобретению нового по-
рядка работы и новых соглашений.
Краткое описание Crystal Orange Web
Придерживаясь идеи о методологии как о наборе соглашений, которые принимает
группа, мы включили в нее набор соглашений, разбитый на пять следующих кате-
горий:
1. Регулярные циклы с обучением
Назначение этой категории состоит в определении основной процедуры получе-
ния ответа на вопрос: “Как нам работается?” и выделения времени на обдумыва-
ние и усовершенствование. Каждое соглашение, кроме проведения самого
рабочего семинара в конце каждого цикла, может изменяться по результатам ра-
бочих семинаров.
1.1 Двухнедельные циклы разработки. Все производство выполняется цик-
лами разработки, имеющими фиксированную продолжительность в две
недели. После каждой поставки каждая команда может выбрать время
следующей поставки через две или четыре недели в зависимости от того,
что она может поставить для использования в Web. Каждая команда
обязана поставлять что-либо полезное для общего использования каж-
дые четыре недели.
1.2 . Рабочий семинар в конце цикла, объявление полученных предложений.
В конце каждого цикла компания собирается и обсуждает, что работает
хорошо, что не работает должным образом и какие идеи нужно попробо-
вать в следующем цикле. В результате собрания появляется и объявля-
ется всем перечень полезных приемов.
2. Базовый процесс
Эта категория должна зафиксировать, кто какие части работы выполняет и кто ка-
кие решения принимает; ее цель — избегать дублирования или разрывов в работе
248
Глава 6
и заглядывать достаточно далеко вперед, чтобы раньше заметить возможные
проблемы. Процесс предназначен для поставки бизнес-проектов в Web.
2.1 Владелец бизнес-проекта кратко описывает вариант использования с точ-
ки зрения бизнес-процессов и системный вариант использования (Cock-
burn, 2001с). Вариант использования для бизнеса иллюстрирует
предлагаемые новые системные возможности в действии, обращая особое
внимание на неавтоматизированные бизнес-процессы, возникающие в ре-
зультате неправильной работы системы.
2.2 Краткое описание используется технологической группой для оценки
объема работы по реализации этой функции. Прежде чем соглашаться
на дальнейшую работу, руководители выполняют рецензирование вари-
антов использования для бизнеса, оценку технологической группы и
значимости проекта. Проектировщики пользовательского интерфейса
работают со службой маркетинга и бизнес-аналитиками, чтобы вклю-
чить эти функции в общий процесс работы, а затем создать эскизы экра-
нов и описания на XML.
2.3 . Бизнес-аналитики создают детализированные описания вариантов ис-
пользования и данных, которые передаются проектировщикам пользо-
вательского интерфейса, программистам серверной части и програм-
мистам сервлетов. Программисты сервлетов создают сервлеты на осно-
ве описаний XML для пользовательского интерфейса, вариантов испо-
льзования, описаний данных и интерфейсов сервера. Программисты
сервера и сервлетов создают регрессионные тесты для своего кода и со-
вместно выполняют тестовые варианты. Когда тестовые примеры при-
знаны годными и код выдерживает проверку тестами, он передается для
интеграционного тестирования. Тестировщики донимают разработчи-
ков, заставляя их исправлять любые оставшиеся ошибки, обнаружен-
ные до размещения кода на сайте.
2.4 Тестировщики, выполняющие интеграционное тестирование, направ-
ляют изменения, распространяемые в новой версии, во внутреннюю
группу, а также в центр обработки запросов.
2.5 По размещенному на сайте коду центр обработки запросов возвращает
отчеты об ошибках в специальную SWAT-команду, чьей единственной
задачей является устранение проблем. SWAT-команда формируется из
группы разработки каждые две недели путем ротации.
3. Максимальное продвижение, минимальные отвлечения
Цель соглашений этой категории — обеспечить, чтобы сотрудники работали над
задачами, представляющими для компании наибольшую ценность, имели время
сосредоточиться на этой работе и делали в ней успехи.
Методологии семейства Crystal
249
3.1 Основные корпоративные проекты получают приоритеты и явно объяв-
ляются для каждого двухнедельного цикла производства. Они назнача-
ются отдельным лицам, чтобы каждый человек знал две-три приори-
тетных лично для него работы за весь цикл.
3.2 Работа разбита на части, которые могут быть завершены и протестиро-
ваны за двухнедельные циклы, и разбивается далее на более мелкие ча-
сти, которые можно выполнить за один-три дня. Каждый сотрудник,
работающий над несколькими проектами, гарантированно получает на
один проект хотя бы два последовательных дня и не может в это время
быть назначен на другое задание.
3.3 На белых досках, находящихся за стенами их комнат, разработчики пока-
зывают текущее состояние работы, которую они планируют завершить в
данную неделю. Каждое утро разработчики встречаются с владельцем те-
кущего рабочего проекта. Они проводят короткое совещание для опреде-
ления текущего состояния работы, ее основных приоритетов и
обсуждения любых вопросов. Все остальное время владельцу проекта не
разрешается снова задавать вопросы о состоянии. Каждый день период с
10:00 до 12:00 объявлен “временем сосредоточения”. В этот период не
проводится собраний, и каждый сотрудник компании может выключить
телефон.
4. Максимальная бездефектность
Цель соглашений этой категории — создать культуру “ликвидации ошибок на месте”.
4.1 Каждый класс сервера и сервлета сопровождается набором автомати-
зированных регрессионных модульных тестов, написанных программи-
стом для его собственного кода с использованием JUnit, HttpUnit или
эквивалентных средств. Программисты лишь тогда отдают свой код для
интеграционного тестирования, когда их тесты выдержали тщательную
проверку другого такого же разработчика. Тестировщик, выполняющий
интеграционное тестирование, получает от другого программиста код,
тестовые варианты и комментарий, в котором говорится, что тот руча-
ется за качество тестов.
4.2 Сервер содержит механизм циклической проверки, поэтому тестиров-
щики, выполняющие интеграционное тестирование, могут поддержи-
вать свою собственную контролируемую базу данных тестов (которой
могут пользоваться и другие).
4.3 Для описания своих транзакций и ожидаемых результатов бизнес-экс -
перты используют предельно простой язык. Этот язык позволяет тести-
ровщикам, владельцам проекта и разработчикам сервлетов создать
тестовый сценарий проверки и включить его в базу данных тестов.
250
Глава 6
4.4 Статистика щелчков мышью для экранов, собранная в центре обработ-
ки запросов, вывешивается на видном месте, чтобы каждый мог видеть,
где посетители сайта сталкиваются с трудностями (проблемами навига-
ции или проблемами, вызванными программными ошибками).
5. Сообщество, ориентированное на диалог
Назначение этой категории — указать долгосрочную цель, к которой стремится
компания.
5.1 В конечном счете программисты, проектировщики пользовательского
интерфейса, тестировщики, владельцы проектов, специалисты по мар-
кетингу и другие специалисты должны объединиться в межфункциона-
льных командах, чтобы максимально увеличить эффект диалога по
поводу распространения проектов через границы специальностей и све -
сти к минимуму распространение слухов о представителях других про-
фессий. При этом должен соблюдаться баланс между уровнем
обеспеченности кадрами и растущими потребностями в рабочем про-
странстве.
Размышления о Crystal Orange Web
В этой методологии меня поражают две вещи.
Первая — это уменьшение роли процесса и рабочих продуктов. Они присут-
ствуют, но занимают лишь часть пространства, обычно выделяемого им.
Вторая неожиданность — это полнейшее отсутствие параллельной разра-
ботки, одного из моих излюбленных приемов ускорения работы. Параллельная
разработка отсутствует из-за узких мест в системе.
У программистов накопилось огромное отставание в работе, у них отсутст-
вовал резерв производительности, и их работу постоянно прерывали. Сотруд-
ники компании были совершенно неопытны как разработке ПО, так и в
предметной области. Два этих момента вместе означали, что программисты не
могли вести перекрывающуюся разработку и хранить требования в устной фор-
ме. От информации им нужна была “устойчивость”, т.е. им не хватало записан-
ных спецификаций.
Со временем это должно измениться. Когда это случится, я надеюсь, что они
сократят объем бумажной работы и увеличат диалоговое общение. А пока им
нужна бумага.
Шесть месяцев спустя
Я представляю эту методологию в том виде, в котором она была создана в качестве
стартовой методологии. Со временем мы должны ожидать некоторого сдвига, по-
скольку сотрудники будут придумывать новые способы работы и начнут отклонять-
ся от строгой дисциплины установленного порядка.
Методологии семейства Crystal
251
Через шесть месяцев Майкл Джордаан (Michael Jordaan), руководитель
eBucks.com, так прокомментировал рабочие привычки группы:
“Очевидно, что после вашего ухода некоторая дисциплинированность оста-
лась, хотя отдельные приемы не выдержали испытания.
Остались двухнедельные циклы с тщательным планированием времени за-
вершения, что помогает разработчикам и владельцам проектов планировать, тес-
тировщикам — досконально тестировать, а заказчикам — авансом получать
информацию о запланированных модернизациях.
Мы обсуждали трехнедельные циклы, но сочли это слишком долгим сроком.
Более сложные задачи, которые нельзя решить за две недели, выполняются за
два цикла (четыре недели), но мы продолжаем поощрять инкрементную разра-
ботку.
Проведение совещаний в конце цикла строго соблюдается, и это стало одним
из немногих мероприятий, когда мне удается поговорить со всей командой. Я взял
себе за правило отдавать дань тем, кто участвовал в успешных модернизациях. Бу-
дем надеяться, что публичное признание дает хорошую мотивацию. На каждом со-
вещании мы обсуждаем ошибки, предложения по улучшению и тем самым
поддерживаем создаваемую нами культуру обучения.
Качество кода, размещаемого на сайте, чрезвычайно возросло, поскольку
команда тестировщиков обладает правом вето и не допускает плохой код к разме-
щению на сайте (а это могло бы поставить нас в неудобное положение).
SWAT-команда, которая должна сокращать число ошибок в работающем
коде, также сделала большие успехи, отвечая на запросы клиентов и центра об-
работки запросов.
Мы до сих пор твердо придерживаемся времени сосредоточения (ка>вдое
утро в 10:00 у нас все так же звонит звонок). Если в какой-то день я должен
обойтись без этих двух часов, я начинаю паниковать, настолько полезно это ока-
залось.
Некоторые приемы не прижились, например обычай вывешивать на доске
текущие приоритеты и продвижение работы. Возможно, вопрос о помехах работе
не стоит теперь так остро, поскольку люди стали работать на дому, и, наверное,
отношения между владельцами проектов и разработчиками стабилизировались.
Может быть, люди просто ленятся.
Большинство разработчиков в каждый момент имеют не больше трех
задач, не считая двух ключевых специалистов, работающих со вспомо-
гательной системой. Их перечень задач легко доходит до пятнадцати
для каждого. Более того, их все еще отвлекают проблемы, возникаю-
щие на сайте, которые мешают им завершать их задачи и срывают пла-
ны других разработчиков и бизнес-экспертов.
Проблема здесь в нехватке квалифицированных кадров. Это вековая
проблема: подготовка специалистов, несомненно, является верным
252
Глава 6
решением в среднесрочной перспективе, хотя требует больше време-
ни, чем просто выполнение всей работы самостоятельно".
В этих комментариях я с некоторым удовлетворением отметил, что команда
по-прежнему использует основные элементы процесса: циклы с обучением и по-
иск способов изменить даже эти циклы так, чтобы они лучше соответствовали их
потребностям.
Я заметил, что способности и квалификация критичны для этого проекта, и
обратил внимание, что люди отошли в сторону от тех приемов, которые, вероят-
но, были лишь излишествами методологии.
Что дольше?
Используете ли вы семейство Crystal или нет, повысьте в вашем проекте значение
морального состояния и коммуникации, чтобы люди обменивались информацией
немного лучше. Это относится к любой базовой методологии.
Привлеките ваших опытных разработчиков, находящихся на уровне 2, к со-
зданию методологии. Если в вашей команде нет сотрудников этого уровня, то:
Изучите базовую методологию
Начните проводить рабочие семинары, чтобы кто-либо скорее поднялся до
уровня 2
Сравните то, что делает ваша команда, с тремя образцами методологии, при-
веденными в данной главе. Выберите несколько идей и примените их к своему
проекту.
Приложение А____________________________________________
Манифест быстрой
разработки программного
обеспечения
“Мы открываем лучшие способы разработки ПО, создавая его сами и помо-
гая другим. Благодаря этой работе мы стали ценить:
Индивидуумов и взаимодействия выше процессов и инструментов
Работающее ПО выше всеобъемлющей документации
Сотрудничество с заказчиками выше согласований условий договора
Реагирование на изменения выше соблюдения плана
Это означает, что, хотя элементы в правой части также имеют свою
ценность, но больше мы ценим элементы, расположенные слева".
В начале 2001 г. семнадцать сторонников “легковесных” процессов разра-
ботки собрались в штате Юта, чтобы обсудить, есть ли у них что-либо общее или
имеются только разные точки зрения. Одним из них был я.
Мы согласились, что в слове “легковесный” заключено слишком много про-
тивопоставлений и недостаточно веры. Сойдясь во взглядах на важность способ-
ности реагировать на меняющиеся требования в пределах временных рамок
проектов, мы выбрали слово “быстрый” (agile).
Мы согласились с четырьмя ценностями, приведенными выше, и с дюжиной
принципов, поддерживающих эти ценности. Мы пришли к общему мнению, что
не заинтересованы в дальнейших поисках согласия за пределами этой области.
Нашу группу мы назвали “Быстрый альянс” (Agile Alliance).
В данном приложении обсуждаются наша встреча, эти ценности и принципы.
254
Приложение А
Быстрый альянс
Наша встреча состоялась в феврале 2001 г. в местечке Snowbird, штат Юта.
Семнадцатью участниками встречи были: Кент Бек, Майк Бидл (Mike Beed-
1е), Ари ван Беннекам (Arie van Bennekum), Алистер Коберн, Уорд Каннингем,
Мартин Фаулер, Джеймс Греннинг (James Grenning), Джим Хайсмит, Эндрю
Хант, Рон Джеффрис, Джон Керн (Jon Kern), Брайен Мейрик (Brian Marick), Ро-
берт Мартин, Стивен Меллор (Stephen J. Mellor), Кен Швабер, Джефф Сазер-
ленд и Дейв-"Прагматик" Томас (Dave “Pragmatic" Thomas). (Если бы Дейв
Томас из Object Technology International смог присоединиться к нам в ту неделю,
мы имели бы в числе подписавших сторон аж двух Дейвов Томасов!)
Каждое присутствовавшее лицо имеет свою версию встречи. Мой вариант
излагается в этом приложении (но я передал этот текст всем остальным).
Мы встретились, чтобы понять, нет ли чего-либо общего между различными
“легкими” методологиями: Adaptive Software Development, ХР, Scrum, Crystal,
Feature-Driven Development, Dynamic System Development Method (DSDM) и
“прагматическим программированием".
Кент Бек, Уорд Каннингем, Рон Джеффрис, Джеймс Греннинг и Роберт
Мартин внесли свое представление об ХР вместе со своим значительным опытом
и собственными личными пожеланиями.
Мартин Фаулер описал продолжительный опыт работы с ХР и опыт оценки
методологий вообще.
Джим Хайсмит представил Adaptive Software Development и идеи, связанные
со свойствами сложных адаптивных систем.
Сам я защищал свои интересы по вопросам “методологии для проекта" и свое-
временного создания методологии.
Джефф Сазерленд, Кен Швабер и Майк Бидл представили Scrum (Schwa-
ber, 2002).
Джон Керн из TogetherSoft представил Feature-Driven Development — ме-
тод, описанный в Java Modeling in Color with UML (Coad, 1999).
Ари ван Беннекам из Нидерландов представил DSDM (Stapleton, 1997).
Энди Хант и Дейв-"Прагматик" Томас, авторы книги The Pragmatic Pro-
grammer, защищали интересы опытных программистов, не присоединившихся
ни к одному методу.
Брайен Мейрик представил перспективы тестирования ПО.
Стивен Меллор присутствовал, чтобы защищать свои интересы в управляе-
мой моделями разработке (model-driven development). Возможно, он был удив-
лен больше всех, обнаружив, что может согласиться со значительной частью
того, что говорилось на встрече, и подписать как манифест, так и принципы.
Приглашения были направлены также другим лицам, и они, разумеется,
внесли бы свой вклад и подписали документы, но здесь перечислены лишь те, кто
присутствовал на встрече, спорил, участвовал в составлении соглашений и под-
писывал их.
Манифест быстрой разработки программного обеспечения
255
Вопреки всему, мы надеялись, что действительно сможем прийти к како-
му-либо согласию.
Ни один из нас не был особенно заинтересован в объединении различных
подходов для создания “унифицированной легкой методологии” (ULM). При та-
ком уровне индивидуализма на встрече можно только удивляться, что мы с
чем-то согласились.
Мы пришли к общему мнению по четырем пунктам:
На первом уровне мы согласились с необходимостью реагировать на из-
менения. “Быстрота” отражает наши намерения и позволяет рассматри-
вать более “тяжелые” методологии для крупных и критически важных
проектов.
На втором уровне мы согласились с четырьмя основными ценностями, опи-
санными в манифесте.
На третьем уровне мы согласил ись (едва - едва) с двенадцатью более деталь-
ными формулировками, согласующимися с этими четырьмя ценностями.
Было ясно, что мы не придем к согласию на четвертом уровне — по поводу
детальной тактики разработки проекта. Мы согласились, что это благо-
творно для нашей отрасли и мы должны продолжать вводить новшества и
соперничать в мире идей, чтобы открыть более широкий набор “быстрых”
методов в области ПО.
С этими четырьмя соглашениями, приняв термин “быстрый”, семнадцать че-
ловек создали “Быстрый альянс”.
Манифест
Рассмотрим формулировки манифеста более внимательно.
“Мы открываем лучшие способы разработки ПО, создавая его сами и
помогая другим”.
Мы (участники группы) — практикующие специалисты в области разработ-
ки ПО, а не просто сторонние наблюдатели, сочиняющие правила для других.
Мы чувствуем, что не придумали методы, а “открыли” их и хотим ясно заявить,
что будем продолжать работу, помогая и рассказывая.
“Благодаря этой работе мы стали ценить...”
Эти идеи возникли не в вакууме, а являются резул* татом нашего непосред-
ственного опыта и размышлений об этом опыте.
Прежде чем перечислять четыре выбора, я забегу г:.сред и напомню заклю-
чительное предложение:
256
Приложение А
“Это означает, что, хотя элементы в правой части также имеют свою
ценность, но больше мы ценим элементы, расположенные слева”.
Мы не заинтересованы в полном сносе здания разработки ПО. Мы понима-
ем, что инструменты, процессы, документация, договоры и планы имеют свою
ценность. Но мы хотим выразить, что в случае самой крайней необходимости (а
это самая обычная ситуация) чем-то нужно пожертвовать. Мы чувствуем, что
люди, находящие поддержку в позициях с правой стороны перечня, не справятся
с работой так же хорошо, как те, кто выбирает левую сторону.
Мы также хотим признать, что некоторые специалисты не соглашаются с не-
которыми или всеми нашими выборами. Увидев наш перечень, один из них сказал:
“Я могу согласиться с тремя из четырех”. Мы согласны, что такого рода расхожде-
ние во мнениях может привести к конструктивному диалогу.
Для “быстрой” методологии не существует противоположности, как нет ее
для бенгальского тигра. У “быстрых” методологий существуют альтернативы, ха-
рактеризуемые по их системам ценностей: “повторяемые”, “размеренные”,
“предсказуемые” и даже “капризные” методологии.
Надо понимать, конечно, что все эти названия указывают на успешные вер-
сии, созданные на практике. Возможно, лучшими терминами были бы “претен-
дующая на быстроту”, “претендующая на предсказуемость” и “претен-
дующая на повторяемость” разработка.
Лично для меня важно оставить место для несогласия по этим вопросам.
Наша отрасль до сих пор не может прийти к согласию в том, что важно для
успешной разработки ПО. В настоящее время лучший подход — просто сказать,
кто что поддерживает. Очевидно, этот момент важен и для других лиц, подписав-
ших манифест.
Имея это в виду, посмотрим на наши четыре выбора:
“Индивидуумы и взаимодействия выше процессов и инструментов”.
Первая ценность связана с участниками команды, противопоставляемыми
ролям на схеме процессов. Хотя для того, чтобы группа людей могла начать дей-
ствовать, требуется описание процесса, но мы видели, что люди незаменяемы,
как устройства, вставляемые в контактные гнезда.
Второй выбор, выдвигаемый здесь на первый план, связан с взаимодействи-
ями мелщу индивидуумами. Новые решения и дефекты в старых решениях обна-
руживаются в обсуждениях, протекающих между людьми. И качество
взаимодействий имеет значение.
В действительности более совершенное сообщество извлекает выгоду из
разработки, построенной вокруг процесса, в такой же степени, как из хаотичной
разработки.
В первой ценности выражено, что мы скорее будем использовать недокумен-
тированный процесс с хорошими взаимодействиями, чем документированный
процесс с недружественными взаимодействиями.
Манифест быстрой разработки программного обеспечения
257
“Работающее ПО выше всеобъемлющей документации”.
Только работающая система может рассказать, что сделано командой. Рабо-
тающий код беспощадно честен.
Документы, описывающие требования, анализ, проектирование, последова-
тельность экранов, диаграммы последовательности взаимодействий объектов и
прочее, удобно использовать как подсказки. Участникам команды они помогают
размышлять о собственном опыте и предположить, каким будет будущее. Доку-
менты служат метками в игре, используемыми для построения образа неизвест-
ного будущего.
С другой стороны, коллективная деятельность, включающая сбор требова-
ний, проектирование, кодирование и отладку ПО, выявляет информацию о
команде разработчиков, о процессе разработки и природе решаемой задачи. Эти
вещи совместно с работающим конечным результатом представляют единствен-
ную надежную меру скорости работы команды, недостатки группы и взгляд на то,
что команда в реальности должна строить.
Как мы видели, документы могут быть очень полезными, но они должны ис-
пользоваться в количестве “как раз достаточные” и “едва достаточные”.
“Сотрудничество с заказчиками выше согласований условий договора”.
Третья ценность описывает отношения между теми, кто хочет, чтобы ПО было
создано, и теми, кто создает ПО. Различие таково, что в “быстрой” разработке, ор-
ганизованной должным образом, нет разделения на “мы” и “они”, а есть только мы".
Сотрудничество имеет отношение к сообществу, дружелюбию, совместному
принятию решений, скорости коммуникации и взаимодействием индивидуумов.
Внимание к сотрудничеству с заказчиками указывает на дружелюбные взаимоот-
ношения (не исключающие конфликты, как объясняется в главе 3) между разны-
ми специальностями и через организационные границы. Выражение “есть только
мы” означает, что и те и другие стремятся к производству полезного ПО.
Хотя иногда договоры полезны, сотрудничество усиливает разработку и ког-
да договор заключен, и когда никакого договора не существует. Доброе сотрудни-
чество может спасти ситуацию с договоров если он оказывается в опасности.
Доброе сотрудничество может иногда сделать договор необязательным. В любом
случае сотрудничество — это решающий элемент.
“Реагирование на изменения выше соблюдения плана”.
Последняя ценность связана с вопросами приспособления к изменениям,
быстро разрушающим проект.
Создание плана полезно, и каждая из “быстрых” методологий содержит спе-
цифические виды планирования. Они также включают механизмы, позволяющи-
еся справиться с меняющимися приоритетами.
258
Приложение А
Методологии Scrum, DSDM и Adaptive Software Development требуют раз-
бивать разработку на ограниченные по времени блоки с пересмотром приорите-
тов после (не внутри) каждого блока (ХР допускает изменение приоритетов
внутри временного блока). Продолжительность временных блоков находится в
диапазоне от двух до четырех недель. Создание временных блоков гарантирует,
что команда получает время и душевное спокойствие для создания работающего
ПО. Сравнительно короткие фазы разработки, которые в Scrum называются
“рывками” (sprints), позволяют спонсорам проекта изменять приоритеты в соот-
ветствии со своими потребностями.
Создание плана полезно. Ссылки на план важны, пока он не оказывается
слишком далек от текущей ситуации. Стараться сохранить устаревший план не-
практично.
Размышления о манифесте
Потребность в разных способах работы в разных ситуациях не включена в мани-
фест, но этот момент Джим Хайсмит и я всегда держим в голове.
Быть “быстрым” в проекте на 100 человек — это совсем не то же самое, что
в проекте для десяти человек. “Быстрый” проект на 100 человек будет использо-
вать более “тяжелую” методологию, чем “быстрый” проект для десятерых. Это
соответствует принципам создания методологии, представленным в главе 4.
Конечно, придерживаясь принципов создания методологии, может иметь
смысл удалить 90 человек из проекта на 100, сохранить десять лучших специали-
стов и затем выполнить “быстрый” проект для десяти человек, который сможет
привести к созданию той же самой системы в тех же временных рамках.
Суть заключается в нашем согласии, что число методологий исчисляется не
единицами, а десятками, причем каждая из них настраивается на конкретную си-
туацию, имеющийся проект, и каждая из них — “быстрая”. Эта мысль в манифе-
сте не зафиксирована.
Некоторые из тех, кто подписал манифест, рекомендуют “быстрые” методо-
логии в первую очередь для особенно напряженных ситуаций. Мой опыт подска-
зывает, что серьезные неожиданности возникают даже в казалось бы стабильных
проектах. Я все еще жду встречи с ^ким проектом, чтобы ценности “быстрых”
методологий оказались излишними.
Поддержка ценностей
Группа семнадцати согласилась с выбором этих ценностей. Разработка следующе-
го уровня положений оказалась более чем продуктивной, учитывая остававшееся в
нашем распоряжении время. Ценности, включенные в этот раздел, составляют те-
кущий рабочий набор.
Эти положения должны развиваться, по мере того как мы будем узнавать о вос-
приятии людьми наших высказываний и сами обдумывать более точные их вариан-
Манифест быстрой разработки программного обеспечения
259
ты. Меня ничуть не удивит, если эта конкретная версия перестанет быть актуальной
вскоре после публикации данной книги. Самую последнюю версию вы можете уз-
нать на сайте www.AgileAlliance.org.
Мы не рассчитываем прийти к согласию по следующему уровню рекоменда-
ций, который относится к тактике проекта: какой объем архитектуры разрабаты-
вается в какое время, какие инструменты нужно использовать, а каких избегать и
т.д. Каждый из нас имеет собственный опыт, свои страхи, желания, философию,
и все это накладывает свой отпечаток на нашу практическую деятельность и ре-
комендации. Наши рекомендации различаются некоторыми особенностями.
Далее приведены положения, с которыми мы согласились, и мой коммента-
рий к каждому их них.
1. Нашей наиболее приоритетной задачей является выполнение заказа
посредством ранней и частой поставки полезного ПО.
Мы заинтересованы поставлять ПО, соответствующее своему назначению.
Как ни странно, некоторые компании, кажется, в действительности не ценят по-
ставку ПО. “Быстрая” разработка сосредоточена на поставке конечного продукта.
Ранняя поставка позволяет одерживать маленькие победы и получать ран-
нюю обратную связь по требованиям, команде и процессу, как мы неоднократно
видели в данной книге.
Частые поставки приносят команде непрерывные победы, быструю обрат-
ную связь и своевременные изменения направления и приоритетов проекта.
Интервалы между поставками должны согласовываться от проекта к проек-
ту, поскольку ежедневные или еженедельные обновления могут причинить поль-
зователям большие беспокойства. Если пользователи не могут осваивать
изменения в системе каждые три месяца, команде проекта необходимо придумать
какой-то другой способ, чтобы получать обратную связь и обеспечивать постоян-
ный рабочий процесс с тестированием и интеграцией.
Это положение придает особое значение поставке тех элементов, которые
имеют огромную ценность для заказчиков. С переменами в настроении потреби-
теля, напряженной конкуренцией и колебаниями на фондовой бирже для проекта
практически невозможно гарантировать приток доходов, если для поставки тре-
буется год или более долгий срок.
Это положение показывает, что ценность достигается рано, поэтому, если
спонсоры лишатся финансирования, они не останутся с кипой долговых обяза-
тельств, но будут иметь работающее ПО, дающее покупателям что-либо ценное.
2. Поставлять ПО часто, с интервалами от пары недель до пары месяцев,
отдавая предпочтение более короткой временной шкале.
Половина “ранней и частой” поставки определяет длины рабочих циклов.
Однажды мне встретился проект, в котором использовалась инкрементная раз-
работка четырехмесячными циклами, но в большинстве проектов используются
260
Приложение А
циклы от одного до трех месяцев. Более короткие циклы используются редко, по-
скольку пользователи обычно не могут получать изменения так часто.
В проекте Winifred (Cockburn, 1998), договоре с фиксированной стоимо-
стью, 50 исполнителями, рассчитанном на восемнадцать месяцев, мы установили
для поставок пользователям трехмесячные циклы. Понимая, что это слишком
длинные циклы, чересчур редко дающие обратную связь, мы добились, чтобы не-
сколько пользователей-экспертов приходили к нам и могли в течение цикла
двавды выполнить рецензирование работающего кода. Эти два пользователь-
ских рецензирования планировались гибко, как правило, около шестинедельной
и восьминедельной отметок.
Если пользователи могут принимать изменения каждый месяц, а команда
разработки может удовлетворять текущие запросы на изменения, то, чем короче
цикл обратной связи, тем лучше.
3. Работающее ПО — основной критерий продвижения вперед.
Это третье упоминание работающего ПО. Принцип выражает мысль твердо:
доверять работающему коду, а не долговым обязательствам в форме планов и до-
кументов. Вы можете пользоваться и другими критериями продвижения, но на
работающий код можно полагаться.
“Быстрые” методологии вознаграждают быструю разработку, раннее полу-
чение работающего кода и постепенное его развитие. Не все проекты в равной
степени поддаются крошечным эволюционным изменениям. Чтобы решить, как
разбить гигантскую архитектуру крупного проекта на мелкие части, которые
можно разрабатывать и тестировать инкрементно, требуется выполнить некото-
рую работу. Однако сделать это можно, и результат стоит затраченных усилий.
Стивен Меллор осмотрительно указал, что при разработке, управляемой мо-
делями, следует демонстрировать два образца работающего кода. Один — это
выполняемая модель, оцениваемая на предмет соответствия потребностям поль-
зователя. Другой образец работающего кода представляет алгоритм генерации
окончательного кода. Во втором труднее выявить ошибки. Многие проекты со-
здавали превосходную выполнимую модель, но не могли вовремя добиться кор-
ректной работы алгоритма, генерирующего код.
4. Приветствуются изменения требований даже на поздних стадиях разра-
ботки. В “быстрых” процессах изменения используются, чтобы заказ-
чик добился преимуществ в конкуренции.
“Быстрые” процессы могут справиться с поздними изменениями требований
именно из-за ранней и частой поставки работающего ПО, применения итераций
и временных блоков, постоянного внимания к архитектуре и готовности обнов-
лять проект.
Если ваша компания может быстро поставлять ПО и реагировать на послед-
нюю поступившую информацию, а ваш конкурент этого не может, то ваша ком-
пания будет иметь преимущество на рынке.
Манифест быстрой разработки программного обеспечения 261
Все “быстрые” методологии обладают неким механизмом, включающим
поздние изменения в требования. Детали различаются для разных методологий.
5. Бизнес-эксперты и разработчики работают совместно на протяжении
всего времени выполнения проекта.
Наша отрасль изобилует проектами, спонсоры которых не позаботились полу-
чить то, что им было нужно. Фрейкс и Фокс сообщают об исследовании, показыва-
ющем тесную взаимосвязь между взаимодействием с пользователями и успехом
или неудачей проекта (Frakes, 1995).
Лучшие связи устанавливаются через бизнес-экспертизу на месте и еже-
дневные обсуждения, чего и требует данное положение. Слово “ежедневный”
определяет эффективный участок, где при необходимости ведутся обсуждения
ведутся. В большинстве проектов проводить ежедневные обсуждения непрак-
тично, и это означает, что такие проекты не расположены на эффективных
участках. Положение указывает, что, чем больше времени требуется на полу-
чение информации от заказчиков или разработчиков, тем больше убытков не-
сет проект.
6. Проекты следует выстраивать вокруг инициативных личностей. Обес-
печьте им необходимую среду, поддержку и доверьте выполнение ра-
боты.
В большей степени нам хотелось бы видеть инициативных, квалифициро-
ванных людей, умеющих хорошо общаться и не использующих никаких процес-
сов, чем строго определенные процессы, используемые людьми без
инициативы. История Ди Хока о ранней версии системы VISA служит тому яр-
ким примером.
Индивидуумы заставляют проекты работать. Их мотивация связана с гордо-
стью за свою работу, дружелюбием и сообществом, возникшим вокруг проекта.
Впервые это заявление я услышал в интервью с Дейвом А. Томасом, в то
время президентом очень успешной компании Object Technology International.
Он сказал: “Мы нанимаем хороших специалистов, даем им необходимые для ра-
боты инструменты и обучение, а затем отходим в сторону и не мешаем работать”.
Я постоянно нахожу подтверждения его рекомендации.
7. Наиболее эффективным способом передачи информации внутри коман-
ды разработчиков является общение лицом к лицу.
Это заявление непосредственно вытекает из глав 3 и 4 данной книги. Я не
буду здесь повторять все предостережения. Просмотрите эти главы, если вы
впервые открыли книгу в этом месте.
8. Лучшие архитектуры, требования и проекты появляются в самооргани-
зующихся командах.
262
Приложение А
У нас состоялась небольшая дискуссия по поводу подбора слов для изложе-
ния этого принципа. Что мы подразумеваем под термином “самоорганизующаяся
команда”: полностью самоорганизующаяся или просто принимающая полезные
идеи от какого-либо участника проекта? Что значит “появляются”: появляются
таинственно или постепенно, маленькими шажками или как логическое следст-
вие используемых командой правил?
Я предпочитаю средний из этих трех вариантов, а Хайсмиту ближе послед-
ний, третий. Никто из нас не назвал первое значение, которое идет от неверного
понимания слова “появляющийся” в смысле “неожиданный”. Наша общая точка
зрения заключается в понимании того, что детали проектирования системы удив-
ляют даже самых опытных проектировщиков.
Мы настаиваем, что архитектуру, так же как требования и процесс, со време-
нем можно регулировать. Архитектура, зафиксированная слишком крепко и слиш-
ком рано, не сможет приспособиться к неизбежным сюрпризам, всплывающим в
ходе реализации проекта или с изменением требований. Архитектура, растущая по
шагам, может следовать за меняющимся знанием команды и меняющимися жела-
ниями сообщества пользователей.
9. Постоянное внимание к техническому совершенству и хорошее проек-
тирование ускоривает “быстроту”.
В аккуратный, хорошо инкапсулированный проект легче вносить изменения, и
это означает большую быстроту его выполнения. Следовательно, чтобы сохранить
быстроту, проектировщики должны для начала создавать хорошие проектные ре-
шения. Кроме того, они должны регулярно пересматривать и усовершенствовать
их для лучшего их понимания, приходящего со временем, и для того, чтобы подчис-
тить погрешности в проекте, внесенные, когда требовалось срезать угол и достичь
краткосрочной цели.
Управление техническим долгом
Уорд Каннингем иногда сравнивает подчистку проекта с погашением
долга. Идя еще дальше, он рассматривает управление "техническим
долгом" проекта.
Внесение в систему поспешных добавок соответствует одалживанию
у будущего — это то же самое, что влезать в долги. Подчистка про-
екта соответствует выплате долга.
Иногда, указывает он, уместно сделать долг и быстро внести в сис-
тему изменения, чтобы воспользоваться предоставленной возможно-
стью. Однако, поскольку со временем долг растет, увеличиваясь на
величину процентов, растут и затраты на проект, связанные с необ-
ходимостью подчистки этих поспешных изменений в проекте.
Срезайте углы в проекте, предлагает он, когда вы готовы принять
этот долг, и подчищайте проект, чтобы погасить долг, прежде чем
проценты по нему вырастут слишком сильно.
Манифест быстрой разработки программного обеспечения
263
Учитывая огромный опыт присутствовавших на встрече, мне было интересно
видеть эту заботу о качестве проектирования вместе с вниманием к небольшим
временным масштабам, краткой документации и людям.
Конфликтующие силы нейтрализуются проектированием, насколько позво-
ляет имеющееся знание, но проектированием инкрементным.
10. “Быстрые” процессы содействуют устойчивому развитию. Спонсоры,
разработчики и пользователи должны быть способны неограниченно
долго поддерживать постоянный темп.
У этого положения есть две стороны. Одна имеет отношение к социальной
ответственности, другая — к эффективности проекта. Не каждый участник
встречи был готов подписаться под утверждением о социальной ответственности,
но по вопросу эффективности согласились все.
Люди утомляются, занимаясь каким-то делом долгое время. Скорость их ра-
боты замедляется не только в сверхурочные часы, но и в нормальное рабочее
время. Они начинают делать больше ошибок. Сокращение отдачи требует увели-
чения рабочего времени. Это одно из проявлений нелинейности человеческого
компонента.
Внимательный, заинтересованный штат сотрудников работает быстрее, чем
усталый и медлительный, даже если оставить в стороне все вопросы социальной
ответственности. Медленная работа — это симптом какой-то ошибки в плане
проекта.
11. Простота — искусство максимально уменьшить объем необходимой
работы — имеет очень важное значение.
Простота — это главное. С этим легко согласиться. Однако понятие просто-
ты настолько субъективно, что о нем трудно сказать что-либо подходящее. Поэ-
тому мы были довольны тем, что все смогли поддержать это положение.
В создании процессов разработки простота — это минимизация выполняе-
мой работы при одновременном выпуске хорошего ПО. Джон Керн напомнил
нам высказывание Паскаля: “Это письмо оказалось длиннее, чем я хотел, поско-
льку у меня не было времени сделать его короче”. Этот комментарий показыва-
ет, как сложно делать простые вещи. Громоздкую модель создать легко. Создать
простой проект, который позволит более эффективно справляться с изменения-
ми, гораздо сложнее.
Касаясь методологии и поведения людей, Джим Хайсмит любит цитировать
Ди Хока:
“Простые, ясные цель и принципы дают начало сложному, умному по-
ведению.
Сложные правила и предписания порождают простое и глупое пове-
дение”.
264
Приложение А
12. Через регулярные интервалы времени команда размышляет о том, как
стать более эффективной, а затем соответственно изменяет свое пове-
дение.
Имеет смысл закончить там, где мы начали. Какая “легкость” подходит для
любого проекта? Почти достаточная и, наверное, более “легкая”, чем вы рассчи-
тываете.
Как этого добиться в проекте? Подумайте о том, что вы делаете. Если ваша
команда будет собираться на час раз в две недели, чтобы поразмышлять о своих
рабочих проблемах, вы сможете развить свою методологию и сделать ее быст-
рой, эффективной и подходящей. Если вы не сможете этого сделать, что ж... тог-
да вы останетесь на том же самом месте.
Размышления о перечисленных положениях
Убедить семнадцать человек согласиться с любым текстом сложно. Чем больше
деталей содержит рекомендация, тем большее значение приобретают различный
опыт и философские воззрения людей.
Мы надеемся, что в четырех главных выбранных ценностях и в двенадцати
поддерживающих положениях вы найдете достаточно информации, чтобы создать
для себя собственные обычаи и традиции.
Приложение В
Наур, Эн и Мусаши
Питер Наур и Пелле Эн написали о разработке ПО две наиболее убедительные ра-
боты из всех, с которыми я знаком. В то же время ни та ни другая работа не извест-
на должным образом, а книга Эна давно распродана. Поэтому я рад представить
отрывки из их статей более широкому кругу читателей.
В статье Питера Наура “Программирование как построение теорий” точно
описывается умственная деятельность при создании ПО и объясняется “построе-
ние метафор” в Extreme Programming (ХР).
Пелле Эн написал замечательную книгу Work-Oriented Development of
Software Artifacts, в которой рассматривает, как идея Витгенштейна о языковых
играх характеризует наше представление о разработке ПО.
Миямото Мусаши, воин-самурай 17 в., не написал ни одной программы.
Конкурирующие школы боевых искусств его времени до боли напоминают сегод-
няшние школы методологий. Он убеждает людей избегать одержимости конкрет-
ными способами и школами, пользоваться в разные моменты разными способами
и ударами и просто “отсекать противнику руку”. Его советы непосредственно
применимы к разработке ПО — если вы осознаете, что вашим противником яв-
ляется задача, а не сосед по кабинету.
Питер Наур. Программирование
как построение теорий
Питер Наур, широко известный как один из авторов нотации для описания синтак-
сиса языков программирования — “формы Бэкуса-Наура” (BNF), написал эту
статью в 1985 г. Она была переиздана в собрании его трудов Computing: A Human
Activity (Naur, 1992).
В этой статье, по моему мнению, содержится наиболее точная оценка того,
что происходит при проектировании и кодировании программы. Я ссылаюсь на
нее регулярно, обсуждая объем документации, которую нужно создать, способы
266
Приложение В
передачи предполагаемого знания и ценность установки метафоры в ХР. В статье
также дан способ исследования экономической структуры методологии.
В ней качество работы программиста связывается с качеством соответствия
мелщу его теорией задачи и теорией решения. При этом качество работы про-
граммиста, работающего на более позднем этапе, связано с соответствием между
его теориями и теориями предыдущего программиста.
Используя идеи Наура, можно сказать, что задача проектировщика состоит
не в передаче дальше проектных решений, а в передаче “теорий”, направлявших
проектирование. Последняя цель более полезна и более уместна. В статье также
выделяется мысль о том, что под знанием теории подразумевается ее освоение, и
поэтому для передачи дальше теории нужно передать дальше явное и неформаль-
ное знание.
Вот как об этом говорит Питер Наур.
“Программирование
как построение теорий"
Введение
В настоящей статье предпринимается еще одна попытка понять, что представляет
собой программирование. По существу, в ней предлагается рассматривать про-
граммирование как деятельность, посредством которой программисты подручны-
ми средствами достигают способности проникновения в суть или создают
определенного вида теорию. Это предложение отличается от более распростра-
ненного понятия, что программирование следует рассматривать как производство
программы и некоторых других текстов.
Отдельные предпосылки изложенных здесь представлений следует искать
в некоторых наблюдениях того, что в действительности происходит с программа-
ми и командами программистов, которые ими занимаются, особенно в ситуациях,
возникающих из неожиданных и, возможно, ошибочных прогонов или реакций
программ и в случае изменений программ. Сложность приспособить такие на-
блюдения к представлению о программировании как производстве внушает
мысль об обманчивости этого представления. Альтернативу дает представление о
построении теорий.
Более общая предпосылка этого изложения связана с важностью соответст-
вующего понимания программирования. Если наше понимание не соответствует
действительности, мы не сможем правильно понять сложности, возникающие в
этой деятельности, и наши попытки их преодолеть породят конфликты и разоча-
рования.
В настоящей статье сначала будут обрисованы некоторые решающие собы-
тия. За ними последует объяснение теории сущности программирования, назван-
ной “представлением о построении теорий”. В последних разделах мы
рассмотрим некоторые следствия из представления о построении теорий.
Наур, Эн и Мусаши 267
Программирование и знание программистов
Я буду использовать термин “программирование” для обозначения всей деятель-
ности при проектировании и реализации программных решений. Меня интересует
деятельность, ставящая в соответствие изменения в реальном мире формальному
манипулированию символами, которое может быть выполнено программой в
компьютере. Из такого представления непосредственно следует, что программи-
рование, о котором я говорю, должно включать развитие во времени, соответству-
ющее процессам реального мира, с которыми соотносят выполнение программы.
Иначе говоря, программирование должно включать модификации программ.
Основное положение, которое я хочу доказать, можно сформулировать, на-
пример, следующим способом. Программирование в указанном смысле главным
образом должно заключаться в построении программистами определенного зна-
ния, которое, по существу, нужно считать непосредственной собственностью
программистов, а любую документацию — вспомогательным, вторичным про-
дуктом.
В качестве подготовки к дальнейшей разработке этого представления будут
описаны примеры реального опыта работы с большими программами, который,
по мере того как я размышлял над этими проблемами, становился для меня все
более и более существенным. Каждый из этих случаев взят из моего собственно-
го опыта или опыта тех, кто имел непосредственный контакт с рассматриваемой
деятельностью.
Случай 1 относится к компилятору. Этот компилятор был разработан груп-
пой А для языка L и прекрасно работал на компьютере X. Теперь перед другой
группой В стоит задача написать компилятор для языка L + М, ограниченного
расширения языка L, для компьютера Y. Группа В решает, что компилятор для L,
разработанный группой А, будет хорошей отправной точкой для ее проекта, и за-
ключает с группой А договор о поддержке, согласно которому они получают пол-
ную документацию, в том числе тексты программ с комментариями и подробное
описание проектных решений, а также личные консультации. Это соглашение
оказалось эффективным, и группе В удалось разработать компилятор, который
ей был нужен. В настоящем контексте существенным моментом было получение
от группы А личных консультаций по вопросам реализации расширений языка М.
На стадии проектирования группа В вносила предложения о способах, которыми
следовало вводить расширения, и передавала их группе А на рассмотрение. В от-
дельных важных случаях оказывалось, что в решениях, предложенных группой В,
группа А не находила использования средств, которые не только были присущи
структуре существовавшего компилятора, но обстоятельно обсуждались в его
документации. Вместо этого предложения группы В базировались на дополнени-
ях к этой структуре в форме вставок, разрушавших мощь компилятора и его про-
стоту. Участники команды А тут же обнаруживали эти случаи и предлагали
простые, эффективные решения, полностью вписывающиеся в существующую
структуру. На этом примере видно, что полного текста программы и дополните-
10 Зак.715
268
Приложение В
льной документации, которая немедленно предоставлялась участниками группы
А, недостаточно для передачи даже деятельной группе В более глубокого проник-
новения в проект.
В последующие годы компилятор, разработанный группой В, был принят
другими программистами той же организации без руководства со стороны группы
А. Информация, полученная одним из участников группы А о компиляторе, пре-
терпевшем дальнейшие модификации в течение десяти лет, ясно показала, что на
этой более поздней стадии мощная первоначальная структура все еще была вид-
на, но стала абсолютно неэффективной из-за самых различных бессистемных до-
полнений. Таким образом, мы снова видим, что текст программы и ее
документация оказались неэффективными носителями некоторых наиболее важ-
ных идей проекта.
Случай 2 имеет отношение к установке и диагностике дефектов в крупной сис-
теме реального времени, предназначенной для мониторинга производственных
процессов. Эта система продавалась ее производителем, каждая поставка системы
адаптировалась индивидуально к конкретной среде датчиков и устройств отобра-
жения. Поставлявшаяся каждый раз программа имела размер порядка 200 тыс.
строк. Управление системой такого рода было связано с ролью и способом работы
группы установки и программистов, искавших ошибки. Факты показали, во-пер-
вых, что эти программисты были тесно связаны сданной системой, поскольку по-
стоянно занимались ею в течение нескольких леТ со времени ее проектирования.
Во-вторых, диагностируя ошибку, они полагались почти исключительно на свое
готовое знание системы, тексты программ с комментариями и не могли себе пред-
ставить никакой дополнительной документации, которая оказалась бы им полезна.
В-третьих, другие группы программистов, ответственные за эксплуатацию отдель-
ных установок системы и поэтому получавшие документацию системы и полное ру-
ководство по ее использованию от компании-производителя, регулярно
сталкивались с трудностями, которые после консультации с программистом произ-
водителя оказались вызваны неадекватным пониманием документации и легко
прояснялись программистами из группы установки и поиска ошибок.
Отсюда следует неизбежный вывод, действующий по крайней мере для отдель-
ных разновидностей больших программ: непрерывная адаптация, модификация и ис-
правление ошибок в таких программах существенным образом зависят от опреде-
ленного знания, которым владеет группа программистов, тесно и непрерывно
связанных с этими программами.
Понятие теории Райла
Если допустить, что существенным результатом программирования должно быть
формирование знания программистов, далее нужно охарактеризовать это знание
подробнее. Здесь его уместно рассматривать как теорию в том смысле, который
придает этому Райл [Ryle, 1949]. Говоря коротко, лицо, владеющее теорией в этом
смысле, знает, как выполнять отдельные вещи, и, кроме того, может поддерживать
Наур, Эн и Мусаши
269
фактическое выполнение путем объяснений, обоснований и ответов на вопросы в от-
ношении рассматриваемой деятельности. Понятие теории Райла проявляется как
пример того, что К. Поппер [Popper и Eccles, 1977] называет невоплощенными
“объектами третьего мира” (World 3), и, таким образом, имеет философское обо-
снование. В настоящем разделе мы дадим понятие теории Райла более подробно.
Райл разрабатывает свое понятие теории как части анализа природы умст-
венной деятельности, в частности черт, которыми умственная деятельность отли-
чается от просто умной деятельности и идет дальше нее. В умном поведении
человек не отображает какое-то конкретное знание фактов, а проявляет способ-
ность делать разные вещи, например, шутить и оценивать шутки, грамотно гово-
рить или ловить рыбу. В частности, умная работа характеризуется в какой-то
степени хорошим исполнением в соответствии с определенными критериями, но
в ней отражена способность человека применять эти критерии, например для об-
наружения и исправления упущений, обучения на чужих примерах и т.д. Понятие
ума не опирается ни на какое понятие, от которого зависит умное поведение, ког-
да человек придерживается правил, предписаний и методов. Напротив, само дей-
ствие следования правилам можно выполнить более или менее разумно; если бы
применение ума зависело от следования правилам, существовали бы правила
следования правилам, следования правилам о следовании правилам и т.д. в бес-
конечном движении назад, что абсурдно.
Умственную деятельность, стоящую выше и идущую дальше просто умной
деятельности, характеризует создание и освоение человеком теории, когда тео-
рия понимается как знание, которым должен владеть человек, чтобы не только
умно выполнять некоторые вещи, но также их объяснять, отвечать на вопросы о
них и т.д. Человек, владеющий теорией, готов начать такую деятельность, в то
время как создающий теорию человек пытается этого добиться.
Понятие теории в использованном здесь смысле применимо не только к де-
тально разработанным конструкциям специализированных проблемных облас-
тей, но в равной степени к видам деятельности, в которых каждое лицо,
получившее образование, будет при определенных обстоятельствах участвовать.
Даже довольно нечестолюбивые повседневные виды деятельности могут привес-
ти людей к теоретизированию, например когда нужно спланировать размещение
мебели или добраться в какое-то место определенными видами транспорта.
Использованное здесь понятие теории не ограничено тем, что можно назвать
наиболее общей или абстрактной частью понимания.’ Например, чтобы теория
механики Ньютона была понятна, недостаточно понимать основные законы,
знать, что сила равна массе, умноженной на ускорение. Кроме того, как подроб-
нее описано Куном [Kuhn, 1970, стр. 187ff], обладающий теорией человек дол-
жен понимать способ, которым основные законы применяются к некоторым
сторонам действительности, чтобы суметь распознать и применить теорию к дру-
гим похожим аспектам. Человек, владеющий теорией механики Ньютона, дол-
жен понимать, как она применяется к движению маятников и планет, и должен
270
Приложение В
суметь распознать аналогичные явления в мире, чтобы правильно применить ма-
тематически выраженные правила этой теории.
Зависимость теории от улавливания некоторых видов сходства между ситуа-
циями и событиями реального мира объясняет, почему знание, которое хранит
некто, владеющий теорией, в принципе не может быть выражено в терминах
правил. На самом деле сходные элементы не выражаются и не могут быть выра-
жены в терминах критериев, так же как сходные элементы многих других видов
объектов, таких как человеческие лица, мелодии или вкус вин.
Теория, создаваемая программистом
В терминах понятия теории Райла программист должен создать теорию об обра-
ботке или поддержке компьютерной программой определенных событий в мире.
Теория, созданная программистом, согласно представлению о программировании
как о построении теорий, имеет превосходство над такими другими продуктами,
как тексты программ, пользовательская документация и дополнительная докумен-
тация, например спецификации.
При отстаивании представления о построении теорий главный вопрос состо-
ит в том, чтобы показать, как знание, которым владеет программист в силу его
теории, неминуемо будет превосходить то, что записано в документированных
продуктах. Знание программиста превосходит содержание документации по
крайней мере в трех основных областях:
1) Программист, владеющий теорией программ, может объяснить, как ре-
шение соотносится с событиями мира, которые оно помогает обрабатывать. Та-
кое объяснение должно иметь отношение к способу, которым события мира как в
своих общих характеристиках, так и в деталях в некотором смысле отображаются
в тексте программы и в какой-либо дополнительной документацию. Таким обра-
зом, программист должен суметь объяснить для каждой части текста программы
и каждой из ее общих структурных характеристик, какой аспект или какая деяте-
льность в мире им соответствует. Наоборот, для каждого аспекта и деятельности
в мире программист способен представить соответствующий способ отображе-
ния в текст программы. Огромная часть аспектов и видов деятельности в мире
будет, конечно же, лежать вне области действия текста программы, не относясь
к ее контексту. Однако решить, что часть мира имеет отношение к программе,
может лишь кто-то, пони|чэдощий весь мир. Разъяснить это понимание должен
программист.
2) Программист, владеющий теорией программы, может объяснить, почему
каждая часть программы такова, как она есть, иными словами, он способен под-
держать актуальный текст программы некоторым обоснованием. Окончательной
базой этого обоснования является и всегда должно оставаться непосредственное
интуитивное знание программиста или его оценка. Это справедливо даже в том
случае, когда для обоснования используются рассуждения, возможно, с примене-
нием правил проектирования, количественных оценок, сравнений с альтернати-
Наур, Эн и Мусаши
271
вами и т.д. Суть в том, что выбор принципов и правил, решение о существовании
отношения между ними и имеющейся ситуацией опять-таки должны в окончате-
льном анализе опираться на непосредственное знание программиста.
3) Программист, владеющий теорией программы, способен конструктивно
отвечать на любой запрос изменения программы для поддержания событий мира
новым способом. Наилучший способ включения изменений в работающую про-
грамму зависит от схожести нового запроса и функциональных возможностей,
уже встроенных в программу. Нужно осознать схожесть между аспектами мира.
Она имеет смысл лишь для личности, обладающей знанием о мире, т.е. для про-
граммиста, и не может быть сокращена ни до какого набора критериев и правил
по тем же приведенным выше причинам, объясняющим, почему обоснование
программы не может быть ограничено таким образом.
Хотя в этом разделе мы рассмотрели некоторые основные аргументы в поль-
зу принятия представления о построении теории, следует учитывать оценку этого
представления: до какой степени оно может содействовать гармоничному пони-
манию программирования и его проблем. Эти темы обсуждаются в следующих
разделах.
Проблемы изменений программ и затрат на изменения
Наше предложение представлять программирование как построение теорий вы-
звано главным образом желанием проникнуть в суть программирования, чтобы
поддержать здравое понимание модификаций программ. Поэтому данный вопрос
мы проанализируем в первую очередь.
С одной мыслью, кажется, согласны все — ПО будет изменяться. Програм-
ма, введенная в эксплуатацию, без всяких исключений воспринимается лишь как
часть ответа на насущные проблемы. Кроме того, само использование програм-
мы внушает идеи о будущих полезных услугах, которые программа должна обес-
печивать. Отсюда вытекает потребность в методах управления изменениями.
Вопрос модификаций программ тесно связан с затратами на программирова-
ние. Сталкиваясь с потребностью изменить поведение программы, мы надеемся
сэкономить и поэтому не пишем абсолютно новую программу, а вносим измене-
ния в текст существующей программы.
Надежда на возможность модификации программы по низкой цене требует
более тщательного анализа. Во-первых, такие надеЖййЧ1е могут поддерживаться
аналогиями с изменениями других сложных, созданных руками человека конструк-
ций. Там, где изменениями пользуются изредка, например в строительстве, хоро-
шо известно, насколько это дорогостоящая процедура, и на самом деле полный
снос существующего здания с последующим возведением нового строения часто
оказывается экономически более предпочтительным. Во-вторых, надежда на де-
шевое изменение программ, по-видимому, находит поддержку в том факте, что
программа является текстом, хранящимся на носителе и допускающим легкое ре-
дактирование. Чтобы эта поддержка была правомерна, следует явно предполо-
272
Приложение В
жить, что в цене преобладает доля стоимости манипулирования текстом. Это
могло бы согласовываться с понятием программирования как производства тек-
ста. В представлении о построении теорий весь этот довод ложен. Это представле-
ние не позволяет надеяться, что дешевые изменения программ вообще возможны.
Следующий довольно близкий вопрос касается гибкости программы. Наде-
ляя программу гибкостью, мы встраиваем в нее определенные эксплуатационные
возможности, которые не требуются немедленно, но могут оказаться полезными
в дальнейшем. Таким образом, гибкая программа способна обрабатывать опре-
деленные классы изменений внешних условий без дополнительных модификаций.
Часто утверждается, что при проектировании программы следует делать
очень гибкими, тогда они будут готовы к изменению условий. Такой совет может
быть разумен, если речь идет о легко достижимой гибкости. Однако, вообще го-
воря, гибкости можно достичь лишь при существенных затратах. Каждый эле-
мент программы следует спроектировать, учесть все обстоятельства, которые он
охватывает, и все параметры, которыми он управляется. Затем он должен быть
реализован, протестирован и описан. Эти затраты оправдываются гибкостью
программы, но ее полезность будет полностью зависеть от будущих событий.
Должно быть ясно, что встроенная гибкость программы — это не ответ на общее
требование приспосабливания программ к изменяющимся условиям окружаю-
щего мира.
При модификации программы существующее программное решение следует
изменить так, чтобы принять во внимание изменение в процессах реального
мира, которым оно должно соответствовать. Прежде всего, при модификации не-
обходимо сопоставить существующее решение с требованиями конкретного из-
менения. В этом сопоставлении должны быть определены степень и вид сходства
между возможностями существующего решения и новыми требованиями. Эта
потребность в определении сходства выявляет достоинства представления о по-
строении теорий. В самом деле, именно при определении сходства становится
очевидным несовершенство любого представления о программировании, которое
игнорирует главное требование непосредственного участия лиц, обладающих со-
ответствующим пониманием. Суть в том, что этот опознаваемый вид сходства до-
ступен людям, владеющим теорией о программе, но не может определяться
правилами, так как даже критерии суждения не могут быть сформулированы.
Программист, проникающий щсуть сходства между новыми требованиями и тре-
бованиями, уже удовлетворенными программой, способен спроектировать изме-
нения в тексте программы, необходимые для реализации модификации.
В определенном смысле речь может идти не об изменении теории, а только
о модификации программы. В самом деле, лицо, владеющее теорией, должно
уже быть готово к ответам на такие вопросы и требования, которые могут приве-
сти к изменениям в программе. Из этого наблюдения следует важный вывод, что
проблемы модификации программы возникают, если считать программирование
производством текстов программ, а не деятельностью по построению теорий.
Наур, Эн и Мусаши
273
На основе представления о построении теорий становится понятным разру-
шение текста программы в результате модификаций, выполненных программи-
стами без надлежащего понимания лежащей в ее основе теории. В сущности,
искомая модификация, рассматриваемая просто как изменение текста програм-
мы и внешнего ее поведения при выполнении, обычно может быть реализована
многими различными и абсолютно правильными способами. В то же время спо-
собы модификации, рассматриваемые в связи с теорией этой программы, могут
выглядеть совершенно по-разному, и некоторые из них, возможно, согласуются с
этой теорией или естественно ее расширяют, в то время как другие ей полностью
не соответствуют, представляя собой разрозненные вставки в ее основную часть.
Это различие в характере всевозможных изменений таково, что может иметь
смысл лишь для программиста, владеющего теорией программы. В то же время
характер изменений, внесенных в текст, крайне важен для долгосрочной жизне-
способности программы. Для поддержания качества программы каждая ее моди-
фикация обязательно должна прочно закрепляться в ее теории. Действительно,
само понятие таких качеств программы, как простота и хорошая структура, мо-
жет быть освоено лишь в терминах теории программы, поскольку эти достоинст-
ва характеризуют актуальный текст программы по отношению к таким текстам,
которые могли бы быть написаны для достижения того же поведения, но сущест-
вуют в понимании программиста лишь как варианты.
Жизнь, смерть и возрождение программы
Основное утверждение представления о программировании как о построении тео-
рий состоит в том, что важнейшая часть любой программы — ее теория, не может
быть выражена никаким мыслимым образом, а неразрывно связана с людьми. От-
сюда следует, что при описании состояния программы важно указать степень, до ко-
торой программисты, владеющие теорией, продолжают за нее отвечать. Чтобы
придать особое значение этому обстоятельству, понятие создания программы мож-
но расширить понятиями ее жизни, смерти и возрождения. Создание программы —
это то же самое, что построение ее теории командой программистов и в этой коман-
де. В течение жизни программы команда программистов, обладающая ее теорией,
продолжает активно контролировать программу и, в частности, сохраняет контроль
над всеми ее модификациями. Смерть программы происходит, когда команда про-
граммистов, владеющая ее теорией, прекращает существование. Мертвую про-
грамму можно продолжать использовать, запускать на выполнение и получать
полезные результаты. Фактическое состояние смерти становится видным, когда на
запросы об изменениях программы нельзя получить умных ответов. Возрождение
программы заключается в воссоздании ее теории новой командой программистов.
В соответствии с этими понятиями длительная жизнь программы зависит от
усвоения ее теории новыми поколениями программистов. Чтобы новый програм-
мист мог освоить существующую теорию программы, ему недостаточно подробно
ознакомиться с текстом программы и другой документацией. Новому программи-
274
Приложение В
сту необходимо получить возможность работать в тесном контакте с программи-
стами, уже владеющими теорией, чтобы хорошо узнать место программы в более
широком контексте ситуаций реального мира, имеющих к ней отношение, приоб-
рести знания о работе программы и узнать, как в рамках теории обрабатываются
необычные реакции и модификации программы. Эта задача обучения новых про-
граммистов теории программы довольно схожа с задачей обучения другим видам
деятельности, в которых знание о способах выполнения определенных вещей
преобладает над знанием о существовании определенных вещей, каковы, напри-
мер, умение писать или играть на музыкальном инструменте. Для обучения наи-
более важно, чтобы учащийся выполнял значимые вещи под соответствующим
наблюдением и руководством. В случае программирования обучение должно
включать обсуждение как связей между программой и важными аспектами и ви-
дами деятельности реального мира, так и ограничений, накладываемых на пред-
меты реального мира, которыми занимается программа.
Очень важное следствие представления о построении теорий состоит в том,
что возрождение программы, при котором теория программы восстанавливается
просто из документации, абсолютно невозможно. Чтобы это следствие не пока-
залось неразумным, можно отметить, что потребность в возрождении совсем
мертвой программы будет возникать, вероятно, редко, поскольку с трудом можно
вообразить, чтобы возрождение было поручено новым программистам без хотя
бы некоторого знания теории, сохраненного первоначальной командой. Даже тогда
представление о построении теорий настоятельно рекомендует, чтобы попытка
возрождения программы предпринималась лишь в исключительных ситуациях и
при полной осведомленности о его высокой цене. Возрожденная теория может от-
личаться от первоначальной, которой владели создатели программы, и поэтому
расходиться с текстом программы.
Представление о построении теорий предпочитает возрождению программы
отказ от ее существующего текста и предоставление вновь сформированной
команде программистов возможности заново решить данную задачу. Именно та-
кая процедура, а не возрождение, более вероятно создаст жизнеспособную про-
грамму с возможно более низкими затратами. Суть в том, что построение теории,
которая должна соответствовать существующему тексту программы и поддержи-
вать его, — это сложная, изобилующая разочарованиями и поглощающая много
времени деятельность. Ное^ьЩ; программист, возможно, будет разрываться между
приверженностью существующему тексту, со всеми его возможными неясностя-
ми и слабостями, и новой теорией, которую он должен будет построить и кото-
рая, на радость или горе, скорее всего будет отличаться от первоначальной
теории, стоящей за текстом программы.
Схожие проблемы возникают, вероятно, даже при постоянной поддержке
жизни программы командой программистов — в результате различной компе-
тенции и опыта работы отдельных программистов, в частности, когда работоспо-
собность команды поддерживается неизбежными заменами отдельных ее
участников.
Наур, Эн и Мусаши
275
Методы и построение теорий
В последние годы произошло много интересных событий в методах программиро-
вания. В настоящем разделе даны некоторые комментарии к связи между пред-
ставлением о построении теорий и понятиями, стоящими за методами
программирования.
Прежде всего, что такое метод программирования? Это не всегда проясняют
даже те авторы, которые рекомендуют конкретный метод. Здесь методом про-
граммирования будет считаться набор рабочих правил для программистов, ука-
зывающих, что программисты должны делать, в каком порядке, какие
обозначения и языки использовать и какие виды документов производить на раз-
личных стадиях.
При сравнении этого понятия метода с представлением о программировании
как о построении теорий наиболее важен вопрос о действиях или операциях и их
упорядочении. Метод предполагает требование, чтобы разработка программы
могла и должна была выполняться как последовательность некоторых видов дей-
ствий, каждое из которых приводит к конкретному виду документированного ре-
зультата. При построении теории не может быть никакой конкретной
последовательности действий, поскольку теория, хранимая человеком, не имеет
ни внутреннего разделения на части, ни внутреннего упорядочения. Вернее ска-
зать, человек, обладающий теорией, в ответ на вопросы или требования сможет
создавать на ее основе представления различного типа.
Что касается использования конкретных»видов обозначений или формализа-
ции, то это опять-таки имеет лишь второстепенное значение, поскольку основ-
ной пункт, теория, не может быть выражен, и поэтому вопроса о форме его
выражения не возникает.
Отсюда следует, что в представлении о построении теорий для основных ви-
дов деятельности в программировании не может быть правильного метода.
Может показаться, что этот вывод в некоторой степени конфликтует с
установившимся мнением и, таким образом, может использоваться как аргу-
мент против представления о построении теорий. Два таких явных противоре-
чия будут здесь рассмотрены: первое связано с важностью метода при занятии
наукой, второе касается успехов методов, используемых в настоящее время при
разработке ПО.
Согласно первому аргументу, разработка ПО1ДОлжна базироваться на на-
учном образе действий и поэтому пользоваться процедурами, аналогичными на-
учным методам. Изъян данного аргумента заключается в предположении, что
есть такая вещь, как научный метод, и она полезна для ученых. В последние
годы этот вопрос был предметом многих споров, и такие авторы, как Фейера-
бенд [Feyerabend, 1978], черпающий свои пояснения из истории физики, и Ми-
дауор [Medawar, 1982], приводивший доводы биолога, пришли к выводу, что
понятие научного метода как набора руководств для практикующего ученого
ошибочно.
276
Приложение В
Это заключение не противоречит, например, работам Польи [Polya, 1954,
1957] о решении задач. Его работы берут пояснения из области математики и
приводят к пониманию, также очень существенному для программирования. Од-
нако они не могут претендовать на представление метода, которым можно дейст-
вовать. Скорее, это собрание предположений, нацеленных на стимулирование
умственной деятельности лица, решающего задачи, путем указания разных спо-
собов работы, которые могут применяться в любой последовательности.
Второй аргумент, который может показаться противоречащим отказу от ме-
тода в представлении о построении теорий, состоит в том, что, согласно опубли-
кованным отчетам, использование конкретных методов было успешным. На этот
аргумент имеется возражение, что методически удовлетворительное исследова-
ние эффективности методов программирования до сих пор, по-видимому, так и не
проведено. Такое исследование должно было бы использовать технику контроли-
руемых экспериментов (см. [Brooks, 1980] или [Moherand Schneider, 1982]). От-
сутствие таких исследований частично объясняется высокими затратами,
которые, несомненно, должны сопровождать подобные изыскания, чтобы резу-
льтаты были значимыми, и частично проблемами определения концепций, лежа-
щих в основе так называемых методов в области разработки программ.
Большинство опубликованных отчетов по таким методам просто описывают и ре-
комендуют определенные приемы и процедуры, не устанавливая их полезность
или эффективность каким-либо систематическим образом. Тщательное исследо-
вание пяти различных методов, проведенное Флойдом и несколькими сотрудни-
ками [Floyd, 1984], привело к выводу, что понятие методов как систем правил,
которое в произвольном контексте и механически будет приводить к подходящим
решениям, не более чем иллюзия. Остается только воздействие методов на обу-
чение программистов. Этот вывод полностью совместим с представлением о про-
граммировании как построении теорий. В самом деле, в этом представлении
качество теории, построенной программистом, будет в значительной степени за-
висеть от его знания модельных решений типичных задач, приемов описания и
контроля и принципов структурирования в сложных взаимодействиях систем, со-
стоящих из многих частей. Таким образом, многие вопросы, касающиеся мето-
дов, значимы для построения теории. В чем представление о построении теорий
отличается от представления методологов, так это в том, какие приемы исполь-
зовать и в каком порядке. По представлению о построении теорий этот вопрос
должен полностью быть дётавлен на усмотрение программиста, который прини-
мает в расчет реальную решаемую задачу.
Статус программистов
и представление о построении теорий
Области, где следствия представления о построении теорий разительно расходят-
ся со следствиями наиболее распространенных в настоящее время представле-
ний, — это области личного вклада программистов и их собственного статуса.
Наур, Эн и Мусаши
277
Расхождения между представлениями по поводу личного вклада програм-
мистов видны во многих общих обсуждениях программирования. В качестве
лишь одного примера рассмотрим исследование модифицируемости крупных
программных систем, предпринятое Оскарсоном [Oskarsson, 1982]. Это иссле-
дование дает исчерпывающую информацию по значительному числу модифика-
ций в одной версии крупной коммерческой системы. Это описание охватывает
исходные данные, сущность и реализацию каждой модификации, причем особое
внимание уделяется способу, которым программные изменения ограничивают-
ся отдельными программными модулями. Однако в нем не содержится даже на-
мека, что реализация модификаций может зависеть от подготовки 500
программистов, занятых в проекте, например от времени, которое они в нем
проработали, и отсутствует указание на способ распределения проектных ре-
шений между 500 программистами. Даже при этих условиях важность лежащей
в основе теории косвенно признается в таких утверждениях, как “решения
были реализованы не в том блоке” и в ссылках на “философию АХЕ”. Однако
из-за способа, которым проводилось исследование, эти признания остаются
лишь изолированными знаками.
В большинстве случаев ведущиеся в настоящее время обсуждения програм-
мирования, кажется, предполагают, что оно похоже на промышленное производ-
ство, причем на программиста смотрят как на компонент этого производства,
которым следует управлять по правилам и который можно легко заменять. Дру-
гое близкое представление утверждает, что лучше всего люди работают, когда
они действуют, как машины, следуют правилам, закономерно обращают внима-
ние на формальные способы выражения, которые делают возможным формули-
рование определенных доводов в терминах формальных преобразований. Такие
представления хорошо согласуются с понятием, по-видимому, распространен-
ным среди лиц, работающих с компьютерами, о том, что человеческий мозг рабо-
тает, как компьютер. На уровне менеджмента компаний эти представления
поддерживают обращение с программистами как с рабочими, имеющими доволь-
но низкую степень ответственности и ограниченное образование.
Согласно представлению о построении теорий основным результатом про-
граммирования является теория, хранимая программистами. Поскольку эта тео-
рия по самой своей природе — часть интеллектуального багажа каждого
программиста, то понятие о программисте как о ледко заменяемом компоненте
деятельности по производству программ должно быть отброшено. Программиста
следуют считать ответственным разработчиком и менеджером процесса, частью
которого является компьютер. Чтобы он мог занимать это положение, ему дол-
жен быть присвоен постоянный статус, аналогичный положению других профес-
сионалов, таких как инженеры или юристы, чей активный вклад как сотрудников
компаний опирается на их интеллектуальную квалификацию.
Повышение статуса программистов, предлагаемое представлением о построе-
нии теорий, должно быть поддержано соответствующей переориентацией их обу-
чения. Хотя такие навыки, как овладение понятиями, представление и обработка
278
Приложение В
данных, остаются важными, основное внимание следует обратить на содействие
созданию теорий и развитию способностей в этой сфере. Можно ли этому научить
и в какой степени — этот вопрос остается открытым. Наиболее многообещающий
подход должен позволить обучаемому работать под руководством наставников над
конкретными проблемами в деятельном и творческом окружении.
Выводы
Признавая модификации программ, требуемые изменениями внешних условий,
важнейшей частью программирования, мы утверждаем, что главная цель этой
деятельности заключается в построении теории для способа, которым имеющие-
ся ситуации могут поддерживаться путем выполнения программы. Такое пред-
ставление приводит к понятию жизни программы, зависящей от ее постоянного
контроля программистами, владеющими теорией. Более того, в этом представле-
нии понятие метода программирования как набора правил процедуры, выполняе-
мой программистом, основывается на неверных допущениях и поэтому должно
быть отброшено. В соответствии с еще одним следствием этого представления
программистам должен быть предоставлен статус ответственных, постоянных
разработчиков и менеджеров процесса, частью которого является компьютер, а
при их обучении особое значение должно придаваться подготовке к построению
теорий с одновре- менным получением знаний по обработке данных и системе
обозначений.
Ссылки
Brooks, R. Е. Studying programmer behaviour experimentally. Comm. ACM 23(4):
207-213, 1980.
Feyerabend, P. Against Method, London, Verso Editions, 1978; ISBN:
86091-700-2.
Floyd, C. Eine Untersuchung von Software-Entwicklungs-Methoden. Pp.
248-274 в книге Programmierumgebungen and Compiler, ed. H. Morgenbrod and
W. Sammer, Tagung 1/1984 des German Chapter of the ACM, Stuttgart, Teubner
Verlag, 1984; ISBN: 3-519-02437-3.
Kuhn, T. S. The Structure of Scientific Revolutions, Second Editions. Chicago,
University of Chicago Press^J^O; ISBN: 0-226-45803-2.
Medawar, P. Pluto's Republic. Oxford, University Press, 1982: ISBN:
0-19-217726-5.
Moher, T., and Schneider, G. M. Methodology and experimental research in
software engineering, \nt. J. Man-Mach. Stud. 16: 65-87, 1. Jan. 1982.
Oskarsson, О Mechanisms of modifiability in large software systems Linkoping
Studies in Science and Technology, Dissertations, no. 77, Linkoping, 1982;
ISBN: 91-7372-527-7.
Polya, G. How To Solve It. New York, Doubleday Anchor Book, 1957.
Наур, Эн и Мусаши
279
Polya, G. Mathematics and Plausible Reasoning. New Jersey, Princeton Uni-
versity Press, 1954.
Popper, K. R., and Eccles, J. C. The Self and Its Brain. London, Routledge and
Kegan Paul, 1977.
Ryle, G. The Concept of Mind. Harmondsworth, England, Penguin, 1963, пер-
вая публикация 1949.
Применение “построения теорий’’
Рассмотрение программирования как построения теорий помогает понять деяте-
льность Extreme Programming (ХР), направленную на “построение метафоры”, а
также соответствующие роли неформального знания и документации при передаче
знания о проекте в команде.
Метафора как теория
Кент Бек советовал командам проектировщиков упрощать общий проект програм-
мы, чтобы он соответствовал одной метафоре. Например, можно сказать: “Эта про-
грамма действительно выглядит, как сборочный конвейер, будто к корпусу по мере
его продвижения по конвейеру добавляются новые детали” или: “Эта программа и
правда выглядит, как ресторан с официантами и меню, поварами и кассирами”.
Если метафора удачна, множество ассоциаций, создаваемых проектировщи-
ками вокруг нее, начинают соответствовать их программной ситуации.
Это в точности идея Haypa о передаче теории внутри команды.
Если метафора “сборочного конвейера” приближена к действительности, то
приходящие в команду программисты, учитывая их знания о сборочных конвейе-
рах, будут догадываться о структуре имеющейся программы и увидят, что их до-
гадки “верны”. Таким образом, всего лишь в двух словах обнаруживается
исключительная мощь.
Ценность удачной метафоры возрастает с числом проектировщиков. Чем
ближе догадки каждого человека к догадкам других участников команды, тем бо-
льше согласованность в проекте законченной системы.
Представьте себе десять программистов; все они работают параллельно и
так быстро, как только возможно, принимая проектные решения и создавая по
ходу работы новые классы. Каждый из них обязательно выводит собственную те-
орию. По мере написания кода теория, связывающая йх работу, становится все
менее согласованной и все более усложненной. Затрудняется не только поддерж-
ка, но и собственная их работа. Проект легко превращается в то, что теоретиче-
ски не должно работать, но почему-то работает. С другой стороны, если у них
есть общая теория, их код лучше согласуется.
Подходящая метафора позволяет программисту точно предположить, где
другой участник команды только что добавил свой код и как согласовать с ним
свой новый фрагмент.
280
Приложение В
Неформальное знание и документация
Документация почти наверняка отстает от текущего состояния программы, но
люди хорошо ориентируются. Что вы должны помещать в документацию?
Это чрезвычайно важно. Назначение документации в том, чтобы подтолк-
нуть память читателя, повернуть в соответствующем направлении мысли об опы-
те и метафорах.
Документация такого рода более стабильна в течение времени жизни про-
граммы, чем просто перечисление имен частей системы, включенных в нее в на-
стоящий момент.
Проектировщикам разрешается использовать любые необходимые формы
выражения, чтобы подготовить релевантные представления. Они даже вправе
применять несколько метафор, если не могут найти единственной, адекватно пред-
ставляющей всю программу целиком. Они могут сказать, что в одной секции реа-
лизован алгоритм рекурсивного сжатия, вторая похожа на бухгалтерскую книгу,
пользовательский интерфейс выполнен по образцу “модель-наблюдатель” и т.д.
Опытные проектировщики часто начинают свою документацию буквально со
следующих элементов:
Метафоры
Текст, описывающий назначение каждого основного компонента
Диаграммы основных взаимодействий между основными компонентами
Даже эти три элемента далеко продвигают команду в направлении построе-
ния полезной теории этого проекта.
Сам исходный код служит для передачи теории следующему программисту.
Простое последовательное соглашение об именах помогает очередному лицу по-
строить согласованную теорию. Когда программисты говорят о “чистом коде”, в
значительной степени это касается легкости, с которой читатель кода может по-
строить согласованную теорию системы.
Документация не может — да от нее это и не требуется — рассказать обо
всем. Она должна помочь следующему программисту построить точную теорию
системы.
Пелле Эн. Языковые игры Витгенштейна
В книге Work-Oriented Development of Software Artifact (Ehn, 1988) Пелле Эн опи-
сывает ряд проектов, в которых были опробованы способы создания такого ПО,
чтобы оно более соответствовало своему конечному использованию, было более
простым в применении и создавалось как программистами, так и пользователями.
Для меня в этой книге главный момент — это метод, примененный Эном при
рассмотрении разработки ПО в контексте четырех философов: Декарта, Маркса,
Хайдеггера и Витгенштейна.
Наур, Эн и Мусаши
281
Человек, работающий в стиле Декарта, считает, что достоинства внешней
реальности заслуживают описания, и обращает свои усилия на фиксацию этой
реальности. Следовательно, его интересует соответствие требований, моделей и
кода реальности. Декартов подход преобладал в нашей области в первой полови-
не прошлого века.
Человек, работающий в стиле Маркса, в первую очередь спрашивает: “Кому
приносит выгоду эта новая система? Как ее внедрение меняет структуру обще-
ственных сил?” Это важный вопрос, и его стоит рассмотреть независимо от того,
насколько вам нравятся политические теории Маркса.
Человек, работающий в стиле Хайдеггера, рассматривает эффективность
системы как инструмент. В идеале пользователь совсем не должен “видеть” сис-
тему. Он должен смотреть через систему на выполняемую задачу. Когда, напри-
мер, я набираю документ, то вижу страницу с растущим текстом; я не “вижу”
текстовый процессор. Профессиональный пианист видит не рояль, а возникаю-
щую музыку; хороший плотник видит входящий в дерево гвоздь, а не молоток.
Рамки оценки Хайдеггера помогают производить системы, более подходящие для
использования.
Лишь стиль Витгенштейна противостоит стилю Декарта. Человек, работаю-
щий в этом стиле, рассматривает проектирование программ как языковую игру,
в которой со временем язык пополняется новыми словами.
В этом немедленно обнаруживается связь с разработкой ПО как кооператив-
ной игрой изобретения и коммуникации. Вероятно, значительной частью моей кон-
струкции кооперативной игры я обязан трудам Эна. Статью, которая приводится
далее, я прочитал и успел забыть за несколько лет до того, как начал разрабаты-
вать идею о кооперативной игре. Начав писать эту книгу, я просмотрел статью за-
ново и поразился тому, как часто в моих высказываниях повторяются слова Эна.
Эн интересуется построением совместного опыта через совместную практи-
ку, непосредственным использованием практики как основы для выявления по-
требностей. Иначе говоря, он работает с неформальным знанием. Более того, он
выделяет место умения в осуществлении практической деятельности (интересно
прочитать слова Мусаши, указывающие на точно то же самое). Хотя тему умения
я рассматривал, Эн разрабатывает ее гораздо более вдумчиво и полно.
Размышление об игре я повел в другом направлении. Меня интересовало в игре
дружелюбие, способствующее общению. Вы увидите, что идеи Эна дополняют оста-
льные идеи этой книги.
Собственными словами Пелле Эн выражает это гораздо лучше, чем я смог
сделать в этом кратком обзоре. Книги Work-Oriented Development of Software Ar-
tifacts, к сожалению, в продаже уже не найти. Однако в этом отрывке из статьи
“Scandinavian Design: On Participation and Skill” (Ehn, 1992) отражен ход мыс-
лей, который я считаю очень важным.
Эта статья длиннее, чем я могу здесь воспроизвести. В приведенном фраг-
менте я выделил курсивом те места, которые имеют отношение к понятию коопе-
ративных игр.
282
Приложение В
“Об участии и умении”
• • •
В дальнейшем я буду предполагать, что это новое понимание может быть
подкреплено знанием языковых игр и обычной языковой философии Людвига
Витгенштейна. Мое внимание сосредоточено на сдвиге в разработке от языка как
описания к языку как действию.
Переосмысление описаний систем
Несколько лет назад меня поразила одна вещь, которую прежде я не замечал.
Размышляя о том, как перспективы заставляют нас выбирать определенные сто-
роны действительности и считать их важными для включения в описание, я не
придал никакого значения собственному предположению, что описания, так или
иначе, являются зеркальными отражениями данной реальности. Раньше я рассуж-
дал так: поскольку в мире есть разные интересы, мы всегда должны сомневаться
в объективности проектных решений, которые в процессе принятия рациональ-
ного решения вроде бы вытекают из проекта. Поэтому я утверждал, что нам нуж-
но создавать описания с разных точек зрения, чтобы сформировать более
достоверное изображение. Однако я не сомневался в декартовой онтологии внут-
реннего мира опытов (души) и во внешнем мире объектов (внешней реальности).
Точно так же я был уверен в предположении, что язык — это наш способ отобра-
жения внешнего мира реальных объектов. Сосредоточившись на том, какие объ-
екты и какие отношения следует представлять в описании систем, я считал само
собой разумеющимся декартов дуализм души и тела, который Витгенштейн так
убедительно отверг в “Философских исследованиях” (1953). Следовательно,
хотя цель моя была противоположной, из-за своей точки зрения я закрывал глаза
на субъективность ремесла, артистизма, страсти, любви и заботы в системных
описаниях.
Наши опыты с проектом UTOPIA вынудили меня пересмотреть мои фило-
софские предположения. При работе с конечными пользователями, типограф-
скими рабочими некоторые методы разработки терпели неудачу, тогда как другие
приносили успех. Спецификации требований и описания систем, основанные на
информации из интервью, не были очень удачными. Улучшения появились: когда
мы предприняли совместные посещения интересных цехов, показов новых филь-
мов, изготовителей и вели обсуждения с другими пользователями; когда мы уде-
ляли значительно больше времени, учась друг у друга — проектировщики у
рабочих и рабочие у проектировщиков; когда мы начали использовать методы
проектирования действием (design-by-doing) и такие описания, как натурные мо-
дели и игры организации работы; когда мы начали понимать и использовать тра-
диционные инструменты как идеал для компьютерных систем.
Этот поворот можно понять в свете двух уроков, данных Витгенштейном.
Первый урок — в разработке нельзя недооценивать значение умения. Как выра-
Наур, Эн и Мусаши
283
зился Питер Уинч (Peter Winch, 1958): “Повар — не тот, кто представляет себе
вид пирога, а затем пытается его испечь. Это человек, обладающий навыками в
кулинарии, и от этих навыков берут начало его замыслы и его достижения”. Вто-
рой урок не заблуждаться относительно роли методов описания в разработке;
Витгенштейн убедительно доказывает: то, что изображение рассказывает, опре-
деляется его использованием.
Далее я проиллюстрирую, как наши “новые” методы разработки в проекте
UTOPIA можно понять с точки зрения Витгенштейна, т,е. почему работает про-
ектирование действием и основанный на умении процесс совместной разработки.
В более общем плане я приведу доводы, что такие инструменты разработки, как
модели, прототипы, макеты, описания и представления, действуют как напоми-
нания и случаи парадигмы на наше созерцание будущих компьютерных систем и
их использование. Такие инструменты разработки эффективны, поскольку они
воскрешают в памяти более ранние опыты. Именно в этом значении мы должны
понимать их как воспроизведения. Я начну с нескольких слов о практике — аль-
тернативе “изобразительной теории реальности”.
Практика — это реальность
Практика как общественное создание реальности является серьезным кандидатом
на замену изобразительной теории реальности. Если коротко, то практика — это
наша повседневная практическая деятельность. Она является формой жизни чело-
века. Она предшествует отношениям субъекта и объекта. Через практику мы созда-
ем как мир объектов, так и свое знание об этом мире. Практика — не только
действие, но и размышление. Но это также и общественная деятельность, осущест-
вляемая в сотрудничестве с другими. Разделять практику с другими — значит, дели-
ться также пониманием мира. Тем не менее это создание мира и нашего понимания о
нем происходит в уже существующем мире. Мир также является порождением
прежней практики. Следовательно, в качестве части практики знание должно быть
понято социально как производство или воспроизводство общественных процессов
и структур, а также как их порождение (Kosik, 1967; Berger & Luckmann, 1966).
На этом фоне мы можем понять разработку компьютерных приложений как
социально и исторически обусловленную деятельность, в которой инструменты и
их использование воображаемы. Это и деятельность, и форма знания — как пла-
номерная, так и творческая.
Что может приобрести проектирование, пораженное “наивными” декарто-
выми предположениями изобразительной теории, при сдвиге фокуса от правиль-
ности описаний к вмешательству в практику? Что это значит — встать на
позицию описания с помощью изображения того, что определено его использо-
ванием? Наиболее важно то, что тогда мы становимся чувствительными к крити-
ческой роли умения и участия в разработке и к возможности превзойти в
практической разработке некоторые границы формализации с помощью более
ориентированных на действие артефактов разработки.
284
Приложение В
Язык как действие
Обдумайте классический пример плотника и его деятельности. В профессиональ-
ном языке плотников существуют не только молотки и гвозди. Если бы плотник де-
лал стул, он мог бы использовать и другие инструменты: струг, дрель, фуганок,
пазник, рубанок, пилу, рейсмус и стамески (Seymour, 1984). Он работал бы с раз-
ным материалом выбрал бы вязовые доски для сидения, древесину ясеня для
подлокотников и дуба для ножек. Он использовал бы расковку, пропарку и изго-
тавливал соединения.
Помогают ли нам, как разработчикам новых инструментов для изготовления
стульев, эти ярлыки инструментов, материалов и видов деятельности? При под-
ходе Витгенштейна ответ должен быть таким: только если мы понимаем практи-
ку, в которой эти имена имеют смысл. Чтобы отметить ярлыком наш опыт, нужно
действовать осознанно. Чтобы действовать осознанно, мы должны быть к этому
подготовлены. Следовательно, нужно изучить, как отмечать опыт ярлыком. Язык
принадлежит не частному лицу, а обществу. Создаваемые нами ярлыки принад-
лежат практике, имеющей общественный смысл. Мы не можем узнавать, не зная
чего-то специфического. Понимать и уметь использовать — это одно и то же
(Wittgenstein, 1953). Понимание профессионального языка создания стульев и
любой другой языковой игры (чтобы использовать термин Витгенштейна) дает
возможность овладеть практическими правилами, которые мы не создавали
сами. Правила — это приемы и соглашения о создании стульев, которые явля-
ются неотъемлемой частью данной практики.
Овладеть профессиональным языком создания стульев — значит научить-
ся эффективно действовать вместе с другими людьми, знающими, как создавать
стулья. “Знать” не означает подробного знания правил, которые вы освоили;
вы должны распознавать, правильно или неправильно что-то сделано. Иметь
представление — значит научиться следовать правилам как части данной прак-
тики. Речевые действия как единство языка и действия являются частью прак-
тики. Они не суть описания, но далее я конкретизирую языковые игры,
сосредоточившись на описаниях процесса разработки в разработке, артефактах
разработки и знании в разработке компьютерных приложений.
Языковые игры
Использовать язык — значит участвовать в языковых играх. Рассматривая наше
следование правилам (а иногда их нарушение) на практике как общественную дея-
тельность, Витгенштейн просит нас думать об играх, о том, как они создаются и ра-
зыгрываются. Мы часто думаем об играх как о веселом, доставляющем
удовольствие занятии. Мне кажется, что этот аспект не следует отвергать, но бо-
лее важно для цели этого обсуждения то, что игры являются такими же видами дея-
тельности, как большинство общих языковых игр, в которые мы играем на нашем
обычном языке.
Наур, Эн и Мусаши
285
Языковые игры, подобно играм, в которые мы играли детьми, — это обще-
ственная деятельность. Чтобы иметь возможность играть в эти игры, мы должны
научиться следовать правилам, тем, которые созданы обществом, но далеко не
всегда подробно. Следование правилам для возможности играть вместе с други-
ми более существенно в игре, чем подробные специфические правила. Игра —
это взаимодействие и сотрудничество. Следовать правилам в практике — значит
уметь действовать понятным для других игроков образом. Эти правила вводятся в
данную практику, от которой их нельзя отделить. Знать их подразумевает воз-
можность их применения в других случаях.
Мы понимаем, что считается игрой, не потому, что у нас есть явное опреде-
ление, а потому, что уже знакомы с другими играми. Между играми существует
некое семейное сходство. Точно так же профессиональные языковые игры могут
быть изучены и поняты из-за их семейного сходства с другими языковыми игра-
ми, в которые мы умеем играть.
Языковые игры осуществляются как речевые действия и другие виды деятель-
ности, как имеющая смысл практика внутри социальных и культурных институ-
циональных структур. Чтобы иметь возможность участвовать в практике специ-
фической языковой игры, некто должен разделять форму жизни, в пределах
которой эта практика возможна. Эта форма жизни включает нашу естественную
историю, а также общественные учреждения и традиции, в которых мы родились.
Это условие превосходит установленные общественные соглашения и рациона-
льную аргументацию. Язык как средство общения требует соглашения не только
в определениях, но и в суждениях. Следовательно, единодушие между субъекта-
ми более фундаментально определяется общностью истории и языка, чем уста-
новленными мнениями (Wittgenstein, 1953).
Может показаться, будто это определение делает нас пленниками языка и
традиции, но на самом деле это не так. Будучи созданными обществом, правила
языковых игр, подобно другим играм, могут также изменяться обществом. Со-
гласно Витгенштейну, существуют даже игры, в которых мы создаем и изменяем
правила по ходу игры. Подумайте о разработке и использовании систем как о
языковых играх. Сама идея языковой игры интервенционистской разработки со-
стоит в том, чтобы должным образом изменять правила языковой игры при испо-
льзовании.
Идея языковых игр ставит акцент на способах лингвистического открытия
и создания нами своего мира. Однако язык понимается как общественное, ис-
торическое и межсубъектное применение лингвистических артефактов. Следо-
вательно, перспектива языковой игры не мешает нам рассмотреть, как мы
приходим к пониманию мира через использование других инструментов.
Инструменты и объекты играют основную роль во многих языковых играх.
Молоток является по своей сути знаком того, что можно с ним делать в опреде-
ленных языковых играх. Таково же и компьютерное приложение. Эти знаки на-
поминают нам, что ими можно делать. В этом свете в разработке компьютерных
приложений важно с помощью этих знаков напоминать пользователям, что они
286
Приложение В
могут делать с приложением в языковых играх в использование (Brock, 1986).
Успех пользовательских интерфейсов “что видишь, то и получаешь” и “непосред-
ственное манипулирование” связан не с более естественным отображением реа-
льности, а с предоставлением более удачных напоминаний о предыдущих опытах
пользователей (Bodker, готовится к печати). Это же справедливо в отношении
инструментов, которые мы используем, в процессе разработки.
Знание и артефакты проекта
Как разработчики мы включены в практику преобразования, в нашем случае —
типичных компьютерных систем и способов, которыми люди их используют. Сле-
довательно, языковые игры в разработку изменяют правила других языковых игр,
в частности использования приложения. Каковы условия эффективного выполне-
ния этого взаимодействия и изменения?
Общее предположение, стоящее за. большинством подходов разработки, за-
ключается, видимо, в том, что пользователи должны уметь давать полные и яв-
ные описания своих требований. Следовательно, акцент делается на методах,
поддерживающих это разъяснение с помощью спецификаций требований или
описаний системы (Jackson, 1983; Yourdon, 1982).
Используя подход Витгенштейна, мы не сосредоточиваемся на “правильно-
сти” описаний системы в разработке, на том, насколько точно отображаются в
них пожелания, существующие в головах пользователей, или насколько правиль-
но описывают они существующие и будущие системы и их применение. Описания
системы являются артефактами разработки. При подходе Витгенштейна наибо-
лее важен вопрос, как мы их используем, т.е. какую роль они играют в процессе
разработки.
Отказ от акцента на “правильности” описаний особенно важен. Об этом нас
уведомляет в “Логико-философском трактате” (1923) молодой Витгенштейн —
автор возможно наиболее сильных аргументов в поддержку изобразительной тео-
рии и декартова подхода к разработке. Причина этого отказа заключается в основ-
ной роли практического знания и творческом следовании правилам языковых игр.
ч Тем не менее мы знаем, что описания системы полезны в языковой игре в
разработку. Новая ориентация, предложенная в подходе Витгенштейна, состоит
в том, что мы считаем такие описания специальным типом артефакта, который
используем как “типичные примеры” или “случаи парадигмы”. Они не являются
моделями в смысле декартовых зеркальных отражений реальности (Nordenstam,
1984). В языковой игре в разработку мы применяем эти инструменты как напо-
минания в наших размышлениях о будущих компьютерных приложениях и их ис-
пользовании. Применяя такие артефакты разработки, мы вызываем воспоми-
нания о предыдущих опытах, и они влияют на наш образ мысли о прошлом и бу-
дущем. Думаю, именно поэтому мы должны понимать их как воспроизведения
(Kaasboll, готовится к печати). И именно так они информируют о нашей практи-
ке. Если это хорошие артефакты разработки, они будут поддерживать правиль-
ные ходы в конкретной языковой игре в разработку.
Наур, Эн и Мусаши
287
Значение артефакта разработки заключено в его использовании в языковой
игре в разработку, а не в его “отображении реальности”. Его способность под-
держивать такое использование зависит от разновидностей опыта, которые он
вызывает, семейного сходства с инструментами, используемыми участниками в
их повседневной рабочей деятельности. Этим можно объяснить, почему прорыв в
проекте UTOPIA был связан с использованием прототипов и макетов. Поскольку
артефакты разработки приобретали форму напоминаний или случаев парадигмы,
они просто не пытались отобразить данную или будущую практику лингвистиче-
ски. Возможно их получение через практическое использование прототипа или
макета. В дальнейшем этот опыт можно было бы обдумать в языковой игре в
разработку на обычном или искусственном языке.
Хороший пример из проекта UTOPIA дает пустая картонная коробка с над-
писью на крышке: “настольный лазерный принтер”. В этом макете функциональ-
ность отсутствует. И все же в игре в разработку, представляющей будущую
работу выдуманного персонала, он работает очень хорошо. Он напомнил участ-
вовавшим в игре печатникам старую “машину пробных отпечатков”, с которой
им доводилось работать в прежней технологии. В то же время пустая коробка
подсказывала, что с помощью новой технологии старую пробную машину можно
было создать заново и расширить ее функции.
Эта языковая игра в разработку проходила в 1982 г. В то время настольные
лазерные принтеры существовали лишь в передовых исследовательских лабора-
ториях, и, несомненно, печатники никогда о них не слышали. Для них мысль о де-
шевом лазерном принтере была “нереальной”.
Как профессиональные разработчики мы были обязаны знать о таких буду-
щих возможностях и предлагать их пользователям. В наши обязанности также
входило предложить это техническое и организационное решение таким образом,
чтобы пользователи могли приобрести опыт и представить себе, что это будет
значить в их практической работе до вложения огромных ресурсов времени, де-
нег и трудозатрат. Поэтому и возникла проектная игра с макетом лазерного при-
нтера. Этот макет был полезен для всех участников, пользователей и разра-
ботчиков (Ehn & Kyng, 1991).
Такая концентрация на нелигвистических артефактах разработки не озна-
чает непризнания важности лингвистических методов. Если их цель заключает-
ся в активизации нашего воображения, а не в зеркальном отображении
реальности, то они действительно могут оказаться наиболее замечательными
человеческими изобретениями. Лингвистические артефакты разработки очень
эффективны, когда они требуют от нас рассказывать то, что имеет смысл для
всех участников.
Практическое понимание и пропозициональное знание
В языковой игре есть много действий (в использовании прототипов и макетов их не
меньше), которые не могут быть явно описаны на формальном языке. Что пользо-
ватели знают, т.е. чему они научились и могут выразить действием, но не могут
288
Приложение В
сформулировать явно на языке? Витгенштейн (1953) просит нас “сравнить знание
и произнесение: какова высота Монблана в футах; как используется слово ’’игра";
как звучит кларнет. Если вас удивляет, что кто-то может знать о чем-то, то вы, воз-
можно, думаете о случае, похожем на первый. Ясно, что это не может быть третий
случай”.
В проекте UTOPIA мы разрабатывали новые компьютерные приложения для
применения в типографской верстке страниц. Печатники могли сообщить нам
названия разных инструментов и материалов, которые они используют: нож,
грунт страницы, основной текст, наборная доска, логотип, автотипия, рамка и
растискивание изображения. Они могли также сообщить, когда и в каком поряд-
ке используют специфические инструменты и материалы, чтобы подготовить ста-
тью. Например, они могли сказать: “Сначала вы подбираете ножом основной
текст и помещаете его внизу намеченной области на грунте страницы. Затем вы
его подгоняете по линии наборной доски. Когда основной текст установлен, бере-
те заголовок — если нет картинки” и т.д. Из такого доклада я, как разработчик,
могу почерпнуть знания, эквивалентные знанию высоты Монблана. То, что мне
удается понять, сильно отличается от практического понимания реальной верст-
ки страницы, как знание высоты Монблана дает мне очень незначительное пони-
мание практического опыта восхождения на гору.
Знание первого типа называется пропозициональным знанием. Это то, чем
вы обладаете, “когда знаете, что что-то имеет место, а также можете в несколь-
ких словах описать то, что вы знаете” (Norclenstam, 1985). Пропозициональное
знание не обязательно более отражательно, чем практическое понимание. Это
просто что-то, о чем мне сообщили, но в отношении чего я не имею ни практиче-
ского опыта, ни теоретического понимания.
Второй случай, соответствующий знанию, как используется слово “игра”,
был более сложным для наших печатников. Как они могли нам рассказать, на-
пример, об умении действовать ножом при верстке страницы в технологии ап-
пликации? Это их практический опыт из языковых игр в типографскую
разработку. Чтобы это показать, они должны это сделать.
А как им следовало рассказывать, что считается хорошим макетом, о слож-
ном взаимодействии наличия и отсутствия, светлого и темного, симметрии и
асимметрии, однотипности и разнообразия? Могли ли они сделать это любым
другим способом, не прибегая к примерам хороших и плохих макетов, которые
они умеют различать, участвуя в играх типографской разработки? Как и в случае
знания о звучании кларнета, обычно это чувственное знание, выражаемое через
знакомство со звуками, запахами и т.д.
Практическое понимание — в смысле практического опыта делания чего-то
и обладания более ранним чувственным опытом — игнорирует формальное опи-
сание. Если бы оно превращалось в пропозициональное знание, оно стало бы
чем-то совершенно другим.
' Сомневаюсь, что нам, разработчикам компьютерных систем для верстки стра-
ниц, удалось бы находить полезные решения без понимания того, как используется
Наур, Эн и Мусаши
289
нож и что считается хорошим макетом. По этой причине мы должны иметь доступ
не только к тому, что может быть сформулировано в качестве явного пропозицио-
нального знания. Мы могли бы только достигнуть этого понимания, участвуя, в из-
вестной степени, в языковых играх использования типографских инструментов.
Следовательно, участие относится не только к пользователям, участвующим в
языковой игре разработки, но — что, наверное, более важно — и к разработчи-
кам, участвующим в использовании.
Следование правилам и традиция
Теперь я обращаюсь к парадоксу следования правилам. Как уже было сказано,
многие правила, которым мы следуем на практике, едва можно отличить от поведе-
ния, в котором мы их выполняем. Мы не знаем, что следовали правилу, пока не
сделали это. Наиболее важные правила, которым мы следуем при умелом испол-
нении, игнорируют формализацию, но мы, тем не менее, их понимаем. Как выра-
зился Майкл Поляны (Michael Polanyi, 1973), философ, занимающийся
неформальным знанием: “Это душераздирающее зрелище — наблюдать беско-
нечные усилия с привлечением микроскопии и химии, математики и электроники,
направленные на воспроизведение единственной скрипки того типа, который по-
луграмотный Страдивари рутинно произвел более 200 лет назад”. Это традицион-
ная сторона человеческого следования правилам. Поляны отмечает, что,
возможно, наша наиболее широко признанная, ясная, основанная на правилах си-
стема — практика общего права — также использует более ранние примеры как
случаи парадигмы. Поляны говорит: “[Общее право] распознает принцип привер-
женности всем традициям, которые практическая мудрость более достоверно во-
площает в действие, чем выражено в правилах действий”. Согласно Поляны, это
также верно для науки, независимо от степени ее притязаний на рациональность и
ясность: “Тогда как четко сформулированное содержание науки успешно препода-
ется во всем мире в сотнях новых университетов, неспецифицированное искусство
научного исследования еще не проникло во многие из них”. Искусство научного
исследования игнорирует полную формализацию, оно должно изучаться на приме-
рах мастера, поведению которого доверяет учащийся.
Привлечение квалифицированных пользователей к разработке нового компь-
ютерного приложения, когда меняются их старые инструменты и рабочие привыч-
ки, отличная иллюстрация тезиса Поляны. Если такие виды деятельности,
которым необходима формализация, как право или наука, так зависимы от практи-
ческого опыта и случаев парадигмы, то почему мы должны ожидать, что другие об-
щественные учреждения, не так нуждавшиеся в формализации, будут меньше
базироваться на практическом опыте, случаях парадигмы и неформальном знании?
Следование правилам и трансцендентность
Разработка представляет собой не только следование правилам, но и творческую
трансцендентность традиционного поведения. Кроме того, это то, что характерно
290
Приложение В
для умелого поведения человека, и именно то, что не придает значения точной фор-
мализации. Через усвоение правил приходит свобода в их расширении. Это твор-
чество основывается на открытом характере следования правилам. На первых
порах мы учимся следовать правилу, будто объезжаем лошадь, но в конце выпол-
няем его творчески (Dreyfus & Dreyfus, 1986). Усвоение правил дает нам возмож-
ность изобретать новые пути действия. Как выразился комментатор Витгенштейна
Алан Джаник (Alan Janik): “Для нас всегда существует возможность следовать
правилу по абсолютно неожиданному пути. Этого не могло бы происходить, если
бы мы должны были иметь подробное правило, чтобы действовать с самого нача-
ла.., возможность радикального нововведения, однако, является логической гра-
ницей описания. Вот что такое неформальное знание” (Janik, 1988). Вот почему
нам нужно обратить серьезное внимание на умение как в разработке, так и в испо-
льзовании компьютерных систем. Мы обращаем внимание на существующее уме-
ние не для запрещения творческой трансцендентности, а как на ее необходимое
условие.
Но какова роль “новых” внешних идей и опытов в разработке? Как традиция
и трансцендентность объединяются в подходе Витгенштейна? Это могло, я пола-
гаю, означать использование какого-то подобия эффекта театральной “отчуж-
денности” Бертольда Брехта (Verfremdungseffekt), чтобы выделить
трансцендентные неиспытанные возможности в повседневной практике, пред-
ставляя хорошо известную практику в новом свете: “аспекты вещей, наиболее
важные для нас, прячутся из-за своей простоты и привычности” (Wittgenstein,
1953). Тем не менее, как сказал Питер Уинч (Peter Winch, 1958, с. 119), исполь-
зуя подход Витгенштейна, “единственное законное использование такого эффек-
та отчужденности — привлечь внимание к знакомому и очевидному, а не
показать его незначительность в нашем понимании”.
Артефакты разработки, лингвистические и прочие, в подходе Витгенштейна,
несомненно, могут использоваться, чтобы разрушить традиционное понимание,
но они должны иметь смысл в обычных языковых играх пользователей. Если ин-
струменты разработки эффективны, то это потому, что с их помощью пользова-
тели и разработчики могут увидеть новые стороны уже известной практики, а не
потому, что они передают новые идеи. Нужно честно признать, что это внимание
к традиционному умению вместе с умением разработки может мешать действите-
льно революционным разработкам. Разработка радикально новых прректов мо-
жет потребовать использования рычагов другого умения и привлечения других
потенциальных пользователей. Некоторые проекты, тем не менее, действительно
революционны, и в нормальных повседневных рабочих ситуациях участие тради-
ционно квалифицированных пользователей критически важно для качества резу-
льтирующего продукта.
Противоречие между традицией и трансцендентностью фундаментально для
разработки. В создаваемых системах можно уделять внимание традиции или
трансцендентности. Следует ли разрабатывать текстовый процессор как расши-
Наур, Эн и Мусаши
291
рение функций традиционной пишущей машинки или как что-то абсолютно но-
вое? Другое измерение — это профессиональная компетенция: следует ли
создавать систему для “старого” умения печатников или новое знание должно за-
менить в будущем это умение? Или третья сторона — разделение труда и сотруд-
ничество: должна ли новая разработка поддерживать традиционную организацию
наборного цеха или ей нужно предлагать новые пути сотрудничества между пе-
чатниками и журналистами? Есть также противоречие между традицией и транс-
цендентностью по отношению к товарам или услугам, производимым с
использованием новой системы: должна ли разработка поддерживать традицион-
ное графическое производство или вводить абсолютно новые услуги, например
настольное издательство?
Традиция и трансцендентность — таков диалектический фундамент разра-
ботки.
Проектирование
действием: Новые "правила игры"
Что мы, как разработчики, должны сделать, чтобы приготовиться к участию в язы-
ковых играх пользователей? Чему должны научиться пользователи, чтобы они
могли участвовать в языковой игре в разработку? И какие средства можно создать
при разработке, чтобы облегчить эти процессы изучения?
Если разработчики и пользователи ведут сходный образ жизни, то они могут
преодолеть разрыв между разными языковыми играми. Можно, по крайней мере
в принципе, создать такую практику разработки, чтобы она в достаточной степе-
ни учитывала семейное сходство между специфической языковой игрой пользо-
вателей и языковыми играми, в которые вмешиваются разработчики
компьютерного приложения. Посредничество должно быть возможным.
Но какие нужны условия для установления этого посредничества? Для Вит-
генштейна не имело бы смысла задавать этот вопрос за пределами данной формы
жизни: “Если бы лев говорил, мы не смогли бы его понять” (1953). В приводи-
мых ниже доводах я предположил, что для общей формы жизни можно создать
условия, и львы с овцами в промышленной жизни, как обсуждалось в первой ча-
сти этой главы, могут существовать совместно. Это в большей степени норма-
тивная точка зрения на то, какой должна быть разработка, скорее демокра-
тическая надежда, чем порицание современных политических условий.
Для того чтобы развить компетентность, необходимую для участия в языко-
вой игре, нужно многому научиться в пределах этой практики. Но вначале чело-
век может понять лишь то, что он уже понял в другой языковой игре. Если мы
понимаем хоть что-то, то лишь благодаря семейному сходству между двумя язы-
ковыми играми.
Какой тип инструментов разработки мог бы поддерживать это взаимодейст-
вие между языковыми играми? Я думаю, что инструменты, которые мы в проекте
UTOPIA называли методами “проектирования действием” — прототипы, макеты
292
Приложение В
и сценарии, — хорошие кандидаты на эту роль. Даже совместные визиты на ра-
бочие места, особенно на те, для которых в системе создаются аналоги, служили
своего рода инструментом разработки, с помощью которого разработчики и по-
льзователи перекидывали мост между своими языковыми играми.
Языковые игры в проектирование действием можно рассматривать с двух то-
чек зрения: пользователей и разработчиков. Пользователи узнают о возможно-
стях и ограничениях новых компьютерных инструментов, и эти самые
инструменты могут стать частью их обычных языковых игр. Разработчики стано-
вятся преподавателями и учат пользователей участвовать в конкретной языковой
игре в разработку. Тем не менее, чтобы установить тип языковых игр, разработ-
чики сами должны учиться у пользователей.
Однако, как ни парадоксально, пользователям и разработчикам не нужно до-
биваться абсолютного понимания, когда они вместе участвуют в языковых играх
в проектирование действием. Участие в языковой игре в разработку и использо-
вание артефактов разработки может иметь конструктивный, но разный смысл
для пользователей и разработчиков. Витгенштейн (1953) отмечает, что, “когда
дети играют в поезда, эта игра связана с их знанием поездов. Однако дети из пле-
мени, не знакомого с поездами, могли бы научиться этой игре у других, не зная,
что она с чего-то скопирована. Можно сказать, что эта игра имеет для нас с ними
разный смысл”. До тех пор, пока языковая игра в разработку представляется лю-
бому участнику не бессмысленным занятием, а совместной деятельностью для
лучшего взаимодействия и получения хорошей разработки, взаимопонимание мо-
жет быть желательным, но не обязательным.
Участие пользователя и умение
Пользователи могут участвовать в языковой игре в разработку, поскольку приме-
нение артефактов разработки придает их деятельности как разработчиков семей-
ное сходство с языковыми играми, в которые они играют в обычных ситуациях
использования. Примером из проекта UTOPIA служит печатник, сидящий у маке-
та будущей рабочей станции для верстки страниц и занимающийся версткой в ими-
таторе будущего компьютерного инструмента.
Семейное сходство — это лишь один аспект этих методов. Другой аспект от-
носится к тому, что может быть выражено. В проектировании действием пользо-
ватель способен выразить как пропозициональное знание, так и практическое
понимание. Например, печатник, работавший с макетом, не только мог сказать,
что для показа всей страницы экран должен быть больше — важное требование
при верстке страницы, — он также мог показать это, что называется, “обрезкой
картинки”, действительно сопровождая слова действиями. Таким образом, он
мог выразить свое практическое понимание, свое чувственное знание благодаря
осведомленности. Работая с макетом, он мог выразить тот факт, что при одном
варианте разработки системы можно получить хорошо сбалансированную стра-
ницу, а при другом — нельзя.
Наур, Эн и Мусаши
293
Участие разработчика и умение
Как разработчики мы можем выражать и пропозициональное знание, и практиче-
ское понимание разработки и компьютерных систем. Мы не только выражаем про-
позициональное знание, говоря, например, что “в проектировании действием
инструменты разработчика имеют много преимуществ по сравнению с описаниями
традиционных систем” или “растровые дисплеи с размером диагонали больше 22
дюймов и разрешением более 2000 х 2000 очень дороги”, но в языковой игре в про-
ектирование действием мы также показываем практическое понимание технических
ограничений и возможностей, “реализуя” их в макете, прототипе, моделировании
или экспериментальной ситуации. Моделирование пользовательского интерфейса
также является важной частью этой языковой игры в разработку.
Наше практическое понимание главным образом будет выражено в способно-
сти создавать такие специфические языковые игры в разработку, чтобы пользова-
тели могли развивать свое понимание будущего применения, участвуя в процессах
разработки.
Как отмечалось выше, у языковых игр есть и другой важный аспект: мы со-
здаем правила по ходу работы. Квалифицированный разработчик должен уметь
участвовать в такой трансцендентной, нарушающей правила деятельности. Воз-
можно, хороший разработчик должен владеть этим искусством с артистической
компетентностью.
Действительно, научиться языковой игре в использование, полностью в ней
участвуя, — это даже более радикальный подход для разработчиков. Менее ра-
дикальным для них, но, возможно, более подходящим было бы сосредоточиться в
разработке лишь на нескольких языковых играх в использование, а для нас —
развить практическое понимание полезных специфических языковых игр в раз-
работку (Ehn & Kyng, 1987). Наконец, по-видимому, для разработчика сущест-
вует новая роль человека, который готовит почву для совместной языковой игры
в разработку, имеющей смысл для всех ее участников.
Некоторые
уроки разработки, умения и участия
Как и в первой части этой статьи, посвященной практике разработки и демокра-
тизму в работе, эту вторую, философскую часть об ориентированной на умение со-
вместной разработке для сферы производства я заканчиваю некоторыми уроками,
пригодными для использования в работе.
В разработке для сферы производства можно использовать следующие об-
щие уроки:
1. Понимание разработки как процесса создания новых языковых игр, име-
ющих семейное сходство с языковыми играми как пользователей, так и
разработчиков, ориентирует нас на разработку для сферы производства
через участие, основанное на умении — способе разработки, который
294
Приложение В
поможет нам выйти за некоторые границы формализации. Подготовка
этих языковых игр в разработку — это новая роль для разработчика.
2. В подходе совместной разработки, основанной на умении, недостаточно
пользоваться традиционными “описаниями систем”. Артефакты разра-
ботки следует понимать главным образом не как средства создания до-
стоверных “изображений реальности”, а как инструменты,
помогающие пользователям и разработчикам обсуждать и получать те-
кущие ситуации и представлять себе будущие.
3. Подходы “проектирования действием”, например использование маке-
тов и других артефактов — прототипов разработки, позволяют обыч-
ным пользователям применить свое практическое умение в процессе
разработки.
Уроки умения в разработке компьютерных систем таковы:
1. Совместная разработка — это процесс изучения, в котором разработ-
чики и пользователи учатся друг у друга.
2. Наряду с пропозициональным знанием практическое понимание явля-
ется типом умения, которое должно серьезно приниматься в расчет в
языковой игре, поскольку наиболее важные правила, которым мы сле-
дуем в умелом исполнении, внедрены в практику и пренебрегают фор-
мализацией.
3. Творчество зависит от открытого характера следования правилам, поэ-
тому внимание к традиционному умению является не преградой творче-
ской трансцендентности, а необходимым условием. Поддержание
диалектического равновесия между традицией и трансцендентно-
стью — основа разработки.
Уроки участия в разработке компьютерных систем таковы:
1. Подлинно совместная разработка требует совместной формы жиз-
ни — общего социального и культурного окружения и общего языка.
Следовательно, совместная разработка означает не только участие
пользователей в разработке, но и участие разработчиков в использо-
вании. Профессиональный разработчик будет пытаться разделить
практику с пользователями.
2. Чтобы сделать реальное участие пользователя возможным, языковая
игра в разработку должна иметь семейное сходство с языковыми игра-
ми, в которых пользователи участвовали прежде. Следовательно, твор-
ческий разработчик должен вовлекать практику пользователей в
организацию процесса разработки, понимая, что каждая новая языко-
вая игра в разработку является уникальным опытом. Однако, как это ни
парадоксально, языковая игра в разработку не должна иметь один и тот
Наур, Эн и Мусаши
295
же смысл для пользователей и разработчиков. Требуется только, чтобы
разработчик подготовил почву для игры, которая имеет смысл для всех
ее участников.
За скукой разработки
В первой части этой статьи, обусловленной скандинавским социальным, историче-
ским и культурным окружением, особое внимание уделялось демократическому
аспекту совместной разработки, основанной на умении, а также важной роли
местного профсоюза и его стратегии в отношении участия пользователей. Во вто-
рой части к повседневной практике совместной разработки, основанной на уме-
нии, были применены некоторые идеи, основанные на философских иссле-
дованиях Людвига Витгенштейна. Как фундаментальные понятия разработки сис-
тем для сферы производства были представлены практическое понимание и се-
мейное сходство между языковыми играми.
Понятие языковых игр ассоциируется с чем-то веселым, но какие практиче-
ские условия необходимы для такого приятного времяпрепровождения в разра-
ботке? Достаточно ли права демократического участия?
Фактически опыт разработки проектов для сферы производства показывает,
что большинство пользователей находят участие в разработке скучным делом,
иногда настолько, что прекращают этим заниматься. Такая проблема не уникаль-
на для скандинавской традиции разработки в сфере производства. К ней обра-
щался, например, Расселл Акоф (Russell Ackoff, 1974), сделавший вывод, что
участие в разработке может быть успешным лишь в том случае, если оно соот-
ветствует трем условиям: (1) существенно меняет дело для участников, (2) веро-
ятна реализация результатов, (3) это весело.
Первые два пункта касаются политической стороны участия в разработке.
Пользователи должны иметь гарантию, что их усилия будут приниматься всерьез.
Последний пункт относится к процессу разработки. Независимо от того, наско-
лько большое влияние может оказать участие, оно должно превзойти скуку тра-
диционных собраний разработчиков, чтобы действительно сделать разработку
значимой и наполненной действием привлеченных участников. Разработка дол-
жна быть веселой. В наших собственных последующих проектах мы попытались
принять этот вызов серьезно и объединили использование семинаров обсужде-
ния будущего, метафорической разработки, разыгрывания ролей и организаци-
онных игр в разработку для сферы производства (Ehn & Sjogren, 1991).
Таким образом, последний урок из скандинавских разработок состоит в том,
что формально демократических и совместных процедур проектирования компь-
ютерных систем для демократизма в работе недостаточно. Наши языковые игры
в разработку должны быть организованы таким образом, чтобы позволить обыч-
ным пользователям не только применять их практически в работе над проектом,
но при этом весело проводить время.
296
Приложение В
Размышления о работе Эна
Каждый раз, читая статью Эна, я понимаю, что остаюсь, может быть, в еще боль-
шем долгу перед этой работой, чем думал раньше. Перечитав ее снова перед напи-
санием этого абзаца, я был поражен его использованием Shu-Ha-Ri, вниманием к
“пониманию через действие” и уяснением того, как в людях, благодаря их действи-
ям, растет новое понимание.
Очевидно, в 1993 г. я не был готов к восприятию очень многих его идей и
привыкал к ним в течение нескольких лет. Это дает мне повод спросить себя, как
много других концепций, им упомянутых, я пока не заметил.
Надеюсь, что через год-другой у вас найдется время перечитать эту статью.
Мусаши
Миямото Мусаши был самураем, жил в 17 в. и не написал ни одной программы.
Он утверждал, что не проиграл ни одного боя. Проиграть бой означало по-
лучить серьезные увечья, поэтому остаться в живых, сохранить руки-ноги це-
лыми к 70 годам было настоящим достижением.
В серии романтических книг о Мусаши описываются его молодые годы, его
бои и духовное развитие. Они замечательно читаются, в них живо изображен его
подход к боевым искусствам, описанный в его личной книге.
Эта личная книга называется Go Rin No Sho (по-английски The Book of Five
Rings — Книга пяти колец); у меня есть перевод Томаса Клири (Thomas Cleary,
Shambhala, 2000). Мусаши написал ее в 70 лет. В книге максимально ясно обри-
совывается его подход, описываются его душевные состояния, специфические
движения и использование больших групп. Это краткая, понятная книга, абсо-
лютно лишенная обычной дзэн-тарабарщины: “Быть, не существуя, сражаться
без боя, побеждать, проигрывая” и т.д.
Я включаю Мусаши в это приложение, поскольку три характеристики его
боевого стиля соответствуют моему стилю разработки ПО, а он так удачно их
описывает:
Не развивайте привязанности ни к какому одному виду оружия и одной шко-
ле боя.
Практикуйте и наблюдайте, размышляя.
Выигрывайте.
В первой рекомендации говорится об использовании любых и всех школ и
приемов без создания особых предпочтений.
В то время, когда писалась книга Мусаши, воины создавали школы вокруг
конкретных поз, стилей, видов оружия и тактик. По его мнению, каждая из них
обладала своими достоинствами и слабостями; следовало использовать несколь-
ко школ, а не привязываться к какой-либо одной из них.
Наур, Эн и Мусаши
297
То же самое справедливо в отношении методов разработки ПО. Не привязы-
вайтесь к UML, RUP, СММ, SEI, ХР, CRC (вставьте еще аббревиатуру вашей
любимой школы или инструмента). Используйте все что угодно, что вам нужно в
данный момент. Открывайте, что вам требуется в разные моменты для разработ-
ки стратегии выбора инструмента и метода, которая будет вам подсказывать, ка-
кой из них доставать и когда его откладывать в сторону.
Во втором пункте дается совет размышлять о том, что и как вы делаете.
Практика, сопровождаемая размышлениями, обсуждалась во всей этой книге.
В третьей рекомендации говорится, что главное — не выглядеть хорошо,
а стремиться побеждать.
Победы в игре в разработку ПО — это поставки законченных программных
продуктов. Если вы можете не использовать никаких процессов, то так и делайте.
Моя вечно любимая рекомендация группе звучит так:
“Что? У вас проект на пять недель с тремя разработчиками, которые уже де-
лали это раньше на той же технологии? Вам не нужен координатор группы —
сделайте то же самое и ступайте по домам”.
Мусаши сказал: “Не делайте бесполезных вещей”.
Мусаши заботился о победе в игре, которая в его случае означала жизнь или
смерть. Я привязан к поставке программ. Умение танцевать не имеет значения,
если программа производится не в срок.
Читая следующий текст, обратите внимание, что уже в 17 в. Мусаши описы-
вает Shu-Ha-Ri и говорит о важности развивать умение.
В разработке ПО “противник” — это решаемая задача. “Убить противника”
значит создать законченный продукт и победить в игре. Вот некоторые выраже-
ния Мусаши (или их перевод Клири), представленные'как отдельные фрагменты.
Книга пяти колец
Сейчас, сочиняя эту книгу, я не заимствую старые изречения буддизма или
конфуцианства и не использую старые рассказы из военных хроник или
книг о военной науке...
Область боевых искусств особенно изобилует напыщенными попытками
произвести эффект, коммерческой популяризацией и спекуляцией как со
стороны тех, кто преподает науку, так и тех, кто ее изучает. В результате,
как кто-то сказал, “любительское боевое искусство стало источником серь-
езных ранений”...
Умелый плотник, знающий размеры и конструкции всех видов строений,
привлекает работников для строительства домов. В этом отношении уме-
лый плотник подобен умелому воину... Поскольку мастер-плотник руково-
дит наемными рабочими, он знает их уровни умения и дает им
соответствующие задачи... Эффективность и ровное движение вперед,
осмотрительность по всем вопросам, признание должной смелости, при-
298
Приложение В
знание разных уровней морали, внушение доверия и осознание, чего можно
ожидать, а чего не стоит — таковы вопросы, занимающие голову масте-
ра-плотника. Основы боевых искусств похожи на это...
Применяя терминологию плотничного дела, воины натачивают свои собст-
венные инструменты, создают разнообразный полезный инвентарь и хранят
его в специальных футлярах... Важнейший навык для плотников — иметь
острые инструменты и поддерживать их наточенными...
Вы должны наблюдать, размышляя, получать общее понимание всей кар-
тины и проявлять абсолютное понимание мелких деталей...
Достигнув основ, человек отделяется от них; таким образом, он доброволь-
но получает независимость от науки боевых искусств и, естественно, дости-
гает удивительных вещей: распознавая ритм, когда приходит время, он
внезапно наносит удар и побеждает...
В моей личной школе человек может победить с длинным мечом, но может
победить и с коротким мечом. По этой причине точная длина меча не уста-
новлена. Путь моей школы — это дух одерживать победы любыми средст-
вами...
Рискуя своей жизнью, вы хотите использовать все ваши инструменты... Мы
считаем, что какое бы ни было оружие, есть время и ситуация, когда оно
подходит... Эффективность копья и алебарды зависит от условий; ни то, ни
другая не очень полезны в толпе... их нужно приберечь для поля битвы...
[лук] не подходит для осады дворца...
В настоящую эпоху не только лук, но и другие искусства больше цветут, чем
плодоносят. Такие навыки бесполезны, когда приходит настоящая нужда...
Вы не должны испытывать особой любви к особому вйду оружия или к че-
му-либо еще в таком же роде. Слишком много — все равно что недостаточ-
но... Самое важное — прагматическое мышление...
Какую бы защиту вы ни приняли, не думайте о ней как о защите; думайте
о ней как о составной части смертоносного действия...
Принимаете ли вы серьезную или скромную защиту — зависит от ситуации;
следуйте наиболее благоприятной...
(Первый прием)... Ваш меч, отскочивший вверх, оставляете в этом положе-
нии, пока ваш противник не ударит снова, после чего вы бьете противника
по рукам снизу...
(Второй прием)... Если ваш меч не задел противника, оставляете его на
мгновение в этом положении, пока противник не ударит снова, после чего
вы наносите удар взмахом снизу вверх...
Наур, Эн и Мусаши
299
(Третий прием)... Когда противникнаноситудар, вы бьете по его рукам сни-
зу.., когда он пытается выбить ваш меч вниз, ритмично поднимаете его
вверх, затем рубите его по рукам сбоку. Суть в том, чтобы сразу убить про-
тивника из нижней позиции, как только он ударит...
Иметь позицию без позиции или защиту без защиты означает, что длинный
меч не допускается держать в неизменной позиции... Как вам держать
меч — это зависит от соотношения сил, от места и должно соответствовать
ситуации; как бы вы его ни держали, нужно держать его так, чтобы было
легче убить противника... Даже если вы можете поймать, выбить или бло-
кировать хлещущий меч противника, или помешать, или препятствовать
его движению, все эти движения — возможность сразить противника. Это
должно быть понято...
... как победить с длинным мечом в соответствии с законами боевых ис-
кусств. Этого нельзя записать подробно, каждый должен понять на практи-
ке, как победить.
... сила знания искусства меча. Это что-то такое, требующее основательно-
го изучения, тысяч дней практики для тренировки и десяти тысяч дней прак-
тики для усовершенствования...
Другие школы стали театральными: наряжаясь и рисуясь, они делают из бо-
евых искусств яркие, прибыльные зрелища... Вы думаете, что, узнав, как
обращаться с длинным мечом, потренировав тело и руки, можно понять,
как достичь победы? В любом случае это ненадежный путь...
... идеи каждой школы и логика каждого пути реализованы по-разному,
в соответствии с особенностями отдельной личности, в зависимости от ее
ума...
Таким образом, в моей школе сложилась антипатия к ограниченному, пре-
дубежденному отношению...
В моей школе не уделяется внимание ничему неразумному; суть вопроса
в том, чтобы использовать силу знания боевых искусств для завоевания
победы любым возможным для вас способом...
Применение методов Мусаши к разработке ПО
Я разделяю с Мусаши три точки зрения, но четвертая у меня иная.
Подходящий инструмент, подходящие приемы
Знайте свои инструменты, знайте, что вам нужно в данный момент, и вы будете по-
нимать, как извлечь пользу из имеющихся в вашем распоряжении инструментов,
300
Приложение В
даже если они несовершенны. Вы можете даже с выгодой пользоваться инстру-
ментами, не предназначенными первоначально для разработки ПО.
Вот как я работаю в двух разных условиях.
Получив для использования CASE-средство, я в первую очередь исключаю
все возможности инструмента, которые не приносят пользу разрабатываемому
проекту. Хотя это и будет означать неполное использование дорогостоящего ин-
струмента, но моя цель состоит не в его максимальном использовании, а в созда-
нии законченного продукта.
В другом проекте как основную стратегию можно выбрать создание оконча-
тельного кода с помощью CASE-средства. В этом проекте мы планируем расши-
рить возможности инструмента, поскольку нам необходимо, чтобы он выполнил
свою задачу.
Знайте свои любимые инструменты и приемы для решения основных задач,
не привязываясь излишне ни к одному из них. Учитесь приспосабливаться к лю-
бому доступному инструменту.
Прямое решение
Посмотрите, не сможете ли вы просто “отрубить противнику руку одним ударом”,
как в бою на мечах. В терминах разработки ПО можно сказать: “сделать и разо-
йтись по домам”. Избегайте излишних затрат.
Когда вам нужно сделать ложный выпад, блокировку, парировать удар про-
тивника, понимайте, что вы это делаете из-за отсутствия альтернативы. Ваши
действия должны быть лишь достаточными для победы. Избегайте напыщенных
попыток произвести эффект — это не помогает достижению результата.
В разработке ПО ищите простые решения для ваших проблем с процессом
разработки так же, как вы ищете простые решения для технических проблем.
Вспомните предложение, резюмирующее работу с Crystal Clear: “Поместите
команду в комнату с печатающими белыми досками, обеспечьте ее доступом к
пользователям-экспертам и попросите поставлять работающие протестирован-
ные программы каждые два месяца”. Если можете это сделать, просто это сде-
лайте.
Размышления и развитие умения
Продолжайте развивать свое умение и регулярно размышляйте о своей работе.
Вмешательство микрокасания
В одной области я действительно расхожусь с Мусаши. Его делом было убивать
людей или быть убитым самому. Мое дело — помогать людям производить и по-
ставлять работающее ПО. Вот в чем впечатляющая разница.
Мне нравится быстро добраться до самого сердца задачи, но людей я остав-
ляю совершенно невредимыми. Стратегия вмешательства с отсеканием рук не-
Наур, Эн и Мусаши
301
эффективна. Я стараюсь добиться в людях, работающих над проектом, самых
незначительных изменений, позволяющих завершить работу: это — вмешатель-
ство микрокасания. (В действительности я считаю, что и в этом Мусаши согла-
сился бы со мной, если бы работал в моей сфере.)
Вмешательство микрокасания основано на двух идеях:
С улучшением понимания требуется меньше вмешательств.
Множество согласованных микроскопических изменений могут оказать
очень серьезный эффект.
Лучше понимание — меньше вмешательство. Двести.лет назад больные си-
филисом умирали. Сто лет назад их подвергали лечению почти смертоносными
препаратами мышьяка. В наши дни им дают антибиотики. Первые антибиотики
убивали широкий спектр бактерий, в настоящее время антибиотики направлены
против специфических бактерий.
Ранние компьютеры производились с использованием больших электронных
ламп. Затем их стали делать из транзисторов. Теперь они состоят лишь из неско-
льких тысяч атомов, а в самое последнее время — просто из отдельных атомов.
Чем меньшая энергия требуется для осуществления необходимого измене-
ния, тем лучше мы понимаем, что делаем. Когда мы понимаем достаточно хоро-
шо, нам нужно сделать лишь микроскопический шаг, и его последствия
произведут интересующий нас макроэффект.
В разработке ПО мы все еще находимся на стадии ампутации. По мере того
как мы лучше понимаем силы, лежащие в основе нашей профессии, мы улучша-
ем ситуацию с помощью все менее и менее значительных изменений. Я знаю, что
предлагать людям изменить их личные привычки — очень существенное требо-
вание, и поэтому предпочитаю изменить размещение команды или перераспреде-
лить работы и предоставить механизму общения между людьми осуществить
гораздо более серьезные изменения.
Сложение небольших изменений. Мне кажется замечательным, что про-
стая ориентация множества микроскопических магнитных доменов в металле
превращает простой металл в сильный магнит.
Тот же самый эффект оказывает на проект ориентация в одном направлении
целей нескольких человек.
Вообразите себе многих людей, работающих над собственными системами
ценностей, преследующих любые цели, случайно возникающие перед ними каж-
дый день. Иногда, почти наугад, они будут то помогать, то мешать друг другу.
Предположим, вы просите каждого человека несколько изменить его пове-
дение в такой степени, которую он посчитает приемлемо незначительной. Вы мо-
жете так организовать изменения, чтобы люди мешали друг другу меньше, а
помогали больше. Они ориентируются в одном и том же направлении. Почти не
затрачивая дополнительной энергии, команда, работающая над проектом, приоб-
302
Приложение В
ретает результирующую силу, абсолютно непропорциональную изменениям (гра-
фически это показано на рис. 3.17 и 3.18). Кент Аретт резюмировал это в
следующей формулировке: “Приукрашивайте, что видите, принимайте на работу
энтузиастов — и дело в шляпе” (см. историю “Меньше да лучше” в главе 4).
Конечно, вмешательство микрокасания имеет свои пределы. Иногда прави-
льный шаг состоит не в том, чтобы продолжать микрокасания, а в том, чтобы за-
менить всю структуру проекта новой структурой. Однажды команде из 30
человек, размещенной в одном месте, удалось поставить программный продукт,
на котором провалилась многонациональная команда из 300 человек.
Это, конечно, искусство — определить, когда проект нужно перестраивать
заново, а когда результата можно добиться микрокасаниями. Интересно, как бы
на этот счет выразился Мусаши?
Приложение С_____________________________________________
Книги и ссылки
Книги, упорядоченные по названиям
л
Adaptive Software Development, Highsmith, J., Dorset House, New York, NY,
2000.
A Discipline for Software Engineering, Humphrey, W., Addison-Wesley, Reading,
MA, 1995.
Agile Competitors and Virtual Organizations, Goldman, S., Nagle, R., Preiss, K-,
John Wiley & Sons, New York, NY, 1995.
Applying UML and Patterns: An Introduction to Object-Oriented Analysis and
Design and the Unified Process, 2nd Ed., Larman, C., Prentice-Hall, Upper
Saddle River, NJ, 2002. (Ларман Крэг. Применение UML и шаблонов проек-
тирования. — М., Вильямс, 2002.)
В
Be Quick — But Don’t Hurry!, Hill, A., Wooden, J., Simon and Schuster, New
York, NY, 2001.
Birth of the Chaordic Age, Hock, D., Berret-Koehler, San Francisco, CA 1999.
c
Cleanroom Software Engineering Practices, Becker, S., Whittaker, J., Idea Group
Publishing, Hershey, PA, 1996.
Common Knowledge: How Companies Thrive by Sharing What They Know, Di-
xon, N., Harvard Business School Press, Boston, MA, 2000.
304
Приложение С
Constantine on Peopleware, Constantine, L., Yourdon Press, Englewood Cliffs, NJ,
1995.
Crystal Clear: A Human-Powered Methodology for Small Teams, Cockburn,
A., Addison-Wesley, Reading, MA, готовится к печати, предварительный
вариант доступен: online по http://members.aol.com/humansandt/crys-
tal/clear.
Death March: The Complete Software Developer's Guide to Surviving 'Mission
Impossible' Projects, Yourdon, E., Prentice-Hall, Upper Saddle River, NJ,
1997. (Йордон Эд. Путь камикадзе. — М., ЛОРИ, 2001.)
Deduction, Johnson-Laird, Р., Byrne, R., Lawrence Erlbaum Associates, Mahwah,
NJ, 1991.
Design Patterns, Gamma, E., Helm, R., Johnson, R., Vlissides, J., Addison-Wesley,
Reading, MA, 1995. (Гамма Э., Хелм P., Джонсон P., Влиссидес Дж. Приемы
объектно-ориентированного проектирования. Паттерны проектирования. —
СПб., Питер, 2001.)
Designing Object-Oriented Software, Wirfs-Brock, R., Wilkerson, B., Wiener, L.,
Prentice-Hall, Upper Saddle River, NJ, 1990.
Developing Object-Oriented Software: An Experience-Based Approach, IBM
Object-Oriented Technology Center, Prentice-Hall, Upper Saddle River, NJ,
1997.
DSDM Dynamic Systems Development Method: The Method in Practice, Staple-
ton, J., Addison-Wesley, Reading, MA, 1997.
Dynamics of Software Development, McCarthy, J., Microsoft Press, Redmond,
WA, 1995.
E
Extreme Programming Applied: Playing to Win, Auer, K., Miller, R., Addi-
son-Wesley, Boston, MA, 2002.
Extreme Programming Explained: Embrace Change, Beck, K-, Addison-Wesley,
Boston, MA, 2000. (Бек Кент. Экстремальное программирование. — СПб.,
Питер, 2002.)
Extreme Programming in Practice, Newkirk, J., Martin, R., Addison-Wesley, Bos-
ton, MA, 2001.
Extreme Programming Installed, Jeffries, R., Hendrickson, C., Anderson, A., Addi-
son-Wesley, Boston, MA, 2001.
Книги и ссылки
305
F
Flow: The Psychology of Optimal Experience, Csikszentmihalyi, M., HarperCol-
lins, New York, NY, 1991.
G
GUIs with Glue, Hohmann, L., Addison-Wesley, Boston, MA, готовится к печати.
I
If Only We Knew What We Know: The Transfer of Internal Knowledge and Best
Practice, O’Dell, C., Grayson, C.J. Jr., The Free Press, New York, NY, 1998.
Improving Software Organizations, Mathiassen, L., Pries-Heje, J., Ngwenyama,
O., Addison-Wesley, Boston, MA, 2001.
Inevitable Illusions: How Mistakes of Reason Rule Our Minds, Piattelli-Palmarini,
M., John Wiley and Sons, New York, NY, 1996.
Introduction to the Personal Software Process, Humphrey, W., Addison-Wesley,
Reading, MA, 1997.
Java Modeling in Color with UML, Coad, P., Prentice-Hall, Upper Saddle River,
NJ, 1999.
Journey of the Software Professional, Hohmann, L., Prentice-Hall, Upper Saddle
River, NJ, 1997.
Just for Fun: The Story of an Accidental Revolution, Torvalds, L., Diamond, D.,
Harperbusiness, New York, NY, 2001.
M
Making Sense of the Organization, Weick, K-, Blackwell Business, Oxford, 2001.
Managing the Flow of Technology, Allen, T., MIT Press, Boston, MA, 1984.
Mathematical Theory of Communication, Shannon, C., Weaver, W., U. of Illinois
Press, Champaign, IL, 1963.
О
Object-Oriented Analysis & Design with Applications, Booch, G., Benja-
min-Cummings, San Francisco, CA, 1994. (Буч Г. Объектно-ориентирован-
ный анализ и проектирование с примерами приложений на C++. — М.,
Бином, СПб., Невский диалект, 1999.)
306
Приложение С
Object-Oriented Methods, Pragmatic Considerations, Martin, J., Odell, J., Prenti-
ce-Hall, Upper Saddle River, NJ, 1998.
Object Solutions: Managing the Object-Oriented Project, Booch, G., Addi-
son-Wesley, Reading, MA, 1996.
On Numbers and Games, Conway, J., Academic Press, London, 2000.
P
Peopleware: Productive Projects and Teams, 2nd Ed., DeMarco, T., Lister, T., Do-
rset House, New York, NY, 1999.
Planning Extreme Programming, Beck, K., Fowler, M., Addison-Wesley, Boston,
MA, 2001.
Project Retrospectives: A Handbook for Team Reviews, Kerth, N., Dorset House,
New York, NY, 2001.
Punished by Rewards: The Trouble with Gold Stars, Incentive Plans, A’s, Praise,
and Other Bribes, Kohn, A., Houghton Mifflin, Boston, MA, 1999, см. также:
http: / / www. gnu, org/philosophy/ motivation, html.
R
Reengineering the Corporation: A Manifesto for Business Revolution, Hammer,
M., Champy, J., Harperbusiness, New York, NY, 1994.
s
Scrum: Agile Software Development, Schwaber, К.» Beedle, M., Prentice-Hall,
Upper Saddle River, NJ, 2002 (см. также: http://www.controlchaos.com).
Situated Learning: Legitimate Peripheral Participation, Lave, J., Wenger, E.,
Cambridge University Press, Cambridge, 1991.
Sketches of Thought, Goel, V., MIT Press, Boston, MA, 1995.
Skunk Works: A Personal Memoir of My Years at Lockheed, Rich, B., Janos, L.,
Little, Brown and Company, Boston, MA, 1994.
Software Creativity, Glass, R., Prentice-Hall, Upper Saddle River, NJ, 1995.
Software for Use, Constantine, L., Lockwood, L., Addison-Wesley, Reading, MA,
1999.
Surviving Object-Oriented Project, Cockburn, A., Addison-Wesley, Reading, MA,
1998.
Книги и ссылки
307
The Art of Computer Programming, Vol. 1-3, Knuth, D., Addison-Wesley, Rea-
ding, MA, 1997, 1998.
The Art of Systems Architecting, 2nd Edition, Maier, M., Rechtin, E., CRC Press,
Boca Raton, FL, 2000.
The Book of Five Rings, Musashi, M., Cleary, T. (перевод), Shambhala Publicati-
ons, Boston, MA, 2000 (см. также: http://www.samurai.com/5rings/).
The Goal, Goldratt, E., North River Press, Great Barrington, MA, 1992.
The Mythical Man-Month: Essays on Software Engineering, Brooks, F., Addi-
son-Wesley, Reading, MA, 1995. (Брукс Ф. Мифический человеко-месяц,
или как создаются программные системы. — СПб., Символ-Плюс, 1999.)
The OPEN Process Specification, Graham, I., Henderson-Sellers, B., Younessi, H.,
Addison-Wesley, Reading, MA, 1997.
The Pragmatic Programmer: From Journeyman to Master, Hunt, A., Thomas, D.,
Addison-Wesley, Reading, MA, 2000.
The Psychology of Computer Programming, Weinberg, G., Silver Edition, Dorset
House, New York, NY, 1998.
The Rational Unified Process, Kruchten, P., Addison-Wesley, Reading, MA, 1999.
(Крачтен Ф. Введение в Rational Unified Process? — M., Вильямс, 2002.)
The Science of Programming, Gries, D., Springer-Verlag, New York, NY, 1987.
The Sciences of the Artificial, Simon, H., MIT Press, Boston, MA, 1987.
The Selfish Gene, Dawkins, R., Oxford University Press, Oxford, 1990.
The Tree of Knowledge: The Biological Roots of Human Understanding, Matura-
na, H., Varela, F., Shambhala Publications, Boston, MA, 1998.
Theory of Constraints, Goldratt, E., North River Press, Great Barrington, MA, 1990.
u
Using CRC Cards: An Informal Approach to Object-Oriented Development, Wil-
kinson, N., SIGS Books and Multimedia, New York, NY, 1995.
w
Work-Oriented Development of Software Artifacts, Ehn, P., Arbetslivscentrum,
Stockholm, 1988.
Writing Effective Use Cases, Cockburn, A., Addison-Wesley, Reading, MA, 2001.
(Коберн А. Современные методы описания функциональных требований к
системам. — М., ЛОРИ, 2002.)
308
Приложение С
Ссылки, упорядоченные по фамилиям
авторов
А
Allen, Т., Managing the Flow of Technology, MIT Press, Boston, MA, 1984.
Auer, K., Miller, R., Extreme Programming Applied: Playing to Win, Addi-
son-Wesley, Boston, MA, 2002.
В
Bach, J., www.satisfice.com
Beck, K., Cunningham, W., “A Laboratory for Teaching Object-Oriented Thin-
king” , ACM S1GLPLAN 24(10): 1-7, 1989.
Beck, K., Extreme Programming Explained: Embrace Change, Addison-Wesley,
Boston, MA, 2000.
♦
Beck, K., Fowler, M., Planning Extreme Programming, Addison-Wesley, Boston,
MA, 2001.
Becker, S., Whittaker, J., Cleanroom Software Engineering Practices, Idea Group
Publishing, Hershey, PA, 1996.
Booch, G., Object-Oriented Analysis & Design with Applications, Benja-
min-Cummings, San Francisco, CA, 1994.
Booch, G., Object Solutions: Managing the Object-Oriented Project, Addi-
son-Wesley, Reading, MA, 1996.
Bordia, P., Prashant, K., “Face-to-Face versus Computer-Mediated Communicati-
ons: A Synthesis of the Literature”, The Journal- of Business Communications
34(1), U. of Illinois, Champaign, IL, Jan. 1997, pp. 99-120.
Brooks, F., The Mythical Man-Month: Essays on Software Engineering, Addi-
son-Wesley, Reading, MA, 1995.
Brown, K., Klastorin, T. & Valluzzi, J., “Project Performance and the Liability of
Group Harmony”, IEEE Transactions on Engineering Management, 37(2),
May 1990, pp. 117-125.
Burns, C., Dishman, E., Verplank, W., Lassiter, B., “Actors, Hairdos & Videota-
pe — Informance Design: Using Performance Techniques in Multi-Disciplina-
ry, Observation-Based Design”, Computer Human Interaction ‘94 Conference
Companion, Boston, MA, April 24-28, pp. 119-120.
Книги и ссылки
309
С
The “СЗ" Team, ’’Chrysler Goes to ‘Extremes’", в Distributed Object Computing,
October, 1998, pp. 24-28.
Coad, P., Java Modeling in Color with UML, Prentice-Hall, Upper Saddle River,
NJ, 1999.
Cockburn, A., Surviving Object-Oriented Project, Addison-Wesley, Reading, MA,
1998.
Cockburn, A., “The Expert-in-Earshot Project Management Pattern”, в Succi, G.,
Marchesi, M., Extreme Programming Examined, Addison-Wesley, Reading,
MA, 2001, pp. 245-247. (2001a)
Cockburn, A., Williams, L., “The Costs and Benefits of Pair Programming”, в Succi,
G., Marchesi, M., Extreme Programming Examined, Addison-Wesley, Rea-
ding, MA, 2001, pp. 223-247. (2001b)
Cockburn, A., Writing Effective Use Cases, Addison-Wesley, Reading, MA, 2001.
(2001c)
Cockburn, A., Crystal Clear: A Human-Powered Methodology for Small Teams,
Addison-Wesley, Reading, MA, готовится к печати, набросок доступен: online
по http://members.aol.com/humansandt/crystal/clear.
Constantine, L., Constantine on Peopleware, Yourdon Press, Englewood Cliffs, NJ,
1995.
Constantine, L., Lockwood, L., Software for Use, Addison-Wesley, Reading, MA,
1999.
Conway, J., On Numbers and Games, Academic Press, London, 2000.
Csikszentmihalyi, M., Flow: The Psychology of Optimal Experience, HarperCol-
lins, New York, NY, 1991.
Curtis, P., Dixon, M., Frederick, R., Nichols, D., “The Jupiter Audi/Video Architec-
ture: Secure Multimedia in Network Places”, в Proceedings of ACM Multime-
dia ‘95, San Francisco, CA, pp. 79-90.
D
Dawkins, R., The Selfish Gene, Oxford University Press, Oxford, 1990.
DeMarco, T., Lister, T., Peopleware: Productive Projects and Teams, 2nd Ed.,
Dorset House, New York, NY, 1999.
Dixon, N., Common Knowledge: How Companies Thrive by Sharing What They
Know, Harvard Business School Press, Boston, MA, 2000.
310
Приложение С
Е
Ehn, Р., Work-Oriented Development of Software Artifacts, Arbetslivscentrum,
Stockholm, 1988.
Ehn, P., “Scandinavian Design: On Participation and Skill”, в Usability: Turning
Technologies into Tools, P. S. Adler and T. A. Winograd, editors, Oxford Uni-
versity Press, New York, NY, 1992, pp. 96-132, online по адресу:
http://www.ilt.columbia.edu/Publications/papers/Ehn.html.
F
Fox, R., “Shu Ha Ri”, The laido Newsletter, 7(2), #54, Feb 1995, online по адресу:
http://www.aikidofaq.com/essays/tin/shuhari.html.
Frakes, W., Fox, C., “Sixteen Questions about Software Reuse”, Communications
of the ACM, 38(6):75-87, 1995.
G
Gamma, E., Helm, R., Johnson, R., Vlissides, J., Design Patterns, Addison-Wesley,
Reading, MA, 1995.
Glass, R., Vessey, I., Conger, S., “Software Tasks: Intellectual or Clerical?” в Infor-
mation and Management, 23(4), Oct., 1992, pp. 183-191.
Glass, R., Software Creativity, Prentice-Hall, Upper Saddle River, NJ, 1995.
Goel, V., Sketches of Thought, MIT Press, Boston, MA, 1995.
Goldman, S., Nagle, R., Preiss, K., Agile Competitors and Virtual Organizations,
John Wiley & Sons, New York, NY, 1995.
Goldratt, E., Theory of Constraints, North River Press, Great Barrington, MA, 1990.
Goldratt, E., The Goal, North River Press, Great Barrington, MA, 1992.
Graham, I., Henderson-Sellers, B., Younessi, H., The OPEN Process Specification,
Addison-Wesley, Reading, MA, 1997.
Gries, D., The Science of Programming, Springer-Verlag, New York, NY, 1987.
Guindon, R., Curtis, B., “Insights from Empirical Studies of the Software Design
Process”, Future Generations Computer Systems, 7(2-3), April, 1992,
pp. 139-149.
H
Hammer, M., Champy, J., Reengineering the Corporation: A Manifesto for Busi-
ness Revolution, Harperbusiness, New York, NY, 1994.
Книги и ссылки
311
Herring, R., Rees, М., “Internet-Based Collaborative Software Development Using
Microsoft Tools”, в Proceedings of the 5th World Multiconference on Syste-
mics, Cybernetics and Informatics (SCI’2001). 22-25 July, 2001. Orlando,
Florida. Online по адресу: http:/ / erwin.dstc.edu.au/Herring/SoftwareEngi-
neeringOverlnternet-SCI2001 .pdf.
Highsmith, J., Adaptive Software Development, Dorset House, New York, NY,
2000.
Hill, A., Wooden, J., Be Quick — But Don’t Hurry!, Simon and Schuster, New
York, NY, 2001.
Hock, D., Birth of the Chaordic Age, Berret-Koehler, San Francisco, CA 1999.
Hohmann, L., Journey of the Software Professional, Prentice-Hall, Upper Saddle
River, NJ, 1997.
Hohmann, L., GUIs with Glue, Addison-Wesley, готовится к печати.
Hovenden, F., “A Meeting and A Whiteboard (Describing the Power to Speak)”, в
Proceedings of the 4th World Multiconference on Systemics, Cybernetics and
Informatics (SCI’2001). July, 2000. Orlando, Florida.
Humphrey, W., A Discipline for Software Engineering, Addison-Wesley, Reading,
MA, 1995.
Humphrey, W., Introduction to the Personal Software Process, Addison-Wesley,
Reading, MA, 1997.
Hunt, A., Thomas, D., The Pragmatic Programmer: From Journeyman to Master,
Addison-Wesley, Reading, MA, 2000.
I
IBM Object-Oriented Technology Center, Developing Object-Oriented Software:
An Experience-Based Approach, Prentice-Hall, Upper Saddle River, NJ, 1997.
J
Jeffries, R., Hendrickson, C., Anderson, A., Extreme Programming Installed, Addi-
son-Wesley, Boston, MA, 2001.
Johnson-Laird, P., Byrne, R., Deduction, Lawrence Erlbaum Associates, Mahwah,
NJ, 1991.
К
Kerth, N., Project Retrospectives: A Handbook for Team Reviews, Dorset House,
New York, NY, 2001.
312
Приложение С
Knuth, D., The Art of Computer Programming, Vol. 1-3, Addison-Wesley, Rea-
ding, MA, 1997, 1998.
Kohn, A., Punished by Rewards: The Trouble with Gold Stars, Incentive Plans,
A’s, Praise, and Other Bribes, Houghton Mifflin, Boston, MA, 1999, см. также
http://www.gnu.org/philosophy/motivation.html.
Kruchten, P., The Rational Unified Process, Addison-Wesley, Reading, MA, 1999.
Larman, C., Applying UML and Patterns: An Introduction to Object-Oriented
Analysis and Design and the Unified Process, 2nd Ed., Prentice-Hall, Upper
Saddle River, NJ, 2002.
Laubacher, R., Malone, T., “Retreat of the Firm and Rise of the Guilds: The Employ-
ment Relationship in an Age of Virtual Business”, MIT Sloan School of Mana-
gement 21st Century Initiative Working Paper #33, Aug.‘2000.
Lave, J., Wenger, E., Situated Learning: Legitimate Peripheral Participation,
Cambridge University Press, Cambridge, 1991.
Maier, M., Rechtin, E., The Art of Systems Architecting, 2nd Edition, CRC Press,
Boca Raton, FL, 2000.
Martin, J., Odell, J., Object-Oriented Methods, Pragmatic Considerations, Prenti-
ce-Hall, Upper Saddle River, NJ, 1998.
Mathiassen, L., Stage, J., “Informatics as a Multi-Disciplinary Education”, в Scan-
dinavian Journal of Information Systems, Vol. 11, No. 1, 1999.
Mathiassen, L., Pries-Heje, J., Ngwenyama, O., Improving Software Organiza-
tions, Addison-Wesley, Boston, MA, 2001.
Maturana, H., Varela, F., The Tree of Knowledge: The Biological Roots of Human
Understanding, Shambhala Publications, Boston, MA, 1998.
McCarthy, J., Monk, A., “Channels, Conversation, Cooperation and Relevance: All
You Wanted to Know about Communication but Were Afraid to Ask”, в Colla-
borative Computing, Vol. 1, No. 1, March 1994, pp. 35-61.
McCarthy, J., Dynamics of Software Development, Microsoft Press, Redmond,
WA, 1995.
Musashi, M., Cleary, T. (перевод), The Book of Five Rings, Shambhala Publicati-
ons, Boston, MA, 2000 (см. также: http:/'/www.samurai.com/brings/).
Книги и ссылки
313
NASA, “Deorbit Flight Software Lessons Learned”, JSC38609, NASA Johnson
Space Center, Jan. 19, 1998.
Naur, P., “Programming as Theory Building”, pp. 37-48 в Computing: A Human
Activity, ACM Press, 1992.
Newkirk, J., Martin, R., Extreme Programming in Practice, Addison-Wesley, Bos-
ton, MA, 2001.
О
O’Dell, C., Grayson, C.J. Jr., If Only We Knew What We Know: The Transfer of In-
ternal Knowledge and Best Practice, The Free Press, New York, NY, 1998.
P
Piattelli-Palmarini, M., Inevitable Illusions: How Mistakes of Reason Rule Our
Minds, John Wiley and Sons, New York, NY, 1996.
R
Raymond, E., “Homesteading the Noosphere”, http:/ftuxedo.org!~esr/wri-
tings/cathedral-bazaar/homesteading/.
Rich, B., Janos, L., Skunk Works: A Personal Memoir of My Years at Lockheed,
Little, Brown and Company, Boston, MA, 1994.
s
Shannon, C., Weaver, W., Mathematical Theory of Communication, U. of Illinois
Press, Champaign, IL, 1963.
Shrage, M., “The Proto Project”, в Fast Company, May, 1999, p. 138, online по ад-
ресу: http://www.fastcompany.com/online/24/schrage.html.
Schwaber, K., Beedle, M., Scrum: Agile Software Development, Prentice-Hall,
Upper Saddle River, NJ, 2002 (см. также: http://www.controlchaos.com).
Sillince, J.A., “A Model of Social, Emotional and Symbolic Aspects of Compu-
ter-Mediated Communication within Organizations”, в Computer Supported
Cooperative Work, Vol. 4, 1996, pp. 1-31.
Simon, H., The Sciences of the Artificial, MIT Press, Boston, MA, 1987.
Stapleton, J., DSDM Dynamic Systems Development Method: The Method in
Practice, Addison-Wesley, Reading, MA, 1997.
314
Приложение С
Sullivan, К., Chalasani, Р., Jha, S., Sazawal, V., “Software Design as an Investment
Activity: A Real Options Perspective”, в Real Options and Business Strategy:
Applications to Decision Making, L. Trigeorgis (Ed.), Risk Books, December,
1999.
Sully, P., “Liveware Matters”, ЦХЕ Magazine, 3(1), June, 1988, pp. 42-46.
Torvalds, L., Diamond, D., Just for Fun: The Story of an Accidental Revolution,
Harperbusiness, New York, NY, 2001.
Webb, D., Humphrey, W., “Using TSP on the TaskView Project”, в CrossTalk, The
Journal of Defense Software Engineering, Feb. 1999, pp. 3-10. Online по ад-
ресу: http://www.stsc.hill.af.inil/crosstalk/1999/feb/webb.asp. 7
Weick, K., Making Sense of the Organization, Blackwell Business, Oxford, 2001.
Weinberg, G., The Psychology of Computer Programming, Silver Edition, Dorset
House, New York, NY, 1998.
Wilkinson, N., Using CRC Cards: An Informal Approach to Object-Oriented Deve-
lopment, SIGS Book and Multimedia, New York, NY, 1995.
Wirfs-Brock, R., Wilkerson, B., Wiener, L., Designing Object-Oriented Software,
Prentice-Hall, Upper Saddle River, NJ, 1990.
X
Extreme Programming, http://extremeprogramming.com.
Y
Yourdon, E., Death March: The Complete Software Developer’s Guide to Survi-
ving ‘Mission Impossible’ Projects, Prentice-Hall, Upper Saddle River, NJ,
1997.