Алистэр Коуберн - Парное программирование - преимущества и недостатки

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

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

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

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

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

Основные преимущества парного программирования заключаются в следующем:

большинство ошибок можно обнаружить в процессе кодирования, а не во время тестирования качества (QA) или же во время работы клиента с системой (см. непрерывная проверка кода);

заметно снижается общий коэффициент ошибок, что подтверждается статистическими данными (см. непрерывная проверка кода);

готовый продукт имеет лучший дизайн и меньший объем программного кода (см. "мозговой штурм" и принцип "парной эстафеты");

команда быстрее справляется с возникающими проблемами (см. принцип "парной эстафеты");

разработчики гораздо больше узнают как о системе, так и самом процессе разработки ПО (см. обучение в поле зрения учителя);

к моменту окончания проекта множество людей обладает глубокими знаниями о каждой из его частей;

люди учатся совместной работе и общению, что приводит к увеличению потока информации внутри команды и положительно влияет на ее динамику;

люди испытывают больше удовольствия от своей работы.

При этом увеличение стоимости разработки при парном программировании составляет вовсе не 100%, как можно было бы ожидать, а приблизительно 15%, что легко окупается за счет более высокого качества программного кода (а значит, меньших затрат на тестирование и поддержку).

1. Salomon, G., Distributed Cognitions: Psychological and educational considerations. Learning in doing: Social, cognitive, and computational perspectives, ed. R. Pea and J.S. Brown. 1993, Cambridge: Cambridge University Press.

2. Constantine, L.L., Constantine on Peopleware. Yourdon Press Computing Series, ed. E. Yourdon. 1995, Englewood Cliffs, NJ: Yourdon Press.

3. Beck, K., Extreme Programming Explained: Embrace Change. 2000, Reading, Massachusetts: Addison-Wesley.

4. Williams, L., et al., Strengthening the Case for Pair-Programming, in IEEE Software. submitted to IEEE Software. Online at www.cs.edu/~lwilliam/Papers/ieeeSoftware.PDF

5. Williams, L.A. and R.R. Kessler. The Collaborative Software Process. in International Conference on Software Engineering 2000. submitted for consideration. Limerick, Ireland. Online at www.cs.edu/~lwilliam/Papers/ICSE.pdf

6. Nosek, J.T., The Case for Collaborative Programming, in Communications of the ACM. 1998. p. 105-108.

7. Humphrey, W.S., A Discipline for Software Engineering. SEI Series in Software Engineering, ed. P. Freeman, Musa, John. 1995: Addison Wesley Longman, Inc.

8. Humphrey, W.S., Introduction to the Personal Software Process. 1997: Addison-Wesley.

9. Flor, N.V. and E.L. Hutchins. Analyzing Distributed Cognition in Software Teams: A Case Study of Team Programming During Perfective Software Maintenance. in Empirical Studies of Programmers: Fourth Workshop. 1991: Ablex Publishing Corporation.

10. Fagan, M.E., Advances in software inspections to reduce errors in program development. IBM Systems Journal, 1976. 15: p. 182-211.

11. Johnson, P.M., Reengineering Inspection: The Future of Formal Technical Review, in Communications of the ACM. 1998. p. 49-52.

12. Lave, J. and E. Wenger, Situated Learning: Legitimate peripheral participation. 1991, New York, NY: Cambridge University Press.

13. Weinberg, G.M., The Psychology of Computer Programming Silver Anniversary Edition. 1998, New York: Dorset House Publishing.

14. DeMarco, T. and T. Lister, Peopleware. 1977, New York: Dorset House Publishers.

15. Cockburn, A., Crystal "Clear": A human-powered software development methodology for small teams, Addison-Wesley, 2001, in preparation. Online at http://members.aol.com/humansandt/crystal/clear

16. Highsmith, J., Adaptive Software Development, Dorset House, 1999.

17. Cockburn, A., Characterizing People as Non-Linear, First-Order Components in Software Development, in International Conference on Software Engineering 2000. submitted for consideration. Limerick, Ireland… Online as Humans and Technology Technical Report, TR 99.05, http://members.aol.com/humansandt/ papers/ nonlinear/nonlinear.htm. (На русском языке: "Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения");