Мифический человеко-месяц - книга про разработку ПО 50-летней давности

Мифический человеко-месяц. Фредерик Брукс.

Книга о том, как пишутся большое программное обеспечение (ПО), очень большое, например, такое как операционные системы. А точнее — про проблемы при написании такого ПО. При этом эта книга написана в 1975 году! Было переиздание книги в 1995 года, но само содержание изменению не подверглось, добавилась только, по большей части, одна глава. Несмотря на возраст книги почти в 50 лет, она весьма популярна у разработчиков — у меня в руках книга, отпечатанная в 2024 году. Книга подаётся как сборник эссе, но читается как весьма целостная книга.

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

Предпоследний главой идут «тезисы книги», которые кратко пересказывают всю книгу. По сути ещё приложили эту же книгу в кратком изложении. Мне кажется было бы проще по тексту подсветить важные мысли. Ну да ладно. Последняя глава — та самая новая глава, оценка мыслей книги, сделанная в 1995 г. — опять вкратце перепечатали книгу со свежими комментариями. Получили трижды написанную книгу в одной. Ну да ладно второй раз.

Основные мысли из книги:

• Стоимость проекта варьируется в зависимости от числа людей и числа месяцев (человеко-месяц), а длительность проекта — нет, т.к. люди и месяца не взаимозаменяемы
• Практически ни один проект невозможно завершить менее чем за 3/4 от рассчитанного оптимального графика, вне зависимости от числа привлеченных людей
• При написании ПО, в среднем, 1/3 уходит на планирование и проектирование, 1/6 — на написание кода, 1/4 — на тестирование компонентов, 1/4 — на тестирование всей системы в целом
• Большой ошибкой будет не выделять достаточное время на тестирование, т.к. сбои выявляются в конце графика, поэтому о проблеме можно не знать почти вплоть до даты поставки
• Добавление людей в проект требует увеличение общего объема трудозатрат на: 1) пересмотр и перераспределения работы; 2)обучения новых работников; 3) увеличение времени на коммуникации
• В большинстве случаев, если проект не укладывается в сроки, то добавление людей задержит его ещё больше
• Лучше иметь систему, в которой нет каких-то особенностей, но отражается один набор идей архитектурного дизайна (концептуальная целостность), чем иметь систему с кучей хороших, но независимых и несогласованных идей
• Концептуальная целостность требует, чтобы проект исходил от одного разработчика или их небольшого числа, действующих в унисон
• Для проекта важен набор документов (целевые критерии, спецификация, график и т.п.) — помимо возможности сообщить друг-другу решения, только когда пишешь, становятся видны недочёты и проступают несогласованности
• Исправление ошибки в ПО имеет существенный (20-50%) шанс привнести ещё одну ошибку
• При планировании надо ставить максимально четкие и недвусмысленные контрольные точки, чтобы не давать возможности участникам заниматься самообманом по поводу их достижения
• Лучшая документация — это хорошочитаемый код (хорошо оформленный, с комментариями, понятными названиями переменных и т.п.)

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

Ставлю 3 из 5 (по 10-балльной бы поставил 7), т.к., несмотря на достаточное количество умных мыслей, КПД книги не такой высокий. А может просто из-за того, что я не разработчик, я не осознал всю пользу книги. Желающим — читайте главу 2 (она дала название книги), а потом краткое изложение книги в главе 18. Далее уже можно выборочно почитать отдельные главы.