Джозеф Фокс - Программное обеспечение и его разработка

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

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

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

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

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

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

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

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

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

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

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

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

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

Первое качество, на которое надо обращать внимание при выборе руководителя разработки программного обеспечения, это не его технические возможности и даже не его личный опыт, а его эмоциональная зрелость и «неуступчивый» характер. Хорошие руководители разработкой умеют соразмерять цели с реальностью и могут твердо стоять на своем, говоря «нет» непрерывным требованиям ввести «еще несколько» функций, совсем немного здесь и еще чуть-чуть там. Такое наращивание функций называется «потерей элегантности» и может оказаться фатальным. Они знают, что время, необходимое на выполнение n + 1 тривиальных вещей, вдвое больше времени, необходимого на выполнение n вещей, если n стало уже достаточно большим (возражение Логга на закон Грея) [42] Dickson P. The Official Rules, New York: Delacorte Press, 1978. . Они знают, что Брукс был прав, когда в книге «Мифический человеко-месяц» написал: «Как получается, что программы опаздывают на год? Это происходит постепенно». Они знают, что требования являются первой линией обороны. Не допускай «врага» к этим позициям, и ты будешь контролировать все события.