Страница:
(рис. 19.3).
Рис. 19.3
Фокус при проектировании такого дерева состоит в том, чтобы ближе к
корню поместить те решения, изменение которых наименее вероятно.
Такая стратегия проектирования повышает повторную используемость
модулей. Еще важнее, что ее можно расширить, включая не только поставляемые
продукты, но и последовательные промежуточные версии, созданные по стратегии
инкрементируемых сборок. В этом случае продукт развивается через
промежуточные стадии с минимумом возврата назад.
Подход Microsoft: "ежевечерняя сборка". Джеймс Маккарти (James
McCarthy) описал мне процесс, использовавшийся им и другими в Microsoft. Это
пошаговое наращивание, доведенное до логического конца. Он пишет:
Сделав первую поставку, новые версии мы поставляем с дополнительными
функциями, по сравнению с существующим работающим продуктом. Почему должен
быть иным процесс первоначальной сборки? С момента достижения нами первой
вехи (у первой поставки три промежуточных вехи) мы каждый вечер заново
собираем разрабатываемую систему (и прогоняем контрольные примеры). Цикл
сборки становится ритмом жизни проекта. Каждый вечер одна или более бригад
программистов, проводящих тестирование, регистрируют модули с новыми
функциями. После каждой сборки у нас есть работающая система. Если сборка
оказывается неудачной, мы останавливаем весь процесс, пока ошибка не будет
найдена и исправлена. В любой момент все в группе знают положение дел.
Это действительно тяжело. Требуется выделение больших ресурсов, но это
управляемый процесс, прослеживаемый и понятный. Он вызывает у команды
доверие к себе. А доверие определяет мораль, эмоциональное состояние.
Такой процесс удивляет и даже шокирует разработчиков в других
организациях. Один из них говорит: "Я взял себе за правило делать сборку
каждую неделю, но ежедневная сборка, я думаю, потребует слишком много
труда." И это, возможно, верно. Например, в Bell Northern Research собирают
систему, состоящую из 12 миллионов строк, раз в неделю.
Инкрементная сборка и быстрое макетирование. Поскольку инкрементная
разработка позволяет рано начать тестирование реальными пользователями, в
чем ее отличие от быстрого макетирования? Мне кажется, что они связаны, но
различаются. Одним можно пользоваться без другого.
Харел дает полезное определение макета:
(версия программы, которая) отражает только проектные решения, принятые
в процессе подготовки концептуальной модели, а не решения, вызванные
соображениями реализации.12
Можно построить макет, который вовсе не является частью продукта,
развивающегося в направлении поставки. Например, можно создать макет
интерфейса, за которым стоит не реально работающая программа, а лишь
конечный автомат, заставляющий его имитировать прохождение состояний. Можно
даже макетировать и тестировать интерфейсы методом волшебника изумрудного
города, когда спрятанный человек имитирует отклик системы. Такое
макетирование может быть весьма полезным для быстрого получения обратной
связи от пользователя, но оно находится совершенно в стороне от тестирования
продукта, который готовится к поставке.
Аналогично, разработчики могут попробовать построить вертикальный срез
продукта, в котором полностью реализован весьма ограниченный набор функций,
чтобы заранее пролить свет на те места, где могут таиться опасности для
производительности продукта. В чем состоит различие между сборкой на первой
вехе в процедуре Microsoft и быстрым макетом? В функциях. Продукт с первой
вехи может иметь такую ограниченную функциональность, что ни для кого не
будет представлять интереса. Готовность продукта к поставке определяется
завершенностью в предоставлении полезного набора функций и своим качеством,
уверенностью в надежной работе.
Парнас был прав, а я - нет в отношении сокрытия информации
В главе 7 я противопоставляю две точки зрения на то, в какой мере
каждый участник команды может иметь право или поощряться к знанию проектов и
текстов программ, созданных коллегами. Во время проекта Operating System/360
мы решили, что все программисты должны видеть весь материал, т.е. у каждого
программиста была рабочая тетрадь проекта, которая к концу насчитывала свыше
10000 страниц. Харлан Миллз убедительно доказывал, что "программирование
должно быть открытым процессом", что предоставление всей работы на общее
обозрение способствует контролю качества как благодаря давлению со стороны
коллег, заставляющему работать хорошо, так и благодаря тому, что коллеги
действительно находят промахи и ошибки.
Этот взгляд резко противоречит мнению Дэвида Парнаса о том, что
программные модули должны быть инкапсулированы, с хорошо определенными
интерфейсами, а внутренность таких модулей должна быть частной
собственностью программиста, невидимой снаружи. Программисты эффективнее
всего работают, будучи ограждены от внутренностей чужих модулей.13
В главе 7 я заклеймил идею Парнаса как "рецепт катастрофы". Парнас был
прав, а я ошибался. Сегодня я убежден, что ограничение информации, часто
осуществляемое теперь методами объектного программирования, является
единственным способом поднять уровень программных разработок.
Используя другие методы, можно действительно попасть в беду. Согласно
методике Миллза программисты могут получить подробности семантики
интерфейсов, с которыми они работают, узнав, что находится "по ту сторону".
Укрывание этой семантики может быть причиной системных ошибок. С другой
стороны, методика Парнаса способствует устойчивости при внесении изменений и
больше подходит к стратегии проектирования, предполагающей изменения в
будущем.
В главе 16 утверждается следующее:
- большая часть роста производительности разработки программного
обеспечения обеспечена устранением второстепенных трудностей, таких как
неудобные языки программирования и медленная оборачиваемость пакетной
обработки;
- легких решений в этом направлении практически не осталось;
- радикального прогресса можно добиться, разрешив существенные
сложности моделирования сложных концептуальных конструкций.
Самое очевидное на этом пути - признать, что программы составляются из
концептуальных блоков, значительно более крупных, чем отдельные операторы
языков высокого уровня: подпрограмм, или модулей, или классов. Если мы
сумеем ограничить проектирование и построение программ задачей соединения
вместе и параметризации таких блоков из ранее созданных наборов, то
радикально повысим концептуальный уровень и избавимся от огромного объема
работ и широких возможностей для ошибок, существующих на уровне отдельных
операторов.
Данное Парнасом определение модулей с сокрытием информации было первым
открытым шагом в этой критически важной программе исследований и идейным
провозвестником объектно-ориентированного программирования. Он определил
модуль как программный объект с собственной моделью данных и собственным
набором операций. Доступ к его данным может быть осуществлен только через
имеющиеся в нем операции. Следующий шаг явился вкладом нескольких
исследователей: развитие модулей Парнаса в абстрактный тип данных, из
которого можно производить много объектов. Абстрактный тип данных
обеспечивает единообразный способ представления и задания интерфейсов
модулей, а также дисциплину доступа, которую легко осуществлять.
Третий шаг, объектно-ориентированное программирование, вводит важное
понятие наследования, при котором классы (типы данных) по умолчанию имеют
атрибуты своих предков в иерархии классов.14 То, что мы рассчитываем
получить от объектно- ориентированного программирования, происходит, в
сущности, от первого шага, инкапсуляции модулей, плюс идея заранее
подготовленных библиотек модулей или классов, спроектированных и
протестированных с целью повторного использования. Многие предпочли
проигнорировать тот факт, что такие модули не просто программы, а
программные продукты в том смысле, который разъяснен в главе 1. Напрасно
рассчитывать на успешное повторное использование модулей, не оплачивая
начальные издержки на разработку качественных программных модулей:
обобщенных, надежных, протестированных и документированных. Объектно-
ориентированное программирование и повторное использование обсуждались в
главах 16 и 17.
Насколько мифичен человеко-месяц? Модель и данные Бема
В течение ряда лет были выполнены многочисленные количественные
исследования производительности труда программистов и влияющих на нее
факторов, особенно соотношений между обеспеченностью персоналом и графиком
работ.
Наиболее обстоятельное исследование сделано Барри Бемом (Barry Boehm)
на основании примерно 63 проектов, в основном в аэрокосмической области, из
них около 25 - в TRW. Его работа "Экономика разработки программного
обеспечения" содержит не только результаты, но и ряд полезных моделей затрат
с нарастающей сложностью. Хотя несомненно, что применяемые в моделях
коэффициенты различны для обычных космических программ и для программ,
создаваемых в аэрокосмической области по правительственным стандартам, все
же его модели подкрепляются огромным количеством данных. Я думаю, что книга
будет полезным классическим трудом и через поколение.
Полученные им результаты уверенно подкрепляют содержащееся в МЧ-М
утверждение о том, что соотношение между численностью занятых и временем
выполнения проекта далеко не линейное, что человеко-месяц действительно
является мифической мерой производительности. В частности, он считает:15
- Существует оптимальное, с точки зрения затрат, время выполнения
графика для первой поставки: T = 2,5 (ЧМ)1/3. То есть оптимальное время в
месяцах изменяется как кубический корень предполагаемого объема работ в
человеко- месяцах - формула, полученная из оценки размера и других факторов
в его модели. Следствием является кривая, дающая оптимальную численность
занятых.
- Кривая стоимости медленно растет, если запланированный график длиннее
оптимального. Работа занимает все отведенное для нее время.
- Кривая стоимости резко растет, если запланированный график короче
оптимального.
- Практически ни один проект невозможно завершить быстрее, чем за .
расчетного оптимального графика вне зависимости от количества занятых в нем!
Этот примечательный результат дает менеджеру программного проекта солидное
подкрепление, когда высшее руководство требует принятия невозможного
графика.
Насколько верен закон Брукса? Были даже проведены тщательные
исследования закона Брукса (намеренно упрощенного), согласно которому
выделение дополнительных людей для отстающего графика проекта лишь
задерживает его выполнение. Лучше всего это сделано Абдель-Хамидом
(Abdel-Hamid) и Мадником (Madnick) в честолюбивой и ценной книге "Динамика
программного проекта: интегрированный подход".16 В книге разработана
количественная модель динамики проекта. Глава о законе Брукса более подробно
вникает в то, что происходит при различных допущениях относительно того,
кого добавляют, и когда. Чтобы исследовать это, авторы развивают собственную
тщательную модель программного проекта среднего размера, предполагая, что у
вновь добавляемых людей есть кривая обучения, и учитывая дополнительные
издержки на общение и обучение. Они приходят к выводу, что "добавление новых
людей к запаздывающему проекту всегда приводит к его удорожанию, но не
всегда к более позднему завершению" (курсив авторов). В частности,
увеличение численности работников в начале проекта гораздо безопаснее, чем в
конце, поскольку добавление новых людей всегда вызывает отрицательный
эффект, для компенсации которого требуются недели.
Штуцке (Stutzke) предлагает более простую модель для проведения
аналогичных исследований, и с тем же результатом.17 Он проводит подробный
анализ процесса и издержек, связанных с привлечением новых работников, явным
образом учитывая отвлечение наставников от непосредственной работы над
проектом. Он проверял свою модель на реальном проекте, в котором численность
работником была удвоена, благодаря чему удалось уложиться в первоначальный
график, несмотря на отставание в середине. Он рассматривает альтернативы
добавлению новых работников, особенно сверхурочную работу. Наибольшую
ценность представляют его многочисленные практические советы о том, как
привлекать новых работников, обучать их, обеспечивать инструментарием и
т.д., чтобы минимизировать отрицательный эффект увеличения персонала.
Особенно достойно внимания его замечание, что дополнительно привлекаемые на
поздних стадиях проекта работники должны быть игроками команды, стремящимися
войти в игру и вписаться в процесс, а не пытаться изменить или
усовершенствовать сам процесс!
Штуцке считает, что дополнительная тяжесть обмена информацией в крупном
проекте имеет второй порядок малости, и не включает ее в свою модель. Не
вполне ясно, учитывают ли ее Абдель-Хамид и Мадник, и если да, то как. Ни в
одной из моделей не учитывается то обстоятельство, что работа должна быть
перераспределена - процесс, который для меня часто оказывался нетривиальным.
"Крайне упрощенная" формулировка закона Брукса становится более
полезной, будучи дополнена этими тщательно сделанными надлежащими
оговорками. Подытоживая, я продолжаю придерживаться исходного утверждения
как приближения к истине нулевого порядка, практического правила,
предупреждающего менеджеров о неразумности инстинктивной попытки вытянуть
запаздывающий проект.
Кадры решают все (или почти все)
Некоторые читатели удивляются, что большая часть рассуждений МЧ-М
посвящена административным сторонам программной инженерии, а не
многочисленным техническим проблемам. Такой перекос частично вызван той
ролью, которую я играл в IBM Operating System/360 (теперь MVS/370). Если
смотреть глубже, это происходит от убеждения, что качество людей, занятых в
проекте, их организация и администрирование имеют гораздо большее значение
для успеха, чем инструменты, которыми они пользуются, или применяемые ими
технические решения.
Последующие исследования подкрепили мою уверенность. Модель COCOMO Бема
признает, что качество команды является важнейшим фактором ее успеха,
практически вчетверо более важным, чем следующий за ним по значимости.
Большинство научных исследований по программной инженерии сосредоточилось на
инструментах. Я люблю хороший инструмент и жажду его. Тем не менее отрадно
видеть продолжение исследовательских программ в отношении заботы о людях, их
роста и поддержки, а также развития управления разработкой программного
обеспечения.
Человеческий фактор. Крупным достижением последних лет стала книга
Демарко (DeMarco) и Листера (Lister) "Человеческий фактор: продуктивные
проекты и программы", изданная в 1987 году. В основе ее лежит положение о
том, что "главные проблемы в нашей работе по природе своей не столько
технологические, сколько социологические". Она изобилует такими жемчужинами,
как "задача менеджера не заставить людей работать, а сделать так, чтобы они
могли работать". В ней говорится о таких прозаических вещах, как помещение,
мебель, совместное питание команды. Демарко и Листер приводят реальные
данные из своего "Программирования военных игр", которые показывают
поразительную корреляцию между производительностью программистов из одной и
той же организации, а также между характеристиками рабочих мест и уровнем
продуктивности и наличия ошибок.
В помещениях наиболее продуктивных программистов тише, они более
личные, лучше защищены против непрошеного вторжения, и они просто больше...
Понимаете ли вы, что покой, пространство и уединенность способствуют лучшей
работе ваших теперешних работников или (с другой стороны) способствует
привлечению и сохранению лучших работников?18
Я искренне рекомендую эту книгу всем моим читателям.
Передача проектов. Демарко и Листер уделяют большое внимание спаянности
команды, неуловимому, но важному качеству. Я думаю, что непонимание
администрацией спаянности служит причиной той готовности, с которой, как я
наблюдал, в компаниях, расположенных на нескольких площадках, проекты
передаются из одной лаборатории в другую.
В своей практике я наблюдал, возможно, с полдюжины передач проекта, и
ни одна из них не была успешной. Можно с успехом передавать задания. Но во
всех случаях попытки передать проект новая команда фактически начинала
сначала, несмотря на наличие хорошей документации, некоторого продвижения в
проекте и некоторых людей из передающей команды. Я думаю, что разрушение
спаянности прежней команды приводит к выкидышу проекта, находящегося в
эмбриональном состоянии, и осуществлению его с начальной точки.
Сила отказаться от власти
Если согласиться, что, как я неоднократно доказывал на протяжении этой
книги, творчество исходит от личностей, а не организационных структур и
процессов, тогда главная задача менеджера программного проекта - создать
организационную структуру и рабочий процесс, способствующий творчеству и
инициативе, а не подавляющие их. К счастью, эта проблема присуща не только
программным организациям, и над ней работали многие большие умы. Е. Ф.
Шумахер (E. F. Schumacher) в классической работе "Малое прекрасно: экономика
ради людей" предлагает теорию организации предприятий, максимизирующую
творческую активность и радость работников. В качестве первого принципа он
выдвигает "принцип вспомогательной функции" из энциклики Quadragesimo Anno
папы Пия XI:
Передача большему и вышестоящему сообществу того, что могут делать
меньшие и нижестоящие организации является несправедливостью и в то же время
серьезным злом и нарушением правильного порядка. Ибо всякая общественная
деятельность по сути своей должна предоставлять помощь членам социальной
группы, а не разрушать и поглощать их... Тем, кто управляет, следует быть
уверенными, что чем лучше среди различных сообществ сохраняется
дифференцированный порядок в соблюдении принципа второстепенной функции, тем
крепче будет власть и эффективность в обществе, тем более счастливым и
процветающим государство.19
Шумахер приводит разъяснение:
Принцип второстепенной функции учит нас, что власть и эффективность
центра увеличатся, если будут тщательно охраняться свобода и ответственность
более низких формирований, а в итоге организация в целом будет "более
счастливой и процветающей".
Как можно добиться такой организации? ... Большая организация должна
состоять из множества полуавтономных единиц, которые можно назвать
квази-фирмами. Каждая из них должна обладать значительной свободой, чтобы
предоставить наилучшие возможности для творчества и предприимчивости...
Каждая из квази- фирм должна иметь свой учет прибылей и потерь, а также
балансовый отчет.20
К числу наиболее замечательных достижений программной инженерии
принадлежат первые этапы практического осуществления таких организационных
идей. Прежде всего, микрокомпьютерная революция создала новую программную
индустрию с сотнями вновь возникших фирм, которые изначально малы и отмечены
энтузиазмом, свободой и творчеством. Сейчас индустрия меняется по мере
поглощения мелких фирм крупными. Посмотрим, поймут ли крупные фирмы важность
сохранения творческой активности мелких, поглощаемых ими.
Еще более примечательно, что высшее руководство ряда крупных фирм
предприняло меры по передаче власти вниз отдельным командам, работающим над
программными проектами, что сближает их с квази-фирмами Шумахера по
структуре и ответственности. Результаты вызвали удивление и удовлетворение.
Джим Маккарти из Microsoft описывал мне свой опыт эмансипации команд:
У каждой бригады (30-40 человек) есть свой набор разрабатываемых
объектов, свой график и даже свои правила разработки, реализации и поставки.
В бригаде есть специалисты в четырех или пяти областях, в том числе
реализации, тестировании и документировании. Бригада сама улаживает
разногласия по пустякам, начальник не вмешивается. Не боюсь переоценить
важность перемещения власти, когда бригада самостоятельно несет
ответственность за свои достижения.
Эрл Уилер (Earl Wheeler), бывший руководитель программных разработок
IBM, поделился со мной своим опытом делегирования вниз полномочий, бывших в
течение долгого времени сосредоточенными у администрации управления IBM.
Ключевым порывом последних лет стало делегирование полномочий вниз. Это
было чудом! Улучшились качество, продуктивность, моральный дух. У нас
небольшие бригады без централизованного управления. Бригады сами определяют
правила производственного процесса, но они испытывают давление со стороны
рынка. И это давление заставляет их самих искать способы решения проблем.
Общение с отдельными членами бригад показывает, конечно, и
удовлетворение от передачи полномочий и свободы, а также более сдержанную
оценку того, в какой мере контроль действительно ослаблен. Тем не менее,
достигнутая степень передачи полномочий являет шаг в правильном направлении.
Получаемые выгода точно те, которые предсказывались Пием XI: в результате
делегирования полномочий центр усиливает свою реальную власть, а организация
в целом становится более счастливой и процветающей.
Какой самый большой сюрприз? Миллионы компьютеров
Все компьютерные гуру, с которыми я разговаривал, признают, что для
них были неожиданностью микрокомпьютерная революция и ее порождение -
производство коробочных программных продуктов. Вне сомнения, это самое
значительное событие за два десятилетия после выхода МЧ-М. Оно имеет
многочисленные последствия для программной инженерии.
Микрокомпьютерная революция изменила характер использования
компьютеров. Шумахер сформулировал проблему более 20 лет назад:
Чего мы действительно хотим от ученых и технологов? Я отвечу так: нам
нужны методы и оборудование, которые:
- достаточно дешевы, чтобы быть доступными практически каждому;
- пригодны для небольших приложений;
- соответствуют потребности человека в творческой деятельности.21
Это как раз те замечательные свойства, которые микрокомпьютерная
революция дала компьютерной промышленности и ее потребителям, которыми
теперь стала широкая публика. Средний американец может сегодня позволить
себе не только собственный компьютер, но и набор программных средств, для
покупки которого 20 лет назад потребовалось бы королевское жалованье. Каждую
из целей, поставленных Шумахером, стоит рассмотреть отдельно. Представляет
также интерес, в какой мере они достигнуты - особенно последняя. В одной
области за другой обычным людям и профессионалам становятся доступны все
новые средства самовыражения.
Отчасти, развитие в других областях происходит так же, как в создании
программ - благодаря устранению побочных трудностей. Побочные ограничения на
рукописи накладывались длительностью и стоимостью перепечатывания для
внесения исправлений. Работу объемом в 300 страниц иногда приходилось
перепечатывать каждые три или шесть месяцев, а в перерыве чиркать в
рукописи. Трудно было оценить влияние внесенных изменений на общий ход мысли
и ритм слов. Сейчас чудесным образом рукописи стали постоянно меняющимися.22
Аналогичную изменчивость компьютер придал многим другим материалам:
картинам художников, планам построек, чертежам механизмов, музыкальным
сочинениям, фотографиям, кинофильмам, слайдовым презентациям, мультимедийным
работам и даже электронным таблицам. В каждом случае при ручном способе
изготовления для того, чтобы увидеть изменения в контексте, требовалось
копирование больших неизменных частей. Теперь, независимо от материала, мы
можем пользоваться такими же выгодами, какие работа в режиме разделения
времени принесла в программирование: возможность редактирования и мгновенной
оценки результата без потери хода мысли.
Творческие возможности усилились также благодаря новым гибким
вспомогательным инструментам. Один пример - сочинение прозы, при котором мы
пользуемся проверкой орфографии, грамматики, стилистическими подсказками,
системами библиографии и замечательной возможностью одновременно видеть
страницы в окончательно отформатированном виде. Мы еще не оценили значения
мгновенного доступа к энциклопедиям и безграничным ресурсам всемирной
паутины для использования писателем импровизированного поиска.
Самое главное, обретенная изменчивость материала упрощает изучение
многих в корне различных возможностей, когда творческая работа только
обретает форму. Вот другой пример, когда порядок величины в количественном
параметре - в данном случае, времени, необходимом для внесения изменений, -
производит качественный скачок в подходе к задаче.
Инструменты для черчения позволяют проектировщикам зданий за час
Рис. 19.3
Фокус при проектировании такого дерева состоит в том, чтобы ближе к
корню поместить те решения, изменение которых наименее вероятно.
Такая стратегия проектирования повышает повторную используемость
модулей. Еще важнее, что ее можно расширить, включая не только поставляемые
продукты, но и последовательные промежуточные версии, созданные по стратегии
инкрементируемых сборок. В этом случае продукт развивается через
промежуточные стадии с минимумом возврата назад.
Подход Microsoft: "ежевечерняя сборка". Джеймс Маккарти (James
McCarthy) описал мне процесс, использовавшийся им и другими в Microsoft. Это
пошаговое наращивание, доведенное до логического конца. Он пишет:
Сделав первую поставку, новые версии мы поставляем с дополнительными
функциями, по сравнению с существующим работающим продуктом. Почему должен
быть иным процесс первоначальной сборки? С момента достижения нами первой
вехи (у первой поставки три промежуточных вехи) мы каждый вечер заново
собираем разрабатываемую систему (и прогоняем контрольные примеры). Цикл
сборки становится ритмом жизни проекта. Каждый вечер одна или более бригад
программистов, проводящих тестирование, регистрируют модули с новыми
функциями. После каждой сборки у нас есть работающая система. Если сборка
оказывается неудачной, мы останавливаем весь процесс, пока ошибка не будет
найдена и исправлена. В любой момент все в группе знают положение дел.
Это действительно тяжело. Требуется выделение больших ресурсов, но это
управляемый процесс, прослеживаемый и понятный. Он вызывает у команды
доверие к себе. А доверие определяет мораль, эмоциональное состояние.
Такой процесс удивляет и даже шокирует разработчиков в других
организациях. Один из них говорит: "Я взял себе за правило делать сборку
каждую неделю, но ежедневная сборка, я думаю, потребует слишком много
труда." И это, возможно, верно. Например, в Bell Northern Research собирают
систему, состоящую из 12 миллионов строк, раз в неделю.
Инкрементная сборка и быстрое макетирование. Поскольку инкрементная
разработка позволяет рано начать тестирование реальными пользователями, в
чем ее отличие от быстрого макетирования? Мне кажется, что они связаны, но
различаются. Одним можно пользоваться без другого.
Харел дает полезное определение макета:
(версия программы, которая) отражает только проектные решения, принятые
в процессе подготовки концептуальной модели, а не решения, вызванные
соображениями реализации.12
Можно построить макет, который вовсе не является частью продукта,
развивающегося в направлении поставки. Например, можно создать макет
интерфейса, за которым стоит не реально работающая программа, а лишь
конечный автомат, заставляющий его имитировать прохождение состояний. Можно
даже макетировать и тестировать интерфейсы методом волшебника изумрудного
города, когда спрятанный человек имитирует отклик системы. Такое
макетирование может быть весьма полезным для быстрого получения обратной
связи от пользователя, но оно находится совершенно в стороне от тестирования
продукта, который готовится к поставке.
Аналогично, разработчики могут попробовать построить вертикальный срез
продукта, в котором полностью реализован весьма ограниченный набор функций,
чтобы заранее пролить свет на те места, где могут таиться опасности для
производительности продукта. В чем состоит различие между сборкой на первой
вехе в процедуре Microsoft и быстрым макетом? В функциях. Продукт с первой
вехи может иметь такую ограниченную функциональность, что ни для кого не
будет представлять интереса. Готовность продукта к поставке определяется
завершенностью в предоставлении полезного набора функций и своим качеством,
уверенностью в надежной работе.
Парнас был прав, а я - нет в отношении сокрытия информации
В главе 7 я противопоставляю две точки зрения на то, в какой мере
каждый участник команды может иметь право или поощряться к знанию проектов и
текстов программ, созданных коллегами. Во время проекта Operating System/360
мы решили, что все программисты должны видеть весь материал, т.е. у каждого
программиста была рабочая тетрадь проекта, которая к концу насчитывала свыше
10000 страниц. Харлан Миллз убедительно доказывал, что "программирование
должно быть открытым процессом", что предоставление всей работы на общее
обозрение способствует контролю качества как благодаря давлению со стороны
коллег, заставляющему работать хорошо, так и благодаря тому, что коллеги
действительно находят промахи и ошибки.
Этот взгляд резко противоречит мнению Дэвида Парнаса о том, что
программные модули должны быть инкапсулированы, с хорошо определенными
интерфейсами, а внутренность таких модулей должна быть частной
собственностью программиста, невидимой снаружи. Программисты эффективнее
всего работают, будучи ограждены от внутренностей чужих модулей.13
В главе 7 я заклеймил идею Парнаса как "рецепт катастрофы". Парнас был
прав, а я ошибался. Сегодня я убежден, что ограничение информации, часто
осуществляемое теперь методами объектного программирования, является
единственным способом поднять уровень программных разработок.
Используя другие методы, можно действительно попасть в беду. Согласно
методике Миллза программисты могут получить подробности семантики
интерфейсов, с которыми они работают, узнав, что находится "по ту сторону".
Укрывание этой семантики может быть причиной системных ошибок. С другой
стороны, методика Парнаса способствует устойчивости при внесении изменений и
больше подходит к стратегии проектирования, предполагающей изменения в
будущем.
В главе 16 утверждается следующее:
- большая часть роста производительности разработки программного
обеспечения обеспечена устранением второстепенных трудностей, таких как
неудобные языки программирования и медленная оборачиваемость пакетной
обработки;
- легких решений в этом направлении практически не осталось;
- радикального прогресса можно добиться, разрешив существенные
сложности моделирования сложных концептуальных конструкций.
Самое очевидное на этом пути - признать, что программы составляются из
концептуальных блоков, значительно более крупных, чем отдельные операторы
языков высокого уровня: подпрограмм, или модулей, или классов. Если мы
сумеем ограничить проектирование и построение программ задачей соединения
вместе и параметризации таких блоков из ранее созданных наборов, то
радикально повысим концептуальный уровень и избавимся от огромного объема
работ и широких возможностей для ошибок, существующих на уровне отдельных
операторов.
Данное Парнасом определение модулей с сокрытием информации было первым
открытым шагом в этой критически важной программе исследований и идейным
провозвестником объектно-ориентированного программирования. Он определил
модуль как программный объект с собственной моделью данных и собственным
набором операций. Доступ к его данным может быть осуществлен только через
имеющиеся в нем операции. Следующий шаг явился вкладом нескольких
исследователей: развитие модулей Парнаса в абстрактный тип данных, из
которого можно производить много объектов. Абстрактный тип данных
обеспечивает единообразный способ представления и задания интерфейсов
модулей, а также дисциплину доступа, которую легко осуществлять.
Третий шаг, объектно-ориентированное программирование, вводит важное
понятие наследования, при котором классы (типы данных) по умолчанию имеют
атрибуты своих предков в иерархии классов.14 То, что мы рассчитываем
получить от объектно- ориентированного программирования, происходит, в
сущности, от первого шага, инкапсуляции модулей, плюс идея заранее
подготовленных библиотек модулей или классов, спроектированных и
протестированных с целью повторного использования. Многие предпочли
проигнорировать тот факт, что такие модули не просто программы, а
программные продукты в том смысле, который разъяснен в главе 1. Напрасно
рассчитывать на успешное повторное использование модулей, не оплачивая
начальные издержки на разработку качественных программных модулей:
обобщенных, надежных, протестированных и документированных. Объектно-
ориентированное программирование и повторное использование обсуждались в
главах 16 и 17.
Насколько мифичен человеко-месяц? Модель и данные Бема
В течение ряда лет были выполнены многочисленные количественные
исследования производительности труда программистов и влияющих на нее
факторов, особенно соотношений между обеспеченностью персоналом и графиком
работ.
Наиболее обстоятельное исследование сделано Барри Бемом (Barry Boehm)
на основании примерно 63 проектов, в основном в аэрокосмической области, из
них около 25 - в TRW. Его работа "Экономика разработки программного
обеспечения" содержит не только результаты, но и ряд полезных моделей затрат
с нарастающей сложностью. Хотя несомненно, что применяемые в моделях
коэффициенты различны для обычных космических программ и для программ,
создаваемых в аэрокосмической области по правительственным стандартам, все
же его модели подкрепляются огромным количеством данных. Я думаю, что книга
будет полезным классическим трудом и через поколение.
Полученные им результаты уверенно подкрепляют содержащееся в МЧ-М
утверждение о том, что соотношение между численностью занятых и временем
выполнения проекта далеко не линейное, что человеко-месяц действительно
является мифической мерой производительности. В частности, он считает:15
- Существует оптимальное, с точки зрения затрат, время выполнения
графика для первой поставки: T = 2,5 (ЧМ)1/3. То есть оптимальное время в
месяцах изменяется как кубический корень предполагаемого объема работ в
человеко- месяцах - формула, полученная из оценки размера и других факторов
в его модели. Следствием является кривая, дающая оптимальную численность
занятых.
- Кривая стоимости медленно растет, если запланированный график длиннее
оптимального. Работа занимает все отведенное для нее время.
- Кривая стоимости резко растет, если запланированный график короче
оптимального.
- Практически ни один проект невозможно завершить быстрее, чем за .
расчетного оптимального графика вне зависимости от количества занятых в нем!
Этот примечательный результат дает менеджеру программного проекта солидное
подкрепление, когда высшее руководство требует принятия невозможного
графика.
Насколько верен закон Брукса? Были даже проведены тщательные
исследования закона Брукса (намеренно упрощенного), согласно которому
выделение дополнительных людей для отстающего графика проекта лишь
задерживает его выполнение. Лучше всего это сделано Абдель-Хамидом
(Abdel-Hamid) и Мадником (Madnick) в честолюбивой и ценной книге "Динамика
программного проекта: интегрированный подход".16 В книге разработана
количественная модель динамики проекта. Глава о законе Брукса более подробно
вникает в то, что происходит при различных допущениях относительно того,
кого добавляют, и когда. Чтобы исследовать это, авторы развивают собственную
тщательную модель программного проекта среднего размера, предполагая, что у
вновь добавляемых людей есть кривая обучения, и учитывая дополнительные
издержки на общение и обучение. Они приходят к выводу, что "добавление новых
людей к запаздывающему проекту всегда приводит к его удорожанию, но не
всегда к более позднему завершению" (курсив авторов). В частности,
увеличение численности работников в начале проекта гораздо безопаснее, чем в
конце, поскольку добавление новых людей всегда вызывает отрицательный
эффект, для компенсации которого требуются недели.
Штуцке (Stutzke) предлагает более простую модель для проведения
аналогичных исследований, и с тем же результатом.17 Он проводит подробный
анализ процесса и издержек, связанных с привлечением новых работников, явным
образом учитывая отвлечение наставников от непосредственной работы над
проектом. Он проверял свою модель на реальном проекте, в котором численность
работником была удвоена, благодаря чему удалось уложиться в первоначальный
график, несмотря на отставание в середине. Он рассматривает альтернативы
добавлению новых работников, особенно сверхурочную работу. Наибольшую
ценность представляют его многочисленные практические советы о том, как
привлекать новых работников, обучать их, обеспечивать инструментарием и
т.д., чтобы минимизировать отрицательный эффект увеличения персонала.
Особенно достойно внимания его замечание, что дополнительно привлекаемые на
поздних стадиях проекта работники должны быть игроками команды, стремящимися
войти в игру и вписаться в процесс, а не пытаться изменить или
усовершенствовать сам процесс!
Штуцке считает, что дополнительная тяжесть обмена информацией в крупном
проекте имеет второй порядок малости, и не включает ее в свою модель. Не
вполне ясно, учитывают ли ее Абдель-Хамид и Мадник, и если да, то как. Ни в
одной из моделей не учитывается то обстоятельство, что работа должна быть
перераспределена - процесс, который для меня часто оказывался нетривиальным.
"Крайне упрощенная" формулировка закона Брукса становится более
полезной, будучи дополнена этими тщательно сделанными надлежащими
оговорками. Подытоживая, я продолжаю придерживаться исходного утверждения
как приближения к истине нулевого порядка, практического правила,
предупреждающего менеджеров о неразумности инстинктивной попытки вытянуть
запаздывающий проект.
Кадры решают все (или почти все)
Некоторые читатели удивляются, что большая часть рассуждений МЧ-М
посвящена административным сторонам программной инженерии, а не
многочисленным техническим проблемам. Такой перекос частично вызван той
ролью, которую я играл в IBM Operating System/360 (теперь MVS/370). Если
смотреть глубже, это происходит от убеждения, что качество людей, занятых в
проекте, их организация и администрирование имеют гораздо большее значение
для успеха, чем инструменты, которыми они пользуются, или применяемые ими
технические решения.
Последующие исследования подкрепили мою уверенность. Модель COCOMO Бема
признает, что качество команды является важнейшим фактором ее успеха,
практически вчетверо более важным, чем следующий за ним по значимости.
Большинство научных исследований по программной инженерии сосредоточилось на
инструментах. Я люблю хороший инструмент и жажду его. Тем не менее отрадно
видеть продолжение исследовательских программ в отношении заботы о людях, их
роста и поддержки, а также развития управления разработкой программного
обеспечения.
Человеческий фактор. Крупным достижением последних лет стала книга
Демарко (DeMarco) и Листера (Lister) "Человеческий фактор: продуктивные
проекты и программы", изданная в 1987 году. В основе ее лежит положение о
том, что "главные проблемы в нашей работе по природе своей не столько
технологические, сколько социологические". Она изобилует такими жемчужинами,
как "задача менеджера не заставить людей работать, а сделать так, чтобы они
могли работать". В ней говорится о таких прозаических вещах, как помещение,
мебель, совместное питание команды. Демарко и Листер приводят реальные
данные из своего "Программирования военных игр", которые показывают
поразительную корреляцию между производительностью программистов из одной и
той же организации, а также между характеристиками рабочих мест и уровнем
продуктивности и наличия ошибок.
В помещениях наиболее продуктивных программистов тише, они более
личные, лучше защищены против непрошеного вторжения, и они просто больше...
Понимаете ли вы, что покой, пространство и уединенность способствуют лучшей
работе ваших теперешних работников или (с другой стороны) способствует
привлечению и сохранению лучших работников?18
Я искренне рекомендую эту книгу всем моим читателям.
Передача проектов. Демарко и Листер уделяют большое внимание спаянности
команды, неуловимому, но важному качеству. Я думаю, что непонимание
администрацией спаянности служит причиной той готовности, с которой, как я
наблюдал, в компаниях, расположенных на нескольких площадках, проекты
передаются из одной лаборатории в другую.
В своей практике я наблюдал, возможно, с полдюжины передач проекта, и
ни одна из них не была успешной. Можно с успехом передавать задания. Но во
всех случаях попытки передать проект новая команда фактически начинала
сначала, несмотря на наличие хорошей документации, некоторого продвижения в
проекте и некоторых людей из передающей команды. Я думаю, что разрушение
спаянности прежней команды приводит к выкидышу проекта, находящегося в
эмбриональном состоянии, и осуществлению его с начальной точки.
Сила отказаться от власти
Если согласиться, что, как я неоднократно доказывал на протяжении этой
книги, творчество исходит от личностей, а не организационных структур и
процессов, тогда главная задача менеджера программного проекта - создать
организационную структуру и рабочий процесс, способствующий творчеству и
инициативе, а не подавляющие их. К счастью, эта проблема присуща не только
программным организациям, и над ней работали многие большие умы. Е. Ф.
Шумахер (E. F. Schumacher) в классической работе "Малое прекрасно: экономика
ради людей" предлагает теорию организации предприятий, максимизирующую
творческую активность и радость работников. В качестве первого принципа он
выдвигает "принцип вспомогательной функции" из энциклики Quadragesimo Anno
папы Пия XI:
Передача большему и вышестоящему сообществу того, что могут делать
меньшие и нижестоящие организации является несправедливостью и в то же время
серьезным злом и нарушением правильного порядка. Ибо всякая общественная
деятельность по сути своей должна предоставлять помощь членам социальной
группы, а не разрушать и поглощать их... Тем, кто управляет, следует быть
уверенными, что чем лучше среди различных сообществ сохраняется
дифференцированный порядок в соблюдении принципа второстепенной функции, тем
крепче будет власть и эффективность в обществе, тем более счастливым и
процветающим государство.19
Шумахер приводит разъяснение:
Принцип второстепенной функции учит нас, что власть и эффективность
центра увеличатся, если будут тщательно охраняться свобода и ответственность
более низких формирований, а в итоге организация в целом будет "более
счастливой и процветающей".
Как можно добиться такой организации? ... Большая организация должна
состоять из множества полуавтономных единиц, которые можно назвать
квази-фирмами. Каждая из них должна обладать значительной свободой, чтобы
предоставить наилучшие возможности для творчества и предприимчивости...
Каждая из квази- фирм должна иметь свой учет прибылей и потерь, а также
балансовый отчет.20
К числу наиболее замечательных достижений программной инженерии
принадлежат первые этапы практического осуществления таких организационных
идей. Прежде всего, микрокомпьютерная революция создала новую программную
индустрию с сотнями вновь возникших фирм, которые изначально малы и отмечены
энтузиазмом, свободой и творчеством. Сейчас индустрия меняется по мере
поглощения мелких фирм крупными. Посмотрим, поймут ли крупные фирмы важность
сохранения творческой активности мелких, поглощаемых ими.
Еще более примечательно, что высшее руководство ряда крупных фирм
предприняло меры по передаче власти вниз отдельным командам, работающим над
программными проектами, что сближает их с квази-фирмами Шумахера по
структуре и ответственности. Результаты вызвали удивление и удовлетворение.
Джим Маккарти из Microsoft описывал мне свой опыт эмансипации команд:
У каждой бригады (30-40 человек) есть свой набор разрабатываемых
объектов, свой график и даже свои правила разработки, реализации и поставки.
В бригаде есть специалисты в четырех или пяти областях, в том числе
реализации, тестировании и документировании. Бригада сама улаживает
разногласия по пустякам, начальник не вмешивается. Не боюсь переоценить
важность перемещения власти, когда бригада самостоятельно несет
ответственность за свои достижения.
Эрл Уилер (Earl Wheeler), бывший руководитель программных разработок
IBM, поделился со мной своим опытом делегирования вниз полномочий, бывших в
течение долгого времени сосредоточенными у администрации управления IBM.
Ключевым порывом последних лет стало делегирование полномочий вниз. Это
было чудом! Улучшились качество, продуктивность, моральный дух. У нас
небольшие бригады без централизованного управления. Бригады сами определяют
правила производственного процесса, но они испытывают давление со стороны
рынка. И это давление заставляет их самих искать способы решения проблем.
Общение с отдельными членами бригад показывает, конечно, и
удовлетворение от передачи полномочий и свободы, а также более сдержанную
оценку того, в какой мере контроль действительно ослаблен. Тем не менее,
достигнутая степень передачи полномочий являет шаг в правильном направлении.
Получаемые выгода точно те, которые предсказывались Пием XI: в результате
делегирования полномочий центр усиливает свою реальную власть, а организация
в целом становится более счастливой и процветающей.
Какой самый большой сюрприз? Миллионы компьютеров
Все компьютерные гуру, с которыми я разговаривал, признают, что для
них были неожиданностью микрокомпьютерная революция и ее порождение -
производство коробочных программных продуктов. Вне сомнения, это самое
значительное событие за два десятилетия после выхода МЧ-М. Оно имеет
многочисленные последствия для программной инженерии.
Микрокомпьютерная революция изменила характер использования
компьютеров. Шумахер сформулировал проблему более 20 лет назад:
Чего мы действительно хотим от ученых и технологов? Я отвечу так: нам
нужны методы и оборудование, которые:
- достаточно дешевы, чтобы быть доступными практически каждому;
- пригодны для небольших приложений;
- соответствуют потребности человека в творческой деятельности.21
Это как раз те замечательные свойства, которые микрокомпьютерная
революция дала компьютерной промышленности и ее потребителям, которыми
теперь стала широкая публика. Средний американец может сегодня позволить
себе не только собственный компьютер, но и набор программных средств, для
покупки которого 20 лет назад потребовалось бы королевское жалованье. Каждую
из целей, поставленных Шумахером, стоит рассмотреть отдельно. Представляет
также интерес, в какой мере они достигнуты - особенно последняя. В одной
области за другой обычным людям и профессионалам становятся доступны все
новые средства самовыражения.
Отчасти, развитие в других областях происходит так же, как в создании
программ - благодаря устранению побочных трудностей. Побочные ограничения на
рукописи накладывались длительностью и стоимостью перепечатывания для
внесения исправлений. Работу объемом в 300 страниц иногда приходилось
перепечатывать каждые три или шесть месяцев, а в перерыве чиркать в
рукописи. Трудно было оценить влияние внесенных изменений на общий ход мысли
и ритм слов. Сейчас чудесным образом рукописи стали постоянно меняющимися.22
Аналогичную изменчивость компьютер придал многим другим материалам:
картинам художников, планам построек, чертежам механизмов, музыкальным
сочинениям, фотографиям, кинофильмам, слайдовым презентациям, мультимедийным
работам и даже электронным таблицам. В каждом случае при ручном способе
изготовления для того, чтобы увидеть изменения в контексте, требовалось
копирование больших неизменных частей. Теперь, независимо от материала, мы
можем пользоваться такими же выгодами, какие работа в режиме разделения
времени принесла в программирование: возможность редактирования и мгновенной
оценки результата без потери хода мысли.
Творческие возможности усилились также благодаря новым гибким
вспомогательным инструментам. Один пример - сочинение прозы, при котором мы
пользуемся проверкой орфографии, грамматики, стилистическими подсказками,
системами библиографии и замечательной возможностью одновременно видеть
страницы в окончательно отформатированном виде. Мы еще не оценили значения
мгновенного доступа к энциклопедиям и безграничным ресурсам всемирной
паутины для использования писателем импровизированного поиска.
Самое главное, обретенная изменчивость материала упрощает изучение
многих в корне различных возможностей, когда творческая работа только
обретает форму. Вот другой пример, когда порядок величины в количественном
параметре - в данном случае, времени, необходимом для внесения изменений, -
производит качественный скачок в подходе к задаче.
Инструменты для черчения позволяют проектировщикам зданий за час