Выбор обложки книга «Мифический человеко-месяц, или Как создаются программные системы»
Привет, Хаброжители! Мы сдаем в типографию юбилейное издание книги Брукса. Просим вас выбрать обложку и ознакомиться с отрывком «Управленческий аудит Вавилонского проекта».
Первое издание этой книги было написано еще в 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) из Университета Карнеги-Меллона предложил еще более радикальное решение. Его тезис заключается в том, что программист наиболее эффективен, если он огражден от подробностей конструкции частей системы, отличных от его собственных. Такой подход предполагает, что все интерфейсы полностью и точно определены. Хотя такой дизайн, безусловно, является здравым, зависимость от его идеального исполнения ведет к катастрофе. Хорошая информационная система не только выявляет ошибки интерфейса, но и стимулирует их исправление.
» Оформить «Предзаказ» можно на сайте издательства сайте издательства
Предлагаем выбрать будущую обложку для нового издания:
