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

Материал из Википедии — свободной энциклопедии
Перейти к: навигация, поиск
Мифический человеко-месяц
The Mythical Man-Month
Автор:

Фредерик Брукс

Язык оригинала:

английский

Оригинал издан:

1975

Издатель:

Addison–Wesley

ISBN:

ISBN 0201835959

Следующая:

Серебряной пули нет

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

История написания и изданий[править | править вики-текст]

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

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

Книга впервые была опубликована в 1975 году, тогда же она вышла и на русском языке. Повторно книга вышла в виде юбилейного издания в 1995-ом, с дополнительными главами: эссе «Серебряной пули нет», опубликованном в 1986 г. (глава 16), пересмотром сказанного в этом эссе 10 лет спустя (глава 17) и комментариями автора к своей же книге через 20 лет после ее первого издания (главы 18 и 19). В России второе издание было опубликовано издательством Символ-Плюс в 2000-ом году, ISBN 5-93286-005-7.

Основные идеи[править | править вики-текст]

Программа и программный продукт[править | править вики-текст]

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

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

Программный продукт требует в 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 Design of Design: Essays from a Computer Scientist. — М.: «Вильямс», 2012. — 464 с. — ISBN 978-5-8459-1792-8.