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

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

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

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

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

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

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

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

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

Эта книга - юбилейное (дополненное и исправленное) издание своего рода библии для разработчиков программного обеспечения во всем мире, написанное Бруксом еще в 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
Ниже можно купить эту книгу по лучшей цене со скидкой с доставкой по всей России.

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

Вводимые термины в книге:

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

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

системный программный продукт — отвечает требованиям к программному комплексу, и программному продукту.

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

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

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

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

Два секретаря — Администратору и редактору нужны секретари. Секретарь администратора обрабатывает переписку, связанную с проектом, а также документы, не относящиеся к продукту.

Делопроизводитель — отвечает за регистрацию всех технических данных бригады в библиотеке программного продукта, превращение программирования «из личного искусства в общественную деятельность»

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

Отладчик — планирует последовательность тестирования и создание среды для тестирования компонентов.

Языковед — может найти эффективные способы использования языка для решения сложных, неясных и хитроумных задач. Иногда ему требуется провести небольшое исследование (два-три дня) для нахождения удачной технологии. Один языковед может работать с двумя или тремя хирургами.

Полезные цитаты из контекста:
Об удовольствии создания программ

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

про оценку времени выполнения задач

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

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

В-третьих, поскольку менеджеры программных проектов не уверены в своих оценках, им часто недостает вежливого упрямства, как у шеф-повара ресторана «Антуан».

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

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

1/3 - планирование,
1/6 - написание программ,
1/4 - тестирование компонентов и предварительное системное тестирование,
1/4 - системное тестирование при наличии всех компонентов.

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

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

Закон Брукса

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

Система 10

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

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

Оптимизация

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

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

Количество ошибок по времени внедрения

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

Концептуальные ошибки дороже, чем синтаксические . К.О.

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

Как растить выдающихся проектировщиков?

Систематически и как можно раньше выявлять первоклассных проектировщиков. Лучшие - не всегда самые опытные.

Назначить наставника, ответственного за рост перспективного проектировщика и тщательно следить за его карьерой.

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

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

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

Мне эта книга повстречалась очень вовремя. Я только что закончил ВУЗ и начал работать программистом. Вначале было очень трудно. Книг по IT тогда было мало. Эту книгу я читал в библиотеке, она была изрядно потрепана. И я поразился, сколько ценного она содержит. Советы Брукса очень помогли мне в начале карьеры. А особенно эта книга пригодилась, когда я сам стал руководить программистами.

Фредерикс Брукс работал в IBM и руководил созданием операционной системы System/360. На тот момент – это был самый крупный программный проект в мире. В процессе работы возникли неожиданные сложности. Брукс был наблюдательным человеком и сумел понять природу этих сложностей. Он сумел сформулировать основные принципы разработки ПО, которые отличают программирование от других отраслей производства.

Что же это за принципы?

Главный вывод, который он назвал законом Брукса гласит:

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

Этот закон обычно иллюстрируют так: “Даже если собрать девять женщин, то они не смогут родить ребенка за месяц”.

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

Метод Вирта

Согласно Бруксу лучший метод разработки ПО – это метод Никлауса Вирта, автора языка Паскаль.

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

Именно этот метод разработки программ я взял на вооружение и долгие годы он помогает мне писать программы более эффективно.

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

ООП – это болезнь

В этой книге я впервые прочитал критическое мнение о модной в те времена объектно-ориентированной технологии разработки программ.

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

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

Исправления портят программу

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

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

Гораздо лучше четко сформулировать требования к программе и реализовать их. Чтобы программа делала что-то одно, но делала это хорошо.

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

Производительность программистов различается в разы

Первый раз о том, что программисты имеют существенно разную производительность, я узнал из книги Брукса. Тогда я не поверил. Но жизнь полностью подтвердила это положение.

В одном из исследований Сакман (Sackman), Эриксон (Erikson) и Грант (Grant) измеряли производительность труда в группе опытных программистов. Внутри одной лишь этой группы соотношение между лучшими и худшими результатами составило примерно 10:1 по производительности труда и 5:1 по скорости работы программ и требуемой для них памяти! Короче, программист, зарабатывающий 20 тысяч долларов в год, может быть в десять раз продуктивнее программиста, зарабатывающего 10 тысяч долларов.

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

Серебряной пули нет

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

Конечно же, все идеи Брукса не перескажешь. Рекомендую к прочтению , чтобы не наступать на многие грабли.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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