«Мифический человеко-месяц: очерки по разработке программного обеспечения» — это книга Фреда Брукса по разработке программного обеспечения и управлению проектами , впервые опубликованная в 1975 году, с последующими изданиями в 1982 и 1995 годах. Ее центральная тема — добавление рабочей силы в программный проект, который отстает от графика. задерживает его еще дольше. Эта идея известна как закон Брукса и представлена вместе с эффектом второй системы и пропагандой прототипирования .
Наблюдения Брукса основаны на его опыте работы в IBM , когда он руководил разработкой OS/360 . Он привлек новых программистов к проекту, который отставал от графика, и это решение, как он позже пришел к выводу, парадоксальным образом задержало проект еще больше. Он также допустил ошибку, утверждая, что один проект — по написанию компилятора АЛГОЛА — потребует шести месяцев, независимо от количества задействованных рабочих (а это требовало больше времени). Склонность менеджеров повторять такие ошибки при разработке проектов привела к тому, что Брукс пошутил, что его книга называется «Библия программной инженерии», потому что «все ее цитируют, некоторые читают, а некоторые следуют ей». [1]
Работа была впервые опубликована в 1975 году ( ISBN 0-201-00650-2 ), [2] переиздана с исправлениями в 1982 году и переиздана в юбилейном издании с четырьмя дополнительными главами в 1995 году ( ISBN 0-201-83595-9 ), включая перепечатку эссе « Нет серебряной пули » с комментариями автора.
Брукс обсуждает несколько причин неудач в планировании. Наиболее устойчивым является его обсуждение закона Брукса : добавление рабочей силы в запоздалый программный проект делает его позже . Человеко-месяц — гипотетическая единица работы, представляющая работу, выполняемую одним человеком за один месяц; Закон Брукса гласит, что возможность измерения полезного труда в человеко-месяцах является мифом и, следовательно, является центральной темой книги.
Сложные проекты программирования невозможно идеально разделить на отдельные задачи, над которыми можно работать без взаимодействия между работниками и без установления набора сложных взаимосвязей между задачами и выполняющими их работниками.
Таким образом, назначение большего количества программистов на проект, отстающий от графика, сделает его еще позже. Это связано с тем, что время, необходимое новым программистам для изучения проекта, и возросшие затраты на общение будут занимать все большее количество доступного календарного времени. Когда n людей должны общаться между собой, по мере увеличения n их производительность снижается, а когда она становится отрицательной, проект откладывается дальше с добавлением каждого человека.
Брукс добавил главу «Нет серебряной пули — суть и происшествия в разработке программного обеспечения» и дальнейшие размышления о ней в главе «Нет серебряной пули» в юбилейном выпуске « Мифического человеко-месяца» .
Брукс настаивает на том, что не существует одной серебряной пули : «не существует ни одной разработки ни в технологии, ни в технике управления, которая сама по себе обещает хотя бы на порядок [десятикратное] улучшение в течение десятилетия производительности, надежности и простоты».
Этот аргумент основан на различии между случайной сложностью и существенной сложностью, подобно тому, как закон Амдала опирается на различие между «параллелизуемым» и «строго серийным».
Эффект второй системы предполагает, что, когда архитектор проектирует вторую систему, это самая опасная система, которую он когда-либо проектировал, поскольку он будет иметь тенденцию включать все дополнения, которые он изначально не добавлял в первую систему из-за присущего времени. ограничения. Таким образом, приступая к созданию второй системы, инженер должен помнить, что он может перепроектировать ее.
Автор отмечает, что в достаточно сложной системе имеется определенное неуменьшаемое количество ошибок. Любая попытка исправить наблюдаемые ошибки имеет тенденцию приводить к появлению других ошибок.
Брукс написал: «Вопрос: как крупный программный проект может опоздать на год? Ответ: один день за раз!» Постепенное отставание по многим направлениям в конечном итоге накапливается, что приводит к большой общей задержке. На каждом уровне управления требуется постоянное внимание к достижению небольших отдельных этапов.
Чтобы сделать систему удобной для пользователя, она должна обладать концептуальной целостностью, чего можно достичь только путем отделения архитектуры от реализации. Один главный архитектор (или небольшое количество архитекторов), действуя от имени пользователя, решает, что входит в систему, а что остается вне ее. Архитектор или команда архитекторов должны разработать представление о том, что должна делать система, и убедиться, что это видение понятно остальной команде. Чья-то новая идея может быть не включена, если она не вписывается в общий дизайн системы. Фактически, чтобы обеспечить удобство использования системы, она может намеренно предоставлять меньше функций, чем она способна. Дело в том, что если система слишком сложна в использовании, многие функции останутся неиспользованными, потому что ни у кого нет времени на их изучение.
Главный архитектор составляет руководство по спецификациям системы. Он должен подробно описывать внешние характеристики системы, то есть все, что видит пользователь. Руководство следует изменять по мере поступления отзывов от групп внедрения и пользователей.
При разработке системы нового типа команда разрабатывает одноразовую систему (намеревается она это или нет). Эта система действует как «пилотный план», раскрывающий методы, которые впоследствии приведут к полной переработке системы. Эта вторая, более умная система должна быть доставлена заказчику, поскольку доставка пилотной системы не вызовет у заказчика ничего, кроме агонии, и, возможно, разрушит репутацию системы, а может быть, и компании.
Каждый менеджер проекта должен создать небольшой базовый набор официальных документов, определяющих цели проекта, способы их достижения, кто будет их достигать, когда они будут достигнуты и сколько они будут стоить. Эти документы также могут выявить несоответствия, которые иначе трудно увидеть.
При оценке времени проекта следует помнить, что программные продукты (которые можно продавать платящим клиентам) и системы программирования в три раза сложнее писать, чем простые независимые собственные программы. [3] Следует иметь в виду, какая часть рабочей недели фактически будет потрачена на технические вопросы, а не на административные или другие нетехнические задачи, такие как встречи, и особенно «стоячие» или «общие руки». "встречи.
Чтобы избежать катастрофы, все команды, работающие над проектом, должны поддерживать связь друг с другом как можно большим количеством способов (электронная почта, телефон, встречи, заметки и т. д.). Вместо того, чтобы что-то предполагать, разработчики должны попросить архитектора(ов) разъяснить свое намерение относительно реализуемой функции, прежде чем переходить к предположению, которое вполне может быть совершенно неверным. Архитектор(ы) несут ответственность за формулирование группового представления проекта и передачу его другим.
Подобно тому, как хирургическую бригаду во время операции возглавляет один хирург, выполняющий наиболее важную работу, а команда направляет помощь с менее важными частями, кажется разумным, чтобы «хороший» программист разрабатывал критические компоненты системы, в то время как остальная часть команды обеспечивала что нужно в нужный момент. Кроме того, Брукс размышляет о том, что «хорошие» программисты обычно в пять-десять раз продуктивнее посредственных.
Программное обеспечение невидимо. Таким образом, многие вещи становятся очевидными только после того, как над новой системой будет проделан определенный объем работы, что позволит пользователю испытать ее. Этот опыт даст понимание, которое изменит потребности пользователя или восприятие потребностей пользователя. Поэтому систему следует изменить, чтобы она соответствовала изменившимся требованиям пользователя. Это может происходить только до определенного момента, иначе система может никогда не быть завершена. К определенной дате в систему больше нельзя вносить изменения, а код следует заморозить. Все запросы на изменения следует отложить до следующей версии системы.
Вместо того, чтобы каждый программист имел свой собственный специальный набор инструментов, в каждой команде должен быть назначен назначенный разработчик инструментов, который может создавать инструменты, индивидуально адаптированные для работы, которую выполняет команда (например, инструмент-генератор кода, который создает код на основе спецификации). . Кроме того, общесистемные инструменты должны создаваться общей группой инструментов под контролем менеджера проекта.
Есть два метода снижения затрат на разработку программного обеспечения, о которых пишет Брукс:
