Каждой методологии - свое время
Страница 5. Заключение

Заключение

Данная статья строилась на основе полученных ранее выводов:

• Поскольку человеческий фактор может легко стать самым важным аспектом, определяющим успешность проекта, методология разработки ПО должна самым непосредственным образом учитывать свойства человеческой натуры, в особенности изменчивость, желание хорошо работать и способность к неформальному общению.
• Разным проектам нужны разные методологии.

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

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

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

И в-третьих, можно создать целую "семью" или спектр методологий, которые бы имели в основе одни и те же базовые принципы, и которые можно было бы точно так же "настраивать" по ходу проекта. Здесь я постарался дать общее представление о методологиях Crystal. Эти методологии отличаются друг от друга по цвету. Для каждой из них характерны свои собственные элементы построения коммуникации. При этом не затрагиваются базовые принципы: замещать письменные рабочие продукты короткими и мощными коммуникационными каналами и часто поставлять заказчику рабочие версии ПО.

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

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

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

[Co1] Cockburn, A., "Characterizing People as Non-Linear, First-Order Components in Software Development", submitted to International Conference on Software Engineering 2000. Online as Humans and Technology Technical Report, TR 99.05, at https://members.aol.com/humansandt/papers/ nonlinear/nonlinear.htm.

[Co2] Cockburn, A., "A methodology per project," submitted to IEEE Software. Online as Humans and Technology Technical Report, TR 99.04, https://members.aol.com/humansandt/ papers/methyperproject/ methyperproject.htm.

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

[Co4] Cockburn, A., Crystal/Clear: A Human-Powered Methodology for Small Teams, Addison-Wesley, 2001, in preparation. Online draft at https://members.aol.com/humansandt/crystal/clear.

[Co5] Cockburn, A., Software Development as a Cooperative Game, Addison-Wesley, 2001, in preparation, online at https://members.aol.com/humansandt/crystal/game.

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

[De2] DeMarco, T., The Deadline, Dorset House, 1997.

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

[Hi] Highsmith, J., Adaptive Software Development, Dorset House, 1999.

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

[Hu2] Humphreys, W., Introduction to the Team Software Process, Addison-Wesley, 2000.

[Ke] Kerth, N., "An approach to postmorta, postparta, and project reviews", online at https://c2.com/doc/ppm.pdf.

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

[Scr] Shwaber, K., "Scrum development process", online at https://www.jeffsutherland.org/oopsla/schwapub.pdf.

[Webb] 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 https://www.stsc.hill.af.mil/crosstalk/1999/feb/webb.asp

[Wei] Weinberg, J., The Psychology of Computer Programming, Silver Edition, Dorset House, 1998.

[XP] eXtreme Programming, as described on the web: https://extremeprogramming.com, https://armaties.com/extreme.html, https://c2.com/ppr/wiki/ExtremeProgrammingRoadmap/html.zip.