Парное программирование: преимущества и недостатки

Заключение

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

большинство ошибок можно обнаружить в процессе кодирования, а не во время тестирования качества (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,papers/ nonlinear/nonlinear.htm. (На русском языке: "Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения");

Приложение: "Специалист в пределах слышимости"(Expert In Earshot) Паттерн управления проектом

(полную версию смотрите на

Суть

Неопытным программистам довольно сложно самостоятельно научиться хорошо работать, поэтому…

Около них (в пределах слышимости) должен находиться высококлассный специалист в данной области.

Показания

(1) Новички плохо обучаются и медленно осваивают новые технологические приемы работы.

(2) Все работают над одним проектом, но несмотря на это, специалисты сидят в отдельном помещении, а новички собраны в общей комнате.

Противопоказания

(1) Согласно правилам, размещение специалистов и новичков в одной комнате запрещено.

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

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

Цели и задачи

(1) Вам нужно, чтобы все делали свою работу - и новички, и опытные специалисты.

(2) Вы хотите, чтобы новички обучались, и считаете, что у ваших специалистов есть чему поучиться.

(3) Вы можете позволить себе выделить часть времени специалистов на то, чтобы они уделяли внимание новичкам (если конечно, те при этом учатся работать).

Но при этом…

(1) Вы не хотите, чтобы специалисты посвящали все свое рабочее время преподаванию.

(2) Люди всегда стесняются беспокоить начальника (или специалиста) телефонным звонком или стуком в дверь.

Сделайте следующее

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

Таким образом

(1) Новички будут перенимать у специалиста опыт и технологию (будем надеяться, правильную)