Чтение онлайн

(Свифт)

"Общепринято выбрать метод, а затем опробовать его. Если он неудачен, оставьте его и испробуйте другой. Но как бы то ни было, не оставляйте попыток".

(Ф. Д, Рузвельт)

Опытные установки и увеличение масштабов

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

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

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

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

Постоянны только изменения

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

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

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

Тем нс менее, некоторые изменения в целях и задачах неизбежны, и лучше быть готовым к ним, чем считать, что их не будет. Неизбежны изменения не только в целях, но н в стратегии и методах разработки. Концепция "работы в корзину" сама по себе является принятием того факта, что, научившись чему-то, мы вносим в проект изменения4).

Планирование изменений в системе

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

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

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

Планирование изменений в организации

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

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

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

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

Барьеры носят социологический характер, и при их преодолении следует постоянно проявлять бдительность. Во-первых, сами руководители зачастую считают ведущих специалистов "слишком ценными" для того, чтобы использовать их непосредственно в программировании. Во-вторых, работа .в области административного управления имеет более высокий престиж. Чтобы справиться с этой проблемой, на некоторых предприятиях, например в фирме Bell Labs, отказались от каких бы то ни было титулов и званий. Каждый профессинальный служащий является "штатным техническим сотрудником". Другие, например, фирма IBM, имеют двойную лестницу продвижения по службе (см. рис. 11.1). Ступени теоретически эквивалентны.

Рис. 11.1. Двойная лестница продвижения по службе в фирме IBM.

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