Продолжаю обзор IT-классики, которая попала в мою коллекцию благодаря акции books.ru " Книги по свободной цене". На очереди вторая книга - по управлению проектами. Вслед за Джоэлом Спольски, я расскажу о книге Фредерика Брукса "Мифический человеко-месяц или как создаются программные системы".
Технико-тактические характеристики:
Технико-тактические характеристики:
Год издания: 2007 (Символ)
Страниц: 304
Скорость чтения - выше среднего
Время на прочтение: 6-8 часов
Полезность - высокая
Полезность - высокая
Это классическая книга по управлению проектами: первое издание книги вышло в 1975 году, общий тираж - более 250.000 экземпляров.
Книга состоит из 19 глав. Каждая глава - отдельный очерк, как и в книге Джоэла Спольски. Первые 7 глав описывают общие трудности, которые возникают при управлении программными проектами. Главы с 8 по 15 описывают различные аспекты управления проектами: объем работ, размер программы, внутреннюю документацию, первую версию, инструментарий, архитектуру, опоздания в проектах, пользовательскую документацию. В главе 16 Брукс утверждает, что "серебряной пули нет", и приводит доказательства. Эта глава вызвала споров больше, чем остальные главы книги вместе взятые. В книгу 1995 года добавлена глава 17, которая включает ответы Брукса на замеча ния критиков, и также уточняет взгляды к предыдущему изданию книги.
Несмотря на то, что каждая глава - отдельная статья, я рекомендую читать книгу от начала до конца. Книга Брукса не читается в один присест, но и не слишком сложная и заумная. Книга полезна и тестировщику, так как Брукс уделяет внимание и тестированию программного продукта, говорит о важности системного тестирования, независимой группы тестирования, плюс озвученные взгляды на формирование команды относятся и к команде тестировщиков (для тестировщиков-автоматизаторов, для ручных тестировщиков - все, кроме советов по программированию и архитектуре): например, методы оценок, аудит менеджмента Вавилонского проекта.
Чуть ниже - мой конспект книги. Замечу, что конспект Брукса - в главе 18, которую он добавил в издание 1995 года и в которой Брукс систематизировал взгляды из глав.
Книга состоит из 19 глав. Каждая глава - отдельный очерк, как и в книге Джоэла Спольски. Первые 7 глав описывают общие трудности, которые возникают при управлении программными проектами. Главы с 8 по 15 описывают различные аспекты управления проектами: объем работ, размер программы, внутреннюю документацию, первую версию, инструментарий, архитектуру, опоздания в проектах, пользовательскую документацию. В главе 16 Брукс утверждает, что "серебряной пули нет", и приводит доказательства. Эта глава вызвала споров больше, чем остальные главы книги вместе взятые. В книгу 1995 года добавлена глава 17, которая включает ответы Брукса на замеча ния критиков, и также уточняет взгляды к предыдущему изданию книги.
Несмотря на то, что каждая глава - отдельная статья, я рекомендую читать книгу от начала до конца. Книга Брукса не читается в один присест, но и не слишком сложная и заумная. Книга полезна и тестировщику, так как Брукс уделяет внимание и тестированию программного продукта, говорит о важности системного тестирования, независимой группы тестирования, плюс озвученные взгляды на формирование команды относятся и к команде тестировщиков (для тестировщиков-автоматизаторов, для ручных тестировщиков - все, кроме советов по программированию и архитектуре): например, методы оценок, аудит менеджмента Вавилонского проекта.
Чуть ниже - мой конспект книги. Замечу, что конспект Брукса - в главе 18, которую он добавил в издание 1995 года и в которой Брукс систематизировал взгляды из глав.
- Программный продукт (интерфейсы, системная интеграция) или программный комплекс (обобщение, тестирование, сопровождение, документация) стоит в 3 раза дороже автономной программы, а системный программный продукт - в 9 раз дороже.
- Программирование доставляет удовольствие, поскольку отвечает глубокой внутренней потребности в творчестве и удовлетворяет чувственные потребности, которые есть у всех нас.
- Печали программирования: необходима безошибочная точность действий, полномочия ниже ответственности, периоды однообразного и кропотливого труда, продукт может оказаться устаревшим в момент своего завершения.
- Программные проекты чаще проваливаются из- за нехват ки календарного времени, чем по всем остальным причи нам, вместе взятым.
- Причины провалов проектов из-за нехватки времени: слабо развиты методы оценок, методы оценки ошибочно путают достигну тый прогресс с затраченными усилиями, менеджеру недостает упрямства из-за неуверенности в оценках, выполнение графика работ слабо контролирует ся.
- В основе планирования разработки программ лежит ложное допущение, что все будет хорошо, т. е. каждая задача займет столько времени, сколько «должна» занять.
- Использование человеко-месяца как единицы измерения объема работы является опасным заблуждением (не учтены другие зависимости: разделимость задачи, обмен данными, обучение).
- Эмпирическое правило Брукса при планировании разработки ПО:
1/3 — планирование,
1/6 — написание программ,
1/4 — тестирование компонентов и предварительное систем
ное тестирование,
1/4 — системное тестирование при наличии всех компонентов. - Закон Брукса - Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше.
- Хорошие и плохие программисты очень сильно различаются между собой по производительности.
- Решение Миллза - на каждом участке работы была команда, организо ванная наподобие бригады хирургов, а не мясников: хирург, второй пилот, администратор, редактор, секретарь, делопроизводитель, инструментальщик, отладчик, языковед.
- Концептуальная целостность - важнейшая характеристика системного проекта.
- Для некоторого заданного уровня функциональности лучшей оказывается та система, в которой можно работать с наи большей простотой и непосредственностью.
- Блау: всю программу создания составляют три отдельные стадии: архитектура, разработка и реализация. Ока зывается, что на практике их можно начинать параллельно и продолжать одновременно.
- Получение архитектуры извне уси ливает, а не подавляет творческую активность группы исполни телей.
- Архитектору, когда он сталкивается с неприемлемо высо кой стоимостью, необходимо:
- Помнить, что ответственность за изобретательность и творче ство, проявляемые при реализации, несет строитель, поэтомуархитектор предлагает, а не требует.
- Всегда быть готовым предложить некоторый способ реализа ции своих замыслов и быть готовым согласиться с любым другим способом, позволяющим решить задачу не хуже.
- Выдвигая такие предложения, действовать без шума и огласки.
- Не рассчитывать на признательность за сделанные предло жения.
- Эффект второй системы архитектора
- Лучший друг менеджера проекта — его постоянный противник, независимая организация, тестирующая продукт. Каждой организации, ведущей разработки, нуж на такая независимая группа технического аудита, которая долж на быть неподкупна.
- Аудит менеджмента Вавилонского проекта. Было: ясность цели, человеческие ресурсы, материалы, достаточно времени, адекватные технологии. Не было: обмена информацией и вы текающей из него организации. Итог - fail.
- Обмен информацией между бригадами: неформально, совещания, рабочая тетрадь.
- Способы, позволяющие сократить обмен информацией, — разделение труда и специализация функций.
- Характеристики древовидной организации программистов, чтобы быть эффективной:
- задание,
- продюсер,
- технический директор или архитектор,
- график работ,
- разделение труда,
- определение интерфейсов между разными частями.
- Не люди должны быть втиснуты в чи сто теоретические организационные формы, а организация долж на строиться вокруг тех людей, которые есть.
- Объем работы = (константа) × (количество команд)1,5
- Планируйте выбросить первую версию — вам все равно придется это сделать. (Сейчас
я считаю его ошибочным — не в силу чрезмерного радикализма, но в силу чрезмерной упрощенности.) - Ссистемная отладка займет больше времени, чем предполагается, а ее сложность оправдывает досконально систематичный и плановый подход:
- используйте отлаженные компоненты (компонент готов к использованию в системной проверке, когда все его ошибки найдены, но необязательно уже исправлены),
- создайте больше окружений,
- контролируйте изменения ("фиолетовые провода),
- добавляйте компоненты по одной,
- квануйте изменения.
- Отставание, растущее понемногу изо дня в день, труднее рас познать, труднее предотвратить, труднее исправить.
- Верно то, что создание программных систем всегда будет труд ным. Серебряной пули нет по самой природе вещей.
- Верификация программ не означает создания программ, ли шенных ошибок. И здесь нет чудес. Математические доказатель ства тоже могут быть ошибочными. Поэтому хотя верификация может облегчить тестирование, она не может отменить его.
- за одинаковые сроки команда может нарастить значительно более сложный объект, чем построить.
- Практически ни один проект невозможно завершить быстрее, чем за 3/4 расчетного оптимального графика вне завиимости от количества занятых в нем.
Вывод. Книга must-read каждому тестировщику, не только для общей ИТ-грамотности и обращения к
"классике".Содержит общие взгляды на управление программными проектами, проверенные временем и на которые ссылаются многие современные авторы и докладчики. Автор уделяет внимание и роли тестирования. Читается достаточно легко, или последовательно, или отдельно по главам. Для повторного обращения к книге используйте конспект идей Брукса в главе 18.