Глава 2. Мифический человеко-месяц
2.1 Программные проекты чаще проваливаются из-за нехватки календарного времени, чем по всем остальным причинам, вместе взятым.
2.2 Чтобы приготовить вкусную пищу, нужно время; некоторые задачи нельзя ускорить, не испортив результат.
2.3 Все программисты являются оптимистами: "Все будет хорошо".
2.4 Поскольку программист работает с чистыми идеями, мы не ожидаем особых трудностей при реализации.
2.5 Но сами наши идеи бывают ошибочными - отсюда и ошибки в программах.
2.6 Наши методы оценивания, основанные на учете затрат, смешивают затраты с полученным результатом. Человеко-месяц является ошибочным и опасным заблуждением, поскольку предполагает, что месяцы и количество людей можно менять местами.
2.7 Разделение задачи между несколькими людьми вызывает дополнительные затраты на обучение и обмен информацией.
2.8 Мое практическое правило: 1/3 времени - на проектирование, 1/6 - на написание программы, 1/4 - на тестирование компонентов и 1/4 - на системное тестирование.
2.9 Как научной дисциплине нам не хватает методов оценки.
2.10 Поскольку мы не уверены в своих оценках сроков работы, нам часто не достает смелости упрямо отстаивать их под нажимом руководства и клиентов.
2.11 Закон Брукса: если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше.
2.12 Добавление рабочей силы увеличивает общий объем затрат тремя путями: труд по перекраиванию задач и происходящее при этом нарушение работы, обучение новых людей, дополнительное общение.
Глава 3. Операционная бригада
3.1 Самые лучшие программисты-профессионалы в 10 раз продуктивнее слабых при равной подготовке и двухлетнем стаже (Сакман, Грант и Эриксон).
3.2 Данные Сакмана, Гранта и Эриксона не выявили корреляции между опытом и продуктивностью. Я думаю, что это всегда так.
3.3 Лучше всего иметь маленькую активную команду - как можно меньше мыслителей.
3.4 Часто лучше всего, если команда состоит из двух человек, один из которых является лидером. (Обратите внимание, как Богом задуман брак.)
3.5 Для создания действительно крупных систем маленькая активная команда работает слишком медленно.
3.6 Опыт разработки большинства действительно больших систем показывает, что подход к ускорению с позиций грубой силы оказывается дорогостоящим, медленным, неэффективным и приводит к появлению систем, не являющихся концептуально целостными.
3.7 Организация по типу хирургических бригад с главным программистом предлагает способ достижения целостности продукта благодаря его проектированию в нескольких головах и общей продуктивности благодаря наличию многочисленных помощников при радикально сокращенном обмене информацией.
Глава 4. Аристократия, демократия и системное проектирование
4.1 "Концептуальная целостность является наиболее важным соображением при проектировании систем."
4.2 "Окончательную оценку проекту системы дает отношение функциональности к сложности концепций", а не только богатство функций.