Алистэр Коуберн - Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения

• Название: Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения
• Автор: Алистэр Коуберн
• Издательство: Humans and Technology
• Жанр: Деловая литература
• Год: 1999

Мы, методологи, проектируем сложные системы, но не принимаем во внимание рабочие характеристики активного компонента этих систем, компонента, который известен своей нелинейностью и изменчивостью - человека. В этой статье вкратце перечислены те теории и проекты, которые мне пришлось изучить, чтобы осознать этот совершенно очевидный факт, а также определить, какие качества человеческой психики должны учитываться в создании методологии и более общих рекомендациях касающихся процесса разработки. Именно по этим качествам можно делать наиболее верные прогнозы относительно будущего течения проекта и применимости к нему какой-либо методологии.

---

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

Вариации поведения культур методологу учитывать еще труднее, чем вариации каждодневного поведения отдельных индивидуумов. На сегодняшний день я не знаю ни одной методологии, при создании которой принимались бы во внимание культурные особенности (моя методология - не исключение). Впрочем, я знаю людей, которые учитывают местные культурные особенности при формулировании методологических рекомендаций.

И другие

Вот еще несколько свойств человеческой натуры, на которые я полагаюсь. Они приводятся здесь кратко, в виде списка:

Обучение . Человек обучается с помощью наблюдения и практики. Это когнитивный и социальный принцип, хорошо известный в определенных кругах [La], однако до сих пор не использующийся должным образом при разработке программного обеспечения. Я пытаюсь найти возможность применить этот принцип на практике, но пока не придумал для этого подходящей методологической структуры.

Поток . В контексте программных разработок "поток" означает время, отведенное для спокойного эффективного размышления над задачей [Dm], [Cs], [Co98]. Это время должно быть уравновешено временем, отведенным для коммуникаций. Как установить подобный баланс при напряженном процессе работы над проектом - выше моего понимания. Тем не менее, многие особо подчеркивают, что время, отведенное на спокойное размышление, играет заметную роль в конечном успехе проекта.

Работа по примерам . Некоторые когнитивные психологи убедительно доказывают, что наш механизм дедукции основан на создании отдельных примеров проблем [J-L]. CRC-карточки и варианты использования (use cases) - два способа разработки программного обеспечения, построенные на примерах. Кстати сказать, те, кто их используют, неоднократно свидетельствуют об их эффективности. Новички часто предпочитают "диаграммы экземпляров" (instance diagrams) правильному объектно-ориентированному проектированию. Впрочем, ими пользуются даже опытные проектировщики. Идея создания документации, основанной на примерах, пока не нашла должного отклика у методологов, и представляет собой тему для дальнейшей работы в этой области.

Кинетическое и мульти-сенсорное мышление . CRC-карточки, разыгрывание ролей при анализе и проектировании, рисование на доске, создание прототипов интерфейсов на бумаге, все эти виды деятельности подразумевают, что во время размышлений человек говорит и движется. Пока на эту тему нет исследований, я могу лишь сказать, что в программных разработках можно продуктивно использовать все эти техники.

Личные свойства характера . Вы и сами, наверное, не раз видели крайне нелюдимых главных проектировщиков, которые бросают на произвол судьбы свою команду. И, не смотря ни на что, эти прекрасные программисты продолжают занимать должности, которые требуют от человека большой общительности! Нередко мы можем встретить и руководителей проектов, которые не умеют принимать решения. Однако для конечного успеха проекта очень важно, насколько личные качества человека подходят для занимаемой им должности. Эти качества нужно учитывать и с точки зрения профессионального роста человека, однако нередко такие должности являются единственным способом продвижения по служебной лестнице.

Поражение из-за консерватизма . Люди предпочитают терпеть поражение, но действовать по-старинке, чем идти на риск ради успеха [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.