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

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

Первое издание
Автор	Фредерик Брукс
Предмет	Управление программными проектами
Издатель	Эддисон-Уэсли
Дата публикации	1975 г.
ISBN	0-201-00650-2 (изд. 1975 г.), 0-201-83595-9 (изд. 1995 г.)
OCLC	1201368
Десятичная дробь Дьюи	001,6 / 425
Класс LC	QA76.6 .B75
С последующим	" Нет серебряной пули "

«Мифический человеко-месяц: эссе по разработке программного обеспечения» - это книга Фреда Брукса по разработке программного обеспечения и управлению проектами ,впервые опубликованная в 1975 году с последующими выпусками в 1982 и 1995 годах. потом." Эта идея известна как закон Брукса и представлена ​​вместе с эффектом второй системы и пропагандой прототипирования .

Наблюдения Брукса основаны на его опыте в IBM, когда он руководил разработкой OS / 360 . Он добавил больше программистов в проект, отстававший от графика, решение, которое он позже заключает, как ни странно, задержало проект еще больше. Кроме того, он сделал ошибку, утверждая , что один проект, участие в написании ALGOL компилятора -would требуется шесть месяцев, независимо от количества работников , занятых (это требуется больше). Склонность менеджеров повторять такие ошибки при разработке проектов привела к тому, что Брукс язвительно заметил, что его книга называется «Библия программной инженерии», потому что «все ее цитируют, некоторые читают, а некоторые придерживаются ее». ^[1]Книга считается классикой, посвященной человеческим факторам в разработке программного обеспечения. ^[2]

Редакции [ править ]

Работа была впервые опубликована в 1975 году ( ISBN 0-201-00650-2 ), переиздана с исправлениями в 1982 году и переиздана в юбилейном издании с четырьмя дополнительными главами в 1995 году ( ISBN 0-201-83595-9 ), включая переиздание. эссе « Нет серебряной пули » с комментариями автора.  

Представленные идеи [ править ]

Мифический человеко-месяц [ править ]

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

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

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

• Формула группового взаимодействия: n ( n - 1) / 2
• Пример: 50 разработчиков дают 50 · (50 - 1) / 2 = 1225 каналов связи.

Нет серебряной пули [ править ]

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

Брукс настаивает на том, что не существует единой « серебряной пули» - «не существует единой разработки ни в технологии, ни в технике управления, которая сама по себе обещает хотя бы на один порядок [десятикратное] улучшение в течение десятилетия в производительности, надежности и простоте. "

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

Эффект второй системы [ править ]

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

Тенденция к неснижаемому количеству ошибок [ править ]

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

Отслеживание прогресса [ править ]

Брукс написал: «Вопрос: как крупный программный проект может опаздывать на один год? Ответ: Один день за раз!» Дополнительные проскальзывания на многих фронтах в конечном итоге накапливаются, что приводит к большой общей задержке. Постоянное внимание к достижению небольших индивидуальных этапов требуется на каждом уровне управления.

Концептуальная целостность [ править ]

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

Руководство [ править ]

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

Пилотная система [ править ]

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

Официальные документы [ править ]

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

Оценка проекта [ править ]

При оценке сроков проекта следует помнить, что программные продукты (которые могут быть проданы платежеспособным клиентам) и системы программирования в три раза сложнее написать, чем простые независимые внутренние программы. ^[4] Следует иметь в виду, какая часть рабочей недели будет фактически потрачена на технические вопросы, в отличие от административных или других нетехнических задач, таких как встречи, и особенно «стоячие» или «все руки». "встречи.

Связь [ править ]

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

Хирургическая бригада [ править ]

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

Заморозка кода и управление версиями системы [ править ]

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

Специализированные инструменты [ править ]

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

Снижение затрат на разработку программного обеспечения [ править ]

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

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

См. Также [ править ]

• Анти-шаблон
• Рефакторинг кода
• Peopleware: продуктивные проекты и команды
• Процесс разработки программного обеспечения
• Закон Хофштадтера

Библиография [ править ]

• - (1975). Мифический человеко-месяц . Эддисон-Уэсли. ISBN 0-201-00650-2.
• Брукс, Фредерик П. младший (сентябрь 1983 г.). «Мифический человеко-месяц» . Журнал ПК . 2 (4): 210–240.
• - (1995). «Глава 17».Refired "Нет серебряной пули" . Мифический месяц человека (юбилейное издание с четырьмя новыми главами под ред.). Эддисон-Уэсли. ISBN 0-201-83595-9.

Ссылки [ править ]

Внешние ссылки [ править ]

В Wikiquote есть цитаты, связанные с: Фредом Бруксом

• Домашняя страница Фредерика П. Брукса-младшего
• Предисловие к Первому изданию, которое можно найти на Safari.Informit.com
• Организация и шаблоны команд
• Обзор Гектора Корреа на главы «Мифический человеко-месяц» и «Нет серебряной пули - сущность и случайность»
• Выбранный ТЕКСТ из Мифического Человеческого Месяца