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

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

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

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

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

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

Леман и Белади дают свидетельства в пользу того, что квант изменений должен быть либо очень большим и редким, либо очень маленьким и частым. [14] Последняя стратегия, согласно их модели, больше подвержена неустойчивости. Мой опыт это подтверждает: я никогда не рискну использовать ее на практике.

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

Как оказывается, что проект запаздывает на год? … Сначала запаздывает на один день.

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

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

Вехи или помехи?

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

Для выбора всех вех есть только одно пригодное правило. Вехами должны служить конкретные особые события, которые можно идентифицировать с полной определенностью. В качестве отрицательных примеров отметим, что написание программы «закончено на 90 процентов» в течение половины всего времени кодирования. Отладка «закончена на 99 процентов» почти всегда. «Планирование завершено» — событие, которое можно объявить почти произвольно. [1]

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

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

Два интересных исследования поведения правительственных подрядчиков по проведению оценок в крупномасштабных исследовательских проектах показали:

1. Оценки продолжительности работы, тщательно проведенные и пересматриваемые каждые две недели перед началом работы, не сильно меняются по мере приближения начала работы, какими бы неверными они ни оказались в конечном итоге.

2. После начала работы завышенные изначально оценки постоянно уменьшаются по мере продвижения.

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

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

”Другая часть тоже опаздывает”

Отставание от графика на один день — ну и что? Кого волнует отставание на один день? Позже нагоним. Другая часть, в которую входит наша, тоже отстает на один день.

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

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

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

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

Во время выполнения проекта диаграмма ПЕРТ дает ответ на деморализующие извинения типа «другая часть тоже запаздывает». Она показывает, когда необходимо развить энергию, чтобы увести свою часть работы с критического пути, и подсказывает способы наверстать потерянное время в других частях.

Под ковром

Когда менеджер низового звена видит, что его маленькая команда отстает, он не склонен бежать к начальнику со своим горем. Возможно, команда сумеет наверстать время, либо он сможет что-нибудь придумать или реорганизовать для решения проблемы. Зачем же беспокоить этим начальника? До поры до времени это допустимо. Для того и существуют менеджеры низового звена, чтобы решать такие проблемы. А у начальника достаточно других забот, требующих его вмешательства, чтобы искать новые. Так вся эта грязь заметается под ковер.

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