ПОДВЕДЕНИЕ ИТОГОВ

ПОДВЕДЕНИЕ ИТОГОВ

Итак, традиционный процесс создания ПО имеет следующие характеристики:.
■ Последовательный переход от требований к разработке, кодированию и тестированию.
■ Достижение 100%-ной готовности всех видов рабочих продуктов на каждой стадии жизненного цикла.
■ Рассмотрение всех требований, рабочих продуктов, компонентов и т.д. на равных основаниях.
■ Достижение высокоточного соответствия между всеми рабочими продуктами на каждой стадии жизненного цикла.
К основным характеристикам современного процесса итерационной разработки относятся:.
■ Непрерывная «круговая» разработка, начиная от требований и заканчивая тестированием, на постоянно меняющемся уровне абстракции.
■ Максимально полное понимание определяющих требований (20%) настолько рано, насколько это практически осуществимо.
■ Совершенствование рабочих продуктов вглубь и вширь, основанное на приоритетах, определяемых управлением рисками.
■ Отнесение анализа на предмет завершенности и непротиворечивости на более поздние стадии жизненного цикла.
Схема современного процесса направлена против главных причин платы за большой масштаб, присущей традиционному процессу создания ПО. На рис. 17.1 показано следующее поколение процесса выполнения проекта по созданию ПО с помощью графика зависимости прогресса разработки от времени, причем прогресс определяется как процент написанного кода (который можно продемонстрировать в его окончательной форме). (Рисунок имеет тот же формат, что и рис. 1.2 и 15.1.)
Рис. 17.1. Процесс выполнения проекта следующего поколения.
Моей целью было объяснить, каким образом можно переместиться в верхнюю, темную область, используя современный процесс, который поддерживается совершенной, полностью интегрированной средой и архитектурой, основанной на компонентах. Преуспевающие организации смогут поставлять программные продукты, которые большей частью конструируются из уже существующих компонентов за меньшее на 50% время, с меньшими на 50% затратами ресурсов на разработку и которые сопровождаются командами на 50% меньшими тех, что требуются для современных систем.
Переход любой организации к новым способам и технологиям всегда сопровождается мрачными предчувствиями и опасениями относительно возможной неудачи. Сохранение существующего статус-кво и доверие к уже испробованным методам обычно признается наиболее безопасным путем. В индустрии ПО, в которой для большинства организаций процент успешно завершенных проектов весьма мал, путь сохранения статус-кво не всегда является самым безопасным. Когда организация решается на осуществление перехода, то поборниками перехода внутри организации и деятелями со стороны обычно даются две рекомендации, основанные на традиционном подходе: (1) опробовать новые технологии на небольших пилотных программах и (2) быть готовыми к дополнительным затратам ресурсов — денег и времени — на первый проект, на котором осуществляется переход. Я считаю обе рекомендации непродуктивными.
Небольшие пилотные программы редко приводят к важным изменениям парадигмы. Опробование нового небольшого способа, инструмента или метода на скоротечной маломасштабной работе — скажем, менее трех месяцев и всего лишь несколько исполнителей — зачастую дает хорошие результаты, начальный толчок или подтверждение концепции. Проблема с пилотными программами заключается в том, что они почти никогда не находятся на критичных путях развития организации. Соответственно они не заслуживают привлечения специалистов высшей категории, адекватных ресурсов и внимания менеджеров.
Наиболее плодотворные изменения в организационной парадигме, которые мне когда-либо встречались, являлись результатом приблизительно такого набора обстоятельств: организация выбирала наиболее критичный для нее проект и персонал высшего разряда, предоставляла адекватные ресурсы и требовала получения высоких результатов. С другой стороны, если организация ожидает от нового метода, инструмента или технологии неблагоприятного влияния на результаты выполнения новаторского проекта, такие ожидания обычно оправдываются. Почему? Потому что ни один менеджер организации не будет сознательно оказывать неблагоприятное воздействие на наиболее важные проекты организации, и такие проекты — это место, где собираются лучшие люди. Следовательно, новаторский проект окажется не критичным проектом, над которым работают не критичные сотрудники, от которых не приходится ожидать многого. Такие непритязательные ожидания зачастую оказываются самосбывающимся пророчеством.
Лучший способ перейти к более зрелому итерационному процессу разработки, который поддерживает технологии автоматизации и современную архитектуру, это произвести выстрел:.
■ Готовься. Выполните свое домашнее задание. Проанализируйте современные подходы и технологии. Определите (или усовершенствуйте, или оптимизируйте) ваш процесс. Обеспечьте его совершенной средой, инструментарием и компонентами. Тщательно спланируйте.
■ Целься. Выберите критичный проект. Наберите хорошую команду, обеспечьте ее дополнительными ресурсами и потребуйте высоких результатов.
■ Огонь. Выполните организационный план и план проекта строго и до конца.