Читаем Путь камикадзе [Смертельный марш] полностью

Итак, пожалуйста, не надо воспринимать эту главу как предлог для отказа от каких-либо процессов, методологий или методов вообще; в самом деле, это может погубить безнадёжный проект. Фокус заключается в том, чтобы отыскать те процессы, методологии или методы, которые действительно работают, и которым команда будет следовать естественным образом и бессознательно. Последнее особенно важно: команда испытывает такой стресс и давление, что должна делать многие вещи чисто инстинктивно. Если взвалить на команду бремя новых, незнакомых процессов, которые настолько сложны, что они вынуждены будут каждые пять минут останавливаться и заглядывать в руководство, чтобы определить, что делать дальше, то все пропадёт впустую. Поэтому надо поступать проще – и если команда может запомнить только одно слово, этим словом должно быть приоритетность.


Литература к главе:

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 году, когда я только начинал свою карьеру программиста.

Перейти на страницу:
Нет соединения с сервером, попробуйте зайти чуть позже