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

Прочитал книгу Фредерика Брукса "Мифический человеко-месяц" и хочу поделиться выдержками из книги, которые показались мне наиболее значимыми.

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

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

О разнице между программой, программным продуктом, программным комплексом и системным программным продуктом

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

О недостатках работы программистом

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

Об оптимизме в планировании и срыве сроков

Итак, в основе планирования разработки программ лежит ложное допущение, что все будет хорошо, т.е. каждая задача займет столько времени, сколько «должна» занять.
<...>
Дороти Сэйерс (Dorothy Cayers) в своей превосходной книге «Разум творца» (“The Mind of the Maker”) выделяет в творческой деятельности три стадии: замысел, реализацию, взаимодействие.
<...>
Творение будет завершено, когда кто-либо прочтет книгу, воспользуется компьютером или запустит программу, тем самым вступив во взаимодействие с разумом их создателя.
<...>
Для человека, который что-то создает, неполнота и противоречивость идей выявляются только при их реализации. Поэтому для теоретика изложение на бумаге, экспериментирование, изготовление является неотъемлемыми частями творческого процесса.

Робость в оценках

Омлет, обещанный через две минуты, может успешно жариться, но если через две минуты он не готов, то у клиента есть две возможности: ждать еще или съесть его сырым. Тот же выбор встает и перед заказчиком программного обеспечения.

О сроках

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

О принятии решений в рамках команды

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

Во-вторых, в обычной бригаде партнеры равны, и неизбежные разногласия должны разрешаться путем переговоров или компромиссов. <...> В хирургической бригаде различий интересов нет, а разногласия единолично решаются хирургом. Эти два различия — отсутствие разбиения задачи и отношение подчиненности — позволяют хирургической бригаде действовать uno animo.

Концептуальное единство

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

О дисциплине

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

О творческом процессе в работе архитектора и в работе разработчика

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

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

Самодисциплина — эффект второй системы

Первый проект архитектора стремится к скромности и ясности. Архитектор понимает, что не знает, чем занимается, поэтому он занимается этим со старанием и самоограничением.

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

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

О провале проекта Вавилонской башни

Так почему же провалился проект, если все это у них было? Чего у них не хватало? Двух вещей — обмена информацией и вытекающей из него организации.

О ролях: продюсер и технический директор

В чем назначение продюсера? Он собирает бригаду, распределяет работу и устанавливает график ее выполнения. Он занимается приобретением необходимых ресурсов. Это означает, что большая часть его функций состоит в общении, которое направлено вне бригады, — вверх и в стороны.
<...>
А что же технический директор? Он постигает проект, который должен быть реализован, выявляет его составляющие, определяет, как он будет выглядеть внешне, и делает эскиз внутренней структуры. Он обеспечивает единство и концептуальную целостность проекта в целом и таким образом способствует ограничению сложности системы. При возникновении технических проблем он изыскивает их решения или при необходимости изменяет системный проект. Он, согласно прелестному выражению Ала Каппа, является «своим человеком в паршивых делах». Общение его происходит преимущественно внутри команды. Его работа почти исключительно техническая.

Теперь видно, что для этих двух функций требуются совершенно разные способности. Способности встречаются в разных сочетаниях, и отношения между продюсером и директором должны определяться теми конкретными сочетаниями, которыми они обладают. Не люди должны быть втиснуты в чисто теоретические организационные формы, а организация должна строиться вокруг тех людей, которые есть.
<...>
Что хуже всего получается у менеджеров проектов, — так это использование технического гения людей, не очень сильных в администрировании.

Об оценке сроков

Опыт — дорогой учитель, но для глупцов другого нет

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

О бумажной работе

Однако понемногу он начинает понимать, что некоторая небольшая часть этих документов заключает в себе значительную часть его административной работы. Подготовка каждого из них служит главным поводом для сосредоточения мысли и кристаллизации обсуждений, которые без этого длились бы вечно. Ведение этих документов становится механизмом наблюдения и предупреждения. Сам документ становится памяткой, индикатором состояния и базой данных для составления отчетов.
<...>
Задача менеджера состоит в том, чтобы разработать план и выполнить его. Но только записанный план является точным и может быть сообщен другим. Такой план состоит из документов, описывающих: что, когда, по какой цене, где и кто. Этот маленький набор важных документов охватывает значительную часть работы менеджера. Если в самом начале понять их всеохватывающую и важную сущность, то они станут для менеджера добрым инструментом, а не раздражающей обузой. Сделав это, он определит свой курс более четко и быстро.

О разработке чего-то принципиально нового

В этом мире нет ничего постояннее непостоянства.

Разумно взять метод и испытать его. При неудаче честно признайтесь в этом и попробуйте другой метод. Но главное, делайте что-нибудь.

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

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

