Мифический человеко-месяц . или Как создаются программные системы

англ. Frederick P. Brooks Jr.. The Mythical Man-Month · 1975
Краткое содержание книги
Читается за 30 минут, оригинал — 8 ч

Из чего состоит сложность

«Мифический человеко-месяц» был написан тогда, когда человечество и не мечтало о персональном компьютере в каждом доме. Книга приблизила эту возможность. Из 1960–1970-х неразличимы айфоны и беспроводная связь, однако принципы управления сложными проектами, которые сформулировал в те годы молодой ученый Фредерик Брукс, работавший тогда в передовой сфере кибернетики — создании OS/360 в IBM, — могут быть полезны и по сей день. Мы подготовили саммари этой замечательной книги с комментариями руководителя разработки Smart Reading Вячеслава Никулина.

В 1960–1970-е годы не существовало разнообразного готового инструментария удаленной коммуникации, совместной работы над макетами и документацией, систем ведения и контроля поставленных задач и использованных ресурсов. Хотя сейчас все эти технологии активно используются, процесс разработки и проектирования ПО только усложняется. ПО разрабатывается для многих прикладных сфер жизни, разные программы автоматизировано взаимодействуют друг с другом, ошибки в оценке трудозатрат на разработки таких систем имеют те же корни, что и 40 лет назад. 

Программа и программный продукт — не одно и то же. Программный продукт отличается от программы:

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

Создание программного продукта требует в три раза больше времени, чем программа. При этом программное обеспечение (ПО) — одно из самых сложных творений человека, и с этой сложностью нелегко совладать. Мощным стимулом для повышения продуктивности ПО было широкое использование языков высокого уровня (исследователи приписывают этому фактору пятикратный рост продуктивности ПО).

Свою роль сыграли и унифицированные среды программирования. И все-таки ПО можно упрощать лишь до определенного предела, который ставят четыре условия:

1) сложность (огромное количество программных конфигураций затрудняет их описание и тестирование);

2) подчиненность форме (интерфейсы создаваемого ПО должны подчиняться многообразию человеческих институтов и систем, для которых и создаются);

3) изменчивость (ПО функционально, а функциональность — то, что в наибольшей степени подвержено изменениям в связи с быстро меняющейся реальностью);

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

Объективные трудности, однако, можно минимизировать, если организовать создание ПО грамотно. Дело не в том, как работают компьютеры, а в людях.

Как организовать коллектив

Разоблачение человеко-часа

Главная причина, по которой провалилось большинство программных проектов, — нехватка времени.

  • Программистов губит оптимизм: поскольку их продукт создается не из глины или красок, но из чистых мысленных абстракций, они зачастую уверены, что в реализации проекта не будет больших трудностей. Между тем сами идеи бывают ошибочными, а это влечет ошибки в программах.
  • Мы путаем приложенные усилия и движение вперед. Ход выполнения работы не зависит от человеко-часов, люди и время не взаимозаменяемы.

Люди и месяцы взаимозаменяемы только тогда, когда не нужно выстраивать коммуникацию между сотрудниками. Сбор хлопка на полях? Идея человеко-часов работает. Создание ПО? Идея человеко-часов проваливается, потому что разные этапы этой работы взаимозависимы и программисты должны тратить время на взаимодействие друг с другом. Времени на наладку коммуникации всегда уходит больше, чем на усилия по сокращению времени выполнения отдельных этапов работы. Поэтому привнесение в проект новых сил на поздних стадиях разработки только отодвигает срок сдачи проекта (закон Брукса).

Брукс вывел правило для определения графика работ по сборке ПО.

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

Спустя 20 лет, в редакции 1995 года, Брукс указал на уязвимое место в этой схеме: если она реализуется линейно, накопление ошибок неизбежно и с увеличенным на отладку кода временем. В издании 1975 года Брукс настаивал на практике пилотной системы, которую программисты должны создать перед тем, как разработают окончательную модель. Пилот выявит ошибки в проектировании, а потом будет полностью отредактирован. За 20 лет подход к созданию программ изменился, и в 1995-м Брукс признает: принцип «Планируй выбросить!» не работает. Он указывает на преимущества инкрементной модели — поэтапной стратегии, когда разные части системы разрабатываются в разное время и разными темпами, а если одна часть готова, ее сразу интегрируют в систему. Но его базовый принцип остался неизменным: добавить рабочую силу в отстающий по графику проект — окончательно затормозить процесс.


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

Концептуальная целостность — ключевое условие проекта. Вспомним средневековые соборы Европы, которые строились десятилетиями, но сохранили стилистическое единство. К этому же должны стремиться разработчики ПО. Отличный пример концептуальной целостности — интерфейс WIMP (windows, icons, menus, pointers — окна, значки, меню, указатели), ныне известный каждому пользователю.

Продолжение — на Smart Reading
Зарегистрируйтесь на Smart Reading и получите доступ к этому и ещё 700 пересказам нонфикшен-книг. Все пересказы озвучены, их можно скачать и слушать фоном. Первые 7 дней доступа — бесплатно.

Понравился ли пересказ?

Ваши оценки помогают понять, какие пересказы написаны хорошо, а какие надо улучшить. Пожалуйста, оцените пересказ:

Читайте также