Войти
 | |
| Автор | Фредерик Брукс |
|---|---|
| Тема | Программное обеспечение управление проектом |
| Издатель | Аддисон-Уэсли |
| Дата публикации | 1975, 1995 |
| ISBN | 0-201-00650-2 (изд. 1975), 0-201-83595-9 (изд. 1995 г.) |
| OCLC | 1201368 |
| Десятичное число Дьюи | 001,6 / 425 |
| Класс LC | QA76.6.B75 |
| Далее следует | "No Silver Bullet " |
The Mythical Man-Month: Essays on Software Engineering - книга по разработке программного обеспечения и управлению проектами, написанная Фредом Бруксом Впервые опубликовано в 1975 году, с последующими изданиями в 1982 и 1995 годах. Его центральная тема заключается в том, что «добавление рабочей силы в поздний программный проект делает его позже». Эта идея известна как закон Брукса и представлена вместе с эффектом второй системы и поддержкой прототипирования.
. Наблюдения Брукса основаны на его опыте в IBM при управлении разработкой OS / 360. Он добавил еще программистов к проекту, отставшему от графика, решение, которое он позже заключает, как ни странно, задержало проект еще больше. Он также совершил ошибку, утверждая, что один проект, связанный с написанием ALGOL компилятора, потребует шести месяцев, независимо от количества задействованных рабочих (это требовало больше времени). Склонность менеджеров повторять подобные ошибки при разработке проектов привела к тому, что Брукс заметил, что его книга называется «Библия программной инженерии», потому что «все ее цитируют, некоторые читают, а некоторые придерживаются ее». Книга считается классикой, посвященной человеческим элементам в разработке программного обеспечения.
Работа была впервые опубликована в 1975 году (ISBN 0-201-00650-2 ), переизданный с исправлениями в 1982 г. и переизданный в юбилейном издании с четырьмя дополнительными главами в 1995 г. (ISBN 0-201-83595-9 ), включая перепечатка эссе "No Silver Bullet " с комментариями тары автора.
Брукс обсуждает несколько причин сбоев планирования. Наиболее устойчивым является его обсуждение закона Брукса : Добавление рабочей силы в поздний программный проект делает это позже. Человеко-месяц - это гипотетическая единица работы, представляющая работу, выполненную одним человеком за один месяц; Закон Брукса гласит, что возможность измерения полезной работы в человеко-месяцах является мифом и, следовательно, центральным элементом книги.
Сложные проекты программирования не могут быть идеально разделены на отдельные задачи, над которыми можно работать без взаимодействия между рабочими и без установления набора сложных взаимосвязей между задачами и рабочими, выполняющими их.
Следовательно, если назначить больше программистов для проекта, который отстает от графика, это сделает это еще позже. Это связано с тем, что время, необходимое новым программистам, чтобы узнать о проекте, и увеличенные накладные расходы на коммуникацию потребуют постоянно увеличивающегося количества доступного календарного времени. Когда n человек вынуждены общаться между собой, по мере увеличения n их результативность уменьшается, а когда становится отрицательной, проект откладывается с каждым добавленным человеком.
Брукс добавил «Никакой серебряной пули - сущность и случайности разработки программного обеспечения» - и дальнейшие размышления об этом, «Нет серебряной пули» - к юбилейному выпуску «Мифического человека-месяца».
Брукс настаивает на том, что не существует одной серебряной пули - «не существует единой разработки ни в технологии, ни в технике управления, которая сама по себе обещает хотя бы один порядок [десятикратное] улучшение производительности, надежности и простоты за десять лет ».
Аргумент основан на различии между случайной сложностью и существенной сложностью, подобно тому, как закон Амдала основывается на различии между «строго последовательным» и «параллелизируемым».
Эффект второй системы предполагает, что когда архитектор проектирует вторую систему, это самая опасная система, которую он когда-либо проектировал, потому что они будут стремиться включать все дополнения, которые они изначально не добавляли в первую систему из-за внутренних ограничений по времени. Таким образом, приступая к разработке второй системы, инженер должен помнить, что он подвержен чрезмерной инженерии.
99 мелких ошибок.. Устраните одну, исправьте ее..
127 маленьких ошибок в коде...Автор отмечает, что в достаточно сложной системе существует определенное неснижаемое количество ошибок. Любая попытка исправить наблюдаемые ошибки обычно приводит к появлению других ошибок.
Брукс написал: «Вопрос: как крупный программный проект может опаздывать на год? Ответ: День за днем!» Дополнительные проскальзывания на многих фронтах в конечном итоге накапливаются, что приводит к большой общей задержке. На каждом уровне управления требуется постоянное внимание к достижению небольших индивидуальных вех.
Чтобы сделать систему удобной для пользователя, система должна иметь концептуальную целостность, которая может быть достигнута только путем отделения архитектуры от реализации. Один главный архитектор (или небольшое количество архитекторов), действуя от имени пользователя, решает, что входит в систему, а что остается. Архитектор или команда архитекторов должны разработать представление о том, что должна делать система, и убедиться, что это видение понимается остальной частью команды. Новую идею можно не включить, если она не вписывается в общий дизайн системы. Фактически, чтобы обеспечить удобство использования системы, она может сознательно предоставлять меньше функций, чем она способна. Дело в том, что если система слишком сложна для использования, многие функции останутся неиспользованными, потому что ни у кого нет времени на их изучение.
Главный архитектор выпускает руководство по системным спецификациям. Он должен подробно описывать внешние характеристики системы, то есть все, что видит пользователь. В руководство следует вносить изменения по мере поступления отзывов от групп внедрения и пользователей.
При разработке системы нового типа команда разработает систему выброса (намерена она этого или нет). Эта система действует как «пилотный план», который раскрывает методы, которые впоследствии приведут к полному изменению конструкции системы. Эту вторую, более умную систему следует доставить заказчику, поскольку поставка пилотной системы не вызовет ничего, кроме мучений у заказчика и, возможно, разрушит репутацию системы и, возможно, даже компании.
Каждый менеджер проекта должен создать небольшой базовый набор официальных документов, определяющих цели проекта, способы их достижения, кто будет их достигать, когда они собираются быть достигнутыми и сколько они будут стоить. Эти документы могут также обнаруживать несоответствия, которые иначе трудно увидеть.
При оценке сроков проекта следует помнить, что продукты для программирования (которые могут быть проданы платным клиентам) и системы программирования в три раза сложнее писать как простые независимые внутренние программы. Следует иметь в виду, какая часть рабочей недели будет фактически потрачена на технические вопросы, в отличие от административных или других нетехнических задач, таких как встречи, и особенно «стоячие» или «общие» встречи.
Чтобы избежать катастрофы, все команды, работающие над проектом, должны поддерживать связь друг с другом как можно большим количеством способов - по электронной почте, телефону, встречам, запискам и т. Д. Предполагая что-либо, разработчики должны попросить архитектора (-ов) разъяснить свое намерение в отношении реализуемой функции, прежде чем переходить к предположению, которое вполне может быть полностью неверным. Архитектор (ы) несут ответственность за формирование общей картины проекта и ее передачу другим.
Так же, как хирургическая бригада во время операции возглавляется одним хирургом, выполняющим наиболее критическую работу, в то же время направляя бригаду на помощь с менее важными частями, кажется разумным иметь «Хороший» программист разрабатывает важные системные компоненты, а остальная часть команды обеспечивает то, что необходимо, в нужное время. Вдобавок Брукс размышляет о том, что «хорошие» программисты обычно в пять-десять раз продуктивнее посредственных.
Программное обеспечение невидимо. Поэтому многие вещи становятся очевидными только после того, как в новой системе будет проделан определенный объем работы, что позволит пользователю испытать ее. Этот опыт позволит получить понимание, которое изменит потребности пользователя или восприятие потребностей пользователя. Следовательно, система должна быть изменена, чтобы соответствовать изменившимся требованиям пользователя. Это может произойти только до определенного момента, иначе система может никогда не быть завершена. В определенный момент в систему нельзя вносить больше изменений, и код следует заморозить. Все запросы на изменения следует отложить до следующей версии системы.
Вместо того, чтобы каждый программист имел свой собственный специальный набор инструментов, в каждой команде должен быть назначенный производитель инструментов, который может создавать инструменты, сильно адаптированные для работы, которую выполняет команда., например, инструмент генератора кода, который создает код на основе спецификации. Кроме того, общесистемные инструменты должны создаваться общей командой инструментов под контролем менеджера проекта.
Есть два метода снижения затрат на разработку программного обеспечения, о которых пишет Брукс:
 | В Викицитатнике есть цитаты, связанные с: Фредом Бруксом |
