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

Продолжаю обзор IT-классики, которая попала в мою коллекцию благодаря акции books.ru "Книги по свободной цене". На очереди вторая книга - по управлению проектами. Вслед за Джоэлом Спольски, я расскажу о книге Фредерика Брукса "Мифический человеко-месяц или как создаются программные системы".

Технико-тактические характеристики:

Год издания: 2007 (Символ)

Страниц: 304

Скорость чтения - выше среднего

Время на прочтение:  6-8 часов
Полезность - высокая

Это классическая книга по управлению проектами: первое издание книги вышло в 1975 году, общий тираж - более 250.000 экземпляров.

Книга состоит из 19 глав. Каждая глава - отдельный очерк, как и в книге Джоэла Спольски. Первые 7 глав описывают общие трудности, которые возникают при управлении программными проектами. Главы с 8 по 15 описывают различные аспекты управления проектами: объем работ, размер программы, внутреннюю документацию, первую версию, инструментарий, архитектуру, опоздания в проектах, пользовательскую документацию. В главе 16 Брукс утверждает, что "серебряной пули нет", и приводит доказательства. Эта глава вызвала споров больше, чем остальные главы книги вместе взятые. В книгу 1995 года добавлена глава 17, которая включает ответы Брукса на замеча ния критиков, и также уточняет взгляды к предыдущему изданию книги.

Несмотря на то, что каждая глава - отдельная статья, я рекомендую читать книгу от начала до конца. Книга Брукса не читается в один присест, но и не слишком сложная и заумная. Книга полезна и тестировщику, так как Брукс уделяет внимание и тестированию программного продукта, говорит о важности системного тестирования, независимой группы тестирования, плюс озвученные взгляды на формирование команды относятся и к команде тестировщиков (для тестировщиков-автоматизаторов, для ручных тестировщиков - все, кроме советов по программированию и архитектуре): например, методы оценок, аудит менеджмента Вавилонского проекта.

Чуть ниже - мой конспект книги. Замечу, что конспект Брукса - в главе 18, которую он добавил в издание 1995 года и в которой Брукс систематизировал взгляды из глав.

1. Программный продукт (интерфейсы, системная интеграция) или программный комплекс (обобщение, тестирование, сопровождение, документация) стоит в 3 раза дороже автономной программы, а системный программный продукт - в 9 раз дороже.
2. Программирование доставляет удовольствие, поскольку отвечает глубокой внутренней потребности в творчестве и удовлетворяет чувственные потребности, которые есть у всех нас.
3. Печали программирования: необходима безошибочная точность действий, полномочия ниже ответственности, периоды однообразного и кропотливого труда, продукт может оказаться устаревшим в момент своего завершения.
4. Программные проекты чаще проваливаются из- за нехват ки календарного времени, чем по всем остальным причи нам, вместе взятым.
5. Причины провалов проектов из-за нехватки времени: слабо развиты методы оценок, методы оценки ошибочно путают достигну тый прогресс с затраченными усилиями, менеджеру недостает упрямства из-за неуверенности в оценках, выполнение графика работ слабо контролирует ся.
6. В основе планирования разработки программ лежит ложное допущение, что все будет хорошо, т. е. каждая задача займет столько времени, сколько «должна» занять.
7. Использование человеко-месяца как единицы измерения объема работы является опасным заблуждением (не учтены другие зависимости: разделимость задачи, обмен данными, обучение).
8. Эмпирическое правило Брукса при планировании разработки ПО:
   1/3 — планирование,
   1/6 — написание программ,
   1/4 — тестирование компонентов и предварительное систем
   ное тестирование,
   1/4 — системное тестирование при наличии всех компонентов.
9. Закон Брукса - Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше.
10. Хорошие и плохие программисты очень сильно различаются между собой по производительности.
11. Решение Миллза - на каждом участке работы была команда, организо ванная наподобие бригады хирургов, а не мясников: хирург, второй пилот, администратор, редактор, секретарь, делопроизводитель, инструментальщик, отладчик, языковед.
12. Концептуальная целостность - важнейшая характеристика системного проекта.
13. Для некоторого заданного уровня функциональности лучшей оказывается та система, в которой можно работать с наи большей простотой и непосредственностью.
14. Блау: всю программу создания составляют три отдельные стадии: архитектура, разработка и реализация. Ока зывается, что на практике их можно начинать параллельно и продолжать одновременно.
15. Получение архитектуры извне уси ливает, а не подавляет творческую активность группы исполни телей.
16. Архитектору, когда он сталкивается с неприемлемо высо кой стоимостью, необходимо:
    
    • Помнить, что ответственность за изобретательность и творче ство, проявляемые при реализации, несет строитель, поэтомуархитектор предлагает, а не требует.
    • Всегда быть готовым предложить некоторый способ реализа ции своих замыслов и быть готовым согласиться с любым другим способом, позволяющим решить задачу не хуже.
    • Выдвигая такие предложения, действовать без шума и огласки.
    • Не рассчитывать на признательность за сделанные предло жения.
17. Эффект второй системы архитектора
18. Лучший друг менеджера проекта — его постоянный противник, независимая организация, тестирующая продукт. Каждой организации, ведущей разработки, нуж на такая независимая группа технического аудита, которая долж на быть неподкупна.
19. Аудит менеджмента Вавилонского проекта. Было: ясность цели, человеческие ресурсы, материалы, достаточно времени, адекватные технологии. Не было: обмена информацией и вы текающей из него организации. Итог - fail.
20. Обмен информацией между бригадами: неформально, совещания, рабочая тетрадь.
21. Способы, позволяющие сократить обмен информацией, — разделение труда и специализация функций.
22. Характеристики древовидной организации программистов, чтобы быть эффективной:
    
    1. задание,
    2. продюсер,
    3. технический директор или архитектор,
    4. график работ,
    5. разделение труда,
    6. определение интерфейсов между разными частями.
23. Не люди должны быть втиснуты в чи сто теоретические организационные формы, а организация долж на строиться вокруг тех людей, которые есть.
24. Объем работы = (константа) × (количество команд)1,5
25. Планируйте выбросить первую версию — вам все равно придется это сделать. (Сейчас
    я считаю его ошибочным — не в силу чрезмерного радикализма, но в силу чрезмерной упрощенности.)
26. Ссистемная отладка займет больше времени, чем предполагается, а ее сложность оправдывает досконально систематичный и плановый подход:
    
    1. используйте отлаженные компоненты (компонент готов к использованию в системной проверке, когда все его ошибки найдены, но необязательно уже исправлены),
    2. создайте больше окружений,
    3. контролируйте изменения ("фиолетовые провода),
    4. добавляйте компоненты по одной,
    5. квануйте изменения.
27. Отставание, растущее понемногу изо дня в день, труднее рас познать, труднее предотвратить, труднее исправить.
28. Верно то, что создание программных систем всегда будет труд ным. Серебряной пули нет по самой природе вещей.
29. Верификация программ не означает создания программ, ли шенных ошибок. И здесь нет чудес. Математические доказатель ства тоже могут быть ошибочными. Поэтому хотя верификация может облегчить тестирование, она не может отменить его.
30. за одинаковые сроки команда может нарастить значительно более сложный объект, чем построить.
31. Практически ни один проект невозможно завершить быстрее, чем за 3/4 расчетного оптимального графика вне завиимости от количества занятых в нем.

Вывод. Книга must-read каждому тестировщику, не только для общей ИТ-грамотности и обращения к "классике".Содержит общие взгляды на управление программными проектами, проверенные временем и на которые ссылаются многие современные авторы и докладчики. Автор уделяет внимание и роли тестирования. Читается достаточно легко, или последовательно, или отдельно по главам. Для повторного обращения к книге используйте конспект идей Брукса в главе 18.