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

      "Как же мне справиться со всеми этими бумагами, которые приходят в мой офис?" - спрашивает один. Другой отвечает: "Ну, это совсем не сложно! Просто следи, чтобы твой стол всегда был пустым - четыре корзины по углам, несколько папок в верхнем ящике…". Он не смог закончить. "Чтобы стол был пустым?!" - закричали все. "Но ведь это невозможно!"
      Обратите внимание, что советчик предложил им одновременно изменить свои привычки, а также совершать определенное действие постоянно и единообразно.
      Если бы люди обладали последовательностью и постоянством, они могли бы убирать бумаги с рабочего стола, предотвращать кариес, избавляться от лишнего веса, бросать курить, и может быть, даже разрабатывать программное обеспечение, укладываясь в рабочий график.
      Как саркастически заметил Карл Вигерт (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 года, и могу смело рекомендовать их как главный методологический элемент.

Все люди разные

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

И другие

      Вот еще несколько свойств человеческой натуры, на которые я полагаюсь. Они приводятся здесь кратко, в виде списка:
      Обучение . Человек обучается с помощью наблюдения и практики. Это когнитивный и социальный принцип, хорошо известный в определенных кругах [La], однако до сих пор не использующийся должным образом при разработке программного обеспечения. Я пытаюсь найти возможность применить этот принцип на практике, но пока не придумал для этого подходящей методологической структуры.
      Поток . В контексте программных разработок "поток" означает время, отведенное для спокойного эффективного размышления над задачей [Dm], [Cs], [Co98]. Это время должно быть уравновешено временем, отведенным для коммуникаций. Как установить подобный баланс при напряженном процессе работы над проектом - выше моего понимания. Тем не менее, многие особо подчеркивают, что время, отведенное на спокойное размышление, играет заметную роль в конечном успехе проекта.
      Работа по примерам . Некоторые когнитивные психологи убедительно доказывают, что наш механизм дедукции основан на создании отдельных примеров проблем [J-L]. CRC-карточки и варианты использования (use cases) - два способа разработки программного обеспечения, построенные на примерах. Кстати сказать, те, кто их используют, неоднократно свидетельствуют об их эффективности. Новички часто предпочитают "диаграммы экземпляров" (instance diagrams) правильному объектно-ориентированному проектированию. Впрочем, ими пользуются даже опытные проектировщики. Идея создания документации, основанной на примерах, пока не нашла должного отклика у методологов, и представляет собой тему для дальнейшей работы в этой области.
      Кинетическое и мульти-сенсорное мышление . CRC-карточки, разыгрывание ролей при анализе и проектировании, рисование на доске, создание прототипов интерфейсов на бумаге, все эти виды деятельности подразумевают, что во время размышлений человек говорит и движется. Пока на эту тему нет исследований, я могу лишь сказать, что в программных разработках можно продуктивно использовать все эти техники.
      Личные свойства характера . Вы и сами, наверное, не раз видели крайне нелюдимых главных проектировщиков, которые бросают на произвол судьбы свою команду. И, не смотря ни на что, эти прекрасные программисты продолжают занимать должности, которые требуют от человека большой общительности! Нередко мы можем встретить и руководителей проектов, которые не умеют принимать решения. Однако для конечного успеха проекта очень важно, насколько личные качества человека подходят для занимаемой им должности. Эти качества нужно учитывать и с точки зрения профессионального роста человека, однако нередко такие должности являются единственным способом продвижения по служебной лестнице.
      Поражение из-за консерватизма . Люди предпочитают терпеть поражение, но действовать по-старинке, чем идти на риск ради успеха [Pi]. Это объясняет, почему люди уже столько лет используют в работе метод водопада, несмотря на то, что он уже несколько десятков лет не приносит ничего, кроме проблем, и имеет множество альтернатив в лице спирального, инкрементного и итеративного вида разработок.
      Изменение привычек . Самая трудная вещь на свете из всего, что я знаю - это заставить человека изменить свои привычки. При этом люди меняют привычки почти спонтанно, если изменить их систему ценностей. За 20 лет работы я видел, как это делали (преднамеренно и сознательно) раза два, и скажу, что это впечатляет.
      "Маленькие головы" . Даже от опытных проектировщиков постоянно слышишь: "Я могу удерживать в голове только небольшую долю всей информации". Существует несколько способов ведения документации, которые призваны облегчить подобные задачи, однако ни один из них пока не объединяет в себе использование рабочих артефактов, созданных с "невысокой степенью точности", и активную межличностную коммуникацию.
      Я уверен, что существуют и другие свойства человеческой натуры, которые оказывают сильное влияние на процесс разработки ПО, а также на те рекомендации, которые должны давать мы, методологи. Я описал здесь только те, которые в настоящее время сам использую в работе.

Заключение

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

Библиография

      [B87] Beck, K. and Cunningham, W., "A laboratory for teaching object-oriented thinking", Proceedings of the OOPSLA Conference, 1987, ACM Sigplan Oct., 1987, pp.1-7.
      [B99] Beck, K., Extreme Programming Explained: Embrace Change, Addison Wesley Longman, 1999.
      [Br] Britcher, R., The Limits of Software, Addison Wesley, 1999.
      [Ch] Christensen, M., et al. , "The M.A.D. experience: multiperspective application development in evolutionary prototyping", in the ECOOP'98 proceedings, Lecture Notes in Computer Science, Vol. 1445, Goos, G., Hartmanis, J, van Leeuwen, J., eds., 1998, pp. 13-41.
      [Ci] Citrin, W., Cockburn A., von Kaenel, J., Hauser, R., "Using formalized temporal message-flow diagrams," Software Practice and Experience, 1995.
      [Co94] Cockburn A., "In search of methodology," Object Magazine, July 1994.
      [Co95] Cockburn A., "Unraveling incremental development," Object Magazine, Jan. 1995.
      [Co98] Cockburn A., Surviving Object-Oriented Projects, Addison Wesley, 1998.
      [Co98p] Cockburn A., Position statement for "Software development and process" panel, ECOOP '98, online at http://members.aol.com/acockburn/papers/Ecoop98panel.htm
      [Co00]Cockburn A., Crystal(Clear): A human-powered software development methodology for small teams, Addison Wesley, in prep. Online at http://members.aol.com/humansandt/crystal/ clear.
      [Cs] Csikszentmihalyi, M., Flow: The Psychology of Optimal Experience, Harper Perennial, 1990
      [C3] The C3 Team, "Chrysler goes to 'Extremes'", in Distributed Object Computing, October, 1998, pp. 24-28.
      [Dm] DeMarco, T., Lister, T., Peopleware 2nd Edition, Dorset House, 1999.
      [EP] Extreme Programming, web notes, start from www.extremeprogramming.com.
      [Gr] Gries, D, The Science of Programming, Springer Verlag, 1987.
      [Ha] Harel, D., Politi, M., Modeling Reactive Systems with Statecharts, McGraw-Hill, 1998.
      [Hi] Highsmith, J., Adaptive Software Development, Dorset House, 1999.
      [Ho] Hovenden, F., "An ethnographic account of writing use cases on an IT project", Humans and Technology Technical Memo, 1999.10.30, online at http://members.aol.com/humansandt/papers/ethno1.htm.
      [Hu] Humphrey, W., A Discipline for Softwrae Engineering, Addison Wesley, 1995.
      [Je] Jeffries, R., "Extreme testing", in Software Testing and Quality Engineering, March/April, 1999, pp. 23-26.
      [J-L] Johnson-Laird, P. and Byrne, R. Deduction, Lawrence Erlbaum Associates, 1991.
      [La] Lave, J., Situation Learning: Legitimate Peripheral Participation, Cambridge Press, 1991.
      [Mi] Mills, H., Dyer, M., Linger, R., "Cleanroom Software Engineering," IEEE Software Vol 2 (1984) No. 9, 19-24.
      [NASA] JSC38609, "Deorbit flight software lessons learned", NASA Johnson Space Center, Jan 19, 1998 online at
      [Pi] Piatelli-Palmarini, M., Inevitable Illusions : How Mistakes of Reason Rule Our Minds, Wiley amp; Sons, 1996.
      [Pl] Plowman, L., "The interfunctionality of talk and text", Computer Support of Cooperative Work, vol. 3, 1995, pp.229-246.
      [Si] Sillince, J.A., "A model of social, emotional and symbolic aspects of computer-mediated communication within organizations", Computer Support of Cooperative Work vol. 4, 1996, pp. 1-31.
      [Web] Webb, D., Humphrey, W., "Using TSP on the TaskView Project", in CrossTalk, The Journal of Defense Software Engineering , Feb 1999, pp. 3-10, online at http://www.stsc.hill.af.mil/crosstalk/1999/feb/webb.asp
      [Wei] Weinberg, J., The Psychology of Computer Programming, Silver Edition, Dorset House, 1998.
      [Yo] Yourdon, E., Death March Projects, Prentice Hall, 1997.