Научиться работать вместе - значит научиться более быстро решать вместе со своими коллегами различные проблемы, а не скрывать друг от друга свои мысли и идеи. В этом случае заметно совершенствуется командный стиль работы.
Если пара программистов сумеет сработаться, то им будет гораздо легче общаться. Кроме того, это общение будет протекать гораздо чаще. При увеличении объема и частоты коммуникаций увеличивается и общий поток информации, циркулирующий внутри команды. Чтобы усилить и ускорить этот процесс, нужно не забывать менять партнеров в парах.
Похоже, все это существенно улучшает производительность команды. К сожалению, эти выводы основываются только на рассказах самих программистов. Никаких статистических данных на этот счет у нас пока нет.
Персонал amp; Управление проектом
Руководство проектом только выигрывает от улучшения качества работы персонала и уменьшения рисков, которые с ним связаны.
И компании, и команде разработчиков выгодна атмосфера постоянного обучения и обмена знаниями. Во время работы над проектом существенно возрастают профессиональные навыки разработчиков - как в области языков программирования, так и в области проектирования.
Снижается риск потери ключевых разработчиков, так как многие их коллеги хорошо знают каждую из частей системы. Некоторые называют это "принципом грузовиков": "Сколько разработчиков должен сбить грузовик, чтобы проект не смог нормально завершиться?" Наихудший из возможных ответов: "Одного". Если знания о системе рассредоточены по всей команде разработчиков, это существенно повышает требуемое количество грузовиков, а вместе с ним и уровень безопасности проекта.
Основные преимущества парного программирования заключаются в следующем:
большинство ошибок можно обнаружить в процессе кодирования, а не во время тестирования качества (QA) или же во время работы клиента с системой (см. непрерывная проверка кода);
заметно снижается общий коэффициент ошибок, что подтверждается статистическими данными (см. непрерывная проверка кода);
готовый продукт имеет лучший дизайн и меньший объем программного кода (см. "мозговой штурм" и принцип "парной эстафеты");
команда быстрее справляется с возникающими проблемами (см. принцип "парной эстафеты");
разработчики гораздо больше узнают как о системе, так и самом процессе разработки ПО (см. обучение в поле зрения учителя);
к моменту окончания проекта множество людей обладает глубокими знаниями о каждой из его частей;
