Как я говорил ранее, самая большая проблема, связанная с CASE-средствами, заключается в том, что они поддерживают (а иногда навязывают) определённую методологию, которую проектная команда не понимает и не желает использовать.

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

Упомянутая выше проблема CASE-средств, вероятно, представляет собой наиболее очевидный пример трюизма: средства и процессы связаны друг с другом достаточно сложным образом. Бессмысленно браться за CASE-средство, поддерживающее структурный анализ, если вы никогда не слышали сокращений DFD и ERD. Использование такого CASE-средства будет не только бесполезным, но и чрезвычайно обременительным, если проектная команда искренне полагает, что DFD и ERD представляют собой лишённые смысла формы бюрократических документов, преследующие единственную цель: чтобы блюстители методологии могли прикрыть свои задницы.
Но ситуация не всегда бывает такой черно-белой. Например, проектная команда может считать, что диаграммы потоков данных полезны, но только как «неформальное» средство моделирования. Таким образом, «гибкое» CASE-средство может рассматриваться как нужное и полезное, в то время как «жёсткое» CASE-средство может быть отвергнуто. Можно провести очевидную аналогию с текстовым процессором: мы все способны оценить достоинства проверки орфографии, но не хотим, чтобы нас заставляли её использовать, и вполне вероятно, что мы её никогда не использовали, поскольку проверка орфографии слишком медленна и неудобна (по крайней мере, именно под таким предлогом я не использую её в Microsoft Word!). Мы будем ещё больше раздражаться, если текстовый процессор будет настойчиво отвергать слово «ain’t» как ошибочное, или требовать, чтобы любые фразы, содержащие утверждения расистского или женоненавистнического характера, утверждались специальным комитетом. Нескольких таких «замечательных» свойств может оказаться достаточно, чтобы вынудить нас вернуться к бумаге и карандашу.
Все это означает, что команда безнадёжного проекта должна в первую очередь нормально воспринимать те процессы и методологии, которым она собирается следовать; кроме того, она должна решить, каким из этих процессов следовать беспрекословно, а каким — следовать духу, но не букве закона. После принятия такого решения можно соответственно выбрать (или отвергнуть!) средства и технологию. Таким же образом менеджер проекта может решить использовать какое-либо средство для усиления процесса, необходимость которого все понимают, но на практике следуют ему достаточно небрежно; хорошие примеры таких процессов — контроль версий и управление конфигурацией.
Один из величайших мифов, касающихся использования инструментальных средств в любых проектах (и особенно опасных в безнадёжных проектах) заключается в отношении к средству как к «серебряной пуле», которая позволит творить чудеса. Разумеется, поиском чудес занимается в основном высшее руководство, однако даже менеджера проекта могут соблазнить рекламные заявления поставщика, уверяющего, что с помощью его гениальных средств можно в десять раз повысить производительность программирования, тестирования или какой-нибудь другой деятельности.
Помимо проблемы, заключающейся в новизне таких средств и в том, что никто не знает, как их использовать (о чем будет говориться ниже), существует более важный момент: средство может стать подобным «серебряной пуле» только в том случае, если оно будет позволять или заставлять разработчиков изменять свои процессы. Например, если я пишу программу, а затем компилирую её, я делаю это в соответствии с определённым процессом. При этом программированию может предшествовать процесс сквозного контроля или тщательного, формального проектирования. Теперь, если вы дадите мне компилятор, который работает на 10% быстрее, чем предыдущий, это облегчит мою работу и сделает её несколько более эффективной; может быть, незначительно возрастёт продуктивность всего проекта в целом. Но мне не придётся менять свой процесс.
С другой стороны, если мне дадут компилятор, который работает в десять раз быстрее, то он изменит мой процесс. Так произошло, когда мы перешли в 70-е годы от ночной пакетной компиляции к онлайновой компиляции, затем к компиляции на собственных ПК и рабочих станциях в 1980-е годы, и затем к различным сочетаниям пошаговой компиляции (а ля Delphi) и интерпретации (а ля Visual Basic). Вследствие этого многие разработчики отказались от тщательного проектирования, предшествующего кодированию, из тех соображений, что они смогут писать программы на ходу и импровизировать в процессе кодирования; во многих проектах отказались также от практики сквозного кодирования, полагая, что программист и так сможет быстро обнаружить и исправить свои ошибки.
Едва ли кто-нибудь станет возражать против использования усовершенствованных технологий, позволяющих избавляться от рутинных и утомительных процессов. Гораздо труднее внедрить новую технологию, требующую введения новых процессов или модификации существующих процессов, к которым мы привыкли. Хорошим примером служит процесс повторного использования и связанная с ним технология библиотек повторно используемых компонент, броузеров и других средств. Проектные команды, использующие эту технологию, могут повысить уровень повторного использования кода приблизительно от 20 процентов (уровень, который я называю «случайным») до 60 процентов и более; разумеется, если технология используется в масштабе всей организации, то уровень повторного использования может достигать 80-90 процентов и более.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71