Поэтому планируйте выбросить первую версию — вам все равно придется это сделать.

Об изменении требований в процессе разработки

Первый шаг — признание того, что изменение — это образ жизни, а не постороннее и досадное исключение. Косгроув мудро указал, что программист поставляет удовлетворение потребности пользователя, а не какой-то осязаемый продукт. И в то время как программы создаются, тестируются и используются, меняются как фактические потребности пользователя, так и понимание им своих потребностей.
<...>
Я далек от того, чтобы считать, будто все изменения целей и требований клиента можно или необходимо учитывать в проекте. Очевидно, должен быть установленный порог, который должен подниматься все выше и выше по ходу разработки, иначе ни один продукт никогда не будет создан.

О багах в своем коде

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

Как оказывается, что проект запаздывает на год?
... Сначала запаздывает на один день.

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

Отставание, растущее понемногу изо дня в день, труднее распознать, труднее предотвратить, труднее исправить.

О точности сроков

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

О том как убедить программистов поддерживать документацию в актуальном состоянии

Томас Дж. Уотсон Старший (Thomas J. Watson, Sr.) рассказал мне историю своего первого опыта в качестве продавца кассовых аппаратов в северной части штата Нью-Йорк. Исполненный энтузиазма, он отправился в путь в своем фургоне, нагруженном кассовыми аппаратами. Он прилежно объехал свой участок, но ничего не продал. Обескураженный, он сообщил об этом своему хозяину. Послушав некоторое время, управляющий сказал: «Помоги мне загрузить несколько касс в фургон, запрягай лошадь, и поедем снова.» Так они и сделали, и обходя покупателей одного за другим, старик показывал, как продавать кассовые аппараты.

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

О самодокументировании

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

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

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

О типах и приоритетах задач

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

О связи между размером и сложностью программ

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

...

При разработке программ трудно решить, что именно сказать, а не собственно сказать. Никакое облегчение выражения не может дать больше, чем незначительные выгоды.

О спецификации

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

О разработке технических требований

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

О некорректности метафоры “строительства” программы в современных условиях

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

Электроинструмент для ума

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

О стоимости разработки повторно используемых компонент

Йордон дает оценку того, сколько это стоит: «Хорошее эмпирическое правило говорит, что повторно используемые компоненты потребуют вдвое больших затрат, чем «одноразовые» компоненты.»

О важности документирования решений

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

Об управлении проектом и графике его разработки

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

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

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

Еще раз о документации

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

Определение портрета пользователей

Чем крупнее и аморфнее группа предполагаемых пользователей, тем более необходимо явно ее определить, если вы намерены достичь концептуальной целостности. У каждого члена группы проектировщиков наверняка есть неявный мысленный образ пользователя, и все образы будут отличаться друг от друга. Поскольку представление архитектора о пользователе явно или подсознательно оказывает влияние на все архитектурные решения, важно, чтобы команда проектировщиков пришла к единому общему образу. Для этого необходимо составить список признаков предполагаемых пользователей, указав в нем:

• кто они такие,
• что им нужно,
• что, по их мнению, им нужно,
• чего они хотят.

О пошаговой разработке

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

На следующем шаге мы навешиваем модуль ввода (возможно, примитивный) и модуль вывода. Voila! Работающая система, делающая нечто, возможно, неинтересное. Теперь, функция за функцией, мы строим и добавляем модули. На каждом шаге мы имеем работающую систему.

О ежедневных сборках

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

Это действительно тяжело. Требуется выделение больших ресурсов, но это управляемый процесс, прослеживаемый и понятный. Он вызывает у команды доверие к себе. А доверие определяет мораль, эмоциональное состояние.

О рабочем месте программиста

В помещениях наиболее продуктивных программистов тише, они более личные, лучше защищены против непрошеного вторжения, и они просто больше… Понимаете ли вы, что покой, пространство и уединенность способствуют лучшей работе ваших теперешних работников или (с другой стороны) способствует привлечению и сохранению лучших работников?

О главной задаче менеджера проекта

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

Эпилог

Область связанных с компьютерами знаний претерпела взрыв, как и соответствующая технология. Будучи аспирантом в середине 50-х, я мог прочесть все журналы и труды конференций. Я мог оставаться на современном уровне во всей научной дисциплине. Сегодня же мне в моей интеллектуальной жизни приходится с сожалением расставаться с интересами то в одной, то в другой подобласти, поскольку количество документов превысило всякую возможность справиться с ними. Масса интересов, масса замечательных возможностей для учебы, исследований, размышлений. Чудесное затруднение! Не только конца не видно, но и шаг не замедляется. В будущем нас ожидают многие радости.

Я бы рекомендовал прочитать эту книгу всем тем чья работа любым образом связана с разработкой программного обеспечения.