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

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

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

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

Плодотворность этих совещаний обусловлена несколькими причинами:

1. Одна и та же группа – архитекторы, разработчики и исполнители – на протяжении месяцев встречаются между собой каждую неделю. Не требуется времени, чтобы ввести людей в курс дела.

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

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

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

5. Открытое предоставление права принятия решения главному архитектору помогает избежать поиска компромиссов и задержек.

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

Эти сессии проводились накануне важных дат окончательного принятия разделов руководства. Присутствовали не только представители программистов и проектировщиков по архитектуре, но и менеджеры программных, маркетинговых и реализационных проектов. Председательствовал менеджер проекта System/360. Повестка работы включала обычно около 200 пунктов, в основном мелких, перечисленных в развешанных по комнате списках. Заслушивались все стороны и принимались решения. Благодаря чуду компьютерной верстки (и превосходной работе сотрудников) каждое утро каждый участник обнаруживал на своем рабочем месте исправленное руководство, в которое были внесены решения, принятые накануне.

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

Множественные реализации

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

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

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