Фредерик Брукс - Мифический человеко-месяц или как создаются программные системы

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

Третий шаг, объектно-ориентированное программирование, вводит важное понятие наследования, при котором классы (типы данных) по умолчанию имеют атрибуты своих предков в иерархии классов. [14] То, что мы рассчитываем получить от объектно-ориентированного программирования, происходит, в сущности, от первого шага, инкапсуляции модулей, плюс идея заранее подготовленных библиотек модулей или классов, спроектированных и протестированных с целью повторного использования. Многие предпочли проигнорировать тот факт, что такие модули не просто программы, а программные продукты в том смысле, который разъяснен в главе 1. Напрасно рассчитывать на успешное повторное использование модулей, не оплачивая начальные издержки на разработку качественных программных модулей: обобщенных, надежных, протестированных и документированных. Объектно-ориентированное программирование и повторное использование обсуждались в главах 16 и 17.

Насколько мифичен человеко-месяц? Модель и данные Бёма

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

Наиболее обстоятельное исследование сделано Барри Бёмом (Barry Boehm) на основании примерно 63 проектов, в основном в аэрокосмической области, из них около 25 – в TRW. Его работа «Экономика разработки программного обеспечения» содержит не только результаты, но и ряд полезных моделей затрат с нарастающей сложностью. Хотя несомненно, что применяемые в моделях коэффициенты различны для обычных космических программ и для программ, создаваемых в аэрокосмической области по правительственным стандартам, все же его модели подкрепляются огромным количеством данных. Я думаю, что книга будет полезным классическим трудом и через поколение.

Полученные им результаты уверенно подкрепляют содержащееся в МЧ-М утверждение о том, что соотношение между численностью занятых и временем выполнения проекта далеко не линейное, что человеко-месяц действительно является мифической мерой производительности. В частности, он считает: [15]

• Существует оптимальное, с точки зрения затрат, время выполнения графика для первой поставки: T = 2,5 (ЧМ) 1/3 . То есть оптимальное время в месяцах изменяется как кубический корень предполагаемого объема работ в человеко-месяцах — формула, полученная из оценки размера и других факторов в его модели. Следствием является кривая, дающая оптимальную численность занятых.

• Кривая стоимости медленно растет, если запланированный график длиннее оптимального. Работа занимает все отведенное для нее время.

• Кривая стоимости резко растет, если запланированный график короче оптимального.

• Практически ни один проект невозможно завершить быстрее, чем за [3] Л расчетного оптимального графика вне зависимости от количества занятых в нем! Этот примечательный результат дает менеджеру программного проекта солидное подкрепление, когда высшее руководство требует принятия невозможного графика.

Насколько верен закон Брукса? Были даже проведены тщательные исследования закона Брукса (намеренно упрощенного), согласно которому выделение дополнительных людей для отстающего графика проекта лишь задерживает его выполнение. Лучше всего это сделано Абдель-Хамидом (Abdel-Hamid) и Мадником (Madnick) в честолюбивой и ценной книге «Динамика программного проекта: интегрированный подход». [16] В книге разработана количественная модель динамики проекта. Глава о законе Брукса более подробно вникает в то, что происходит при различных допущениях относительно того, кого добавляют, и когда. Чтобы исследовать это, авторы развивают собственную тщательную модель программного проекта среднего размера, предполагая, что у вновь добавляемых людей есть кривая обучения, и учитывая дополнительные издержки на общение и обучение. Они приходят к выводу, что «добавление новых людей к запаздывающему проекту всегда приводит к его удорожанию, но не всегда к более позднему завершению» (курсив авторов). В частности, увеличение численности работников в начале проекта гораздо безопаснее, чем в конце, поскольку добавление новых людей всегда вызывает отрицательный эффект, для компенсации которого требуются недели.

Штуцке (Stutzke) предлагает более простую модель для проведения аналогичных исследований, и с тем же результатом. [17] Он проводит подробный анализ процесса и издержек, связанных с привлечением новых работников, явным образом учитывая отвлечение наставников от непосредственной работы над проектом. Он проверял свою модель на реальном проекте, в котором численность работником была удвоена, благодаря чему удалось уложиться в первоначальный график, несмотря на отставание в середине. Он рассматривает альтернативы добавлению новых работников, особенно сверхурочную работу. Наибольшую ценность представляют его многочисленные практические советы о том, как привлекать новых работников, обучать их, обеспечивать инструментарием и т.д., чтобы минимизировать отрицательный эффект увеличения персонала. Особенно достойно внимания его замечание, что дополнительно привлекаемые на поздних стадиях проекта работники должны быть игроками команды, стремящимися войти в игру и вписаться в процесс, а не пытаться изменить или усовершенствовать сам процесс!

Штуцке считает, что дополнительная тяжесть обмена информацией в крупном проекте имеет второй порядок малости, и не включает ее в свою модель. Не вполне ясно, учитывают ли ее Абдель-Хамид и Мадник, и если да, то как. Ни в одной из моделей не учитывается то обстоятельство, что работа должна быть перераспределена — процесс, который для меня часто оказывался нетривиальным.

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

Кадры решают все (или почти все)

Некоторые читатели удивляются, что большая часть рассуждений МЧ-М посвящена административным сторонам программной инженерии, а не многочисленным техническим проблемам. Такой перекос частично вызван той ролью, которую я играл в IBM Operating System/360 (теперь MVS/370). Если смотреть глубже, это происходит от убеждения, что качество людей, занятых в проекте, их организация и администрирование имеют гораздо большее значение для успеха, чем инструменты, которыми они пользуются, или применяемые ими технические решения.

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

Человеческий фактор. Крупным достижением последних лет стала книга Демарко (DeMarco) и Листера (Lister) «Человеческий фактор: продуктивные проекты и программы», изданная в 1987 году. В основе ее лежит положение о том, что «главные проблемы в нашей работе по природе своей не столько технологические, сколько социологические». Она изобилует такими жемчужинами, как «задача менеджера не заставить людей работать, а сделать так, чтобы они могли работать». В ней говорится о таких прозаических вещах, как помещение, мебель, совместное питание команды. Демарко и Листер приводят реальные данные из своего «Программирования военных игр», которые показывают поразительную корреляцию между производительностью программистов из одной и той же организации, а также между характеристиками рабочих мест и уровнем продуктивности и наличия ошибок.