Мифический человеко-месяц

«Мифический человеко-месяц, или Как создаются программные системы» (англ. The Mythical Man-Month: Essays on Software Engineering) — книга Фредерика Брукса об управлении проектами в области разработки программного обеспечения.

Фактически книга Брукса представляет собой сборник очерков, в которых последовательно обсуждаются узловые проблемы разработки крупных программных проектов: повышение производительности труда программистов, организация коллективной работы, планирование и выполнение графика реализации. Одной из главных тем книги стала идея, получившая впоследствии название «закон Брукса», о том что привнесение в проект новых сил на поздних стадиях разработки лишь отодвигает срок сдачи проекта^[1].

Англоязычный журнал PC World поместил книгу Брукса на первое место в списке «Десять IT-книг, которые стыдно признать, что не читал» (Top Ten IT Books Never To Admit You Haven't Read)^[2]. Согласно опросу нескольких тысяч членов сообщества Stack Overflow, книга вошла в десятку наиболее влиятельных книг по программированию всех времён^[3]. На сайте библиотеки Ассоциации вычислительной техники книга Брукса характеризуется следующим образом: «Очень мало книг по управлению программными проектами стали столь же влиятельными и неподвластными времени»^[4]. По мнению обозревателя Java World Дастина Маркса, «Мифический человеко-месяц» является одной из наиболее известных книг во всей литературе по разработке программного обеспечения, и, вероятно, самой известной книгой в области управления программными проектами^[5]. По утверждению журнала Компьютерра о книге Брукса, «в США давно считается, что, не прочитав её, ни один менеджер разработки ПО не сможет действовать эффективно»^[6].

История написания и изданий

Наблюдения Брукса основаны на его опыте работы в IBM, полученном в ходе управления проектом по созданию операционной системы OS/360. Для ускорения разработки им была предпринята неудачная попытка привлечения большего числа работников к проекту, сроки по которому уже были сорваны. Заметив свойство менеджеров повторять такие ошибки, Брукс насмешливо называл свою книгу «библией для программной инженерии»: «все её читали, но никто ей не следует!»

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

Книга впервые была опубликована в 1975 году, в 1979 году вышла на русском языке. Юбилейное издание 1995 года (на русском языке — 2000 года) содержит дополнительные главы: эссе «Серебряной пули нет», опубликованное в 1986 г. (глава 16), пересмотр сказанного в этом эссе 10 лет спустя (глава 17) и комментарии автора к его книге через 20 лет после её первого издания (главы 18 и 19).

Основные идеи

Программа и программный продукт. Программный продукт отличается от программы:

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

Программный продукт требует в 3 раза больших затрат времени, чем программа (глава 1).

Мифический человеко-месяц. Время выполнения проекта не обратно пропорционально числу программистов, по крайней мере по 2 причинам.

1. В программировании, в отличие от, например, сбора хлопка, работа не может быть произвольно разделена на несколько независимых частей. Части проекта зависят друг от друга, и некоторые задачи можно начинать выполнять только после того, как будут закончены другие.
2. Программисты должны тратить часть времени на взаимодействие друг с другом.

Если есть N программистов, то количество пар программистов равно N(N—1)/2, то есть с ростом числа программистов затраты времени на взаимодействие растут квадратично. Поэтому начиная с какого-то N, рост числа программистов замедляет выполнение проекта.

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

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

Хирургические группы. Разумно, если в группе разработчиков есть один «хороший» программист, реализующий самые критические части системы, и несколько других, помогающих ему или реализующих менее критические части. Так делаются хирургические операции. Кроме того, по мнению Брукса, лучшие программисты работают в 5-10 раз быстрее остальных (глава 3).

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

Главный архитектор должен сформулировать свои решения в виде руководства для пользователя (глава 4).

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

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

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

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

Пилотная система. Перед тем, как разрабатывать окончательную систему, необходимо разработать пилотную систему. Пилотная система выявит ошибки в проектировании, после чего она должна быть полностью переделана (глава 11). Эту идею Брукс отвергает через 20 лет в главе 19, так как за 20 лет изменился подход к созданию программ — на место принятой в 60-х—70-х каскадной модели разработки пришла итеративная.

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

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

Снижение стоимости разработки. Брукс приводит 2 способа снизить стоимость разработки программного обеспечения:

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

Примечания

Литература

• Ф. П. Брукс мл. Как проектируются и создаются программные комплексы. (Серия: «Библиотечка программиста») = The Mythical Man-Month. — М.: «Наука», Главная редакция физико-математической литературы, 1979. — 152 с илл. с. — ISBN отсутствует.
• Фредерик Брукс. Мифический человеко-месяц или как создаются программные системы. (Серия: «Профессионально») = The Mythical Man-Month. Essays on Software Engineering. Anniversary Edition. — СПб.: «Символ-Плюс», 2000. — 304 с.: ил. с. — ISBN 5-93286-005-7.
• Фредерик П. Брукс. Проектирование процесса проектирования: записки компьютерного эксперта = The Design of Design: Essays from a Computer Scientist. — М.: «Вильямс», 2012. — 464 с. — ISBN 978-5-8459-1792-8.

Ссылки

• Сайт автора

Эта страница в последний раз была отредактирована 22 ноября 2022 в 18:45.