Текст книги "Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения"

Автор книги: Алистэр Коуберн

сообщить о нарушении

Текущая страница: 2 (всего у книги 3 страниц)

Человек – существо общительное

Основным фактором в разработке программного обеспечения является возможность коммуникации. На рисунке 1 изображена некая кривая, с помощью которой я иллюстрирую свои методологические рассуждения. На этом рисунке видно, как падает эффективность коммуникации, если исчезает ее модальность и синхронизация. Этой теме посвящено несколько исследований (см. [Pl] и [Si]), кроме того, эту же зависимость подтверждает и Вайнберг, который описывал проекты около 30 лет назад [Wei].

Самым эффективным видом коммуникации является непосредственное, личное общение (например, когда вы обсуждаете что-либо и рисуете при этом на доске). Если мы будем убирать одно за другим все свойства общения, присущие двум людям, рисующим у доски, мы увидим, как падает эффективность коммуникации. Убирать мы будем следующие свойства:

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

Разнообразные модальности. Человек общается не только словами, но и при помощи жестов. Часто человек может высказать свое суждение жестикуляцией, например, поднимая бровь или указывая на что-то пальцем.

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

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

 
Рисунок 1. Виды коммуникации
Итак, что же произойдет, если мы начнем убирать одно за другим все эти свойства?
 

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

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

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

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

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

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

"Убедитесь, что во всем здании хватает досок для рисования и уголков, где можно попить кофе". Такие компании, как Hewlett-Packard и IBM давно поняли всю эффективность неформального общения, и сейчас в нашей индустрии стало обычным положение, что наиболее эффективное окружение для проектирования разработки ПО можно создать специально поощряя и разрешая собрания небольших групп разработчиков. Вайнберг зафиксировал особые случаи, когда неформальные беседы разработчиков оказывали значительный эффект на общую результативность работы всей группы [Wei]. Нередко удачные решения приходят, когда люди "просто беседуют".

Сейчас существует три сравнительно новых методологии, где одно из основных положений – размещение всех разработчиков в одной комнате или просто в непосредственной близости друг от друга. Это Adaptive Software Engineering [Hi], Extreme Programming [B99], [EP], и Crystal(Clear) [Co00]).

Модель коммуникации, которую мы рассмотрели выше, позволяет, кроме всего прочего, давать рекомендации по архивированию документации:

Пусть человек, занимавшийся проектированием, коротко (5-20 минут) расскажет нескольким коллегам, не знакомым с его разработками, о том, что он сделал. Эти люди выступят в роли тех зрителей, которые будут смотреть будущую запись на видеокассете. Пусть они просто обсуждают предложенный вариант проектирования и задают вопросы по мере необходимости. Обсуждение записывайте на видео. В конце воспроизведите те рисунки и примеры, вокруг которых велась дискуссия, или же приложите к видеозаписи те рисунки, которые использовались при проектировании. Они будут служить мнемонической связкой между самим обсуждением и его предметом.

Я очень обрадовался, когда Лизетт Веласкес (Lizette Velasquez) из "Lucent Technologies" рассказала мне, что она не только с успехом использует эту технику в работе, но что я забыл упомянуть еще один немаловажный момент: очень важно особо отмечать те места обсуждения, когда "происходило нечто интересное". Обычно обсуждение протекает довольно спокойно, но случаются моменты, когда какой-то вопрос вызывает целый поток дополнительных вопросов и комментариев. В таком случае, зрители наверняка захотят вернуться и просмотреть это место еще раз.

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

А тем, кто до сих пор предпочитает книги всем прочим средствам передачи информации, предложу сделать следующее: возьмите, к примеру, замечательную, но очень трудную книгу Design Patterns. Теперь представьте, что вместо того, чтобы разбирать значение паттерна "Decorator" с книжной страницы, у вас есть возможность щелкнуть мышкой и увидеть видеоклип, в котором авторы сами объясняют этот паттерн. Конечно же, в этом случае для передачи своих идей они будут использовать интонацию, жестикуляцию и синхронизацию общения.

Какой же вывод нужно сделать относительно этого свойства человеческой природы? Мы должны стараться поднять коммуникацию в команде разработчиков на максимально высокую точку нашей кривой – настолько, насколько это позволяют обстоятельства.

Люди непостоянны

Когда речь идет о людях, говорить о режимах сбоя нужно осторожно. У англичан есть старинная пословица: «Если ты дашь собаке плохое имя, то лучше ее сразу пристрелить». В самом деле, как вы увидите из приведенных ниже примеров, простые изменения в стиле управления и местной культуре могут привести к огромным изменениям видимого поведения людей. И все же, весь мой опыт говорит о том, что ожидать от людей последовательности и постоянства действий практически невозможно. Как пишет Джим Хайсмит (Jim Highsmith) [Hi]:

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

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

