Мифический человеко-месяц
 Первое издание | |
| Автор | Фред Брукс |
|---|---|
| Язык | Английский |
| Предмет | программными проектами Управление |
| Издатель | Аддисон-Уэсли |
Дата публикации | 1975 |
| Место публикации | Соединенные Штаты |
| ISBN | 978-0-201-00650-6 (изд. 1975 г.), 978-0-201-83595-3 (изд. 1995 г.) |
| 001.6/425 | |
| Класс ЛК | QA76.6 .B75 |
«Мифический человеко-месяц: очерки по разработке программного обеспечения» — это книга Фреда Брукса по обеспечения и управлению проектами разработке программного , впервые опубликованная в 1975 году, с последующими изданиями в 1982 и 1995 годах. Ее центральная тема — добавление рабочей силы в программный проект, который отстает от графика. задерживает его еще дольше. Эта идея известна как закон Брукса и представлена вместе с эффектом второй системы и пропагандой прототипирования .
Наблюдения Брукса основаны на его опыте работы в IBM , когда он руководил разработкой OS/360 . Он привлек новых программистов к проекту, который отставал от графика, и это решение, как он позже пришел к выводу, как ни странно, задержало проект еще больше. Он также допустил ошибку, утверждая, что один проект — по написанию АЛГОЛА компилятора — потребует шести месяцев, независимо от количества задействованных рабочих (а это требовало больше времени). Склонность менеджеров повторять такие ошибки при разработке проектов привела к тому, что Брукс пошутил, что его книга называется «Библия программной инженерии», потому что «все ее цитируют, некоторые читают, а некоторые следуют ей». [1]
Издания
[ редактировать ]Впервые работа была опубликована в 1975 году ( ISBN 0-201-00650-2 ), [2] переиздано с исправлениями в 1982 году и переиздано в юбилейном издании с четырьмя дополнительными главами в 1995 году ( ISBN 0-201-83595-9 ), включая переиздание эссе « Нет серебряной пули » с комментариями автора.
Представленные идеи
[ редактировать ]Мифический человеко-месяц
[ редактировать ]Брукс обсуждает несколько причин неудач в планировании. Наиболее устойчивым является его обсуждение закона Брукса : Добавление рабочей силы в запоздалый программный проект делает его позже . Человеко-месяц — гипотетическая единица работы, представляющая работу, выполняемую одним человеком за один месяц; Закон Брукса гласит, что возможность измерения полезного труда в человеко-месяцах является мифом и, следовательно, является центральной темой книги.
Сложные проекты программирования невозможно идеально разделить на отдельные задачи, над которыми можно работать без взаимодействия между работниками и без установления набора сложных взаимосвязей между задачами и выполняющими их работниками.
Таким образом, назначение большего количества программистов на проект, отстающий от графика, сделает его еще позже. Это связано с тем, что время, необходимое новым программистам для изучения проекта, и возросшие затраты на общение будут занимать все большее количество доступного календарного времени. Когда n людей должны общаться между собой, по мере увеличения n их производительность снижается, а когда она становится отрицательной, проект откладывается дальше с добавлением каждого человека.
- Формула группового общения: n ( n − 1)/2.
- Пример: 50 разработчиков дают 50 × (50 – 1)/2 = 1225 каналов коммуникации.
Нет серебряной пули
[ редактировать ]Брукс добавил главу «Нет серебряной пули — суть и происшествия в разработке программного обеспечения» и дальнейшие размышления о ней в главе «Нет серебряной пули» в юбилейном выпуске « Мифического человеко-месяца» .
Брукс настаивает на том, что не существует одной серебряной пули : «не существует ни одной разработки ни в технологии, ни в технике управления, которая сама по себе обещает хотя бы на порядок [десятикратное] улучшение в течение десятилетия производительности, надежности и простоты».
Этот аргумент опирается на различие между случайной сложностью и существенной сложностью, подобно тому, как закон Амдала опирается на различие между «параллелизуемым» и «строго серийным».
Эффект второй системы
[ редактировать ]Эффект второй системы предполагает, что, когда архитектор проектирует вторую систему, это самая опасная система, которую он когда-либо проектировал, поскольку он будет иметь тенденцию включать все дополнения, которые он изначально не добавлял в первую систему из-за присущего времени. ограничения. Таким образом, приступая к созданию второй системы, инженер должен помнить, что он может перепроектировать ее.
Тенденция к неуменьшаемому количеству ошибок
[ редактировать ]Автор отмечает, что в достаточно сложной системе существует определенное неуменьшаемое количество ошибок. Любая попытка исправить наблюдаемые ошибки имеет тенденцию приводить к появлению других ошибок.
Отслеживание прогресса
[ редактировать ]Брукс написал: «Вопрос: как крупный программный проект может опоздать на год? Ответ: по одному дню за раз!» Постепенное отставание по многим направлениям в конечном итоге накапливается, что приводит к большой общей задержке. На каждом уровне управления требуется постоянное внимание к достижению небольших отдельных этапов.
Концептуальная целостность
[ редактировать ]Чтобы сделать систему удобной для пользователя, она должна обладать концептуальной целостностью, чего можно достичь только путем отделения архитектуры от реализации. Один главный архитектор (или небольшое количество архитекторов), действуя от имени пользователя, решает, что входит в систему, а что остается вне ее. Архитектор или команда архитекторов должны разработать представление о том, что должна делать система, и убедиться, что это видение понятно остальной команде. Чья-то новая идея может быть не включена, если она не вписывается в общий дизайн системы. Фактически, чтобы обеспечить удобство использования системы, она может намеренно предоставлять меньше функций, чем она способна. Дело в том, что если система слишком сложна в использовании, многие функции останутся неиспользованными, потому что ни у кого нет времени на их изучение.
Руководство
[ редактировать ]Главный архитектор составляет руководство по спецификациям системы. Он должен подробно описывать внешние характеристики системы, то есть все, что видит пользователь. Руководство следует изменять по мере поступления отзывов от групп внедрения и пользователей.
Пилотная система
[ редактировать ]При разработке системы нового типа команда разрабатывает одноразовую систему (намеревается она это или нет). Эта система действует как «пилотный план», раскрывающий методы, которые впоследствии приведут к полной переработке системы. Эта вторая, более умная система должна быть доставлена заказчику, поскольку доставка пилотной системы не вызовет у заказчика ничего, кроме агонии, и, возможно, разрушит репутацию системы, а может быть, и компании.
Официальные документы
[ редактировать ]Каждый руководитель проекта должен создать небольшой базовый набор формальных документов, определяющих цели проекта, способы их достижения, кто будет их достигать, когда они будут достигнуты и сколько они будут стоить. Эти документы также могут выявить несоответствия, которые иначе трудно увидеть.
Оценка проекта
[ редактировать ]При оценке времени проекта следует помнить, что программные продукты (которые можно продавать платящим клиентам) и системы программирования в три раза сложнее писать, чем простые независимые собственные программы. [3] Следует иметь в виду, какая часть рабочей недели фактически будет потрачена на технические вопросы, а не на административные или другие нетехнические задачи, такие как собрания, особенно «стоячие» или «общие» собрания.
Коммуникация
[ редактировать ]Чтобы избежать катастрофы, все команды, работающие над проектом, должны поддерживать связь друг с другом как можно большим количеством способов (электронная почта, телефон, встречи, заметки и т. д.). Вместо того, чтобы что-то предполагать, разработчики должны попросить архитектора(ов) разъяснить свое намерение относительно реализуемой функции, прежде чем переходить к предположению, которое вполне может быть совершенно неверным. Архитектор(ы) несут ответственность за формулирование группового представления проекта и передачу его другим.
Хирургическая бригада
[ редактировать ]Подобно тому, как хирургическую бригаду во время операции возглавляет один хирург, выполняющий наиболее важную работу, а команда направляет помощь с менее важными частями, кажется разумным, чтобы «хороший» программист разрабатывал критические компоненты системы, в то время как остальная часть команды обеспечивала что нужно в нужный момент. Кроме того, Брукс размышляет о том, что «хорошие» программисты обычно в пять-десять раз продуктивнее посредственных.
Замораживание кода и управление версиями системы
[ редактировать ]Программное обеспечение невидимо. Таким образом, многие вещи становятся очевидными только после того, как над новой системой будет проделан определенный объем работы, что позволит пользователю испытать ее. Этот опыт даст понимание, которое изменит потребности пользователя или восприятие потребностей пользователя. Поэтому систему следует изменить, чтобы она соответствовала изменившимся требованиям пользователя. Это может происходить только до определенного момента, иначе система может никогда не быть завершена. К определенной дате в систему больше нельзя вносить изменения, а код следует заморозить. Все запросы на изменения следует отложить до следующей версии системы.
Специализированные инструменты
[ редактировать ]Вместо того, чтобы у каждого программиста был свой собственный специальный набор инструментов, в каждой команде должен быть назначен назначенный разработчик инструментов, который может создавать инструменты, индивидуально адаптированные для работы, которую выполняет команда (например, инструмент-генератор кода, который создает код на основе спецификации). . Кроме того, общесистемные инструменты должны создаваться общей командой разработчиков инструментов под контролем менеджера проекта.
Снижение затрат на разработку программного обеспечения
[ редактировать ]Есть два метода снижения затрат на разработку программного обеспечения, о которых пишет Брукс:
- Нанимать исполнителей можно только после того, как архитектура системы будет завершена (этап, который может занять несколько месяцев, в течение которых преждевременно нанятым исполнителям может нечего делать).
- Другой метод, о котором упоминает Брукс, заключается в том, чтобы вообще не разрабатывать программное обеспечение, а просто покупать его « с полки », когда это возможно.
См. также
[ редактировать ]- Антипаттерн
- Рефакторинг кода
- Закон Конвея
- Закон Хофштадтера
- Закон Линуса , утверждение, что «при достаточном количестве глаз все насекомые мелкие», как описано в «Соборе и базаре».
- Peopleware: продуктивные проекты и команды
- Процесс разработки программного обеспечения
Библиография
[ редактировать ]- Брукс, Фредерик П. (1975). Мифический человеко-месяц . Аддисон-Уэсли. ISBN 0-201-00650-2 .
- Брукс, Фредерик П. (1983). «Мифический человеко-месяц» . Журнал ПК . 2 (4): 210–240.
- Брукс, Фредерик П. (1995). «Глава 17. Повторный выпуск« серебряной пули »». Мифический человеко-месяц (юбилейное изд.). Аддисон-Уэсли. ISBN 0-201-83595-9 .
Ссылки
[ редактировать ]- ^ Рот, Дэниел (12 декабря 2005 г.). «Часто цитируют, редко читают» . CNN . Проверено 23 октября 2010 г.
- ^ Брукс, Фредерик П. младший (1975). Мифический человеко-месяц: Очерки по разработке программного обеспечения (PDF) . Издательская компания Аддисон-Уэсли . ISBN 0-201-00650-2 . Проверено 10 декабря 2022 г.
- ^ Мифический человеко-месяц , рисунок 1.1, стр. 13
Внешние ссылки
[ редактировать ]
- Официальный сайт Университета Северной Каролины, Чапел-Хилл
- Структура организации и команды
- Рецензия Гектора Корреа на главы «Мифический человеко-месяц» и «Нет серебряной пули – суть и случайность»
- Выбранный текст из «Мифического человеко-месяца»
| Компьютер проект управление |
|  | ||||
|---|---|---|---|---|---|---|
