10,49 €
Mehr erfahren.
- Herausgeber: Питер
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Russisch
- Veröffentlichungsjahr: 2023
Немногие книги по управлению проектами можно назвать столь же значимыми, как «Мифический человеко-месяц». Смешение примеров из реальной разработки ПО, мнений и размышлений создает яркую картину управления сложными проектами. Эти эссе основаны на пятидесятилетнем опыте работы Брукса менеджером проектов в IBM System/360, а затем в OS/360. Первое издание книги вышло 45 лет назад, второе - 25 лет назад. Возникают новые методологии, появляются новые языки программирования, растет количество процессоров, но эта книга продолжает оставаться актуальной. Почему? Спустя полвека мы продолжаем повторять ошибки, которые описал Брукс. Некоторые темы, поднимаемые в книге, кажутся устаревшими, но это лишь видимость. Фундаментальные проблемы, стоящие за ними, все так же актуальны в наше время. Важно знать свое прошлое, чтобы понимать, куда развивается индустрия разработки программного обеспечения. Поэтому спустя 45 лет мы и читаем Брукса. Многое изменилось в мире, но девять женщин все так же не могут выносить ребенка за один месяц. ;)
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 322
Ähnliche
Научный редактор Д. Мамонов
Переводчик А. Логунов
Художник В. Мостипан
Корректоры Н. Викторова, Н. Сидорова
Фредерик Брукс
Мифический человеко-месяц, или Как создаются программные системы. — СПб.: Питер, 2020.
ISBN 978-5-4461-1636-2
© ООО Издательство "Питер", 2020
Все права защищены. Никакая часть данной книги не может быть воспроизведена в какой бы то ни было форме без письменного разрешения владельцев авторских прав.
Оглавление
Об авторе
Фредерик Брукс © Jerry Markatos
Фредерик П. Брукс-младший — Кенановский профессор информатики Университета Северной Каролины в Чапел-Хилле. Наиболее известен как «отец компьютера IBM System/360», работал менеджером проекта по его разработке, а затем менеджером проекта OS/360 в IBM.
За эту работу в 1985 году он, Боб Эванс и Эрих Блох были награждены Национальной медалью США в области технологий и инноваций. Ранее был архитектором компьютеров IBM Stretch и Harvest.
В Чапел-Хилле доктор Брукс основал отдел информатики и возглавлял его с 1964 по 1984 год. Служил в Национальном научном совете и Научном совете Министерства обороны США.
Предисловие научного редактора к русскому изданию 2020 года
Дмитрий Мамонов,
Chief Architect, Wrike
Сколько битов в байте? Восемь.
Но так было не всегда. Ни общего термина байт, ни стандарта «8-бит» в 1960-х еще не было. Книга «Мифический человеко-месяц», которую вы держите в руках, была написана Фредериком Бруксом как попытка анализа и систематизации его опыта руководства в проекте IBM System/360, грандиозный коммерческий успех которого кардинально изменил всю компьютерную индустрию своего времени и, в частности, привел к формированию единого стандарта кодирования информации — байту.
Эту книгу стоит прочитать для понимания истории развития индустрии разработки программного обеспечения, но и не только поэтому. Брукс одним из первых столкнулся с трудностями разработки больших программных проектов. Да, за прошедшие с первого издания книги 45 лет в разработке произошли качественные изменения во всем, начиная от производительности компьютеров и заканчивая подходами к организации разработки, тем не менее темы, которые поднимаются в этой книге, все еще актуальны и стоят того, чтобы над ними задуматься.
Для своего времени операционная система OS/360, о которой говорит Брукс, разрабатываемая в рамках проекта System/360, была, наверное, так же широко известна среди специалистов, как сейчас Linux. Отсылки к ней не требовали отдельных пояснений. Но с тех пор сменилось уже много поколений операционных систем, и для лучшего понимания событий, описываемых в книге, стоит напомнить ключевые детали, связанные с историей этого проекта.
Краткая история разработки System/360
В начале 1960-х корпорация IBM была абсолютным лидером рынка компьютеров. Ее доля составляла 75 %. Однако перспективы становились все менее радужными. Абсолютно все системы IBM были несовместимы между собой. Серии 1401, 1620, 7070 и т.д. были полностью изолированными. Хотите перейти с 1401 на 1620 — купите не только новый процессор, но и всю периферию. Софт тоже придется переписать.
Дорогое удовольствие для клиента, не каждый на такое решится. Да и для самой IBM ситуация выглядела плохо. Приходилось поддерживать производство устаревшего оборудования, содержать штат специалистов, умеющих его настраивать, обучать инженеров на стороне клиента устаревшим технологиям. При этом переход с одной системы на другую требовал полного переобучения. Ситуацию усугубляло то, что многие из систем были узкоспециализированными, например диспетчерские системы.
И вот в январе 1961 года 29-летний Брукс представляет проект очередной серии 8000. Конечно, новая система лучше предыдущих во всем, но в одном она с ними одинакова. Это еще один полностью уникальный комплекс, переход на который обойдется клиентам в миллионы, как и его поддержка самой IBM. Понятно, что это тупик. Проект закрывают, а Бруксу предлагают возглавить группу по разработке совершенно новой системы. Но какой — никто не знал. Одно было понятно: новая система должна обеспечить в дальнейшем обратную совместимость как на аппаратном, так и на программном уровнях, а также быть системой общего назначения, подходящей и банкам, и военным, и ученым.
Была сформирована группа из 25 человек во главе с Бруксом, которая занялась разработкой плана новой системы. Процесс двигался медленно, и чтобы его ускорить, руководство решило переселить рабочую группу в отель в пригороде Нью-Йорка с ультиматумом, что команда не выйдет оттуда, пока не придет к общему решению. И они пришли. И этому решению дали зеленый свет.
Весь аппаратно-программный комплекс назвали System/360, а операционную систему — OS/360. Иронично, что проблемы обратной совместимости были решены за счет отказа от совместимости с предыдущими системами.
Типичная конфигурация высокопроизводительной серии, выпущенной в 1967 году, составляла до 16,6 миллиона операций в секунду и порядка 512 килобайт оперативной памяти. Данные могли храниться на магнитных лентах, до 20 мегабайт на ленте, либо на жестких дисках объемом около 5 мегабайт. В качестве высокоуровневых языков программирования использовались Cobol, Fortran, Algol и PL/1.
Разработка системы заняла существенно больше планируемых сроков, ее стоимость составила не $625 млн, но $5,25 млрд — не многим меньше, чем программа Apollo с ее ракетами, астронавтами и высадкой на Луну за тот же 1965 год. Риск банкротства для IBM был вполне реален, но все обошлось. Анонс системы состоялся 7 апреля 1964 года, а первые продукты были выпущены в середине 1965-го. Коммерческий успех был грандиозный. Принцип взаимозаменяемости компонент, заложенный в рамках этой системы, соблюдается и по сей день.
Однако с организационной точки зрения проект нельзя назвать вполне удачным. Быстро, дешево, качественно — ни одно из этих свойств достигнуто не было.
Однако эта книга, как ретроспектива самого проекта, вполне успешна. Многие современные профессиональные разработчики знакомы с ней. И даже в наши дни, пусть и нечасто, отсылки на изложенные Бруксом идеи можно услышать в технической беседе. Тем не менее со времен написания книги в индустрии многое изменилось, и кажется важным подчеркнуть некоторые ключевые достижения, произошедшие в наше время.
Взгляд из XXI века
Вы держите в руках перевод второго издания книги 1995 года. Кроме оригинального материала первого издания, вышедшего в 1975-м, оно расширено новыми главами, в которых автор отражает свои новые и пересмотренные соображения, а также изменения в индустрии за 20 лет, прошедших с первого издания. Сейчас, спустя еще четверть века, стоит отметить ряд качественных изменений, достигнутых в наше время.
С точки зрения производительности компьютеров достигнут огромный прогресс, и не только в сравнении с 1965 годом, но и с 1995-м. При этом в наши дни динамика роста производительности процессоров существенно замедлилась. Сейчас новые системы развиваются скорее за счет расширения количества вычислительных ядер процессора, нежели за счет увеличения производительности одного ядра. Однако для разработчика современные компьютеры и ноутбуки великолепны.
Персональный компьютер, как массовое явление 90-х, существенно расширил аудиторию разработчиков программного обеспечения, при этом подход к разработке изменился не так значительно. А вот глобальное распространение интернета привело к кардинальным изменениям. Возможность не только мгновенно получить любую доступную информацию, но и публиковать собственные материалы, общаться в реальном времени — все это принципиально изменило современный подход к организации работы, и не только в разработке. Смартфоны — это второй качественный рывок в коммуникации, произошедший за последние чуть более чем 10 лет.
Гигантские изменения произошли и в плане развития инфраструктуры разработки. Использование систем управления версиями кода, таких как git, mercurial или svn, стало стандартом де-факто для организации совместной работы над кодом приложения. Существует множество систем для организации непрерывной интеграции кода, сборки, регрессионного тестирования. Юнит-тестирование адаптировано индустрией, есть огромное количество зрелых фреймворков для написания автоматических тестов. Облачные среды исполнения, такие как AWS или GCE, дали возможность легко получить ресурсы, необходимые для развертывания приложения, и многое, многое другое. При этом все перечисленное доступно как сервис и до определенной степени бесплатно.
Современные платформы разработки, например Java, .Net, Python и прочие, и сопутствующие им библиотеки кода позволяют решать большинство прикладных задач разработки гораздо лучше, чем C++ образца 1995 года. Конечно, и C++ с тех пор также сильно развился. Появляются и языки, такие как Rust, продвигающие новые принципы программирования.
Одной из лучших сред разработки в 90-х была Delphi: функции автодополнения при написании кода были доступны уже тогда. Но возможность писать код чуть быстрее не так важна, как возможность легко вносить в него изменения. В 1999-м вышла книга Мартина Фаулера «Рефакторинг», и уже через несколько лет появились среды разработки, такие как IntelliJ Idea, поддерживающие техники рефакторинга кода. Способность быстро и без ошибок вносить изменения в уже написанный код позволила адаптировать приложение к постоянным изменениям требований.
Жизненный цикл современных программных продуктов также кардинально изменился. Значительная часть современной разработки — это web-приложения, доступные как сервис. Развертывание новой версии таких приложений занимает минуты, и релиз новой версии часто происходит по несколько раз в день. Это совсем не то же самое, что релиз коробочных продуктов один раз в год. Даже в мобильной разработке новую версию приложения можно выпускать каждые несколько дней. Разработка короткими итерациями, а не проектами длительностью в год сейчас стала нормой.
Радикально новые подходы в организации разработки также стали развиваться совсем недавно. Значимым толчком в этом направлении стала публикация Манифеста Agile в 2001 году, в котором кроме четырех широко известных принципов был задан и главный посыл: «Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь разработкой непосредственно и помогая в этом другим». И многие новые методы разработки приобрели популярность. Сейчас все больше компаний организуют разработку по Scrum, и это можно считать нормой. При этом сам подход появился сравнительно недавно, в 1995 году, а широкое применение получил уже в нашем веке.
Все перечисленное мы уже привыкли воспринимать как должное. Дети в детском саду организуют каналы на YouTube, почему нет. Перефразируя Гибсона, можно сказать, что будущее уже здесь, и оно уже почти равномерно распределено. Но в конце 80-х — начале 90-х, когда формировался материал второго издания книги Брукса, положение дел в индустрии разработки все еще было во многом сходно с историей проекта OS/360. Неудивительно, что Брукс выражал определенный скепсис в отношении того, что в ближайшем десятилетии (от 1985 года) случится качественный прорыв, который позволит разрабатывать программное обеспечение на порядок быстрее. Но он также высказал и надежду, что на большей дистанции, в течение 40 лет, за счет множества трудоемких и локальных изменений в каждой из областей разработки прорыв все-таки случится. И оказался прав.
Тем не менее и сейчас мы продолжаем повторять многие ошибки, которые Брукс наблюдал еще полвека назад. Пусть многие темы, поднимаемые в книге, и выглядят очевидно устаревшими, но это лишь видимость. Фундаментальные проблемы, стоящие за ними, продолжают оставаться актуальными и в наше время.
Актуальность тем
Наверняка многие менеджеры могут привести примеры проектов, которые были выполнены в срок, уложились в бюджет, а заказчик остался доволен. Типовые проекты существуют, и их планирование вполне реально. Но во многом разработка продолжает оставаться инновационной, а структура приложений — сложной. Такие проекты принципиально невозможно планировать: ни сроки их завершения, ни необходимые ресурсы, ни то, что будет получено в итоге. И хотя известно, что в такой ситуации лучшее, что можно сделать, это работать короткими итерациями, отслеживая прогресс и корректируя планы в конце каждого цикла, реализовать такой подход удается не всегда.
Дональд Кнут, известный математик и теоретик, продвигает идею грамотного программирования (literate programming). Кроме того, он автор и разработчик издательской системы TeX, являющейся стандартом подготовки научных статей. Разработку системы Кнут планировал завершить за один год, но на то, чтобы довести ее до уровня совершенства, ему потребовалось более десятилетия.
С реальными проектами так не получается. Всегда есть реальный бюджет и сроки. К сожалению, и сейчас, как и во времена Брукса, в случае отставания проекта частой реакцией руководства является добавление в проект дополнительных разработчиков. Это приводит к тому, что проект затягивается на еще больший срок, и тут дело даже не в том, что мы не понимаем последствий таких действий. Просто в безвыходной ситуации нужно сделать хоть что-то, чтобы не быть обвиненным в бездействии. А если единственный способ, с помощью которого менеджер может повлиять на горящий проект, — добавление в него больше ресурсов, именно это менеджер и сделает, можно быть уверенным.
Вопросы, связанные со сложностью планирования проектов, подробно рассматриваются в книге. Следует отметить, что рекомендации по планированию, изложенные в главах первого издания, признаны ошибочными самим автором, однако в материалах второго издания вполне четко излагаются принципы инкрементальной и итеративной разработки. Существенная часть книги посвящена вопросам концептуальной сложности приложений и их архитектуры.
Приложения, которые мы используем повседневно, такие как веб-браузер, чаты, электронные таблицы и многое-многое другое, уже достигли того уровня совершенства, что взаимодействие с ними происходит естественно и непринужденно, будто все так и должно быть. Но как разработчики программного обеспечения, мы часто сталкиваемся с не вполне восторженной реакцией пользователей на продукт, который разрабатываем. «Сложный», «запутанный», «непонятный», «бесполезный» — вот эпитеты, которые не стесняются раздавать пользователи. И хотя каждый из нас, конечно, старается сделать свою работу хорошо, подобная оценка часто бывает справедлива.
Вопрос концептуальной целостности архитектуры остается более чем актуальным. Как добиться того, чтобы разные части приложения органично стыковались между собой, а схожие задачи в различных его частях решались аналогичным образом? Как организовать интерфейс так, чтобы смысл отображаемого на экране был понятен пользователю, а реакция на выполненное действие не вызывала удивления и раздражения? В решении этих вопросов Брукс видит ключевую роль Архитектора — человека, который продумывает механику взаимодействия пользователя с системой. Сейчас такую роль часто выполняет UX-дизайнер, но суть проблем осталась та же. Как и Брукс, мы стремимся создавать целостные, удобные приложения, работать с которыми приятно и эффективно, пусть это и не всегда удается с первого раза.
Куда мы идем
Современная индустрия переживает этап стремительного взросления. Это ярко проявляется в том, что многие компании начали вводить профессиональные уровни разработчиков по аналогии с системой разрядов на производстве. Конечно, это следствие того, что подходы ко множеству задач систематизированы, и, действуя по схеме, можно добиться успешного их решения. Но в этом же кроется и некоторая опасность. Повторяя заготовленное решение, можно упустить возможность реализовать задачу лучшим образом.
Нетрудно вообразить мрачную картину того, как все еще творческая работа разработчика превратится в рутину следования правилам и инструкциям. И в какой-то мере это правильно и неизбежно, но лишь до определенной степени. Хочется верить, что фундаментальная сложность проблем, с которыми приходится иметь дело разработчикам, всегда предоставит возможность проявить себя в поиске неординарного решения.
Какой станет разработка в ближайшие 20 лет, пока нельзя сказать с полной уверенностью. Но знать, какой она была в прошлом, определенно полезно. Фредерик Брукс дает отличное описание того, какой была индустрия 25 и 45 лет назад. Прочитать эту книгу стоит хотя бы ради того, чтобы понять, как и куда развивается индустрия разработки программного обеспечения.
От издательства
Ваши замечания, предложения, вопросы отправляйте по адресу [email protected] (издательство «Питер», компьютерная редакция).
Мы будем рады узнать ваше мнение!
На веб-сайте издательства www.piter.com вы найдете подробную информацию о наших книгах.
Посвящение из издания 1975 года
Посвящается двоим людям, особенно обогатившим мои годы в IBM:
Томасу Дж. Уотсону-младшему, чья глубокая забота о людях по-прежнему пронизывает его компанию, и Бобу О. Эвансу, чей смелый менеджмент превратил работу в приключение.
Посвящение из издания 1995 года
Посвящается Нэнси, Божьему дару для меня.
Предисловие к изданию 1995 года
К моему удивлению и восторгу, книга «Мифический человеко-месяц» продолжает оставаться популярной спустя 20 лет. Тираж превысил 250 тысяч экземпляров. Меня часто спрашивают, каких мнений и рекомендаций, изложенных в 1975 году, я придерживаюсь и по сей день, а какие изменились и как. Хотя я время от времени обращался к этому вопросу в своих лекциях, давно хотелось написать эссе на эту тему.
Питер Гордон (Peter Gordon), ныне партнер издательства Addison-Wesley, терпеливо и услужливо работает со мной с 1980 года. Он предложил, чтобы мы подготовили юбилейное издание. Мы решили не пересматривать оригинал, а перепечатать его нетронутым (за исключением тривиальных исправлений) и дополнить более актуальными мыслями.
Глава 16 является статьей «Серебряной пули нет: существенные и частные признаки инженерии программного обеспечения» (No Silver Bullet: Essence and Accidents of Software Engineering), опубликованной IFIPS (Международной федерацией по обработке информации) в 1986 году, которая выросла из моего опыта председательства в Научном совете Министерства обороны США. Мои соавторы этого исследования и наш исполнительный секретарь Роберт Л. Патрик (Robert L. Patrick) оказали неоценимую помощь в моем возвращении к реальным крупным проектам по созданию программного обеспечения. Статья была перепечатана в 1987 году в компьютерном журнале IEEE Computer и получила широкую известность.
Статья «Серебряной пули нет» оказалась провокационной. Она предсказала, что в течение десятилетия не будет создано ни одного решения, которое само по себе привело бы к повышению продуктивности разработки на порядок. До истечения десятилетия остался год; мое предсказание, похоже, сбывается. Статья «СПН» стала поводом для более оживленной дискуссии в литературе, чем было заложено в «Мифическом человеко-месяце». В связи с этим в главе 17 даются комментарии по некоторым опубликованным критическим замечаниям и обновляются мнения, изложенные в 1986 году.
Работая над обзором и обновлением книги «Мифический человеко-месяц», я поразился, как мало тезисы, заявленные в ней, были подвергнуты критике, доказаны или опровергнуты текущими исследованиями и опытом в инженерии ПО. Теперь для меня оказалось полезным каталогизировать эти тезисы в сырой форме, лишенной подтверждающих аргументов и данных. В надежде, что эти голые утверждения привлекут аргументы и факты для доказательства, опровержения, обновления или уточнения, я включил этот план в главу 18.
Глава 19 как таковая является новым эссе. Читателя следует предупредить о том, что новые мнения далеко не так прочно базируются на опыте работы «в полях», как это было в оригинальной книге. Дело в том, что в последнее время я работал в университетской среде, а не в промышленности, и над небольшими, а не крупномасштабными проектами. С 1986 года я занимался инженерией ПО только как преподаватель, а не как исследователь. Мои исследования, скорее, были посвящены виртуальным средам и их приложениям.
При подготовке этой ретроспективы я стремился изложить текущие взгляды моих друзей, которые фактически работают в инженерии программного обеспечения. Я в долгу перед Барри Бемом, Кеном Бруксом, Диком Кейсом, Джеймсом Коггинсом, Томом Демарко, Джимом Маккарти, Дэвидом Парнасом, Эрлом Уилером и Эдвардом Йордоном за их замечательную готовность делиться мнениями, вдумчиво комментировать наброски и перевоспитывать меня. Фэй Уорд великолепно справилась с изданием новых глав.
Я благодарю Гордона Белла, Брюса Бьюкенена, Рика Хейса-Рота, моих коллег из целевой группы Научного совета Министерства обороны США по военному программному обеспечению, и в особенности Дэвида Парнаса, за их существенные и стимулирующие идеи, а также Ребекку Бирли за подготовку статьи, напечатанной здесь в качестве главы 16. Анализ задачи разработки программного обеспечения в категориях существенных и частных признаков возник благодаря Нэнси Гринвуд Брукс, которая использовала такой анализ в статье о методе Судзуки преподавания игры на скрипке.
Традиции издательства Addison-Wesley не позволили мне в предисловии к изданию 1975 года выразить свою признательность сотрудникам издательства, которые сыграли ключевую роль. Следует особо отметить вклад двух человек: Нормана Стэнтона, который в то время был главным редактором, и Герберта Боэса, который в то время был художественным редактором. Боэс разработал элегантный стиль, который один рецензент, в частности, охарактеризовал как «широкие поля (и) образное использование шрифта и макета». Что еще важнее, так это его рекомендации по оформлению книги: именно он рекомендовал снабдить рисунком каждую главу. (В то время у меня было только два рисунка: Смоляные ямы и Реймский собор.) На то, чтобы найти все картинки, мне потребовался целый год, но я бесконечно благодарен за совет.
Soli Deo Gloria — одному Господу слава.
Ф. Б.-мл.
Чапел-Хилл, Северная Каролина. Март 1995
Предисловие к первому изданию
Во многих отношениях управление крупным проектом по разработке программного обеспечения похоже на управление любым другим крупным предприятием — в большей степени, чем считают большинство программистов. Но во многих других отношениях оно отличается — в большей степени, чем ожидают большинство профессиональных менеджеров.
Профессиональные знания в этой области накапливаются. Было проведено несколько конференций, сессий на конференциях AFIPS, вышло несколько книг и статей. Но они ни в коем случае еще не готовы к какой-либо систематической хрестоматийной обработке. Однако представляется уместным предложить эту небольшую книгу, отражающую, по существу, личный взгляд.
Хотя я изначально вырос на «программной» стороне компьютерных наук, в течение тех лет (1956–1963), когда была разработана автономная управляющая программа и компилятор высокоуровневого языка, я главным образом был вовлечен в аппаратную архитектуру. Когда в 1964 году я стал менеджером проекта Operating System/360, я обнаружил, что за последние несколько лет мир программирования сильно изменился благодаря прогрессу.
Опыт управления проектом OS/360 стал очень познавательным, хотя и очень разочаровывающим. Команде, включая Ф.М. Трапнелла (F. M. Trapnell), сменившего меня на посту менеджера проекта, есть чем гордиться. Указанная система обладает большими преимуществами дизайна и исполнения, и она была успешной в достижении ее широкого использования. Некоторые идеи, наиболее заметно зависящие от устройств ввода-вывода и управления внешними библиотеками, были технически инновационными и сейчас широко копируются. Теперь система является достаточно надежной, достаточно эффективной и очень универсальной.
Однако эти усилия нельзя назвать полностью успешными. Любой пользователь OS/360 быстро осознает, что до идеала еще далеко. Недостатки в дизайне и исполнении в особенности свойственны управляющей программе, в отличие от компиляторов языков. Большинство этих недостатков относятся к периоду дизайна 1964–1965 годов и, следовательно, должны быть возложены на меня. Кроме того, продукт опоздал, он занял больше памяти, чем планировалось, затраты оказались в несколько раз выше оценочных, и он не очень хорошо работал как в первом релизе, так и в нескольких последующих.
После ухода из IBM в 1965 году и приезда в Чапел-Хилл, как было первоначально согласовано, я возглавил работу над проектом OS/360 и начал анализировать опыт работы с OS/360 для того, чтобы увидеть, какие могут быть извлечены управленческие и технические уроки. В частности, я хотел бы объяснить совершенно разный опыт руководства в разработке аппаратного обеспечения для System/360 и программного обеспечения для OS/360. Эта книга — запоздалый ответ на мучительные вопросы Тома Уотсона, почему разработкой ПО трудно управлять.
В этом стремлении я извлек пользу из долгих бесед с Р.П. Кейсом (R. P. Case), помощником менеджера в 1964–1965 годах, и Трапнеллом, менеджером в 1965–1968 годах. Я сравнил свои выводы с выводами других менеджеров крупных проектов, включая Ф. Дж. Корбато (F. J. Corbato) из Массачусетского технологического университета, Джона Харра (John Harr) и В. Высоцкого (V. Vyssotsky) из Bell Telephone Laboratories, Чарльза Портмана (Charles Portman) из International Computers Limited, А.П. Ершова из вычислительной лаборатории Сибирского отделения Академии наук СССР и А.М. Пьетрасанту (A. M. Pietrasanta) из IBM.
Мои собственные выводы воплощены в следующих далее эссе. Они предназначены для профессиональных программистов, профессиональных менеджеров, и в первую очередь для профессиональных менеджеров-программистов.
Несмотря на то что главы написаны как отдельные эссе, в них, в особенности в главах 2–7, содержится центральный аргумент. Если кратко, то я считаю, что крупные программные проекты страдают от проблем менеджмента, отличных от проблем менеджмента мелких проектов, что обусловливается разделением труда. Я считаю, что критически необходимо сохранять концептуальную целостность самого продукта. В этих главах рассматриваются трудности достижения целостности и методы достижения этой целостности. В последующих главах рассматриваются другие аспекты менеджмента в инженерии программного обеспечения.
Литература в указанной области немногочисленна, но при этом весьма распылена. Поэтому я попытался дать ссылки, которые будут освещать конкретные места и направлять заинтересованного читателя к другим полезным работам. Многие мои друзья читали рукопись, и некоторые подготовили обширные полезные комментарии; там, где они казались ценными, но не вписывались в основной текст, я включил их в заметки.
Поскольку эта книга состоит из эссе и не является сплошным повествованием, все ссылки и заметки были вынесены в конец, и читателю можно пропустить их при первом чтении.
Я глубоко признателен мисс Саре Элизабет Мур, мистеру Дэвиду Вагнеру и миссис Ребекке Бернс за помощь в подготовке рукописи, а также профессору Джозефу Слоуну за советы по подбору иллюстраций.
Чапел-Хилл, Северная Каролина. Октябрь 1974 года
1. Смоляные ямы
Корабли на мели — моряку маяк.
Голландская пословица
Ч. Р. Найт (C. R. Knight). Панно «Смоляные ямы в Ла-Брея», Палеонтологический музей находок Джорджа К. Пейджа на ранчо Ла-Брея
Ни одна из доисторических сцен не была столь яркой, как сцена смертельной схватки огромных зверей в смоляных ямах1. Мы видим, как динозавры, мамонты и саблезубые тигры борются с тисками смолы. Чем яростнее борьба, тем глубже смола затягивает, и каждому зверю, неважно, как силен он и ловок, в конце концов уготована гибель.
Разработка больших программных систем в течение последнего десятилетия была такой смоляной ямой, огромные и могущественные звери ожесточенно пытались в ней выжить. Большинство из них вышли с работающими системами, не многие достигли целей, придерживаясь графиков и бюджетов. Крупные и малые, массивные или жилистые, команда за командой вязли в смоле. Отдельно взятая проблема, по-видимому, не вызывает никаких трудностей — любую конкретную лапу можно вырвать из тисков. Но накопление одновременных и взаимодействующих факторов постепенно замедляет движение. Все, похоже, были удивлены вязкостью проблемы, и ее природу трудно было понять. Но мы должны попытаться понять, если хотим ее решить.
Поэтому давайте начнем с определения ремесла системного программирования и присущих ему радостей и горестей.
Система программирования как продукт
Иногда в новостях можно прочесть о том, как два программиста в перестроенном гараже создали важную программу, которая превосходит все усилия крупных команд. И каждый программист готов поверить в такие истории, ибо знает, что может собрать любую программу гораздо быстрее, чем та тысяча инструкций языка в год, о которых сообщается, будто они пишутся в производственных командах.
Почему же тогда не все команды по программированию были заменены специализированными гаражными дуэтами? Нужно смотреть на то, что производится.
В левом верхнем углу рис. 1.1 находится программа. Как таковая она закончена, готова к выполнению автором в системе, в которой
Рис. 1.1. Эволюция продукта системы программирования
была разработана. Это то, что обычно производится в гаражах, причем является объектом, который отдельный программист использует для оценивания продуктивности.
Существует два способа конвертирования программы в более полезный, но более дорогостоящий объект. Эти два способа представлены по краям рисунка.
Двигаясь вниз через горизонтальную границу, программа становится программным продуктом. Это программа, которая может выполняться, тестироваться, исправляться и расширяться кем угодно. Она может использоваться во многих операционных средах, для многих наборов данных. Для того чтобы стать публичным программным продуктом, программа должна быть написана в обобщенном виде. В частности, диапазон и форма входных данных должны быть обобщены настолько, насколько это позволяет базовый алгоритм. Затем программа должна быть тщательно протестирована, чтобы сделать ее надежной. Для этого нужно подготовить достаточное количество контрольных примеров для проверки диапазона допустимых значений входных данных и определения его границ, обработать эти примеры и зафиксировать результаты. Наконец, продвижение программы до стадии программного продукта требует ее тщательного документирования, с тем чтобы любой мог ею пользоваться, исправлять и расширять. В качестве эмпирического правила я оцениваю, что программный продукт стÓит по крайней мере в три раза больше, чем отлаженная программа с той же функциональностью.
Двигаясь через вертикальную границу, программа становится компонентом системы программирования. Он представляет собой коллекцию взаимодействующих программ, скоординированных по функциональности и упорядоченных по формату таким образом, что их совокупность представляет собой целостное обеспечение для выполнения крупных задач. Для того чтобы стать компонентом системы программирования, программа должна быть написана так, чтобы каждый вход и выход подчинялся синтаксису и семантике с точно определенными интерфейсами. Программа также должна быть составлена так, чтобы использовать только прописанный бюджет ресурсов, включая пространство памяти, устройства ввода-вывода, компьютерное время. Наконец, программа должна быть протестирована вместе с другими компонентами системы во всех ожидаемых комбинациях. Это тестирование получится обширным, так как число случаев растет комбинаторно. Указанное тестирование является времязатратным, поскольку трудноуловимые ошибки возникают из-за неожиданных взаимодействий отлаживаемых компонентов. Компонент системы программирования стÓит по меньшей мере в три раза дороже, чем автономная программа с той же функциональностью. Стоимость может быть больше, если система имеет много компонентов.
В правом нижнем углу рис. 1.1 находится продукт систем программирования. Он отличается от простой программы во всех вышеперечисленных отношениях. Он стÓит в девять раз дороже. Но он является поистине полезным объектом, конечным результатом наибольших усилий в разработке системных программных продуктов.
Радости ремесла
Почему программирование приносит радость? Какие удовольствия в качестве награды ждут его практика?
Во-первых, это чистая радость от изготовления вещей. Как ребенок получает удовольствие от лепки куличика из песка, так и взрослый наслаждается созданием вещей, в особенности вещей по своему собственному дизайну. Думаю, что этот восторг должен быть образом восторга Господа от созидания, восторга, проявляющегося в отчетливости и новизне каждого листика и каждой снежинки.
Во-вторых, это удовольствие делать вещи, которые полезны другим людям. Глубоко внутри мы хотим, чтобы результат нашего труда был полезен и востребован. В этом отношении система программирования практически не отличается от первой детской подставки для ручек из глины «для папиного кабинета».
В-третьих, это увлекательная возможность придавать форму сложным головоломным объектам, состоящим из взаимосвязанных движущихся частей, и наблюдать за тем, как они работают в тонких циклах, воспроизводят последствия принципов, заложенных с самого начала. Запрограммированный компьютер обладает всей прелестью пинбольной машины или музыкального автомата, доведенных почти до предела совершенства.
В-четвертых, это радость от постоянного усвоения нового — этого предостаточно в неповторяющейся работе. Так или иначе, проблема всегда нова, и решающий ее чему-то учится: иногда практическому, иногда теоретическому, а иногда и тому и другому.
Наконец, это удовольствие работать в такой послушной среде. Программист, как и поэт, работает лишь в небольшом отрыве от чистого мыслительного материала. Он строит свои замки из воздуха, творя усилием воображения. Немногие среды творения настолько гибки, так легко поддаются полировке и переработке, так легко способны реализовывать грандиозные концептуальные структуры. (Как мы увидим позже, у этой самой сговорчивости есть свои проблемы.)
И все же программный конструкт, в отличие от слов поэта, реален в том смысле, что он движется и работает, производя видимые результаты, отличные от него самого. Он печатает результаты, рисует картинки, издает звуки, двигает манипуляторами. В наше время волшебство мифов и легенд стало реальностью. Стоит набрать правильное заклинание на клавиатуре, и экран дисплея оживает, показывая вещи, которых никогда не было и не могло быть.
Таким образом, программирование доставляет удовольствие, поскольку отвечает глубокой внутренней потребности в творчестве и удовлетворяет чувственные потребности, которые есть у всех нас.
Горести ремесла
Однако не все является наслаждением, и знание присущих ремеслу горестей облегчает их ношу.
Во-первых, человек должен действовать безупречно. Компьютер похож на магию и в этом отношении тоже. Если один символ, одна пауза заклинания не находится строго в правильной форме, то волшебство не сработает. Люди не совершенны, и немногие сферы человеческой деятельности этого требуют. Необходимость приспосабливаться к требованиям совершенства — это, я думаю, самая трудная часть овладения программированием.2
Конечные целевые критерии устанавливают другие люди, они предоставляют ресурсы и обеспечивают информацией. Редко кто-то контролирует условия своей работы или даже ее цель. С точки зрения менеджмента, мы зависим от многих. Однако, похоже, в любой работе формальная власть несоизмерима с ответственностью. На практике фактические (в отличие от формальных) полномочия приобретаются с самого момента достижения конечной цели.
Зависимость от других имеет особенно неприятную системному программисту сторону. Он зависит от чужих программ, которые часто плохо спроектированы, плохо имплементированы, поставлены не полностью (нет исходного кода или тестовых случаев) и плохо документированы. Программист должен тратить часы на изучение и исправление того, что в идеале должно быть завершенным, доступным и пригодным для использования.
Следующая горесть состоит в том, что заниматься дизайном великих концепций — это удовольствие; отыскивать мелкие ошибки — это просто работа. Вместе с любой творческой деятельностью приходят тоскливые часы монотонного, кропотливого труда, и программирование не является исключением.
Далее обнаруживается, что отладка имеет линейную сходимость или даже хуже, где ожидалось что-то вроде квадратичного подхода к концу. И поэтому тестирование затягивается, при этом на поиск последних ошибок приходится тратить больше времени, чем на поиск первых.
И последней каплей, которая может переполнить чашу горестей, может стать опасность того, что продукт, над которым так долго трудились, устареет еще до его завершения. Коллеги и конкуренты уже вовсю гоняются за новыми и более совершенными идеями. И уничтожение плода вашей мысли уже не только задумано, но и запланировано.
Это звучит хуже, чем есть на самом деле. Новый и более совершенный продукт, в общем-то, недоступен, когда кто-то завершает свой собственный; о нем только говорят. И к тому же на его разработку уйдут месяцы. Настоящий тигр никогда не сравнится с бумажным, только если не потребуется его реальное использование. И тогда добродетели реальности получают удовлетворение сами по себе.
Разумеется, технологии, которые мы используем, постоянно развиваются. Как только дизайн замораживается, он становится устаревшим с точки зрения его концепций. Но имплементация реальных продуктов требует разделения на фазы и подгруппы. Устаревание имплементации должно измеряться по отношению к другим существующим имплементациям, а не по отношению к нереализованным концепциям. Задача и миссия состоят в том, чтобы найти реальные решения реальных задач в реальные сроки с имеющимися ресурсами.
Это и есть программирование и смоляная яма, в которой вязнут многие усилия и творческая деятельность со своими собственными радостями и горестями. Для многих радости намного перевешивают горести, и для них остальная часть этой книги попытается проложить дощатый мостик через смоляную яму.
1 Смоляные ямы Ла-Брея — месторождение окаменелостей верхнего плейстоцена, расположенное в парке Хэнкок, Лос-Анджелес. Наличие смоляных ям позволило обнаружить животных, сохранившихся в этом материале. Смола медленно поднималась на поверхность земли в этом регионе в течение нескольких десятков тысяч лет, образуя сотни вязких углублений, которые заключали в ловушку животных, имевших неосторожность туда подойти. — Примеч. пер.
2Ершов считает это не только горестью, но отчасти и радостью. A.P. Ershov. Aesthetics and the human factor in programming // CACM. 1972. Vol. 15, N 7. July. P. 501-505
2. Мифический человеко-месяц
Высокая кухня требует времени. Если вас заставляют ждать, то только для того, чтобы лучше вас обслужить и доставить вам удовольствие.
Меню ресторана «Antoine», Новый Орлеан
Фото меню ресторана «Antoine», Новый Орлеан. UPI Photo/Архив Беттмана
Программные проекты чаще проваливаются из-за нехватки календарного времени, чем по всем остальным причинам вместе взятым. Почему такая причина катастрофы наиболее распространена?
Во-первых, наши методики оценивания развиты слабо. По сути, они отражают молчаливое допущение, что все пойдет как надо.
Во-вторых, наши методики оценивания ошибочно путают усилия с прогрессом, допуская, что люди и месяцы взаимозаменяемы.
В-третьих, поскольку мы не уверены в наших оценках, менеджерам часто не хватает вежливого упрямства шеф-повара ресторана Antoine.
В-четвертых, ход выполнения графика плохо контролируется. Методы, проверенные и рутинные в других инженерных дисциплинах, считаются радикальными инновациями в инженерии программного обеспечения.
В-пятых, когда выявляется отставание от графика, естественным (и традиционным) ответом становится добавление рабочей силы. Это все равно что подлить масла в огонь: будет только хуже, гораздо хуже. Больше огня требует больше горючего, и в результате начинается регенеративный цикл, который заканчивается катастрофой.
Контроль графика работ станет темой отдельного эссе. Рассмотрим другие аспекты проблемы подробнее.
Оптимизм
Все программисты — оптимисты. Возможно, это современное колдовство в особенности привлекает тех, кто верит в счастливый конец и сказочных волшебниц. Возможно, сотни мелких разочарований отпугивают всех, кроме зацикленных по привычке на конечной цели. Возможно, дело просто в том, что компьютеры существуют не так много лет, программисты — еще моложе компьютеров, а молодые всегда оптимистичны. Но как бы ни работал процесс отбора, результат будет бесспорным: «на этот раз она обязательно запустится» или «я только что отыскал последний баг».
Таким образом, первое ложное допущение, лежащее в основе определения графика разработки, состоит в том, что все пойдет хорошо, то есть каждая часть работы будет продолжаться столько, сколько она «должна» длиться.
Повсеместное присутствие оптимизма среди программистов заслуживает пристального изучения. Дороти Сэйерс (Dorothy Sayers) в своей замечательной книге «Ум творца» (The Mind of the Maker) делит творческую деятельность на три стадии: идея, имплементация и взаимодействие. Таким образом, книга, компьютер или программа сначала возникают как идеальный конструкт, построенный вне времени и пространства, но завершенный в сознании автора. Он реализуется во времени и пространстве с помощью пера, чернил и бумаги или с помощью проводов, кремния и феррита. Творение завершается, когда кто-то читает книгу, пользуется компьютером или выполняет программу, тем самым взаимодействуя с умом творца.
Описание, которое использует мисс Сэйерс, может пролить свет не только на человеческую творческую деятельность, но и на христианское учение о Троице, и будет полезно в нашей нынешней работе. Для людей, создающих что-то, незавершенность и противоречивость идей становятся ясными только в процессе имплементации. Таким образом, написание, экспериментирование, «отработка» являются существенными дисциплинами для теоретика.
Во многих творческих видах деятельности среда исполнения является неподатливой. Древесина раскалывается, краски размазываются, электрические цепи закольцовываются. Эти физические лимиты среды ограничивают круг идей, которые могут быть воплощены, и они также создают неожиданные трудности в имплементации.
Имплементация, таким образом, требует времени и пота как по причине физических сред, так и по причине неадекватности лежащих в основе идей. Мы склонны обвинять физические среды в большинстве наших трудностей с имплементацией, поскольку они чужды нам — в отличие от идей, которыми мы гордимся.
Однако компьютерное программирование создает продукт с помощью чрезвычайно податливой среды. Программист строит из чистого мысленного материала — концепций и их очень гибких представлений. Поскольку среда является податливой, мы не ожидаем больших трудностей в имплементации; отсюда наш всепроникающий оптимизм. Поскольку наши идеи могут исходить из ложных умозаключений, в нас самих есть баги; так что наш оптимизм не является оправданным.
В отдельно взятой работе допущение о том, что все пойдет хорошо, влечет за собой влияние вероятностей на график работ. Возможно, все действительно пойдет по плану, так как существует вероятностное распределение для задержки, которая будет неожиданно встречена по ходу, а «отсутствие задержки» имеет конечную вероятность. Однако большие проекты в разработке состоят из многих задач, и некоторые из них выстроены впритык. Вероятность того, что все пойдет хорошо, становится ничтожно малой.