"Как же мне справиться со всеми этими бумагами, которые приходят в мой офис?" – спрашивает один. Другой отвечает: "Ну, это совсем не сложно! Просто следи, чтобы твой стол всегда был пустым – четыре корзины по углам, несколько папок в верхнем ящике…". Он не смог закончить. "Чтобы стол был пустым?!" – закричали все. "Но ведь это невозможно!"

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

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

Как саркастически заметил Карл Вигерт (Karl Wiegert): "We are not short on practices , we are short on practice " ("нам не хватает практики, а не правил"). И таких правил, действительно, немало. Дэвид Гриз (David Gries) в своей книге "The Science of Programming" ("Наука программирования") дает подробные инструкции по тому, как нужно создавать правильные программы [Gr]. Хорошее средство проектирования представляют собой CRC-карточки [B87]. В методологии под названием "Extreme Programming" [EP], известной своим парным программированием и автоматическим тестированием [Je], тоже используются хорошо известные эффективные методики. Подробно описаны все составляющие методологии "Cleanroom" [Mi]. Уотс Хамфри (Watts Humphrey) дает подробные инструкции программистам, которые хотят работать более эффективно с помощью "Personal Software Process" (PSP) [Hu]. Последовательное и постоянное применение любой из этих методологий замечательно улучшило бы любой проект из тех, которые я видел.

Проблема в одном – в словах "постоянный" и "последовательный". Если PSP и Extreme Programming применять лишь время от времени, то они теряют свой смысл. Написанный наполовину код не может быть безошибочным. Точно так же, как и в случае с лишними бумагами на столе, методологию нужно применять полностью, последовательно, изо дня в день.

Непоследовательность – обычная причина режима сбоя у человека. Существуют методологии, которые требуют от своих адептов строгой последовательности действий. Такие методологии я называю "высоко дисциплинированными". Как показывают опросы, проводимые в различных проектах, именно такие методологии наиболее уязвимы, однако в некоторых проектах они используются довольно успешно. Вот пример применения методологии PSP в организации с пятым уровнем CMM. Мне он кажется весьма поучительным: [Web]:

Летом 1996 года небольшую группу программистов ознакомили с методологией PSP. Несмотря на то, что все были настроены относительно обучения весьма положительно, сразу после его окончания новая методология стала использоваться все меньше и меньше. Вскоре никто из тех, кто специально обучился этой методологии, не использовал ее в работе. Когда этих людей спросили, почему они не используют PSP, ответ был практически один и тот же: "PSP – очень строгая методология, поэтому если никто не требует от меня отчета, мне проще работать по-старому".

Чтобы такого не случилось, в методологиях, требующих высокой дисциплины, должны существовать некие регулирующие элементы, которые заставляли бы людей быть более последовательными. В методологии "Cleanroom" есть правило, запрещающее компиляцию, которое подкреплено определенным способом управления. Для Extreme Programming необходим "наставник" ("coach"), который следит за соблюдением всех предписаний этой методологии. В PSP такие функции не были предусмотрены, поэтому неудивительно, что группа разработчиков из нашего примера перестала ей пользоваться – у этой методологии просто не было никакой структуры поддержки. Предполагается, что эти факторы будут предусмотрены в TSP [Web].

Однако, несмотря на все это, существуют люди, которые могут на протяжении длительного времени делать свою работу последовательно и дисциплинированно (это лишний раз показывает, насколько все мы отличаемся друг от друга). Иногда для того, чтобы повлиять на дисциплинированность группы достаточно поменять ее руководителя. Спасибо Трюгве Реенскаугу (Trygve Reenskaug) за историю, которая прекрасно показывает, как стиль управления влияет на личные качества:

Недалеко отсюда был маленький галантерейный магазинчик, жуткое место. Товар в беспорядке, продавщицы полируют ногти или болтают по телефону, на покупателей никто не обращает внимания. Вскоре он закрылся, и на том же месте открылся другой магазин. О, тут дела пошли по-другому! Этот магазин был чистый, аккуратный, продавщицы всегда предупредительны… Только вот странное дело – продавщицы ведь были те же самые!

На самом деле хорошо известно, что личный стиль руководителя имеет огромное значение. Году в 1997 те, кто работал над проектом Chrysler Comprehensive Compensation [C3] узнали это на собственном опыте. Сначала основными принципами разработки были "думать наперед", "нечеткое, но растяжимое планирование" и "программный код – личное дело разработчика". Затем вся команда перестроилась (главной движущей силой этих перемен был Кент Бек (Kent Beck)), и основными принципами стали "делайте все простым и понятным, потом можно внести необходимые дополнения", "весь код должен быть общедоступным, и любая пара программистов может вносить в него любые изменения". Таким образом, одни и те же люди смогли принять совершенно новые для себя принципы работы и пройти путь от полного беспорядка, отсутствия коммуникации и невыполнения обязательств по поставкам к последовательному применению новой высокодисциплинированной методики и регулярному выполнению обязательств в течение трех лет работы.

