Поражение из-за консерватизма . Люди предпочитают терпеть поражение, но действовать по-старинке, чем идти на риск ради успеха [Pi]. Это объясняет, почему люди уже столько лет используют в работе метод водопада, несмотря на то, что он уже несколько десятков лет не приносит ничего, кроме проблем, и имеет множество альтернатив в лице спирального, инкрементного и итеративного вида разработок.
Изменение привычек . Самая трудная вещь на свете из всего, что я знаю - это заставить человека изменить свои привычки. При этом люди меняют привычки почти спонтанно, если изменить их систему ценностей. За 20 лет работы я видел, как это делали (преднамеренно и сознательно) раза два, и скажу, что это впечатляет.
"Маленькие головы" . Даже от опытных проектировщиков постоянно слышишь: "Я могу удерживать в голове только небольшую долю всей информации". Существует несколько способов ведения документации, которые призваны облегчить подобные задачи, однако ни один из них пока не объединяет в себе использование рабочих артефактов, созданных с "невысокой степенью точности", и активную межличностную коммуникацию.
Я уверен, что существуют и другие свойства человеческой натуры, которые оказывают сильное влияние на процесс разработки ПО, а также на те рекомендации, которые должны давать мы, методологи. Я описал здесь только те, которые в настоящее время сам использую в работе.
Заключение
Основные свойства человеческой натуры имеют первостепенное значение для разработки ПО, а не второстепенное, как принято считать. Следовательно, главной задачей наших исследований должно быть изучение влияния человеческого фактора на процесс разработки. Я предлагаю сделать эту тему основной в области программных разработок на ближайшие 20-50 лет.
В этой статье я привел несколько характерных особенностей человеческой натуры, которые играют существенную роль при разработке методологии.
Во-первых, мы, люди, весьма сильно реагируем на временную синхронизацию и модальности коммуникации. Я считаю, что физическая досягаемость собеседнику и удобство общения имеют здесь решающее значение.
Во-вторых, люди непостоянны. Я считаю, что все методологии, требующие от своих последователей строгой дисциплины, будет сложно осуществлять на практике.
В-третьих, все люди разные, причем не только в зависимости от времени, но и в зависимости от группы, в которой находятся. Сейчас при разработке методологий культурные различия не учитываются, однако это необходимо исправить в ближайшее время.
В-четвертых, люди имеют чувство гражданского долга, хорошо ориентируются в ситуации и берут инициативу в свои руки. Именно из этих качеств и складывается наиболее частая причина успешного завершения работы над проектом: "В ключевой момент разработки несколько человек..".
Человеческой непоследовательности противостоят такие положительные качества, как способность к общению и ориентации в текущей ситуации. Я склонен полагать, что в методологии можно с успехом использовать различные артефакты, выполненные с невысокой степенью точности (разработчики будут восполнять пробелы в процессе коммуникации). Это предположение подтверждается архивами уже завершенных проектов (его можно считать верным при условии наличия необходимой квалификации, как у разработчиков, так и у руководителей).
В названии статьи я называю людей "компонентами". Именно это принято делать в работах, посвященных проектированию процессов и методологий. Ошибкой в таком подходе является то, что "люди", в отличие от "компонентов" весьма изменчивые и нелинейные, причем каждый человек в случае успеха или неудачи ведет себя уникальным образом. Эти факторы имеют первоочередное значение, ими нельзя пренебрегать. Неспособность создателей процессов и методологий принимать их во внимание приводит, как мы это нередко видим, к разнообразным неожиданностям в реализации проекта.
И последнее. Я надеюсь, мне удалось показать, что нам категорически не хватает исследований на эту тему. Может быть теперь, читая статью, которую я написал 30 лет спустя вслед за Вайнбергом, исследователи примут мой вызов. С моей точки зрения, особенно нужны психологические и этнографические исследования, в процессе которых можно будет выявить другие важнейшие факторы, о которых я здесь не упоминаю.
Библиография
[B87] Beck, K. and Cunningham, W., "A laboratory for teaching object-oriented thinking", Proceedings of the OOPSLA Conference, 1987, ACM Sigplan Oct., 1987, pp.1-7.
[B99] Beck, K., Extreme Programming Explained: Embrace Change, Addison Wesley Longman, 1999.
[Br] Britcher, R., The Limits of Software, Addison Wesley, 1999.
[Ch] Christensen, M., et al. , "The M.A.D. experience: multiperspective application development in evolutionary prototyping", in the ECOOP'98 proceedings, Lecture Notes in Computer Science, Vol. 1445, Goos, G., Hartmanis, J, van Leeuwen, J., eds., 1998, pp. 13-41.
[Ci] Citrin, W., Cockburn A., von Kaenel, J., Hauser, R., "Using formalized temporal message-flow diagrams," Software Practice and Experience, 1995.
[Co94] Cockburn A., "In search of methodology," Object Magazine, July 1994.
[Co95] Cockburn A., "Unraveling incremental development," Object Magazine, Jan. 1995.
[Co98] Cockburn A., Surviving Object-Oriented Projects, Addison Wesley, 1998.
[Co98p] Cockburn A., Position statement for "Software development and process" panel, ECOOP '98, online at http://members.aol.com/acockburn/papers/Ecoop98panel.htm
[Co00]Cockburn A., Crystal(Clear): A human-powered software development methodology for small teams, Addison Wesley, in prep. Online at http://members.aol.com/humansandt/crystal/ clear.
[Cs] Csikszentmihalyi, M., Flow: The Psychology of Optimal Experience, Harper Perennial, 1990
[C3] The C3 Team, "Chrysler goes to 'Extremes'", in Distributed Object Computing, October, 1998, pp. 24-28.
[Dm] DeMarco, T., Lister, T., Peopleware 2nd Edition, Dorset House, 1999.
[EP] Extreme Programming, web notes, start from www.extremeprogramming.com.
[Gr] Gries, D, The Science of Programming, Springer Verlag, 1987.
[Ha] Harel, D., Politi, M., Modeling Reactive Systems with Statecharts, McGraw-Hill, 1998.
[Hi] Highsmith, J., Adaptive Software Development, Dorset House, 1999.
[Ho] Hovenden, F., "An ethnographic account of writing use cases on an IT project", Humans and Technology Technical Memo, 1999.10.30, online at http://members.aol.com/humansandt/papers/ethno1.htm.
[Hu] Humphrey, W., A Discipline for Softwrae Engineering, Addison Wesley, 1995.
[Je] Jeffries, R., "Extreme testing", in Software Testing and Quality Engineering, March/April, 1999, pp. 23-26.
[J-L] Johnson-Laird, P. and Byrne, R. Deduction, Lawrence Erlbaum Associates, 1991.
[La] Lave, J., Situation Learning: Legitimate Peripheral Participation, Cambridge Press, 1991.
[Mi] Mills, H., Dyer, M., Linger, R., "Cleanroom Software Engineering," IEEE Software Vol 2 (1984) No. 9, 19-24.
[NASA] JSC38609, "Deorbit flight software lessons learned", NASA Johnson Space Center, Jan 19, 1998 online at
[Pi] Piatelli-Palmarini, M., Inevitable Illusions : How Mistakes of Reason Rule Our Minds, Wiley amp; Sons, 1996.
[Pl] Plowman, L., "The interfunctionality of talk and text", Computer Support of Cooperative Work, vol. 3, 1995, pp.229-246.
[Si] Sillince, J.A., "A model of social, emotional and symbolic aspects of computer-mediated communication within organizations", Computer Support of Cooperative Work vol. 4, 1996, pp. 1-31.
[Web] Webb, D., Humphrey, W., "Using TSP on the TaskView Project", in CrossTalk, The Journal of Defense Software Engineering , Feb 1999, pp. 3-10, online at http://www.stsc.hill.af.mil/crosstalk/1999/feb/webb.asp
[Wei] Weinberg, J., The Psychology of Computer Programming, Silver Edition, Dorset House, 1998.
[Yo] Yourdon, E., Death March Projects, Prentice Hall, 1997.