Помню, как я писал свою первую программу. Это было упражнение по Фортрану в рамках курса, известного под названием 6.41. В те дни в Мас-сачусетском технологическом институте все шло под своими номерами, в том числе и моя программа. Написать ее не составило труда — она всего лишь не скомпилировалась с первого раза. Или со второго. Я был подавлен и опустошен. Когда мне все-таки удалось ее скомпилировать, я был просто шокирован тем, что она не работала. Я не мог понять, почему — мне казалось, что все написано правильно. Я показал ее своему соседу по комнате. Маршалл специализировался на математике. Я думаю, что он начал писать алгоритмы еще до появления компьютеров, на которых их можно было применять.

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

«А это что?» — спрашивал Маршалл, тыча своим корявым бруклинским пальцем.

«Похоже, что С.»

«Здесь это не нужно.» И он был прав. Этот оператор компилировался, однако компьютер прочитывал его не так, как я предполагал. Маршалл возвращался к чему-то, связанному с градиентами и операторами Гамильтона, и оттачивал свою интерпретацию песни Марлона Брандо (Marlon Brando) из «А Streetcar Named Desire». Из всего этого я уяснил, что Маршаллу никогда нельзя показывать то, что я написал, особенно если это код. Он всегда найдет в нем что-нибудь неправильное, а мне придется на-ходить в себе силы, чтобы отнестись к этому, как к одолжению. Кроме того, это неизменно вызывало у него очередной приступ музыкального мычания: «Стелла! Стелла!». Скоро начало занятий, а я все еще не был готов. Конечно, со временем я понял, что обсуждение проблемы с приятелем-программистом часто оказывается самым эффективным способом обнаружения какого-нибудь незаметного бага или составления какого-нибудь мудреного алгоритма. На самом деле многие из нас знают, что изложение своих идей коллеге, играющему роль «звукового экрана», или выяснение его мнения по поводу чего-то неясного может быть не только полезной и ценной процедурой для конечного продукта, но и веселым занятием, помогающим построить хорошие рабочие отношения.

П. Дж. Плоджеру (P. J. Plauger) все же пришлось потратить силы, чтобы научить меня пользоваться преимуществами видимости. Вскоре после того как он создал компанию Whitesmith, Ltd., я стал приходить в его нью-йоркскую «штаб-квартиру» — небольшую квартиру на Манхэттене. В углу одной из комнат стоял мини-компьютер, принтер был засунут в шкаф, чтобы не было шума, а по всей комнате, которая считалась «гостиной», были расставлены несколько терминалов. И за каждым терминалом находилось по два программиста!

Конечно, кодировать за каждой клавиатурой мог только один программист, а другие заглядывали ему через плечо и давали надоедливые советы (нью-йоркцы, особенно школьники, называют это kibitzing[34]). В комнате стоял непрерывный гул. Сыпались вопросы по алгоритмам или о правильности начального значения, выдвигались предложения о том, как выйти из цикла, раздавались призывы обратить внимание на синтаксическую ошибку или на тест, выполняемый в неверном порядке, или на неправильный регистр. Время от времени два программиста менялись местами, и тот, который сидел за клавиатурой, теперь становился профессиональным «раздражителем».

