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

Автор: Фредерик Брукс
Оценка: 9 из 10

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

В этой книге замечательно объясняется почему при увеличении количества исполнителей, проект будет выполняться еще дольше. С какой скоростью растет количество ошибок при отладке программы. А самое главное, автор рассказывает на что нужно обратить внимание при оценки трудо- и время затрат при разработке проекта.

В течение ряда лет при планировании разработки программного обеспечения я пользуюсь следующим эмпирическим правилом:
1/3 — планирование,
1/6 — написание программ,
1/4 — тестирование компонентов и предварительное системное тестирование,
1/4 системное тестирование при наличии всех системных компонентов

Это правило имеет несколько важных различий с общепринятым планированием:
1. На планирование отводится больше времени, чем обычно. И все равно этого времени едва достаточно для разработки подробных и надежных технических условий и недостаточно для проведения исследовательских работ или поиска новейших технологий.
2. Половина графика работ, отведенная на отладку законченного кода, значительно выше нормы.
3. Та часть, которую легко оценить, т.е. написание кода, занимает всего одну шестую общего времени.
Изучая проекты, график которых был составлен традиционным образом, я обнаружил, что немногие из них отводили по графику половину времени на отладку, но на практике в большинстве случаев тратили на нее половину фактического времени. Многие проекты укладывались в график на всех этапах, исключая системное тестирование.
Особенно катастрофические последствия может иметь недостаток времени для системного тестирования. Поскольку задержка происходит в конечной части графика, никто не подозревает о том, что график находится под угрозой срыва вплоть до дня сдачи продукта. Плохие вести, полученные поздно и без предупреждения, обескураживают клиентов и менеджеров.
Более того, задержка на этом этапе имеет особенно тяжелые материальные и психологические последствия. Проект осуществляется при полной укомплектованности работниками и максимальных финансовых издержках. Что важнее, программное обеспечение должно обеспечить поддержку другой деловой активности (поставки компьютеров, запуска новых производственных мощностей и т.п.), и связанные с задержкой вторичные издержки очень высоки. На практике эти вторичные издержки могут быть выше, чем все прочие. Поэтому очень важно в изначальном графике работ отвести достаточно времени для системного тестирования.

Вы познакомитесь с законом Брукса и его доказательством:

Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше.

Узнаете как вести рабочую документацию так, чтобы все работники были в курсе этих изменений и четко понимали не только свой участок работы, но и работу все остальной команды, даже если в разработке участвует 2000 человек.

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

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

Эта книга далеко не художественная, а серьезная техническая, однако читается очень легко и приятно. Автор так все разложил по полочкам, что хочется невольно преклонить голову в знак благодарности.

Если вы работаете в команде, если вы ставите сроки тех или иных работ, если вам ставят сроки на выполнение тех или иных задач… то обязательно прочтите эту книгу.

Врезки