Алистэр Коуберн - Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения
Обзор книги Алистэр Коуберн - Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения
Алистэр Коуберн
Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения
( [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-карточки.
