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

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

Энциклопедичный YouTube

1 / 2

10 лучших книг по программированию

Как стать крутым программистом? Несколько советов!

Субтитры

История написания и изданий

Наблюдения Брукса основаны на его опыте работы в IBM , полученном в ходе управления проектом по созданию операционной системы OS/360 . Для ускорения разработки им была предпринята неудачная попытка привлечения большего числа работников к проекту, сроки по которому уже были сорваны. Заметив свойство менеджеров повторять такие ошибки, Брукс насмешливо называл свою книгу «библией для программной инженерии»: «все её читали, но никто ей не следует!»

Также Брукс утверждал, что написание компилятора языка Алгол потребует шести месяцев - независимо от количества людей, вовлечённых в проект.

Книга впервые была опубликована в 1975 году , тогда же она вышла и на русском языке. Повторно книга вышла в виде юбилейного издания в 1995-м, с дополнительными главами: эссе «Серебряной пули нет », опубликованном в 1986 г. (глава 16), пересмотром сказанного в этом эссе 10 лет спустя (глава 17) и комментариями автора к своей же книге через 20 лет после её первого издания (главы 18 и 19). В России второе издание было опубликовано издательством Символ-Плюс в 2000 году , ISBN 5-93286-005-7 .

Основные идеи

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Эта книга - юбилейное (дополненное и исправленное) издание своего рода библии для разработчиков программного обеспечения во всем мире, написанное Бруксом еще в 1975 году. Тогда же книга была издана на русском языке и давно уже стала библиографической редкостью. В США полагают, что без прочтения книги Брукса не может состояться ни один крупный руководитель программного проекта. Если вы никогда не слышали об этой книге, вы можете поискать ссылки на нее в Интернете (Frederick P. Brooks, The Mythical Man-Month). Вам все сразу станет понятно.

Содержание
Предисловие к изданию 1995 года
Предисловие к первому изданию
Глава 1. Смоляная яма
Глава 2. Этот мифический "человеко-месяц"
Глава 3. Операционная бригада
Глава 4. Аристократия, демократия и системное проектирование
Глава 5. Эффект второй системы
Глава 6. Донести слово
Глава 7. Почему не удалось построить Вавилонскую башню?
Глава 8. Объявляя удар
Глава 9. Два в одном
Глава 10. Документарная гипотеза
Глава 11. Планируйте на выброс
Глава 12. Острый инструмент
Глава 13. Целое и части
Глава 14. Назревание катастрофы
Глава 15. Обратная сторона
Глава 16. Серебряной пули нет - сущность и акциденция в программной инженерии
Глава 17. Новый выстрел "Серебряной пули нет"
Глава 18. Заявления "Мифического человеко-месяца": правда или ложь?
Глава 19. "Мифический человеко-месяц" двадцать лет спустя
Эпилог
Примечания и ссылки.

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

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

Бесплатно скачать электронную книгу в удобном формате, смотреть и читать:
Скачать книгу Мифический человеко - месяц или как создаются программные системы - Брукс Ф. - fileskachat.com, быстрое и бесплатное скачивание.

Скачать pdf
Ниже можно купить эту книгу по лучшей цене со скидкой с доставкой по всей России.

Краеугольный камень в основании профессии менеджера проектов.

Практически любой громкий эпитет тут не будет лишним. Книга как символ эпохи. Название и фамилия автора вписаны в историю развития информационных технологий аршинными буквами. На страницах «Мифического человеко-месяца» не только содержатся фундаментальные знания по управлению проектами, но и обобщается почти полувековой опыт разработки приложений в команде. Брукс был одним из первых, кого охватила своеобразная золотая лихорадка. Хотя он и предупреждал, что «серебряной пули нет», по его следам, в поисках Эльдорадо, все же последовали многие.

