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

Вещи написаны в книге кажутся поверхностными и очевидными. Прописные истинны, а-ля "9 женщин не могут родить ребенка за месяц". Но. Я разработчик, и мне было забавно читать и понимать, что за последние пару лет я видел вживую в исполнении менеджмента буквально все ошибки, от которых пытается предостеречь автор. Хотя, это говорит скорее не о какой-от уникальной ценности информации в книге, а о качестве менеджмента. Книгу прочесть все-таки стоит, хотя бы из-за легендарной главы "Серебряной пули нет". А еще это неплохой экскурс в историю становления отрасли.

В книге автор резюмирует свой опыт в сфере разработки программного обеспечения, накопленный в том числе при разработке OS/360. Автор пишет о наиболее распространенных ошибках при разработке ПО, напротив, успешных методах, а также о своих взглядах на развитие программной инженерии. Может быть интересно всем, кто занимается разработкой или управлением в сфере IT.

За пять лет карьеры менеджера проектов я брался за эту книгу три раза. И только с четвертой попытки она покорилась мне.

Вообще, "Мифический человеко-месяц" Брукса считается библией IT-менеджера, но читать ее крайне тяжело.

Тут тебе и сложность языка и устаревание информации. Что не удивительно, ведь впервые книга была издана в 1975 году. Уууууу.... Привет, динозаааааавры!

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

Но все же ценность книги не в этом.

Брукс вынес на обсуждение…

Наконец-то я прочитал эту книгу. Прочитал в основном только потому, что многие мои знакомые разработчики часто спрашивали: "А ты читал Мифический человеко-месяц?" - обязательно прочитай, это классика.

Для меня чтение этой книги было в тягость, я не нашёл в ней совершенно ничего нового для себя и поставил оценку 1 из 5. Если бы меня спросили другие, стоит ли им читать, то я бы сказал следующее. Если вы только окончили институт (стали новоиспеченным инженером-программистом) и мало работали по специальности, то, возможно, книга окажется для вас полезной. Тот же, кто проработал по специальности уже несколько лет, прочитал нескольких других умных книг как по программированию, так и по управлению, и понимает, чем программа, написанная в гараже на коленках, отличается от полноценного…

Прочитал книгу, только потому, что многие люди просто без ума от неё и рассказывали с упоением, что это книга для них открыла "Америку". Книга написана в 70-х годах, дополнение представлено в виде пары новых глав которые были написаны в 80-х годах. В книге автор рассказывает о провале компании IBM в создание своей OS/360 и неправильном подходе в разработке. Автор писал её тогда, когда ещё не было ООП, всех современных языков программирования, грубо говоря даже персональных компьютером тогда ещё не было (преувеличиваю, персональные ПК уже были, но это было больше игрушкой для избранных, чем массовым пользовательским продуктом). Я уже молчу о методологиях разработки, о которых автор знать не мог ибо их тоже не было, когда была написана эта книга. Интереса книга не представляет ибо она не…

В нескольких пунктах: 1. Проекты чаще всего проваливаются из-за недостатка времени, чем по каким-либо другим причинам. 2. Добавление людей в проект на его поздних стадиях лишь замедлит процесс. 3. В зависимости от сложности проекта в человеко-месяцах приводится формула минимального времени выполнения, из которого следует и количество занятых в проекте. При более длительном выполнении проекта его стоимость медленно растет, при более коротком - растет стремительно. 4. В ближайшее время не будет технологий, способных на порядок увеличить скорость разработки. 5. Большой выигрыш в скорости разработки дает использование уже готовых модулей без погружения в их внутренности, но, к сожалению, большинство кода не готовится специально к повторному использованию, что делает его непригодным для…

Книга считается классической в управлении проектами, но лично я ничего качественно нового из нее не вынес. Закон Брукса - самое полезное, что ней, по всей видимости, есть. Также хочется добавить, что для восприятия довольно сложная вещь, так что для руководителей проектов не из числа бывших программистов читать будет тяжеловато.

Классика управления проектами разработки ПО.

На всю жизнь запомнил "Правило Брукса": добавление новых людей в проект не ускорит его окончание.

Второе издание известной книги о создании програмных систем. Первое издание было выпущено в 1975 г., но до сих пор актуально. Если вы программист или менеджер програмных проектов - то это книга из разряда Must read