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

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

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

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

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

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

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

После прочтения, создалось стойкое ощущение, книга устарела не только физически, но и морально. Она возможно и была актуальна на просторах бывшего СССР в конце 20 начале 21 века, когда для стран бывшего СССР, снова открывался этот о дивный, чудный мир IT. Но не позже. Восторг от этой книге может вызвать только у человека который впервые увидел аббревиатуру IT. Все вещи о которых рассказывает автор очевиднее не куда. Всегда необходимо учитывать риски, увеличивать сроки, выделять больше бюджет, и не бояться брать новых сотрудников при этом тратя время на их обучение. А не искать несуществующих "специалистов" с нереальными требованиями, которые божественным чудом должны появится на проекте и сразу всё будет хорошо.

В конце книги идёт краткая ужимка в виде избранных фраз по главам, из целой книги. Саму книгу можно охарактеризовать одной фразой: "Лучше перебздеть,чем недобздеть и мучатся!" Если уж так сильно хочется её прочитать, начните сразу с последней страницы.

Достаточно тяжёлая книга для восприятия, хотя есть моменты, которые привели к некоторому просветлению. Закон Брукса!

Наверно это настолько классика, что почти ничего нового я в этой книжке не нашел. И, кажется, так и не дочитал.. Что, впрочем не умаляет ее достоинств. Если ищете с чего начать путь в IT менеджмент - прочитайте. Для начала - самое оно.

Классика

Must read

"Считается" классикой -- подозреваю, что в основном среди программистов, мечтающих стать менеджерами.