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

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

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

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

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

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

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

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

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

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

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

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

Журнал регистрации телефонных разговоров

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

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

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

Тестирование продукта

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