Выбор обложки книга «Мифический человеко-месяц, или Как создаются программные системы»

Привет, Хаброжители! Мы сдаем в типографию юбилейное издание книги Брукса. Просим вас выбрать обложку и ознакомиться с отрывком «Управленческий аудит Вавилонского проекта».

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

Управленческий аудит Вавилонского проекта

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

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

Как много у Вавилонского проекта было предпосылок для успеха?

Имелись ли у строителей:

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

• Рабочая сила? В достатке.

• Материалы? В Месопотамии в изобилии встречаются глина и битум.

• Достаточно времени? Да, на нехватку времени даже никаких намеков.

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

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

Коммуникация в большом проекте

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

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

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

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

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

• Рабочая книга. В самом начале должна быть запущена формальная рабочая книга проекта. Она заслуживает отдельного раздела.

Рабочая книга проекта

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

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

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

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

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

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

Механика. Как и во многих задачах управления программными проектами, проблема технических меморандумов усложняется нелинейным образом по мере увеличения объема данных. С 10 людьми документы могут быть просто пронумерованы. Для
100 человек часто достаточно нескольких линейных последовательностей. С тысячей людей, неизбежно разбросанных по нескольким площадкам, потребность в структурированной книге
возрастает, а размер книги увеличивается. Как же тогда должна работать такая механика?

Думаю, что это было хорошо сделано в проекте OS/360. Потребность в грамотно структурированной рабочей книге была настоятельно рекомендована О. С. Локеном (O. S. Locken), который увидел ее эффективность в своем предыдущем проекте, операционной системе 1410-7010.

Мы быстро решили, что каждый программист должен ��идеть весь материал, то есть иметь копию рабочей книги в своем кабинете.

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

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

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

Мы не работали и 6 месяцев, как столкнулись с еще одной проблемой в нашем проекте. Рабочая книга была около пяти футов толщиной! Если бы мы сложили 100 копий, которые обслуживали
программистов в наших офисах в манхэттенском здании Time-Life, то они бы превысили высоту самого здания. Более того, сводка ежедневных изменений имела в толщину в среднем два дюйма, что составляло около 150 страниц, которые должны были быть совмещены с целым. Ведение рабочей книги стало занимать значительное время каждого рабочего дня.

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

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

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

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

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

Обратите внимание, что сама книга не изменилась. Это по-прежнему совокупность всей проектной документации, структурированной в соответствии с тщательным дизайном. Единственное изменение состоит в механике распределения и консультаций. Дуглас Энгельбарт (D. C. Engelbart) и его коллеги из Стэнфордского исследовательского института создали такую систему, и используют ее для сборки и ведения документации для сети ARPA.

Дэвид Парнас (D. L. Parnas) из Университета Карнеги-Меллона предложил еще более радикальное решение. Его тезис заключается в том, что программист наиболее эффективен, если он огражден от подробностей конструкции частей системы, отличных от его собственных. Такой подход предполагает, что все интерфейсы полностью и точно определены. Хотя такой дизайн, безусловно, является здравым, зависимость от его идеального исполнения ведет к катастрофе. Хорошая информационная система не только выявляет ошибки интерфейса, но и стимулирует их исправление.

» Оформить «Предзаказ» можно на сайте издательства сайте издательства

Предлагаем выбрать будущую обложку для нового издания: