Как заниматься проблемами программирования пары? [закрытый]

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

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

С чем точно у них есть проблемы? Разве они не проживают, не понимают друг друга? Они на разных уровнях программирования опыта?

может помочь, есть ли у Вас член команды, который может действовать как своего рода "посредник". Кто-то, кто успешно сделал программирование пары в прошлом и может помочь двум в течение их первых нескольких раз вместе.

Переоцените свои методы найма и удостоверьтесь, что Вы выбираете для ориентированных сотрудников команды.

Сбой это, монетные дворы дыхания.

-Adam

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

Заставляют пару открывать линии связи; попытайтесь заставить обе стороны делать новые вещи. Принятие обоих человек является по-настоящему хорошими разработчиками, у них обоих есть много для изучения друг от друга. Попытайтесь изменить их отношение от учителя студенту.

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

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

Я был бы вопрос второго muloh - с какими видами вещи у них есть проблемы?

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

Mary, не ладящая с Fred, потому что Fred не знает достаточно о том, как нормальные люди работают с базами данных? Разве Fred не ладит с Jo, потому что Jo не купается вполне так регулярно, как они должны? Разве Jo не ладит с Mary, потому что Mary является грубым РЫДАНИЕМ? Раз так можно почти гарантировать что Fred, Jo & Mary является также раздражающей остальной частью команды похожими способами.

Просто, потому что один или два человека продвигают проблему достаточно стараться не соединяться, не означает, что проблемы уходят. Это может быть раздражающий другой народ также - у них могут быть альтернативные способы справиться. Как поиск альтернативной занятости, например:-)

, Если команда не работает хорошо вместе, это не команда.

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

Другой подход должен постоянно переключать Ваших пар в толпе. Имейте таймер, который мог бы быть установлен в течение 1/2/3 часов. Когда звонок уйдет, поверните своих пар. Это имеет несколько эффектов:

• Два человека не застревают, соединяясь вместе в течение долгого времени
• , Ваши разработчики доберутся для вращения через текущие истории, знакомящиеся с каждым и различными областями кода
• , Если один из запахов dev, необходимо будет только пройти через короткий период вони!

Создание пары - критически важный метод для гибкой команды. Для начала лучше всего определить разработчиков, которые хотят и могут эффективно работать в парах. Одна известная мне компания проводит экстремальные интервью. То есть они будут проводить собеседование с кандидатами в парах, давая им задачу решить. Их интересует, способны ли разработчики решить проблему, но их интересуют их навыки совместной работы. Учитываются только те, которые могут хорошо работать с другими.

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