а) осуществить сборку программного обеспечения;
б) определить, кому какая версия ПО принадлежит;
в) определить, почему ПО работает на одной системе и не работает на другой.
2) Регистрации узких мест и дефектов с помощью системы конфигурационного управления. В результате стало совершенно невозможно оперативно выяснить, какие ошибки устраняются, а какие проигнорированы; какие компоненты закончены и могут тестироваться.
3) Документальной фиксации основных требований, проектных решений и вариантов, узловых точек в процессе разработки и используемых тестов. В результате участникам проектной команды оказалось чрезвычайно трудно добиться взаимопонимания не только относительно текущего состояния проекта, но также и относительно основных решений, принятых в самом начале проекта.
Итак, пожалуйста, не надо воспринимать эту главу как предлог для отказа от каких-либо процессов, методологий или методов вообще; в самом деле, это может погубить безнадёжный проект. Фокус заключается в том, чтобы отыскать те процессы, методологии или методы, которые действительно работают, и которым команда будет следовать естественным образом и бессознательно. Последнее особенно важно: команда испытывает такой стресс и давление, что должна делать многие вещи чисто инстинктивно. Если взвалить на команду бремя новых, незнакомых процессов, которые настолько сложны, что они вынуждены будут каждые пять минут останавливаться и заглядывать в руководство, чтобы определить, что делать дальше, то все пропадёт впустую. Поэтому надо поступать проще — и если команда может запомнить только одно слово, этим словом должно быть приоритетность .
Литература к главе:
1) Stephen R. Covey, Roger A. Merill, Rebecca R. Merill. First Things First. New York: Simon & Schuster, 1994.
2) Watts Humphrey. A Discipline of Software Engineering. Reading, MA: Addison-Wesley, 1995.
3) James Bach. The Challenge of ‘Good Enough’ Software. American Programmer, October 1995.
4) Jim McCarthy. Dynamics of Software Development. Redmond, WA: Microsoft Press, 1995.
5) G. Pascal Zachary. Show-Stopper! New York: Free Press, 1994.
6) Rob Thomsett. The Indiana Jones School of Risk Management. American Programmer, September 1992.
7) Capers Jones. Assessment and Control of Software Risks. Englewood Cliffs, NJ: Prentice Hall, 1994.
8) Rob Charette. Building Bridges over Intellectual Rivers. American Programmer, September 1992.
Дополнительная литература:
1) 1. Alan M. Davis. Software Requirements: Objects, Functions, and States. Englewood Cliffs, NJ: Prentice Hall, 1993.
2) Mark C. Paulk, Charles V. Weber, Bill Curtis, Mary Beth Chrises, et al. The Capability Maturity Model: Guidelines for Improving the Software Process. Reading, MA: Addison-Wesley, 1995.
3) Robert N. Charette. Application Strategies for Risk Analysis. New York: McGraw-Hill, 1990.
4) Robert N. Charette. Software Engineering Risk Analysis and Management. New York: McGraw-Hill, 1989.
ГЛАВА 6.
ТЕХНОЛОГИЯ И СРЕДСТВА
Летом 1992 года мне довелось обедать с дружной группой менеджеров среднего уровня Microsoft. Во время завязавшейся беседы я спросил, является ли для проектных команд Microsoft обычным делом использование таких методологий, как структурный анализ или объектно-ориентированное проектирование. Ответы были примерно следующими: «иногда», «хммм, вроде бы да», «от случая к случаю» и «а что это такое?». Когда же я спросил их относительно использования CASE-средств (которые в то время все ещё были довольно популярными в индустрии ПО), то из их ответов понял, в чем заключается общее мнение майкрософтовцев: такие средства годятся для «людей с улицы». С таким выражением я ещё не встречался, его можно грубо интерпретировать как «невежественные дикари, которые только что вылезли из своего первобытного леса и начали обучаться программированию, в отличие от настоящих программистов, которые не нуждаются во всяких финтифлюшках».
Будучи слегка уязвлённым, я поинтересовался, используют ли их проектные команды хоть какие-нибудь средства, и в ответ услышал, что каждая команда Microsoft может выбрать любые средства, которые сочтёт подходящими для своего проекта. Ухватившись за такой ответ, я спросил, какое средство считает наиболее важным типичная проектная команда?
«На днях я задал одной из проектных команд такой же вопрос», — ответил один из менеджеров. «Как вы думаете, что они ответили?»
«Какой-нибудь высокопроизводительный компилятор С++?», — спросил я. «Ассемблер? Или мощное средство отладки для устранения множества ошибок в их коде (хи-хи-хи) ?»
«Ничего подобного», — ответил менеджер, игнорируя моё гнусное хихиканье. «Они ответили: электронная почта . Средний разработчик Microsoft получает сотню сообщений в день; он живёт в электронной почте. Уберите электронную почту, и проект умрёт».
Рассказывая этот анекдотический случай, я неспроста в самом начале упомянул 1992 год: эти события происходили до начала эры Internet и World Wide Web. Сотня почтовых сообщений в день потрясла моё воображение; в 1992 году я был безумно счастлив, если получал два или три сообщения в день. Однако можно представить себе, что если бы такой же вопрос о «наиболее важном средстве» был задан в 1996 году, ответом могло быть «World Wide Web»; по аналогии, «факс» в 1987, «ПК» в 1983, «онлайновый терминал» в 1976 и «мой собственный телефон на рабочем столе» в 1964 году, когда я только начинал свою карьеру программиста.
Очевидно, не следует ожидать, что команда безнадёжного проекта сможет ограничиться только одним средством. Большинство команд — даже в «нормальных» проектах — пользуются в своей повседневной работе самыми разнообразными средствами и технологиями. Правда, иногда количество средств становится чересчур большим, технологии — слишком новыми, а иногда нежелательные средства навязываются им некомпетентными менеджерами.
Если вас встревожили эти обстоятельства, позвольте мне уверить вас, что я вовсе не собираюсь агитировать за использование экзотических, суперсовременных средств, которые, телепатически взаимодействуя с программистом, получают из его беспорядочных мыслей хорошо структурированный код. Напротив, я хочу обсудить понятие «минимально необходимого набора средств» для безнадёжных проектов. Я хочу также обратить особое внимание на критически важные взаимосвязи между средствами и процессами, особенно поскольку процессы в безнадёжном проекте, скорее всего, отличаются от тех, которые используются в организации. И, наконец, я хочу предостеречь от использования в безнадёжном проекте совершенно новых средств.
6.1 Минимально необходимый набор средств
В предыдущей главе я настоятельно рекомендовал устанавливать приоритеты для пользовательских требований. Такой же подход можно использовать по отношению к средствам и технологии: существуют средства, которые «необходимо использовать», «следует использовать», и огромное разнообразие средств, которые «можно использовать». Этот подход разумно применить в самом начале проекта, и тому есть ряд причин.
Наиболее очевидная причина лежит в плоскости экономики. Даже если средства хорошо работают и все знакомы с ними, их приобретение может стоить слишком дорого. Кроме того, на их получение может уйти слишком много времени — процесс приобретения в условиях обычной корпоративной бюрократии может завершиться уже после окончания проекта. Для большинства безнадёжных проектов следует сосредоточиться на небольшом количестве критически важных средств, и затем убедить высшее руководство (или соответствующую службу) в необходимости их приобретения.
С другой стороны, предположим, что команда работает в крупной корпорации, имеющей в своём распоряжении сотни различных средств, приобретавшихся в течение целого ряда лет.
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