Чувство гражданского долга и способность ориентироваться в ситуации

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

как правило, человек имеет чувство гражданского долга,

человек предпочитает брать инициативу в свои руки,

человек хорошо ориентируется в окружающей обстановке. Когда я провожу опрос по какому-нибудь проекту, я всегда спрашиваю людей, что, по их мнению, привело к конечному успеху работы. Чаще всего я получаю один и тот же ответ: "В ключевой момент разработки несколько человек взяли на себя инициативу и сделали все от них зависящее, чтобы выполнить проект". Вот один из таких типичных ответов, который опубликован NASA в работе "Deorbit flight software lessons learned" ("Уроки, полученные в результате работ над программным обеспечением для увода космических кораблей с орбиты") [NASA]:

Возможно, наиболее важным (в долгосрочном плане) фактом являлось то, что в процессе работы над проектом образовалась сплоченная команда разработчиков, способная осуществлять быструю разработку систем GN amp;C. Формирование команды складывалось из поиска новых талантливых людей, их обучения, накопления опыта работы с инструментарием, процессом и методологией, и последующей интеграцией в единый спаянный коллектив.

Поработав вместе над проектом целый год, вся команда приобрела хорошие знания в предметной области, а также в методах и средствах разработки. Создание атмосферы дружбы и взаимопомощи среди разработчиков способствовало их взаимному обучению и всячески поощряло его. Готовность членов команды заниматься любым и всеми аспектами проекта многократно оказывалась бесценным подспорьем в работе… (курсив мой, А.К.)

…такая команда будет необходима в дальнейшем и данному отделу, и всему агентству".

Что заставило людей вести себя таким образом? Одна из возможных причин – чувство гражданского долга.

Может быть, наши проекты чаще заканчивались бы успехом, если бы мы просто старались усилить "чувства общности интересов и гражданского долга" в команде разработчиков. Впрочем, я не хочу сказать, что это основная моя рекомендация, потому что в среднем эти чувства и так хорошо развиты, и плохие руководители не упускают случая, чтобы этим воспользоваться (см, к примеру, "Death March" [Yo]).

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

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

"Хорошо ориентироваться в текущей ситуации" – фраза довольно неопределенная, но имеющая далеко идущие последствия. Люди, которые занимаются сортировкой документов, часто просто раскладывают все бумаги на маленькие кучки (используя при этом сортировку методом Шелла). Самое удивительное заключается в том, что нередко они не разбирают эти кучки дальше, на отдельные документы. Часто приблизительного знания вполне достаточно, ведь в случае необходимости они всегда могут пролистать ту или другую кучку и найти требуемое (будущие исследования покажут нам, какие мнемонические техники для этого используются).

Вот пример уже из области разработки ПО. Мы пытаемся сделать документацию по проекту качественной, обновляем устаревшие версии. Однако, зная, что непостоянство – один из наиболее обычных "режимов сбоя" у человека, можно смело предсказать, что документация все равно не будет обновляться достаточно часто. Что касается меня, то я еще не видел ни одного успешно завершившегося проекта, у которого была бы в порядке документация (за исключением тех случаев, когда код или документация создавались автоматически). Зато видел проект, который потерпел крах именно потому, что разработчикам велели обновлять всю документацию после каждого внесенного изменения. Стоимость разработки при этом настолько выросла, а производительность так упала, что проект пришлось вскоре закрыть.

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

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

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

Трюгве Реенскауг рассказал мне как-то еще одну историю. Однажды он предложил систему автоматического проектирования инженеру, который занимался разработкой морских нефтедобывающих платформ. Трюгве предложил, чтобы система автоматически отслеживала все виды работ, которые проводились на любой части платформы, и указывала их показатели. Однако в ответ услышал: "Достаточно будет, чтобы в системе хранились только номера телефонов. Я сам позвоню и узнаю, что было сделано".

В методологии я обозначаю это термином "невысокая точность" (low precision) [Co98]. Я прихожу к заключению, что большинство проектов вполне можно вести, руководствуясь (верными) не очень точными описаниями: не очень точную документацию по проекту легче читать, приводить в порядок и обсуждать. Архитектуру системы, изображенную с невысокой степенью точности, легче запомнить; в таблицах с не очень точно описанными требованиями легче расставлять приоритеты и легче оценивать масштабы сделанной работы на ранних стадиях проекта. Выполненная не очень точно проектная документация лучше передает "идею" проекта, после чего читатель может начать "ориентироваться в ситуации".

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