Изменить стиль страницы

Экстремальное программирование весьма полезно, когда его рассматривают как набор стратегий управления риском. Двухнедельный цикл планирования и поставки, определенный клиентом, является встроенной стратегией ослабления риска с определенной клиентом стоимостью и предназначен для предотвращения опозданий поставки. Как указывают Бек и Фаулер на стр. 18, «хороший клиент хочет принять полную ответственость за успех или провал проекта». Может ли такое случится в вашей работе?

Gilb, Tom. Principles of Software Engineering Management, ed. Susannah Finzi. Wokingham, England: Addison-Wesley, 1988.

Гилб – один из сильнейших и самых ранних защитников инкрементной разработки, которую он называет «эволюционными поставками».

«Посмертный» анализ

Collier, Bonnie, Tom DeMarco. and Peier Fcarey. «A Defined Process for Project Postmortem Review.» IEEE Software, Vol. 13, No. 4 (July 1996), pp. 65-72.

Как указывает название статьи, нужен определенный процесс, а не погружение в воспоминания!

Kerth, Norman L. Project Retrospectives: A Handbook for Team Reviews. New York: Dorset House Publishing, 2001.

Эта маленькая книжка поможет вам установить связь с прошлым, чтобы мы могли научиться лучше действовать в будущем.

Сказки реального мира

Bernstein, Peter L. Against the Gods: The Remarkable Story of Risk. New York: John Wiley amp; Sons, 1996.

Эта книга рассказывает историю группы мыслителей, показавших миру, как понимать и измерять риск, отмечая на стр. 1, что «революционная идея, определяющая границу между современностью и прошлым, является господством риска…»

Bridges, William. Managing Transitions: Making the Most of Change. Reading, Mass.: Perseus Books, 1991.

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

Petroski, Henry. To Engineer Is Human: The Role of Failure in Successful Design. New York: Vintage Books, 1992.

Петроски, профессор отделения гражданского строительства и охраны окружающей среды в университете Дкжа (Duke University), пишет о том, как на практике инженеры весьма успешно справлялись с реальным риском. Настоящая классика, впервые опубликованная в 1985 году.

Rawnsley, Judith H. Total Risk: Nick Leeson and the Fall of Barings Bank. New York: Harper Business, 1995.

Как 28-летний трейдер разрушил могущественное финансовое учреждение? Один неправильный прогноз за другим, и никто не побеспокоился проследить! Ощутимый результат отсутствия управления риском. Вы просто не сможете такое вообразить.

U.S. Marine Corps Staff. Weighting: The U.S. Marine Corps Book of Strategy. New York: Currency Doubleday, 1994.

Что? Книга о том, как воевать? Да, эта потрясающая книжица о том, как воевать, и о том, как преуспеть в проектах по разработке программного обеспечения. И еще раз да, она вам абсолютно подходит.

Vaughan, Karen. The Challenger Launch Decision: Risky Technology, Culture, and Deviance at NASA. Chicago: University of Chicago Press. 1996.

Официальный отчет утверждает, что космический челнок Challenger погиб из-за политического и экономического нажима, которые возобладали над разумным управлением рисками. Эта книга, будучи серьезным академическим исследованием, предлагает нечто гораздо более тонкое, причем гораздо более близкое любой организации.

Анализ основных причин

Andersen, Bjorn, ed. Root Cause Analysis: Simplified Tools and Techniques. Milwaukee: American Society for Quality, 1999.

Пользующийся большим успехом подход к предмету.

Gano, Dean. Apollo Root Cause Analysis: A New Way of Thinking, ed. Vicki E. Lee. Yakima, Wash.: Apollonian Publications, 1999.

Еще один очень популярный текст по анализу основных причин.

Goal/OPC. «Hoshin Planning Research Report.» Salem, N.H.: Goal/QPC, 1989.

Обратите особое внимание на главу 4 «Диаграммы сходства и метол KJ»

Shiba, Shoji, Alan Graham, and David Walden. A New American TQM. Portland, Orcg.: Productivity Press, 1993.

Анализ основных причин, на этот раз в контексте общего управления качеством.

Спиральные модели взаимной выгоды

Boehm, Barry W., and Hoh In. «Identifying Quality-Requirements Conflicts.» IEEE Software. Vol. 13. No. 2 (March 1996), pp. 25-35.

Интересное введение. Для более основательного ознакомления с этими моделями посмотрите сайт университета Южной Калифорнии http://sunset.usc.edu/researcli/WINWIN/winwinspiral.himl