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

• Название: Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения
• Автор: Алистэр Коуберн
• Издательство: Humans and Technology
• Жанр: Деловая литература
• Год: 1999

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

---

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

( [email protected] )

Humans and Technology, Октябрь, 1999

Введение

Этот отчет базируется на моем личном опыте, который я приобрел, изучив около 40 проектов за последние 20 лет.

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

Наиболее заметными исключениями из этого правила являются Джеральд Вайнберг (Gerald Weinberg [Wei]) и Том Демарко (Tom DeMarco [Dm]), чьи книги публикуются сейчас в юбилейных (!) изданиях. Их работы так популярны в нашей отрасли, что, казалось бы, они должны были только повысить интерес к этому предмету и вызвать активизацию исследований в этой области. Сейчас все большее количество консультантов начинает относиться к людям как к главному фактору в разработке ПО [B99] [Hi], однако, в целом, сообщество разработчиков программного обеспечения продолжает игнорировать тот факт, что именно человек должен быть центральной темой исследований. Это представляется мне серьезным упущением - все равно, что не принимать во внимание металлические перекрытия в стенах и жаловаться на плохую работу радиоприемника.

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

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

Теперь, когда я начал учитывать этот параметр, мои методологические прогнозы и выводы стали соответствовать тому, что я вижу в реальной жизни. Теперь я считаю, что люди - это главный , первоочередной двигатель проекта.

Чем же это отличается от того, что писали в "Peopleware" Демарко и Листер (Lister)? Они высказали мнение, что люди представляют собой важный фактор, и указали на некоторую специфику вопроса. Меня же интересует то, как групповые и индивидуальные особенности человека влияют на проектирование способов разработки ПО (иными словами, на методологии), в применении к различным группам, работающим над разными видами задач.

Мои идеи весьма сходны с теми, которые излагал Вайнберг в главе "Teaming" ("Работа в команде") своей книги "The Psychology of Computer Programming" ("Психология программирования"). Особенно все то, что касается противопоставления двух стилей руководства - управления задачами (task management) и управления поддержкой (maintenance management). Это весьма близко к тому, что пытаюсь получить я - некие характеристики и рекомендации, которые из них следуют. Вайнберг основывается на тех проектах, которые он исследовал в 60-е годы. Однако его выводы остаются справедливыми и полезными и сейчас, 30 лет спустя, что еще раз подтверждает стабильность и важность человеческого фактора в разработке ПО. Мне кажется, уже наступило время тщательно изучить подобные факторы, и начать относиться к следующим из них рекомендациям как к основам разработки ПО, а не открывать их для себя каждые 30 лет.

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

Путь ошибок трудных

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

Проблема 1. Людям, занятым в проекте, совершенно неинтересно изучать нашу систему.

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

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

Мы потратили несколько лет, чтобы разработать специальный генератор, трансформирующий диаграммы последовательности и взаимодействия в архитектуру программного продукта и систему правил [Ci]. Многие компании работали (и работают) над сходными задачами, например, выполняемыми конечными автоматами Хэрела (Harel's executable finite state machines) [Ha].

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

Проблема 1. Людям, занятым в проекте, совершенно неинтересно изучать нашу систему.

Проблема 2. Они вполне могут обойтись и без нас, и при этом успешно создавать программное обеспечение. Такое положение дел уже начинало меня беспокоить, и я стал заниматься методологиями разработки ПО (проектировал объектно-ориентированную методологию по заказу IBM Consulting Group (1992-94)). На этот раз, чтобы не наступать на те же самые грабли, я заранее опросил более дюжины различных компаний, которые работали над ОО проектами в различных странах, и тщательно записал все, что они мне рассказали. Изучая эти заметки, я сделал несколько интересных выводов:

Те команды, которые успешно работают над своими проектами, используют инкрементные процессы разработки [Co95]

При проектировании любая техника, сложнее "CRC-карточек" [B87] считается слишком сложной и не используется [Co94].

У тех, кто занимается проектированием, всегда есть возможность отказаться от любого программного продукта или техники, которые им не нравятся. Достаточно сказать начальнику: "Это замедляет работу. Если я буду этим пользоваться, то не уложусь в срок", и он разрешит проектировщикам поступать по собственному усмотрению. В то время это наблюдение не казалось мне особенно важным, но, тем не менее, я его записал и назвал "проектным ограничением" методологии. После этого я разработал весьма привлекательную и, как мне казалось, настолько не формальную, насколько это возможно, методологию и опробовал ее на одном из проектов. Наш опыт описан в документации по проекту Winifred [Co98]. Основной идеей техники проектирования, которую я рекомендовал к использованию, и которой я обучал разработчиков, были CRC-карточки.