Мифический человеко-месяц (Bnsncyvtnw cylkfytk-byvxe)
Мифический человеко-месяц | |
---|---|
The Mythical Man-Month | |
Автор | Фредерик Брукс |
Язык оригинала | английский |
Оригинал издан | 1975 |
Издатель | Addison–Wesley |
ISBN | ISBN 0201835959 |
Следующая | Серебряной пули нет |
«Мифический человеко-месяц, или Как создаются программные системы» (англ. 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 причинам.
- В программировании, в отличие от, например, сбора хлопка, работа не может быть произвольно разделена на несколько независимых частей. Части проекта зависят друг от друга, и некоторые задачи можно начинать выполнять только после того, как будут закончены другие.
- Программисты должны тратить часть времени на взаимодействие друг с другом.
Если есть N программистов, то количество пар программистов равно N(N—1)/2, то есть с ростом числа программистов затраты времени на взаимодействие растут квадратично. Поэтому начиная с какого-то N, рост числа программистов замедляет выполнение проекта.
Если сроки сорваны, наём новых программистов замедляет выполнение проекта и по другой причине: новичкам требуется время на обучение. В книге сформулирован «закон Брукса»: «Если проект не укладывается в сроки, то добавление рабочей силы задержит его ещё больше».
При очень большом числе программистов проект может быть вообще никогда не закончен: из-за общей неразберихи, попытки исправить существующие ошибки в программном обеспечении порождают новые ошибки, так что система не улучшается (глава 2).
Хирургические группы. Разумно, если в группе разработчиков есть один «хороший» программист, реализующий самые критические части системы, и несколько других, помогающих ему или реализующих менее критические части. Так делаются хирургические операции. Кроме того, по мнению Брукса, лучшие программисты работают в 5-10 раз быстрее остальных (глава 3).
Концептуальная целостность. Для обеспечения концептуальной целостности системы необходимо отделить архитектуру от реализации. Один главный архитектор (или небольшая группа), действуя в интересах пользователя, решают, что должно входить в систему, а что не должно. «Очень крутая» идея может быть отвергнута, если предлагаемая возможность не вписывается в общий дизайн системы. Простота очень важна; может быть полезным реализовать только часть возможностей, на которые способна система, потому что если система слишком сложна, часть её возможностей будет оставаться неиспользованной.
Главный архитектор должен сформулировать свои решения в виде руководства для пользователя (глава 4).
Эффект второй системы. Программист, разрабатывающий свою вторую систему, склонен добавлять все те возможности, которые он не смог добавить в свою первую систему (из-за нехватки времени). Поэтому вторая система часто получается перегруженной возможностями (глава 5).
Формальные документы. Каждый менеджер проекта должен составить небольшой набор формальных документов, описывающих цели проекта, как, кем и когда они будут реализованы, и сколько они будут стоить. Эти документы могут вскрыть несоответствия, которые иначе было бы трудно заметить.
Каждая группа разработчиков получает набор требований к своей части системы, включая точное описание её функциональности и предельные требования к процессорному времени, занимаемой памяти, месту на диске и т. д.
Взаимодействие. Чтобы предотвратить катастрофу, группы разработчиков должны взаимодействовать друг с другом всеми возможными способами. Вместо того чтобы строить предположения по поводу реализуемой им функции, разработчик должен задавать архитектору уточняющие вопросы, поскольку предположения могут оказаться совершенно неверными. «Предположение — мать провала».
Пилотная система. Перед тем, как разрабатывать окончательную систему, необходимо разработать пилотную систему. Пилотная система выявит ошибки в проектировании, после чего она должна быть полностью переделана (глава 11). Эту идею Брукс отвергает через 20 лет в главе 19, так как за 20 лет изменился подход к созданию программ — на место принятой в 60-х—70-х каскадной модели разработки пришла итеративная.
Версии и замораживание системы. По мере создания системы, требования пользователя к ней могут меняться под влиянием его опыта работы с незаконченной системой. Эти пожелания пользователя следует учитывать, но только до какого-то момента, иначе работа над системой никогда не будет закончена. После этого спецификации замораживаются, и все последующие требования изменений откладываются до начала работы над следующей версией (глава 11).
Специализированные утилиты. Вместо того, чтобы каждый программист писал собственные утилиты, в каждой группе разработчиков должен быть один программист, ответственный за написание утилит для своей группы (например, генератор кода, создающий код в соответствии с какими-то спецификациями). Должна быть также группа, создающая утилиты для всех работающих над данной системой (глава 12).
Снижение стоимости разработки. Брукс приводит 2 способа снизить стоимость разработки программного обеспечения:
- Нанять программистов только после того, как построена архитектура системы. Иначе при длительности этой стадии, например, в несколько месяцев программистам будет нечего делать.
- Купить часть программного обеспечения у других разработчиков.
Примечания
[править | править код]- ↑ 1 2 Андрей Колесов. [Мифический человеко-месяц: двадцать пять лет спустя] // PC Week (229)7`2000, 07.03.2000
- ↑ Top Ten IT Books Never To Admit You Haven't Read // PC World. — Дата обращения: 02.03.2018.
- ↑ Top Ten Most Influential Programming Books of All Time. — 2011. — 18 ноября. — Дата обращения: 02.03.2018.
- ↑ The mythical man-month (anniversary ed.). — Дата обращения: 02.03.2018.
- ↑ Dustin Marx. Book Review: The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition // JavaWorld. — 2011. — 10 сентября. — Дата обращения: 02.03.2018.
- ↑ Игорь Шапошников. Фредерик Брукс. Мифический человеко-месяц, или Как создаются программные системы Архивная копия от 2 мая 2018 на Wayback Machine // Компьютерра, 04.07.2001
Литература
[править | править код]- Ф. П. Брукс мл. Как проектируются и создаются программные комплексы. (Серия: «Библиотечка программиста») = 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.