Чтение онлайн

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

Впрочем, описание динамического изменения методологии не входит в рамки этой конкретной статьи. Некоторую информацию по этой теме можно почерпнуть в работе [Cockburn98], но более подробно она будет представлена в отдельной статье.

Любая методология состоит из десяти основных элементов: ролей, навыков, видов деятельности, используемых техник, инструментария, поставляемых артефактов, стандартов, мер качества и приоритетов проекта. Главным результатом моей работы, который я обобщил в этой статье, стало обязательное наличие многих разнообразных методологий. В зависимости от размера проекта (числа людей, работу которых необходимо координировать), критичности разрабатываемого приложения и основных приоритетов , в проекте могут применяться различные методологии. Для любой точки в пространстве размер/критичность создатели методологии выбирают определенный ряд аспектов (роли в проекте, виды деятельности, поставляемые продукты и стандарты) и пытаются минимизировать риски, связанные с некоторыми качествами проекта. При этом они базируются на своем личном опыте , к которому относятся также их намерения, страхи и философские воззрения. При сравнении различных методологий необходимо учитывать все эти моменты, а также их соотношения с нуждами проекта или организации.

Мы выяснили четыре основных принципа проектирования методологии. Вкратце их можно описать следующим образом:

чем больше команда, тем "тяжелее" должна быть используемая методология;

увеличивайте "плотность" методологии при увеличении критичности проекта;

чем "тяжелее" методология, тем выше стоимость проекта;

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

[Beck99] Beck, K., Extreme Programming Explained: Embrace Change , Addison-Wesley, 1999.

[C3a] The "C3" Team, "Chrysler goes to 'Extremes'", in Distributed Object Computing, October, 1998, pp. 24-28.

[C3b] Jeffries, R., "Extreme testing", in Software Testing and Quality Engineering, March/April, 1999, pp. 23-26.

[Cockburn98] Cockburn, A., Surviving Object-Oriented Projects , Addison-Wesley, 1998.

[Crystal] Cockburn, A., Crystal/Clear: A Human-Powered Methodology for Small Teams , Addison-Wesley, 2000, in preparation, early version visible at http://members.aol.com/humansandt/crystal/clear.

[DeMarco99] DeMarco, T., Lister, T., Peopleware: Productive Projects and Teams , 2nd Ed., Dorset House, 1999.

[Graham97] Graham, I., Henderson-Sellers, B., Younessi, H., The OPEN Process Specification , Addison-Wesley, 1997.

[Harrison96] Harrison, N., Coplien, J, "Patterns of productive software organizations", Bell Labs Technical Journal, Summer, 1996, pp. 138-145.

[Highsmith] Highsmith, J., Adaptive Software Development , xxx press, 2000.

[Humphreys97] Humphreys, W., Introduction to the Personal Software Process , Addison-Wesley, 1997.

[Martin96] Martin, J., Odell, J., Object-oriented Methods, Pragmatic Considerations , Prentice Hall, 1996.

[Plowman95] Plowman, L., "The interfunctionality of talk and text", CSCW, vol. 3, 1995, pp.229-246.

[Sillince96] Sillince, J.A., "A model of social, emotional and symbolic aspects of computer-mediated communication within organizations", CSCW vol. 4, 1996, pp. 1-31.

[XP] Jeffries, R., Beck, K., et al.,Extreme Programming, as described on the web:http://armaties.com/extreme.html, http://c2.com/ppr/wiki/ExtremeProgrammingRoadmap/html.zip.

( arc@acm.org )

Humans and Technology

Humans and Technology Technical Report, TR 99.04, Oct.1999 7691 Dell Rd, Salt Lake City, UT 84121 USA

arc@acm.org

Original article

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

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

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

В этой статье мы рассмотрим то, как эти идеи были применены в ряде проектов с различным количеством разработчиков, использовавших разные технологии.

Под "методологией" я понимаю то, что написано в качестве первого толкования этого слова в Американском словаре Miriam-Webster: "ряд связанных между собой методов или техник". Оксфордский словарь толкует это слово только как "изучение методов". В этой статье я использую американский вариант. ( Для интересующихся: в "Толковом словаре русского языка" Ожегова это слово трактуется как "принципы и способы организации теоретической и практической деятельности" и "совокупность методов, применяемых в какой-либо науке".
– - прим. переводчиков )

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