Мифический человеко-месяц - The Mythical Man-Month

Мифический человеко-месяц
Мифический человеко-месяц (обложка) .jpg
Первое издание
АвторФредерик Брукс
ПредметПрограммного обеспечения управление проектом
ИздательЭддисон-Уэсли
Дата публикации
1975
ISBN0-201-00650-2 (Изд. 1975 г.), 0-201-83595-9 (изд. 1995 г.)
OCLC1201368
001.6/425
Класс LCQA76.6 .B75
С последующим"Нет серебряной пули " 

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

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

Редакции

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

Представленные идеи

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

Смотрите также: Комбинаторный взрыв

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

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

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

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

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

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

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

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

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

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

Основная статья: Эффект второй системы

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

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

Смотрите также: Heisenbug
99 мелких ошибок в коде.

99 маленьких ошибок.
Снимите один, залатайте его.

127 мелких ошибок в коде ...[3]

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

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

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

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

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

Руководство

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

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

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

Официальные документы

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

Оценка проекта

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

Коммуникация

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

Хирургическая бригада

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

Замораживание кода и управление версиями системы

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

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

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

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

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

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

Смотрите также

Библиография

Рекомендации

  1. ^ Рот, Дэниел (12 декабря 2005 г.). "Часто цитируется, редко преследуется". CNN. Получено 2010-10-23.
  2. ^ «Лучшие 9½ на книжной полке хакеров». Получено 2010-10-23.
  3. ^ Эта юмористическая песня по мотивам 99 бутылок пива присутствует на досках объявлений как минимум с 2000 года (Аноним (2000). "Цитаты о компьютерном программировании".)
  4. ^ Мифический месяц человека Рисунок 1.1, Страница 13

внешняя ссылка