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

9.13 Библиотеки программ должны иметь по две версии каждого компонента — быструю и компактную. (Похоже, что сегодня это устарело.)

9.14 Компактные и быстрые программы почти всегда являются результатом стратегического прорыва, а не тактической грамотности.

9.15 Таким прорывом часто является новый алгоритм.

9.16 Еще чаще прорыв происходит благодаря изменению представления данных или таблиц. Представление — сущность программирования.

Глава 10. Документарная гипотеза

10.1 Гипотеза: Среди моря бумаг несколько документов становятся критически важными осями, вокруг которых вращается все управление проектом. Они являются главными личными инструментами менеджера.

10.2 Для проекта разработки компьютера решающими документами являются цели, руководство, график, бюджет, организационная структура, план помещений, а также оценка, прогноз и цены для самой машины.

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

10.4 Для программного проекта требования те же: цели, руководство пользователя, внутренняя документация, график, бюджет, организационная структура и план помещений.

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

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

10.7 Сопровождение каждого важного документа требует наличия механизма слежения за состоянием и предупреждения.

10.8 Каждый документ в отдельности служит контрольным списком и базой данных.

10.9 Важнейшая задача менеджера — обеспечить общее движение в одном направлении.

10.10 Главная постоянная задача менеджера — общение, а не принятие решений; документы информируют всю команду о планах и решениях.

10.11 Только маленькая часть, возможно, 20 процентов, рабочего времени администратора занята задачами, которые требуют сведений, отсутствующих в его памяти.

10.12 По этой причине модная идея «всеохватывающей информационной системы для управления», обеспечивающей поддержку руководителя, основывается на неверной модели поведения руководителя.

Глава 11. Планируйте на выброс

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

11.2 Этот промежуточный шаг в равной мере необходим для программных продуктов, но для инженеров-программистов пока не стало обычной практикой проводить полевые испытания опытной системы, прежде чем начинать поставки готового продукта. (Сейчас это уже стало общей практикой благодаря выпуску бета-версий. Это не то же самое, что макет с ограниченной функциональностью, альфа-версия, которую я также пропагандирую.)

11.3 Для большинства проектов первую построенную версию едва можно использовать: слишком медленная, слишком большая, слишком сложная в применении, или все это вместе.

11.4 Отбросить и перепроектировать можно все сразу, а можно по частям, но все равно это придется сделать.

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

11.6 Поэтому планируйте выбросить первую версию — вам все равно придется это сделать.

11.7 «Программист поставляет удовлетворение потребности пользователя, а не какой-то осязаемый продукт» (Косгроув).

11.8 Как фактические потребности пользователя, так и понимание им своих потребностей меняются во время создания, тестирования и использования программы.

11.9 Податливость и неосязаемость программного продукта побуждают его создателей (исключительно) к вечному изменению требований.

11.10 Некоторые законные изменения в задачах (и стратегиях разработки) неизбежны, и лучше подготовиться к ним заранее, чем предполагать, что их не будет.

11.11 Способы проектирования системы с учетом будущих изменений, особенно структурное программирование с тщательным документированием интерфейсов модулей, хорошо известны, но не всегда применяются. Полезно также, где только можно, использовать технологии табличного управления. (Такая техника благодаря стоимости и размеру памяти в настоящее время применяется все более успешно.)