Фредерик Брукс Мифический человеко-месяц. Скачать краткое изложение

Фредерик Брукс - Мифический человеко-месяц

Фредерик Брукс — Мифический человеко-месяц

Фредерик Брукс Мифический человеко-месяц. Введение

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

Но очень много написано о том, что уже не актуально сегодня. Например, как вести проектную документацию таким образом, чтобы к ней был доступ у всех (сейчас это эелементарно решается с помощью, напрмиер, google docs). Так же очень долго обсуждается то, что все должны следить за тем, чтобы случайно не использовать чужой байт (или что смерти подобно — Килобайт) оперативной памяти, то же самое касается процессорного времени — сейчас это довольно смешно выглядит. Можно, конечно, байты сопоставить с мегабайтами, а килобайты с современными гигабайтами оперативной памяти, но даже в этом случае это не так критично, как было раньше.

В общем, для современной версии можно было бы прилично сократить объем книги. Здесь я опишу только те идеи, которые действительно важны для разработки ПО в любом виде, в любое время.

Начинается повествование с того, что программирование — одновременно и асфальтовая топь, поглощающая многие начинания, и творческая деятельность с присущими только ей радостями и горестями. В глазах многих ее радости значительно перевешивают все горести, и именно для них эта книга попытается проложить отдельные тропки через топь.

Программа и программный продукт

Программный продукт отличается от программы:

  • максимально обобщённым диапазоном и видом входных данных
  • тщательным тестированием, что является неожиданно сложным этапом
  • наличием подробной документации

Программный продукт требует в 3 раза больших затрат времени, чем программа.

Мифический человеко-месяц

Ложные предпосылки:

  • Все программисты — оптимисты. Поэтому они считают, что все будет идти по плану и ничего непредвиденного не случится. Как мы знаем — это не так.
  • Человеко-месяц — если проект может выполнить один человек за один месяц, то 4 программиста выполнят его за 1 неделю. Это так же неверно — ниже описано почему.

Время выполнения проекта не обратно пропорционально числу программистов, по крайней мере по 2 причинам:

  • В программировании, в отличие от, например, сбора хлопка, работа не может быть произвольно разделена на несколько независимых частей. Части проекта зависят друг от друга, и некоторые задачи можно начинать выполнять только после того, как будут закончены другие.
  • Программисты должны тратить часть времени на взаимодействие друг с другом.

Если есть N программистов, то количество пар программистов N(N-1)/2, то есть с ростом числа программистов затраты времени на взаимодействие растут квадратично. Поэтому начиная с какого-то N, рост числа программистов замедляет выполнение проекта.

Фредерик Брукс предлагает следующую схему для планирования разработки сложных проектов:

  • проектирование — 1/3
  • написание команд -1/6
  • отладка компонент и отдельных подсистем — 1/4
  • системная (комплексная) отладка всех компонент — 1/4

Т.е. непосредственно на программирование уходит всего 1/6 (!!!) времени, отведенного на проект. На мой взгляд (основываясь но собсвенном опыте), для современной веб-разработки можно немного упростить эту схему:

  • проектирование — 1/3
  • программирование -1/3
  • тестирование — 1/3

Если сроки сорваны, наём новых программистов замедляет выполнение проекта и по другой причине: новичкам требуется время на обучение. В книге сформулирован Закон Брукса:

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

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

Хирургические группы

Разумно, если в группе разработчиков есть один «хороший» программист, реализующий самые критические части системы, и несколько других, помогающих ему или реализующих менее критические части. Так делаются хирургические операции. Кроме того, по мнению Брукса, лучшие программисты работают в 5-10 раз быстрее остальных.

Так же обязательно должен быть «2-й пилот», который страхует проект, если главный хирург по каким-то причинам временно или насовсем выбывает из проекта. Это может быть менее опытный, но не менее талантливый программист.

Эффект второй системы

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

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

Концептуальная целостность

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

Простота очень важна; может быть полезным реализовать только часть возможностей, на которые способна система, потому что если система слишком сложна, часть её возможностей будут оставаться неиспользованными.

Главный архитектор должен сформулировать свои решения в виде руководства для пользователя.

Формальные документы

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

  1. Назначение. Какова основная функция программы, для чего она?
  2. Ситуация. На каких мшинах, в какой конфигурации и на какой операционной системе она будет работать?
  3. Область и сфера действия. Какова область входных данных? В каком диапазоне могут появиться выходные результаты?
  4. Реализуемые функции и используемые алгоритмы. Что именно она делает?
  5. Форматы ввода/вывода. Точные и полные.
  6. Рабочие процедуры, включая нормальное И аварийное окончание, описывают все, что видно с пульта и будет получено на выдачах. Комментарий: это, наверное, можно переформулировать для современного программирования так: «Должна быть защита от дурака».
  7. Варианты. Какие функции может выбирать пользователь? Как этот выбор определяется?
  8. Время исполнения. Сколько времени требует задача указанного объема при определенной конфигурации оборудования?
  9. Точность и проверка. Какова ожидаемая точность ответов? Каковы способы проверки точности?

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

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

Задача руководителя — разработать план, а затем реализовать его. Но только записанный план остается точным и коммуникабельным. План состоит из документов па темы: что, когда, сколько, где и кто? Это небольшое множество основных документов воплощает в себе большую часть работы руководителя. Если их важная и ответственная роль будет осознана с самого начала, то руководитель сможет подходить к ним как к полезным инструментам, а не как к тягостным обязанностям.

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

Взаимодействие

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

Пилотная система

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

Специализированные утилиты

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

Версии и замораживание системы

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

Снижение стоимости разработки

Брукс приводит 2 способа снизить стоимость разработки программного обеспечения:

  • Нанять программистов только после того, как построена архитектура системы. Иначе при длительности этой стадии, например, в несколько месяцев программистам будет нечего делать.
  • Купить часть программного обеспечения у других разработчиков.

Купите книгу

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

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

Поделиться в соц. сетях

Опубликовать в Google Plus
Опубликовать в Мой Мир
Опубликовать в Одноклассники

Об авторе Сергей Дегтярев

В данный момент развиваю собственную компанию по разработке сайтов и мобильных приложений. Более подробно расскажу позже...
Запись опубликована в рубрике Краткое изложение книг о бизнесе, Управление проектами с метками , . Добавьте в закладки постоянную ссылку.

Один комментарий: Фредерик Брукс Мифический человеко-месяц. Скачать краткое изложение

  1. Boris говорит:

    Хороший блог.Заценила. Я только новичек.

Комментарии запрещены.