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

Ознакомительная версия.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Аудит менеджмента Вавилонского проекта

Согласно Книге бытия, Вавилонская башня была вторым крупным инженерным предприятием человека после Ноева ковчега. Вавилонская башня стала первым инженерным фиаско.

Эта история глубока и поучительна в нескольких отношениях. Давайте, однако, рассмотрим ее как чисто технический проект и посмотрим, какие уроки администрирования можно из нее извлечь. Насколько хорошо проект был обеспечен необходимыми составляющими успеха? Имелись ли:

1. Ясность цели? Да, хотя и наивно недостижимой. Проект провалился задолго до того, как столкнулся с эти принципиальным ограничением.

2. Человеческие ресурсы? В большом числе.

3. Материалы? Глина и битум в изобилии имеются в Месопотамии.

4. Достаточно времени? Да, нет никаких указаний на ограничения по времени.

5. Адекватные технологии? Да, пирамидальной или конической структуре присуща устойчивость и хорошее распределение нагрузки сжатия. Очевидно, свойства каменной кладки были хорошо известны. Проект провалился до того, как вышел за пределы технологических ограничений.

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

Обмен информацией в большом программном проекте

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

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

Как же должны бригады обмениваться между собой информацией? Всеми возможными способами:

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

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

• Рабочая тетрадь. В самом начале нужно завести рабочую тетрадь учета проделанной работы. Эта тема заслуживает отдельного раздела.

Рабочая тетрадь проекта

Ознакомительная версия.