Я предположил, что недостаток оборудования связан с нехваткой денежных средств, но Плоджер заверил меня, что на самом деле это был особый режим работы. Довольно неэффективный режим, да? Нет. Приняв такой подход, они стали производить законченный и протестированный код быстрее, чем когда-либо. При близком рассмотрении становится понятно, почему. Код, который выходил из этих терминалов-с-двумя-программис-тами, был почти на 100 % свободен от багов. Программа не только содержала меньше ошибок, но и была более рациональной, краткой и эффек-тивной благодаря тому, что над ее созданием работали две светлых головы, а также благодаря ценному диалогу, происходящему между сидящими за терминалом напарниками. Такую модель работы я стал называть «динамическим дуэтом». Принцип, который здесь работает, довольно ясен: увеличение рабочей видимости приводит к увеличению качества! Два программиста, работающие в тандеме, — это не излишество, а прямой путь к большей эффективности и лучшему качеству. (Об этом знают те, кто занимается ХР (extreme programming, экстремальное программирование.)

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

Наверное, это правило особенно подходит для изучения языков программирования. Плоджер заметил, что при изучения языков существует оптимальное количество студентов, которые садятся за один терминал. Это не один студент. Скорее, два. Три тоже подходит, однако в одиночку студент чаще всего изучает язык значительно медленнее, чем в паре в партнером. С другой стороны, четыре и более студентов, сидящих за одним компьютером, всегда мешают друг другу — как в переносном, так и в прямом, физическом смысле. Такие большие группы часто распадаются на более мелкие или начинают применять «разделение машинного времени», что в конечном итоге приводит к снижению эффективности. Поэтому, если вы действительно хотите добавить в свой репертуар язык С++ или Smalltalk, не запирайтесь с руководствами и учебниками, а хватайте своего приятеля-программиста и вместе садитесь за клавиатуру. Знание этого принципа может быть полезным для школ с ограниченным бюджетом, а также для компаний, в которых был расформирован отдел обучения.

Интересно отметить, что для получения выигрыша от видимости в работе необязательно, чтобы кто-нибудь сказал хоть слово. Большинство из нас сталкивалось со случаем, когда какая-то ошибка никак не находилась. Вы изучили тестовый прогон и листинг. Вы знаете, что проблема скрыта в одном из блоков кода, но сколько бы вы по нему не проходили, вам не удается обнаружить, где собака зарыта. Отчаявшись, вы стучите в дверь соседней комнаты и настойчиво требуете помощи. В конце концов, Шарлотта имеет степень Ph.D в Computer Science. Вы начинаете описывать ей суть проблемы. Как только вы добираетесь до цикла, что-то бросается вам в глаза. Шарлотта еще не успела ничего сказать, а вы тихо восклицаете: «О!» — и начинаете робко выходить за дверь, на ходу бормоча благодарности. «Пожалуйста, в любое время», — слышите вы в ответ.

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

Как и все руководства для построения лучших систем, «принцип видимости в работе» может завести слишком далеко. Одной из форм «доведения до абсурда» (или «расширения» до него?) является модель программирования, к которой прибегают некоторые крупные производители программного обеспечения. Этот подход можно назвать «подходом стаи дворняг». Просто соберите много-много программистов и поместите их в большую комнату — некую «арену для быков», заполненную столами и терминалами. Обеспечьте их всем необходимым для доступа к онлайновым базам данных и электронным рассылкам, чтобы все могли читать информацию и обмениваться мнениями. Все мы знаем, к чему приводят такие подходы.

В большинстве ситуаций преимущества видимости существенно возрастают, если к процессу подключается второй человек, однако с каждым новым человеком отдача снижается. Конечно, бывают и исключения из правил, особенно на самых первых или самых последних стадиях разработки системы. Метод мозгового штурма лучше работает при большом количестве мозгов, способных пробудить этот шторм.[35] Небольшие группы смогут создать только пылевой вихрь или могут просто сесть и посидеть спокойно. В разборе кода и анализе дизайнерских проектов также полезно участие нескольких критиков. Чем больше людей просмотрит работу, тем с большей вероятностью могут быть обнаружены ошибки и упущения. С другой стороны, в реальных задачах, связанных с поиском хорошей архитектуры программного обеспечения при наличии сложных взаимосвязанных ограничений, участие слишком большого количества умов зачастую приводит к взаимным стычкам. Вероятно, в качестве оптимального значения здесь подойдет известное правило «7 ± 2».

Принцип видимости в работе достигает зенита в некоторых специальных моделях командной или групповой работы, предназначенных для проектирования программного обеспечения. В модели под названием «Совместное проектирование приложений» (Joint Application Design, JAD) (Wood и Silver, 1989 [69]) группа конечных пользователей и разработчиков проводят анализ требований и выполняют высокоуровневое проектирование с помощью высокоструктурированного процесса обсуждения. Видимость процесса для пользователей и возможность активно вносить свой вклад приводят к созданию превосходных систем и улучшению взаимопонимания между пользователями и разработчиками.

Так называемая «структурно-открытая» команда, описанная в главе 16 (Constantine, 1989 [11]; Thomsett 1990 [62]), является другой моделью, в которой принцип видимости применяется для улучшения качества системы и, в конечном итоге, эффективности разработки. На протяжении всего рабочего цикла участники такой команды проектирования большую часть своей работы выполняют в присутствии друг друга. Марк Ре-тиг (Marc Rettig, 1990 [60]) сообщает, что одна успешная команда тратила половину своего рабочего дня на общие собрания. Конечно, это были не просто приятные встречи, а рабочие сессии. Их цель заключалась не в том, чтобы обсудить черновики или похвалить друг друга за успехи, а в том, чтобы заниматься работой. При «структурно-открытой» командной работе члены группы анализируют задачи, модули и даже разрабатывают детали кода. Такие рабочие сессии проводятся под руководством одного из членов команды, что позволяет сделать их более эффективными и плодотворными. Но самую главную роль здесь играет видимость, которая достигается за счет открытости процесса разработки.

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

Помните, Программист Скрытный — это исчезающий вид. Из журнала Computer Language Magazine, том 9, № 2,1992 г.

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

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

Тогда в чем же проблема? К сожалению, большинство программистов любят программировать. Некоторые из них могут даже не есть и не мыться, а только заниматься программированием. Большинство из них предпочитают писать код, а не рыться в документации, или искать в каталогах, или разбираться в идиотской работе какого-то тупого программиста. Разработчики программного обеспечения создают продукты, а пользователи их применяют. При прочих равных условиях программисты будут разрабатывать и строить с нуля, а не использовать что-либо повторно. Каждый из них убежден, что сможет написать более короткую и более элегантную программу, чем код его предшественника. В силу своего характера программисты имеют предубеждение против повторного использования, даже если оно может повысить их продуктивность. Как побудить их изменить свои привычки? Внезапно с балкона раздается контрапунктное пение хора: «Премии. Рыночные меры. Поощрительные схемы. Гонорары. Графики поощрений. Изменение культуры». Какая приятная какофония!

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

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

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

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

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

Меилир Пейдж-Джонс (Meilir Page-Jones) рассказывает об одном клиенте, у которого библиотека «подержанных» компонентов стала чересчур громоздкой. Руководство решило назначить библиотекаря, чьей обязанностью было извлечение компонентов из библиотеки и контроль за тем, чтобы в хранилище включались только самые лучшие подпрограммы. Легенда сообщает, что этого человека стали называть Конан-Библиотекарем (Conan the Librarian). Тем не менее для эффективности такого подхода должны быть серьезные силы, которые побуждали бы разработчиков вносить свои пожертвования в библиотеку.

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

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

Если снова обратиться к терминологии книжной торговли, эту модель можно представить как модель «школьные учебники». В этой модели команды специалистов стараются определить, что следует преподавать и как, и работают над книгами коллегиально. Результаты часто оказываются великолепными и отличаются яркой графикой, таблицами, упражнениями и удобными примечаниями на полях каждой третьей страницы. К учебникам прилагаются всевозможные рабочие тетради, руководства для учителей, тексты для дополнительного чтения и наглядные пособия. Обычно они неинтересны, безвкусны и даже скучны, а зачастую совершенно не отвечают реальным нуждам школ и учеников.

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

И что считать «использованием»? Каждый вызов или конкретизацию? Каждый случай наследования или ссылки? Одна программа может 130 раз обратиться к компоненту, который ни разу не применялся ни в одном продукте, а другой компонент может однократно применяться в каждой из 27 систем, разработанных в течение года. Какой компонент является более полезным? Какой продукт заслуживает большего гонорара: простой, понятный и часто используемый компонент или искусный и оригинальный класс, который помог сэкономить несколько дней работы в одном проекте?

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

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

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

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

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

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

Из журнала Computer Language Magazine, том 9, № 7,1992 г.

Вы собираетесь изучить Smalltalk, или стать специалистом по Java, или освоить UML, но в сутках есть только двадцать четыре часа. Вы уже опаздываете со сдачей проекта «клиент-сервер», а ваши дети хотели бы хоть иногда видеть вас до того, как закончат школу. Попробуйте суперобучение! Как утверждает реклама, вы сможете научиться объектно-ориенти-рованному программированию за один час. Или иностранный язык — за три секунды. Суперобучение, ускоренные методы, мультисенсорное обучение. Новые методы, разработанные то ли русскими, то ли болгарами, то ли техасцами. Разве не здорово? Надеваете наушники, клюете носом и просыпаетесь, уже зная СОМ или API в Windows. Или проскальзываете на лекцию, недолго похрапываете и уходите, думая «объектами», словно всегда только этим и занимались. Хотите?

Сегодня это называется методами обучения во сне и подсознательного перепрограммирования бессознательного, но все начиналось с программ аудио-тренинга, курсов изучения иностранных языков на кассетах. А еще раньше были долгоиграющие пластинки и даже пластинки на 78 оборотов, что возвращает меня во времена запуска Спутника.

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

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

Конечно, изучить Smalltalk намного легче, чем русский язык. Однако ни тот ни другой язык невозможно выучить во сне. Несмотря на то что вокруг такого обучения возникла целая индустрия, не существует никакого надежного или непротиворечивого подтверждения того, что процесс обучения можно ускорить какими-либо формами музыки или ритма, или инфразвуковых импульсов. Нет подтверждений и тому, что информация, записанная на пороге слышимости на (или под?) музыку в стиле New Age, помогает повысить продажи или сбросить вес, или стать более уверенным в себе. Никакие средства подобного рода не стоят денег, исчезающих с вашей кредитной карты. Они выгодны лишь тем, кто предлагает такое «суперобучение».

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

Экономист Кеннет Боулдинг (Kenneth Boulding), один из создателей современной теории систем, сказал, что ноу-хау — работающее знание — это не то же самое, что знание. Знание, даже очень сложное знание, может быть получено многими способами, однако ноу-хау требует обучения на собственном опыте. Вы можете много узнать о программировании или психотерапии с помощью чтения, или наблюдения за другими людьми, или посещения ярких ознакомительных показов. Однако стать программистом или терапевтом вы сможете только в том случае, если будете писать программы или лечить людей.

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

А как насчет мультимедийных презентаций? Я был преподавателем в Институте исследования систем (Systems Research Institute) в IBM, когда приблизительно в 1970 году Джеймс Мартин (James Martin) поразил коллег и студентов тем, что использовал не один, а целых два проектора для 35-миллиметровых слайдов. С тех пор многое изменилось. Теперь уже все применяют по два проектора! Теперь, чтобы быть впереди всех, требуется намного больше. Цвет. Звук. Графика. Анимация. Игры.

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

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

Более десяти лет я занимался тем, что обучал людей одним из самых трудных и сложных межличностных и когнитивных навыков — пониманию семей как работающих систем и оказанию помощи тем семьям, которые работали недостаточно хорошо (Constantine, 1986 [10]). Поэтому я знаю, что людям действительно можно помочь изменить их взгляды на окружающий мир и понимание этого мира. На современном жаргоне это называется «сдвигом парадигмы». Однако это происходит не за час, и даже не за день.

В чем же суть всей этой мультисенсорности и мультимодалыгости? Существуют различные стили обучения. Одни люди лучше обучаются через прослушивание, другие — через чтение, третьи — через просмотр. А некоторым подходит только самостоятельное изучение. Для одних людей изображение стоит тысячи слов, а другим оно заменяет только 17 или 18. Некоторым «аудиалам» графические или визуальные средства могут быть бесполезны. Одновременное воздействие на разные каналы восприятия увеличивает шансы на то, что все слова, образы и навыки останутся в памяти. Один канал восприятия может усилить обучающий эффект в другом.

Какая-то информация запоминается легче и на более длительное время. Запахи могут оставлять в памяти очень долговременные следы даже после однократного вдыхания. Пространственно-моторное запоминание, то есть память о выполненных движениях и действиях, не просто долговечна — она может способствовать вспоминанию мыслей и ощущений, связанных с движениями. Физическое обращение с предметами, манипулирование материалами, которые ясно представляют некоторые идеи, помогает закрепить понятия — при условии, что физические манипуляции непосредственно с ними связаны.

Мультимодальная коммуникация не обязательно должна вовлекать сложные мультимедийные презентации. Например, во время дискуссии, проходившей на конференции в Лондоне, на вопрос о связи между повторным использованием и объектной технологией я не раздумывая ответил с помощью удерживания двух карандашей в виде буквы «L». Таким способом я хотел показать, что эти концепции — ортогональные, то есть не зависят друг от друга. Позже, уступая под градом острых вопросов, я признал взаимосвязь этих концепций. Объектная технология может способствовать более эффективному повторному использованию. Я составил из карандашей широкую букву «V», чтобы показать, что эти концепции связаны друг с другом. Два дня спустя участники конференции все еще обсуждали эту мини-демонстрацию.

Взаимосвязь между повторным использованием и объектной технологией продемонстрировать легко. Хорошая презентация, прежде всего, должна делать простые вещи простыми в изучении. Трудные вещи всегда будут трудными. Сколько бы систем восприятия вы не применяли, вы не сможете изучить объектно-ориентированное проектирование за один час так же, как не сможете изучить за час программирование. За это время вы сможете узнать только упрощенные — некоторые сказали бы «разбавленные» — варианты основных понятий.

Из журнала Software Development, том 1, № 11, ноябрь 1993 г.

Может ли роботам сниться электрическая овца? Преследуют ли менеджеров программных проектов кошмары о прыжках с водопада?

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

Конечно, на самом деле так обычно не происходит. Так называемая «водопадная» модель разработки программного обеспечения все еще подвергается жарким обсуждениям. Порой она кажется кошмарной частью нашей коллективной мифологии. Бросаясь вниз с водопада, вы теряете контроль над своим движением и направлением. Вы просто летите вниз, хотите вы того или нет. Самое большее, на что вы можете надеяться — не утонуть. Я могу взять часть вины на себя за то, что когда-то давно ввел такие чрезмерно упрощенные понятия. Однако в сравнении с неуправляемым хаосом, который царил в то время, даже такие примитивные модели последовательного цикла работы были прогрессом. С тех пор мало что изменилось.

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

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

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

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

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

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

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

В конце концов, мы придумали новую концепцию цикла разработки, назвав ее моделью «задел-возврат» («feed-forward/work-back»). Это улучшенная преемница различных моделей последовательной разработки, включая не только модель «водопад», но и так называемую модель «водоворот», предусматривающую разработку по спирали. Модель «задел-воз-врат» — это как раз одна из тех очень маленьких идей, которые могут существенно изменить порядок работы. В принципе, эта модель может быть интегрирована практически в любую другую модель цикла разработки программного обеспечения.

Свое название модель «задел-возврат» получила из-за тех циклов, которые она вносит в процесс разработки. Когда вы забегаете вперед, вы «забрасываете» информацию «в будущее», но саму работу не выполняете. Это этап «задел». Когда вы замечаете упущения или ошибки, совершенные ранее, вы сразу же их исправляете. Это этап «возврат». «Задел» идей на будущее и работа в обратном направлении. Вот и все. Каждый раз при забегании вперед вы делаете заметку для себя и коллег. Позже на соответствующем этапе разработки вы рассматриваете эту идею.

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

Важно создать настоящий журнал или файл, который служил бы в качестве такой корзины. Если вы применяете неформальные групповые методы, то заведите в журнале отдельные листы для каждого этапа или вида работы. Если в вашем цикле разработки есть что-нибудь вроде «Подтверждения физического проекта» («Physical Design Validation»), то заведите лист с названием «Подтверждение физического проекта — Входящие сообщения». Если вы используете системы обработки документов или инструменты CASE, то создайте для каждой корзины свой файл, или папку, или другой документ.

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

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

Безусловно, наша цель — эффективное применение «заделов» для сокращения объема «возвратов».

Из журнала Software Development, том 2, № 1, январь 1994 г.

Как и предупреждали представители авиакомпании «Alitalia», наш вылет из Бостона в Рим задержался. Тем не менее мы приземлились вовремя, чтобы успеть на прямой поезд до Флоренции. Там мы собирались провести несколько дней, чтобы насладиться искусством, едой и винами Тосканы. После этого нам предстояло вернуться в Рим для проведения классов по разработке программного обеспечения, ориентированного на пользователя.

Обратите внимание: я не сказал, что наш самолет приземлился «по расписанию». Он приземлился «вовремя». Кроме тонкого различия в понятиях, здесь есть и культурологический вопрос большой важности. Прибытие в 6 ч. 30 мин. на прием, назначенный на 6 ч. 30 мин., есть прибытие «по расписанию». Прибытие в то время, когда очередь у стойки бара уменьшилась и уже выносят горячуюhors d'oeuvres,[36] означает прибытие «вовремя». Вовремя подразумевает функциональную своевременность. Об итальянцах нельзя сказать, что они не способны действовать в атмосфере неотложности, например при приготовлении макарон, когда нельзя пропускатьal dente.[37] В Италии, как и во многих других странах мира, культурологическое ощущение времени не совпадает с реальным временем. Немного раньше, немного позже — какая разница, важен результат, конечный итог. Северный сосед Италии, Швейцария, является ее полным культурологическим антиподом. В этой стране движение поездов и жизнь людей происходит по расписанию, по которому можно сверять швейцарские часы.

Разработка программного обеспечения и прикладных программ тоже может находиться в этом культурологическом континууме. На одном конце — разработка «по расписанию» в соответствии с календарными сроками. На другом — разработка «вовремя», при которой разумных результатов важно достичь к сроку, когда они еще имеют ценность для пользователей. В некоторых случаях внешние силы задают скорость движения стрелок на часах. Некоторые приложения для федеральных учреждений и властных структур отдельных штатов включают в себя определенные компоненты, которые должны быть готовы к юридически установленным датам. Но даже в этом случае сдвоенные часы разработки «по расписанию» и разработки «вовремя» отсчитывают одно время. Новая редакция пакета по подготовке налоговых документов должна быть готова строго к 15 апреля, но на практике не ясно, следует ли начать поставку уже в начале января, или же поставка в середине февраля также отвечает потребностям пользователей. Тем не менее сегодня почти во всех случаях руководство настаивает на том, чтобы программное обеспечение поставлялось по расписанию. Крайние сроки исполнения приближаются даже быстрее, чем сроки, диктуемые жесткой конкуренцией, которая царит в мире программирования с ограниченным финансированием.

В результате быстрое проектирование приложений стало одним из методологических безумств в нашем деле. Процесс разработки зажат в тиски абсолютных календарных планов по продвижению и сдаче проекта. Сдача в срок становится главнейшим, если не единственным критерием успеха проекта. Высокопроизводительные «SWAT»-команды лучших программистов вооружаются новейшими программными инструментами, позволяющими сократить время цикла разработки продукта. Осуществление проекта в какой-то выдуманный, но жестко заданный рынком период времени становится важнее других целей. Когда подходит крайний срок, сдается все, что получилось, — вместе с ошибками, изъянами и всем остальным.

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

На одной конференции по программному обеспечению я был свидетелем крайнего проявления культуры быстрой разработки. Представьте: начальник вручает вам спецификацию нового приложения как раз в тот момент, когда вы входите в комнату, и говорит, что через 40 минут вы должны представить рабочую программу. Здесь уже не до моделей и методов. Это авральное программирование, не больше и не меньше.

Такой режим был условием на «Суперкубке по Visual С++» на Software Development'94 (с тех пор он стал обычным явлением на конференциях). Толпившаяся аудитория наблюдала за тем, как команды программистов из Microsoft и Borland с молниеносной скоростью пишут программы (программисты из Symantec на этом соревновании не появились). Ричард Хэйл Шо (Richard Hale Shaw) из журнала PC Week играл роль Донахью (Donahue), в то время как судьи и публика то изумлялись, то смеялись, то аплодировали. Словом, как сказал мой друг и штатный судья Дж. Д. Хилдебрэнд (J. D. Hildebrand) из журнала Windows Tech Journal, это было захватывающее зрелище. К тому времени я уже забыл, насколько веселым может быть занятие программированием. Конечно, мне не приходилось демонстрировать «штамповку кода» на 12-футовом экране перед толпой в 1100 человек. Хотя не так уж и много программистов сталкиваются с такими экстремальными ситуациями, как эта, все большее число разработчиков чувствуют приставленный к виску пистолет, вынуждающий их создавать программное обеспечение все быстрее и быстрее. На занятиях и во время консультаций все больше и больше программистов говорят мне о драконовских сроках и усиливающемся давлении графиков, словно вручаемых с Олимпа. Часто я слышу: «Мы хотим тестировать более тщательно, но нам сказано сдавать все как есть» или «Мы хотели бы сделать более удобный интерфейс, но босс не позволяет», или «У нас нет времени на то, чтобы сделать это как следует, — у нас едва есть время на то, чтобы сделать это вообще».

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

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

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

Поставка достойного программного обеспечения вовремя — это именно то, что в конечном итоге имеет значение для делового и профессионального успеха. Разработчикам никогда не следует принимать как данность нереалистичные сроки исполнения. Для выполнения своих истинных обязанностей перед работодателями им нужно научиться вести переговоры о сроках на основе компромиссов по объему работы и ее качеству.

В некоторых случаях, даже если начальник говорит вам гнать халтуру, надо идти вперед, делая свою работу хорошо.

Из журнала Software Development, том 2, № 7, июль 1994 г.

Городок Лорн (Lome) в Австралии — это ворота на Великую океанскую дорогу (The Great Ocean Road), которая вьется вдоль одного из самых прекрасных побережий в мире, под звуки оглушающего прибоя волн, мимо крутых обрывов и белоснежных морских берегов, по которым можно идти и на протяжении многих миль не встретить ни души. Когда я жил в Австралии, Викторианское отделение Австралийского компьютерного сообщества пригласило меня в Лорн на свою ежегодную конференцию. Я должен был помочь в судействе на их первом конкурсе по разработке программного обеспечения Software Challenge. Это был 6-часовой марафон по разработке приложений, на котором с помощью новейших инструментов быстрого визуального проектирования создавалось приложение для взвешивания грузовиков, работающих на переработке отходов. Это было третье соревнование по быстрой разработке, в котором я участвовал в качестве судьи, поэтому у меня уже был какой-то опыт в этом деле (см. главу 30). Например, я научился не издавать стоны в тех случаях, когда система вызывала исключения GPF,[38] и сдерживать свое волнение, когда соперники приближались к финишной ленточке, на больших оборотах завершая отладку. Кроме того, я узнал, что во время соревнований и сам смогу чему-то научиться, даже не соревнуясь.

Через час после начала соревнований я стал прохаживаться по «турнирной комнате», выделенной для программистов. По всей комнате расположились команды, состоящие из трех человек. Все они лихорадочно писа-ли код на Visual Works, PowerBuilder, SQL for Windows — все, за исключением одной группы невозмутимых молодых ребят из команды Ernst amp; Young. Когда я подошел к ним, я едва поверил своим глазам. Команда под руководством Крейга Брайта (Craig Bright) рисовала диаграммы! Вместо того чтобы согнуться над клавиатурами, как это сделали их соперники, они сгрудились вокруг листков бумаги. Они уточняли определение требований и усердно планировали архитектуру создаваемой системы. Заметив мой интерес, один из них дал мне копию своего боевого плана. Это был блокнот, содержавший краткое описание их обычной методологии, которая была модифицирована специально для этого соревнования. В блокноте все было расписано по пунктам, по этапам, с учетом промежуточных готовых компонентов. Это было полное, упорядоченное описание всего процесса быстрого проектирования. Даже в пылу гонки «ноздря в ноздрю», когда до сдачи результатов по более чем 200 функциональным пунктам оставалось меньше дня, эта группа демонстрировала невозмутимость под давлением и спокойно анализировала задачу и разрабатывала ее решение. Я был поражен.

Не раз я говорил студентам, что чем меньше остается времени до сдачи системы, тем важнее знать, что именно вы сдаете. Если на программирование приложения есть только четыре дня, то лучшее, что можно сделать для достижения успеха, — это потратить первые два дня на тщательное проектирование. Конечно, мне никогда не приходилось подтверждать свою веру программированием сложного приложения за один день. Легко быть праведным, когда ваша вера не подвергается испытаниям.

Безусловно, команда Ernst amp; Young была именно той командой, чья вера в процесс проверялась на прочность. Уже в самом начале, едва очутившись в конференц-зале, они умудрились сжечь свою совершенно новую систему на базе Pentium. Быстрый перенос программного обеспечения на лэптопы позволил продолжить работу, хотя и с меньшей мощностью аппаратного обеспечения.

Наконец, когда они перешли от журналов и блокнотов к клавиатурам и мониторам, дело опять осложнилось. На первый взгляд казалось, что соперники добились непреодолимого превосходства, тем более что некоторые из них уже демонстрировали какие-то рабочие компоненты. Однако в программировании поверхностные впечатления зачастую оказываются обманчивыми. На самом деле, к середине дня в контрольной точке, когда судьи оценивали команды программистов и проверяли их результаты по выполненным функциональным пунктам, парни из Ernst amp; Young превратили свое методичное спокойствие во внушительное лидерство. Тща-тельный анализ и планирование давали свои результаты — даже в этих жестких условиях.

Тем не менее, как говорится, был еще не вечер.

По результатам начальной оценки на последнем месте оказалась команда из Xpedite Professional Services Pty. Ltd. под руководством Сью Стивене (Sue Stevens). Пока другие команды усердно наращивали функциональность, они сосредоточились на деталях и тщательно продумывали код, направив все усилия на обработку ошибок и исключений. Однако этот метод, очевидно, не подходил для чрезвычайно плотного цикла разработки, установленного на соревновании. На полпути команда Xpedite решила поменять свою стратегию.

Когда подошло время финальной оценки, команда Ernst amp; Young начала объединять различные компоненты своей методично построенной системы. В спешке, когда все файлы переносились на одну машину, они нечаянно записали черновые версии поверх рабочих файлов. Мы все совершали такую ошибку, случайно перепутав направление копирования. Я и сам совершил ее всего за несколько месяцев до этого, когда переносил файлы Power Point, созданные для другой конференции. К счастью, у меня были резервные копии. К несчастью, у команды Ernst amp; Young их не было. Затерев большую часть своих данных, к финалу они пришли с меньшим количеством функциональных пунктов по сравнению с результатами в середине соревнований.

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

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

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

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

И наконец, еще об одном, хотя это и кажется очевидным. Хорошее управление версиями необходимо даже при очень коротких циклах программной разработки. Даже под непомерным давлением сроков — или, возможно, особенно под таким давлением — время, затраченное на создание резервных копий и версий, идет только на пользу. По сути, управление резервными копиями и версиями было необходимо включить в ускоренный метод разработки, применявшийся командой Ernst amp; Young. Именно это они и пообещали сделать к следующему соревнованию.

Из журнала Software Development, том 3, № 10, октябрь 1995 г.

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

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

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

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

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

Возможно, для этого надо заново пересмотреть место архитектуры программного обеспечения в процессе разработки. Обычно под архитектурой мы понимаем нечто, предшествующее построению. Однако так же, как можно переписать код, можно перестроить и архитектуру (в мире экстремального программирования такая процедура называется рефакторин-гом). Например, одному большому банку в Австралии пришлось вернуться к своим традиционным системам после того, как был прекращен один претенциозный и чрезмерно крупный проект построения новой общебанковской информационной системы. Прежняя система объединяла многие поколения клуджей[Клудж (от англ. kludge) — устройство, программа или ее часть, которые теоретически не должны работать, но почему-то работают. — Примеч. ред.

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

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

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

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

Архитектурное планирование может существенно сэкономить время даже при очень жестких графиках работ. У саги о доблестной команде Ernst amp; Young, которая во время однодневного соревнования нашла время на проектирование архитектуры своей системы (см. главу 30), есть продолжение. Эта команда в полной готовности появилась на следующем соревновании Software Challenge, проходившем на XTWorld в Брисбене (Австралия). На этот раз они применяли новый инструмент (Delphi от Borland) и пересмотренный план для «безумного проектирования приложений» (так этот процесс назвали их соперники). Кроме того, они использовали управление версиями и резервное копирование, а также быстрый, но тщательный анализ и планирование архитектуры. Они выиграли.

Из журнала Software Development, том 4, № 1, январь 1996 г.

«Тотальное управление качеством» (Total Quality Management), «Непрерывное улучшение рабочего процесса» (Continuous Process Improvement) или ISO — в большинстве современных терминов, касающихся качества процесса и продукта, акцент ставится на стремлении к качеству в масштабах всего предприятия и солидные инвестиции с долгосрочной перспективой. Продуманные схемы для оценки и повышения «зрелости процесса», такие как общеизвестная модель развития функциональных возможностей (Capability Maturity Model), разработанная Институтом разработки программного обеспечения (Software Engineering Institute), могут быть весьма полезны. Однако применение подобных моделей может потребовать много ресурсов (Humphrey, Snyder, Willis, 1991 [41]) и привести к непредусмотренным последствиям (Bollinger и McGowan, 1991 [5]). Для получения наибольшей, долговременной отдачи могут понадобиться программы для значительной реструктуризации и обеспечения всестороннего качества. Однако даже небольшие практические шаги будут способствовать быстрому и ощутимому улучшению качества программного обеспечения и эффективности самого проекта.

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

Первые шаги зачастую оказываются самыми важными, а первым шагом в улучшении качества является правильное определение приоритетов. Для улучшения качества продукта и процесса его создания само качество должно стать приоритетом. Если для вас и для организации в целом оно не важно, а стремление к нему не проявляется в действиях руководства, то качество не будет важным критерием и для разработчиков. Все это не означает плакаты с надписями «Качество — наша первая задача!» или напоминания работникам о необходимости стремиться к отсутствию ошибок, Здесь наиболее важно то, что вы делаете, а не то, что говорите.

К сожалению, привычные представления и методы действий современных руководителей часто мешают им сделать качество реальным приоритетом, Одним из наибольших препятствий является чрезмерное стремление многих компаний «успеть выйти на рынок». В области новейших технологий, например в разработке программного обеспечения, видение руководства особенно заужено. Руководители не видят что-либо за пределами так называемого «рыночного окна». Если вы пропускаете это окно, все можно считать потерянным. Суть состоит в том, чтобы выйти на рынок раньше других, пусть даже с продуктом низкого качества и большим количеством ошибок. Когда забота о рыночном окне превосходит заботу о качестве, то качество начинает страдать. Это вполне очевидно. Безусловно, своевременность имеет значение, но все же это вопрос приоритетов. Когда выбор стоит между упаковыванием и продажей, по сути, бета-тес-товой версии и проведением еще одного цикла тщательного тестирования и доработки, то что обычно выбирается?

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

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

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

Механизм расходования средств требует обоснования, однако анализировать нужно не только затраты, представляющие только одну часть уравнения, но и прибыль от инвестиций. Например, австралийский консультант Роб Томсет (Rob Thomsett) показал, что одинаковую отдачу можно получить как от инвестирования в CASE-технологии, так и от вложений в формирование команды, однако конечная прибыль от инвестирования в командную работу будет на порядок больше. Тем не менее CASE — это яркая технология, которую можно показать, тогда как эффективная командная работа невидима, поэтому многие компании предпочитают тратить деньги на аппаратные и программные средства, а не на человеческий фактор (peopleware).

Думайте о прибыли от инвестирования, а не о сдерживании расходов

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

Проблема не в том, что люди не заботятся о качестве, как жалуются некоторые руководители. Исследование (1991 г.), проведенное компанией Brooks International и охватившее 11000 человек из 6 отраслей, показало, что более 90 % работников чувствовали личную ответственность за качественное выполнение работы. Однако семь человек из десяти заявили, что качество не было важным фактором в оценке их деятельности. И только 25 % опрошенных утверждали, что руководство действительно оценивало повышение качества. Так что же мы поощряем? На самом деле признание и поощрения любого рода намного более редки, чем думают большинство руководителей. Почти 80 % руководителей искренне утверждают, что их подчиненные получают достаточное поощрение, но только один из семи подчиненных соглашается с этим (Lickert, 1989 [48]).

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

Когда вы видите то, что вам нравится, начинайте хлопать в ладоши как сумасшедший

Почти каждый слышал изречение, утверждающее, что нельзя контролировать то, что нельзя измерить (DeMarco, 1982 [32]). Часто такие слова оказываются прелюдией к активной кампании по запуску проекта, связанного с измерением параметров программного обеспечения или обеспечением статистического контроля качества. У формальных измерений есть множество преимуществ. Однако если на мгновение задуматься, то можно понять, что в жизни есть много важных вещей, которые родители, учителя, руководители контролируют, но не измеряют. Многое вообще нельзя измерить. Когда речь заходит о людях, то важным становится внимание, а не измерение. Значение имеет то, что вы контролируете. Любой хороший родитель знает: чем больше обращать внимание на капризы, тем больше будет капризов, У систем вообще и у человеческих систем в частности есть особенность, согласно которой само наблюдение изменяет предмет наблюдения. На этом основан хорошо известный эффект Хо-ворна (Hawthorne effect): если сделать группу объектом наблюдения и просто уделять больше внимания ее работе, это приведет к повышению производительности.

Безусловно, объект ваших наблюдений имеет значение, потому что именно на него и будет оказываться воздействие. Если оценивать программистов по краткости написанного кода, они будут производить меньшие по размеру системы. Если критерием является дружественность системы по отношению к пользователю, то вы получаете более удобные программы (Weinberg и Schulman, 1974 [66]).

В Австралии новый руководитель группы по разработке программ технического обслуживания захотел улучшить не только эффективность своей команды, но и ее статус и значение в компании. Для этого среди прочего он стал посылать основным программистам отчеты об ошибках, которые были обнаружены и исправлены в системах после их передачи «в производство». Программист мог получить записку, в которой просто сообщалось, что в минувшие выходные в системе произошел сбой и некорректное закрытие файла вывода, однако программист Куинфорп из отдела технического обслуживания обнаружил ошибку в цикле модуля Z091, который был исправлен, перекомпилирован и протестирован за 1,6 часа.

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

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

Обратная связь — это важный ингредиент. Когда работники получают информацию о собственной производительности и ее связи с организационными целями, качество повышается. Это основа открытой модели руководства, в которой работники получают не только отчеты о производстве и ошибках, но и финансовую информацию о затратах, статьях расходов и прибылей (Саве, 1990 [6]; Finegan, 1990 [36]). Обладая такой информацией, работники проще оптимизируют распределение времени и улучшают собственные рабочие процессы. Ключом здесь является обратная связь, которая объединяет индивидуальную и командную производительность с общей финансовой картиной. Работникам известны не только выявленные ошибки и время, затраченное на программирование, но и общая стоимость работ, и получаемая в результате выгода (или убыток) с точки зре-

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

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

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

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

Запомни, это все — данные

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

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

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

Ведение детального протокола всех трудностей — изъянов, упущений, жалоб потребителей, изменений дизайна, ошибок в анализе, «улучшений» при бета-тестировании — является важным шагом. Другой шаг заключается в регулярном и методичном изучении всех неполадок. Это означает, что в каждом проекте необходимо предусматривать время для методичных размышлений. Если мы не изучаем свои ошибки и не учимся на них, то как мы сможем избежать их в будущем?

Для улучшения качества особенно важно никогда не путать оппозицию и критику с нелояльностью.

Поощряйте критику

Зачастую именно противоположный взгляд или критическое рассмотрение дает самую ценную информацию о возможностях улучшения процесса. На самом деле качество решения задач в чрезвычайной степени зависит от наличия критики. Группы, в которых есть «свой критик» или «спорщик», а также группы, практикующие диалектические процессы столкновения идей и активной критики, работают с большей производительностью (Constantine, 1989 [11]; Priem и Price, 1991 [59]).

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

Исправляйте процесс, а не только программу

В названии одной известной песни 60-х годов можно найти действенный принцип улучшения качества:

Пусть светит солнце

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

Опыт показывает, что качество программного обеспечения можно значительно улучшить, если просто увеличить объем работы, выполняемой лицом к лицу (глава 26). Когда двое или более людей вместе работают над одной задачей, качество повышается. Как правило, повышение видимости рабочего процесса повышает его качество. Почему? В принципе, для того чтобы два программиста, вместе создающие программу, внесли ошибку или отступили от стандартов и правил, они должны сговориться об этом. Однако заметить ошибку или отступление от правил может и один человек. Забудьте о том, что вы слышали про «групповое мышление» или коллективную посредственность. Все эти эффекты существуют, но они зависят от определенных условий. Групповые лидеры могут легко способствовать улучшению качества решения задач и избежанию недостатков группового мышления. Для этого лидерам любых групп достаточно просто воздерживаться от выражения своего собственного мнения или откладывать его на какое-то время (Anderson и Balzer, 1991 [2]).

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

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

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

* Применяйте разделение труда

Этот принцип является важнейшим компонентом метода «чистого» (clean room) программирования. С помощью этого подхода были созданы некоторые средние и крупные системы, которые практически не содержали ошибок (Cobb и Mills, 1990 [8]). В этой модели один человек или группа пишет код, стараясь «все сделать правильно». Еще кто-нибудь выполняет компиляцию и тестирование, стараясь обнаружить ошибки и погрешности. В этой модели есть и другие приемы, но даже простое разделение обязанностей само по себе может повысить качество. Знание того, что кто-то другой в команде не только просматривает код, но и занимается компиляцией и тестированием, повышает ответственность и побуждает принимать правильные решения с первого раза.

Десятилетия исследований и практический опыт показали нам, что по продуктивности лучшие программисты зачастую на порядок отличаются от худших и в два раза от средних программистов (DeMarco и Lister, 1987 [33]).

^[3] Некоторые группы значительно повысили качество своей работы и продуктивность путем простого сокращения штата программистов, оставив только самых лучших. Один подход к повышению качества заключается в том, чтобы взять только самых лучших игроков, предоставить в их распоряжение все ресурсы, создать мотивацию для достижения наилуч-ших результатов в работе и позволить им ее сделать. Такой подход может быть особенно привлекательным в эпоху «сокращения расходов».

Конечно, каждый руководитель знает, что в любой организации есть «звезды», но не каждый желает избавляться от вспомогательных игроков. На самом деле мы хотим найти способ помочь другим «стать лучше», что приводит нас к принципу перекрестного обучения. Идея заключается в том, чтобы разработчики программного обеспечения имели больше возможностей учиться друг у друга.

Пусть все друг друга учат

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

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

Как это ни странно, во многих организациях, искренне стремящихся улучшать качество, существуют правила и условия, которые препятствуют его улучшению. Даже такие простые вещи, как способы определения сроков исполнения и составления бюджетов, значительно влияют на качество проектов. Обычно все факторы — бюджет, распределение ресурсов, подбор персонала, методология и сроки исполнения — уже определены на тот момент, когда проект передается разработчикам. На какой стадии можно достичь улучшения качества? Нам нужна по крайней мере одна степень свободы. Если все переменные ограничены, система становится сверхопределенной, а путей к победе у нас нет. Чем при возникновении проблем жертвуют в первую очередь? Качеством! При жестких сроках исполнения, например, устанавливаемых в соответствии с каким-то выдуманным «рыночным окном», дело зачастую доходит до таких высказываний: «У нас нет времени на то, чтобы сделать все как надо». Это указывает на одно из простейших изменений, способных улучшить качество программного обеспечения:

Обсуждайте сроки исполнения

Разработчики должны непосредственно участвовать в определении сроков поставки продукта и стадий исполнения проекта. Определение сроков следует рассматривать как переговоры, в ходе которых могут быть найдены компромиссы. «Да, проект можно сдать к концу года, если вас устраивает 15 ошибок на каждую тысячу строк. Либо мы можем пообещать более низкую частоту ошибок, если вы согласны вдвое сократить количество экранов».

Методы повышения качества программного обеспечения не всегда сложны и необязательно требуют больших затрат. Некоторые простые приемы могут привести к значительным изменениям. Прежде всего, определите свои приоритеты — присвойте качеству высокий приоритет. Не допускайте, чтобы ваш бизнес зависел от рыночных окон. Старайтесь думать о прибыли от инвестирования, а не о сдерживании затрат.

Далее, признавайте и поощряйте качество. Обращайте на него внимание. Обеспечьте обратную связь и широкий доступ к информации. Прислушивайтесь ко всему. Помните, что все новости являются хорошими, особенно плохие. Поощряйте критические оценки. Отслеживайте и изучайте ошибки и корректируйте рабочий процесс, а не только программу. Пусть светит солнце — сделайте рабочий процесс более видимым. Способствуйте перекрестному обучению — пусть каждый учит каждого. Когда вопрос качества имеет особое значение, применяйте только лучшие ингредиенты. И всегда ведите переговоры о сроках исполнения!

По материалам журнала American Programmer, февраль 1992 г.

Примечания:

3

Число, выведенное в 1956 году психологом Джорджем Миллером, относится к возможности человека обрабатывать в кратковременной памяти только от пяти до девяти элементов.

34

От kibitz (амер. англ.) — давать непрошеные советы.

35

Автор обыгрывает разные значения слова «storm». Brainstorming (англ.) — мозговой штурм (групповой метод решения сложных задач). Storm (англ.) — шторм, буря, штурм

36

Закуска (фр.).

37

Al dente (ит.) — в итальянской кухне: момент варки, когда макароны находятся в идеальной готовности.

38

GPF (general protection fault) — общее нарушение защиты.