Каждому проекту своя методология - [7]

Заключение

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

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

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

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

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

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

Библиография

[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://extremeprogramming.com, http://armaties.com/extreme.html, http://c2.com/ppr/wiki/ExtremeProgrammingRoadmap/html.zip.

(#mailto:[email protected])

Humans and Technology

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

[email protected]

Original article