Parprogrammering: Forskelle mellem versioner

Content deleted Content added
m Retter tankestreger – burde ignorere [[ ]], {{ }} og <math> samt <gallery>
Linje 13:
|pages=25
|isbn=0-201-74576-3}}"When pairing is working at its best, … both share the same goal for completing the task."</ref>
* Arbejd således at der tages en lille opgave/mål ad gangen, - noget I kan færdiggøre indenfor nogle få minutter. Bare det at formulere et problem i ord, overfor et andet menneske, hjælper med til at fokusere både dig selv og din partner på opgaven. Det sikrer også at begge ved hvad I arbejder på ''lige nu''. Man kan trygt færdiggøre denne opgave inden man begynder på noget nyt, og er mindre fristet til at forlade opgaven for at håndtere kompleksitet der lige er dukket op. Det kan man gøre senere.
* Som driver, stol på at observeren er dit sikkerhedsnet. Færdiggør det aktuelle lille mål så hurtigt du kan , og ignorer større og afledte problemer.
* Som Observer, læs koden, idet driveren skriver den. Tænk på mulige bugs, større problemer og måder at forenkle eller forbedre designet. Hvis der er fejl eller ulæselig kode, skal det straks tages op. Vent til det lille delmål er opnået med at tage større aspekter op; designforbedringer, f.eks. Skriv disse større ting ned, så driveren kan holde sig fokuseret på den aktuelle opgave. Hvis du for eksempel kan se at koden ikke tager højde for et null-input, skriv en note: "Lav en unit test for null-input".
* Skift roller hver halve time. 15 minutter er mere almindeligt.
* Skriv en unit test først, før I implementerer kode. Dette hjælper med til at definere det næste lille mål i arbejder på. På denne måde bliver det næste lille mål: "bestå Unit-testen".
=== Begynder - Ekspert par sammensætning ===
* Den person der ved mindst om systemet eller sproget bør være driver det meste af tiden, for at sikre at begynderen forbliver aktivt engageret.
 
Linje 73:
|date=2003
|pages=23
|isbn=0-201-74576-3}}"Two people working in a pair treat their shared time as more valuable. They tend to cut phone calls short; they don't check e-mail messages or favorite Web pages; they don't waste each other's time." (Ward's Wiki 1999, contributed by Paul Chisholm).</ref> - eller andre brud på disciplinen når de arbejde med deres partner. Partneren "Keeps them honest".<ref>{{cite book|last=Beck|first=Kent|title=Extreme Programming Explained|publisher=Addison-Wesley|date=2000|pages=102|isbn=201-61641-6|authorlink=Kent Beck}}"Under stress, people revert. They will skip writing tests. They will put off refactoring. They will avoid integrating. With your partner watching, though, chances are that even if you feel like blowing off one of these practices, your partner won't."</ref><ref>{{cite book|last=Williams|first=Laurie|title=Pair Programming Illuminated|publisher=Addison-Wesley|date=2003|pages=24|isbn=0-201-74576-3}}"With any software development process there is a constant struggle to get the software engineers to follow the prescribed process. A benefit of pair programming is improved adherence to procedures and standards."</ref>
* ''Robust "Flow":'' Det virker som om det "Flow" der er i arbejdet bliver mere robust, og kommer hurtigere: Den ene spørger den anden: "Hvad arbejder vi på?" Flowet er også mere robust overfor afbrydelser: Den ene tager sig af afbrydelsen mens den anden arbejder videre.
* ''Færre afbrydelser:'' Folk er mere tilbageholdende med at afbryde et par end en der arbejder alene.<ref>{{cite book|last=Williams|first=Laurie|title=Pair Programming Illuminated|publisher=Addison-Wesley|date=2003|pages=24|isbn=0-201-74576-3}}"Others see us already working with someone else, and they leave us alone. The net effect is that we have bigger blocks of uninterrupted time, which is good for our mental state and our progress. It also reduces task-switching, which for some people generates a huge overhead."</ref>
Linje 91:
|url=http://www.economist.com/displayStory.cfm?Story_ID=779429}}.</ref>
 
Et studie af Williams et al. 2000 viste en forbedring i korrekthed på omkring 15 %, - og 20 til 40 % besparelse på tid, men mellem 15 og 60% forøgelse i indsats. Williams et al. 2000 citerer også et tidligere studie (Nosek 1998) som også havde 40% lavere tidsforbrug for en 60 % forøgelse af arbejdsindsats.
 
Et studie præsenterer et streng videnskabeligt eksperiment, hvor begynder-begynder par imod begynder-soloer oplever betydelig større produktivitetsstigninger end ekspert-ekspert-par imod ekspert-soloer.<ref name='ijhcs'>According to "Int J. of Human Computer Studies Vol (64) 2006</ref>