Средства и процессы

Проблема CASE-средств, вероятно, представляет собой наиболее очевидный пример трюизма: средства и процессы связаны друг с другом достаточно сложным образом. Бессмысленно браться за CASE-средство, поддерживающее структурный анализ, если разработчики никогда не слышали сокращений DFD и ERD. Использование такого CASE-средства будет не только бесполезным, но и чрезвычайно обременительным, если проектная команда искренне полагает, что DFD и ERD представляют собой лишенные смысла формы бюрократических документов.

Но ситуация не всегда бывает такой черно-белой. Например, проектная команда может считать, что диаграммы потоков данных полезны, но только как неформальное средство моделирования. Таким образом, "гибкое" CASE-средство может рассматриваться как нужное и полезное, в то время как "жесткое" CASE-средство может быть отвергнуто. Можно провести очевидную аналогию с текстовым процессором: все способны оценить достоинства проверки орфографии, но не все хотят, чтобы ее заставляли использовать.

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

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

Помимо проблемы, заключающейся в новизне таких средств и в том, что никто не знает, как их использовать (о чем будет говориться ниже), существует более важный момент: средство может стать подобным "серебряной пуле" только в том случае, если оно будет позволять или заставлять разработчиков изменять свои процессы. Например, если разработчик пишет программу, а затем компилирует ее, он делает это в соответствии с определенным процессом. При этом программированию может предшествовать процесс сквозного контроля или тщательного, формального проектирования. Теперь, если ему дадут компилятор, который работает на 10% быстрее, чем предыдущий, это облегчит работу и сделает ее несколько более эффективной; может быть, незначительно возрастет продуктивность всего проекта в целом. Но разработчику не придется менять свой процесс.

С другой стороны, если появится компилятор, который работает в десять раз быстрее, то он изменит процесс. Так произошло, когда разработчики перешли в 70-е гг. от ночной пакетной компиляции к онлайновой компиляции, затем - к компиляции на собственных ПК и рабочих станциях в 80-е гг. и затем - к различным сочетаниям пошаговой компиляции (а ля Delphi) и интерпретации (а ля Visual Basic). Вследствие этого многие разработчики отказались от тщательного проектирования, предшествующего кодированию, из тех соображений, что они смогут писать программы на ходу и импровизировать в процессе кодирования. Во многих проектах отказались также от практики сквозного кодирования, полагая, что программист и так сможет быстро обнаружить и исправить свои ошибки.

Едва ли кто-нибудь станет возражать против использования усовершенствованных технологий, позволяющих избавляться от рутинных и утомительных процессов. Гораздо труднее внедрить новую технологию, требующую введения новых процессов или модификации существующих процессов, к которым все привыкли. Хорошим примером служит процесс повторного использования и связанная с ним технология библиотек повторно используемых компонентов, браузеров и других средств. Проектные команды, использующие эту технологию, могут повысить уровень повторного использования кода приблизительно от 20% (уровень, который можно назвать "случайным") до 60% и более. Разумеется, если технология используется в масштабе всей организации, то уровень повторного использования может достигать 80 — 90% и более.

Разница между 20- и 80%-ным уровнем повторного использования эквивалентна четырехкратному повышению производительности. Постепенное повышение уровня повторного использования приносит больше выгод, чем можно было бы ожидать. Если уровень повторного использования возрастает с 80 до 90%, это означает, что вместо разработки "с нуля" 20% кода проектной команде придется разрабатывать только 10%. Таким образом, их загрузка снизится вдвое.

Все это вполне достойно называться "серебряной пулей", но совершенно бесполезно, если проектная команда (и в конечном счете вся организация) окажется неспособной или не пожелает менять свои процессы в соответствии с требованиями технологии повторного использования. Ирония заключается в том, большинство организаций поставят в вину самой технологии свои собственные провалы: они приобретут дорогостоящую библиотеку классов или поменяют свою старую технологию разработки ПО на объектно-ориентированную технологию исходя из предположения, что объекты и повторное использование — это одно и то же. Когда они в конечном счете обнаружат, что не добились сколько-нибудь ощутимых результатов, то будут винить во всем объектную технологию, библиотеку классов, поставщика и др. Между тем все процессы остались в точности такими же, какими были до внедрения новой технологии. Культура такой организации может быть выражена следующей фразой: "Только бездари пользуются чужим кодом; настоящие программисты, черт возьми, пишут свой!"

Относительно экстремального проекта в этом заключена весьма простая мораль: если внедрение новых средств потребует серьезного изменения "стандартных" процессов команды, то это значительно увеличит проектный риск и, возможно, будет способствовать провалу проекта. Иногда дополнительные проблемы вносит необходимость обучения и освоения практического использования новых средств. Однако обычно гораздо более серьезной проблемой является изменение режима работы, который целиком определяется процессом. Это довольно трудно сделать и в нормальных условиях, когда достаточно времени, чтобы относительно безболезненно перейти к новому процессу. Для экстремального проекта такой переход будет просто катастрофическим.