<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmi:id="-nfbUMyTTqEbCp3HDn-NjOA" name="pair_programming,3.85153041801319E-307" guid="-nfbUMyTTqEbCp3HDn-NjOA" changeDate="2006-11-10T04:14:32.495+0330" version="1.0.0">
  <mainDescription>&lt;a id=&quot;XE_xp__pair_programming&quot; name=&quot;XE_xp__pair_programming&quot;>&lt;/a>&lt;a id=&quot;XE_pair_programming__in_xp&quot; name=&quot;XE_pair_programming__in_xp&quot;>&lt;/a> &#xD;
&lt;h3>&#xD;
    Topics&#xD;
&lt;/h3>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        &lt;a href=&quot;#WhatIsPair&quot;>What is pair programming?&lt;/a>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;a href=&quot;#WhyPair&quot;>Why Pair Program?&lt;/a>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;a href=&quot;#FormingPairs&quot;>How Pairs Form&lt;/a>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;a href=&quot;#ChangingPairs&quot;>When to Change Partners&lt;/a>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;a href=&quot;#WorkingAlone&quot;>Can't I work alone?&lt;/a>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;a href=&quot;#Productivity&quot;>Doesn't this cut my productivity in half?&lt;/a>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;a href=&quot;#Hygiene&quot;>Hygiene and Etiquette Issues&lt;/a>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;a href=&quot;#Disabilities&quot;>Disabilities and Physical Incompatibilities&lt;/a>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;a href=&quot;#Distributed&quot;>Our Team is Geographically Distributed&lt;/a>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;a href=&quot;#BossHog&quot;>My Pair Partner Hogs the Keyboard and Ignores Me&lt;/a>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;a href=&quot;#NoSolution&quot;>My Pair Partner and I Cannot Agree on a Solution&lt;/a>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;a href=&quot;#Language&quot;>My Partner and I have different First Languages&lt;/a>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;a href=&quot;#Schedule&quot;>How do we deal with different personal schedules?&lt;/a>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;a href=&quot;#OddNumber&quot;>What if we have an odd number of programmers?&lt;/a>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;a href=&quot;#Pathologies&quot;>Pairing Pathologies&lt;/a>&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;WhatIsPair&quot; name=&quot;WhatIsPair&quot;>What is pair programming?&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Pair programming is a programming discipline in which all production code is written by pairs of programmers. Each pair&#xD;
    works together at a single workstation. They share the keyboard, mouse, and monitor.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The two programmers work closely together. The keyboard moves back and forth between them frequently. Both eyes are&#xD;
    locked on the screen. Both minds are immersed in the code. The code is the product of both brains, not just one. Both&#xD;
    programmers are equally engaged in writing the code, and neither can claim authorship.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Pairs are short lived. A good pairing time is four hours. Sometimes a pair may last for a day. Very rarely they might&#xD;
    last for a week. Instead, the pairs form for a few hours and then break up and reform with different partners.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    During the iteration-planning meeting, each programmer signed up for tasks to complete by the end of the iteration. The&#xD;
    programmer remains responsible for those tasks. Half of the pairs he works in will be working on his tasks, and half&#xD;
    will be working on other's tasks.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;WhyPair&quot; name=&quot;WhyPair&quot;>Why Pair Program?&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Pair programming is a form of continuous code review and usually replaces the practice of code reviews and code&#xD;
    walkthroughs. The idea is that if code reviews are a good thing, then continuously reviewing the code is better.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Even though every task is the responsibility of an individual programmer, many other programmers will have worked on&#xD;
    that task with the responsible programmer. Thus, knowledge of the system spreads through the team, and no single&#xD;
    programmer can claim ownership of any part of the code. It is likely that any programmer on the team will be able to&#xD;
    work in any module in the system.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Sometimes you get stuck on ideas and can't see past them. Your pair partner can often provide the necessary nudge to&#xD;
    get you to see a different point of view.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    When new people join the team, they learn by pairing. Over the course of one iteration, they will pair with everybody&#xD;
    on the team and see every part of the system currently being worked upon. This is an excellent way to train a new team&#xD;
    member.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;FormingPairs&quot; name=&quot;FormingPairs&quot;>How Pairs Form&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    You come to work in the morning and attend the stand-up meeting. Then you walk up to someone and ask him if he'll help&#xD;
    you. Or perhaps someone will walk up to you and ask you to help him. The rule is: when asked, you must say yes.&#xD;
    However, you can negotiate schedule.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Pairs form naturally. Managers do not get involved with selecting pairs. Pairing is not scheduled or controlled in any&#xD;
    formal manner. The coach or another team member or the team as a whole may notice that certain team members have&#xD;
    adopted pathological pairing activities and may intervene.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;ChangingPairs&quot; name=&quot;ChangingPairs&quot;>When to Change Partners&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        When you get tired of your current partner.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        When you think your current partner is too tired or distracted to help.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        When the two of you get stuck on a concept.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Lunchtime.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Quitting time.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Or generally whenever you feel like it.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;WorkingAlone&quot; name=&quot;WorkingAlone&quot;>Can't I work alone?&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Yes, of course. You just can't check in production code that you've written on your own.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Often we need to hide away somewhere and think some issue through without someone else breathing down our neck or&#xD;
    distracting us with news of his sister-in-law's hypoglycemia. It is perfectly OK to hide away, and every programmer&#xD;
    should have a private place to go.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    When alone, it is perfectly OK to write some code to help you think through a program. However, in an XP team, you are&#xD;
    not allowed to check that code into the production environment. Instead, you can bring that code to your next pairing&#xD;
    session and walk through it with your partner. Your partner must be given every right to modify, delete, or otherwise&#xD;
    refactor it. You should help your partner become comfortable with the code and keep an open mind to every refactoring.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Often the best approach is for the two of you to review the code you wrote and then rewrite it as a pair. Remember, the&#xD;
    value of a piece of code is not actually in that code. Rather, it is in the neurons and synapses of the programmers. It&#xD;
    is always much easier to write a module the second time, and the result is always better. So, if you program alone,&#xD;
    think of the code as a rough draft that you will throw away and rewrite with your pair partner.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;Productivity&quot; name=&quot;Productivity&quot;>Doesn't this cut my productivity in half?&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Apparently not. Teams that work in pairs do not report significant loss of productivity. Indeed, they tend to report&#xD;
    that they are more productive than when they worked alone.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    This anecdotal evidence is backed up by some research studies. Some of those studies can be found at &lt;a href=&quot;http://www.pairprogramming.com&quot; target=&quot;_blank&quot;>www.pairprogramming.com&lt;/a>.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    One might explain these results by viewing the programmers as two runners pacing each other. When one gets tired or&#xD;
    defocused, the other provides the motivation and inspiration to keep going. Also, the pair spends less time going down&#xD;
    dead ends and being blocked on ideas.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    One thing seems clear. Typing is not the critical element. If it were, then pairing would certainly cut productivity in&#xD;
    half. It may be that pairing allows the two to think twice as quickly.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;Hygiene&quot; name=&quot;Hygiene&quot;>Hygiene and Etiquette Issues&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Hygiene and etiquette issues are bad breath, body odor, post-nasal drip, colds, rude noises, gas, motor mouths,&#xD;
    telephone-jockeys, day-traders, hypochondriacs, etc. Humans are a dirty species. Amazingly, we are usually able to get&#xD;
    along with each other's nasty little idiosyncrasies, but there are times when one person has certain habits that are&#xD;
    over the top. How do you pair with such a person?&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Grin and bear it, it'll only last for a couple of hours.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Bring breath mints.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Leave deodorant or gelucel on his desk.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Write anonymous letters to the offender.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Disconnect the phone.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Complain to your boss.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        But, by far, the best advice is to tell your pair partner outright what bothers you.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;Disabilities&quot; name=&quot;Disabilities&quot;>Disabilities and Physical Incompatibilities&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Left handed vs. right handed mouse users.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Some people need special keyboards to control RSI or OOS.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Some people use Dvorak keyboards.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Some people need to special screens to be able to see.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Some people prefer a trackball to a mouse.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    Problems like these are pretty easy to overcome. Equip certain workstations with two keyboards, two mice, two monitors,&#xD;
    etc. Pairs don't have to work at the exact same keyboard, mouse, or monitor.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    In fact, pairs don't really have to use the same workstation. They could use two completely independent workstations&#xD;
    sitting next to each other, connected with NetMeeting or some other kind of collaboration software.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;Distributed&quot; name=&quot;Distributed&quot;>Our Team is Geographically Distributed&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    At best, pairing over geographical boundaries is difficult. The best approach is to split the project up into&#xD;
    sub-projects that can be done separately at each geographic location. That way the programmers at each location can&#xD;
    pair with each other and won't have to interact as much with the remote programmers.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Sometimes the project cannot be easily split amongst all the geographic sites. In that case, you can use NetMeeting or&#xD;
    other collaborative software to facilitate remote pairing. Remote pairing is possible but not as effective as local&#xD;
    pairing. When you pair locally, you have the advantage of body language, eye contact, and all the other nuances of&#xD;
    person-to-person communication to help you. When you pair remotely, you are forced to use a sub-optimal communication&#xD;
    channel.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;BossHog&quot; name=&quot;BossHog&quot;>My Pair Partner Hogs the Keyboard and Ignores Me&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Perhaps you are outrunning him. Try to go a little slower and get him engaged.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Perhaps he's got personal problems that are distracting him. Suggest that this might not be a good time to pair.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Perhaps he thinks you aren't listening to his ideas. Make sure you talk though all ideas with him, and make sure he&#xD;
        has a chance to try as many of his ideas as you get to try of yours.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Perhaps he thinks you've been hogging the keyboard. Push the keyboard in his direction and ask him to drive.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Perhaps he is just not ever going to want to pair program, no matter what. For the moment, the best you can do is&#xD;
        dissolve the pair and choose another partner. If the behavior continues, the team will have to decide what to do&#xD;
        about it. Perhaps the team will ask him to write configuration scripts or something.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;NoSolution&quot; name=&quot;NoSolution&quot;>My Pair Partner and I Cannot Agree on a Solution&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Gently ask him if you can drive for a while.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Gently ask him to describe what he is doing.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Perhaps he needs time to think alone. Suggest this to him and dissolve the pair.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Perhaps he just can't pair program. Dissolve the pair and choose another partner. If the behavior continues, the&#xD;
        team will have to figure out what to do.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;Language&quot; name=&quot;Language&quot;>My Partner and I have different First Languages&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Your only choice is to slow down and work hard to communicate. You might understand him better by writing strategic&#xD;
    notes than by talking. Work hard on helping him with pronunciation and grammar. Work hard at understanding his accent&#xD;
    and usage. It will take time, but the situation will improve. Do not give up!&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;Schedule&quot; name=&quot;Schedule&quot;>How do we deal with different personal schedules?&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Some people come in early; some people stay late. How can you find pair partners if everybody has a different working&#xD;
    schedule?&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Pairs only last for a few hours. All you need is enough overlap time for pairs to form and work effectively. Most&#xD;
    personal schedules allow this.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Team members may have to get creative with their scheduling to accommodate each other. Some folks may have to change&#xD;
    their schedules to make sure that others have sufficient pairing opportunity. For example, if Bill can only work in the&#xD;
    evenings, the team may decide to adopt a rotating schedule for others who can come in late one day and pair with Bill.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;OddNumber&quot; name=&quot;OddNumber&quot;>What if we have an odd number of programmers?&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Remember that pairs break up and reform frequently. The odd man out will not have to wait long before someone becomes&#xD;
    available to pair with. In the meantime, he can read his email or a trade journal or just read through some code that&#xD;
    he is unfamiliar with.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;Pathologies&quot; name=&quot;Pathologies&quot;>Pairing Pathologies&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Joined at the hip. Sometimes two people decide to pair exclusively. This is not a good idea. They are missing the&#xD;
        opportunity to get the whole team's input and are isolating themselves into one part of the system. The team should&#xD;
        break them up by suggesting that they pair with others.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        The blind leading the blind. It's not a good idea for new members of the team to pair too often with other new&#xD;
        members of the team. Newbies should pair most often with team members with more seniority.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    &lt;br />&#xD;
    &lt;br />&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