Концепция, проверенная временем. Феноменальный рост производительности в процессе разработки программного обеспечения – это не более чем миф. Пугающая в общем-то честность. Тем не менее идут годы, а исследователи продолжают «ломать копья» на эту тему. Главную роль в процессе разработки программного обеспечения Брукс отводит хорошим проектировщикам. После прочтения руководители поневоле задумаются: так ли необходимо экономить на аналитиках? Впрочем, главная цель исследования Брукса не в этом. «Мифический человеко-месяц», если угодно, призван закрепить за разработкой приложений статус творчества. Задача амбициозная, но, кажется, у Брукса действительно получилось ее выполнить. Новейшая научно-техническая революция служит тому доказательством.

Как ни крути, такую книгу мог написать только американец. Автор открыт для диалога. Последние главы, дополняющие первое издание, по сути, содержат всю мыслимую и немыслимую критику на закон Брукса. Без купюр. Надо сказать, что закон ее выдерживает, причем не без блеска. Автор дает комментарии на каждый выпад в его сторону, честно соглашаясь с оппонентами или твердо споря с ними. «Мифический человеко-месяц» остается незыблемым, как Стоунхендж или Египетские пирамиды.

Меняются методологии, появляются новые языки программирования, растет производительность аппаратного обеспечения, но книга продолжает оставаться актуальной. В чем секрет? Все просто: Брукс нашел нужную точку зрения. Разработка программного обеспечения – это не столько про технологии и инструменты, сколько про людей. Феноменальный рост IT-технологий породил массу иллюзий, заставив менеджеров проектов забыть про самое главное – своих сотрудников. Брукс вернул их на грешную землю.

Зачем и кому читать?
Проще ответить на вопрос кто не должен прочесть эту книгу. Не читать деспотам, чтобы продолжать травить команды. Не читать истерикам, чтобы продолжать жечь нервы и ресурсы. Не читать новичкам, чтобы оставаться «подающими надежды».

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

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

Основные тезисы книги

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

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

Закон Брукса : если проект не укладывается в сроки, то добавление рабочей силы задержит его ещё больше. Добавление рабочей силы увеличивает общий объём затрат тремя путями: труд по перекраиванию задач и происходящее при этом нарушение работы, обучение новых людей, дополнительное общение.

Команда проекта

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

Данные Портмана по ICL показывают, что занятые на полный рабочий день программисты только около 50 процентов времени занимаются программированием и отладкой, а остальное время занимают разные дополнительные задачи.

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

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

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

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

Архитектура информационной системы

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

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

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

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

На всём протяжении реализации системные архитекторы должны постоянно проявлять бдительность с целью непрерывного обеспечения целостности системы.

Сопровождение информационной системы

Программному продукту грозит устаревание ещё до его завершения. Если систему не развивать, она морально устаревает.

Все исправления имеют тенденцию к разрушению структуры, увеличению энтропии и дезорганизации системы. Даже самое искусное сопровождение программы только отдаляет момент повержения её в состояние неисправимого хаоса, выходом из которого является повторное проектирование с самого начала.

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

Исправление одной ошибки с большой вероятностью (от 20 до 50 процентов) вносит другую. (из-за того, что во время сопровождения теряется архитектура).

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

«Мифический человеко-месяц или Как создаются программные системы» - книга Фредерика Брукса об управлении проектами в области разработки программного обеспечения , центральной темой которой стало то, что привнесение в проект новых сил на поздних стадиях разработки лишь отодвигает срок сдачи проекта. Эта идея стала известна под названием «закон Брукса». Книга была впервые опубликована в году, тогда же она вышла и на русском языке. Повторно книга вышла в виде юбилейного издания в 1995-ом, вместе с комментариями автора и новым эссе «Серебряной пули нет ». В России второе издание было опубликовано издательством Символ-Плюс, ISBN 5-93286-005-7 .

Наблюдения Брукса основаны на его опыте работы в IBM , полученном в ходе управления проектом по созданию операционной системы OS/360. Для ускорения разработки им была предпринята неудачная попытка привлечения большего числа работников к проекту, сроки по которому уже были сорваны. Заметив свойство менеджеров повторять такие ошибки, Брукс насмешливо называл свою книгу «библией для программной инженерии»: «все её читали, но никто ей не следует!»

Также Брукс утверждал, что написание компилятора языка Алгол потребует шести месяцев - независимо от количества людей, вовлечённых в проект.

Основные идеи

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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