The team serves three key purposes:
- drastically reduce the search space for partner search for pair programming;
- create a context for reflecting on progress, what is working and not, and exchange ideas at semi-regular meetings; and
- facilitate establishing some connection with a coach (TA).
The teams are created by us, and it usually takes about one week before the teams are announced because we do not know the names of everyone taking the course until then. mark:You do not get to pick your team members.
The teams will meet at least once each sprint, meaning at least five times during the course. The coaches will initiate these meetings.
Reusing Wikipedia’s definition (emphasis added),
Pair programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently.
While reviewing, the observer also considers the “strategic” direction of the work, coming up with ideas for improvements and likely future problems to address. This is intended to free the driver to focus all of their attention on the “tactical” aspects of completing the current task, using the observer as a safety net and guide.
Den bakomliggande orsaken till att parprogrammering är obligatorisk är att parprogrammering (och andra tekniker för att uppnå liknande effekt med avseende på kunskapsspridning, granskning, etc.) inte bara tenderar att resultera i bättre kod än kod som produceras av en enskild, utan också förbättrar inlärningen. Genom att prata tvingas du sätta ord på vad du gör, och reflektera. Ibland försöka förklara något som du själv inte förstår fullt, etc. Det stimulerar framförallt djuplärningen – du kommer alltså i mindre utsträckning att glömma bort allt efter att kursen är slut.
Det finns många olika varianter av parprogrammering. Tanken på IOOPM är att det vid varje tillfälle skall vara en person som är “driver” i bemärkelsen att vara vid tangentbordet, och att paren skall byta driver mycket ofta, minst en gång var 30:e minut, men helst oftare. Det kan vara en god idé att byta vid logiska enheter, t.ex. byta i samband med att en funktion blir klar eller att testerna för funktionen har skrivits. Det är också bra om inte samma person skriver funktionen f och dess tester. Senare i kursen kan arbetet med att skriva test och funktion paralleliseras, men regelbunden avstämning, säg var 10:e minut, är ändå bra, liksom att sitta brevid varandra.
Det är inte parprogrammering att dela upp en uppgift i två delar
och göra hälften var eftersom båda medlemmarna i ett kodpar måste
får individuellt godkänt på alla mål vid redovisning. När
examinatorn frågar en enskild person om ett mål och pekar på en
del av koden måste den kunna ge ett bra svar. Att säga “jag skrev
inte just den biten” är inte ett acceptabelt svar. Det är rimligt
att anta att vissa delar av uppgiften görs separat eftersom ca
Om en person i paret upplevs som expert och en som novis är det bra att vädra det tidigt (ibland upplever båda att den andre är experten…). Om så är fallet är det fortfarande viktigt att byta regelbundet och att båda utför samma typ av arbete. Om novisen sitter i baksätet kommer hen nämligen inte att lära sig lika mycket vilket manifesterar sig på kursen genom att hen inte klarar kodprovet och därmed inte kursen.
Som nämnt ovan går det utmärkt att ha ett par där en (A) siktar på ett högre betyg än en annan (B). Det kan t.ex. manifestera sig genom att A gör vissa utökningar på egen hand, eller vissa redovisningar på egen hand.
Vi rekommenderar:
- Att ni använder en mix av solo-programmering och parprogrammering. Parprogrammeringen är lämplig för att se till att ni är synkade, drar åt samma håll och är överens om viktiga designbeslut – implementera vissa saker tillsammans för att komma överens om stil, hjälpas åt med komplex logik etc., men det är inte så att allt arbete måste ske samtidigt.
- Använd git och GitHub för att dela all kod – utgå från att kod som inte är versionhanterad i molnet kommer att gå förlorad.
- Skriv tydliga och vettiga commit-meddelanden så att din partner lätt kan förstå vad du har gjort.
- Använd en delad Cloud 9-yta för parprogrammering som är kopplad till ert GitHub-repository.
- Komplettera Cloud 9 (editeringen) med en videochat typ Zoom eller motsvarande och en textchatt typ MatterMost.
Every new sprint on the course should start by you finding a new
programming partner. Start planning for this a couple of days
ahead. Since you are not joined at the hip, nor have to work
synchronously on everything, it is not imperative that you and
your partner are fully aligned time-wise. For example, maybe you
are already done with assignment
Use the groups MatterMost channel to announce that you will be needing a new partner soon.
Plan ahead so you don’t have to lose time blocking on a new partner.
If you have problems finding a partner, talk to your coach.
Sex gånger under kursen möts[fn::Lämpligtvis online med hjälp av Zoom eller motsvarande – men det är förstås upp till er alla att bestämma hur ni vill göra.] teamet för ett uppföljningsmöte, som coachen (en assistent) kallar till. Här är en förteckning av mötena, samt vad ämnesraden för rapportmailet skall vara för detta möte (se nedan).
| Möte | Ämnesrad på rapportmail |
|---|---|
| Första möte under C-bootstrap | Ni behöver inte skicka ett mejl under Bootstrap |
| Fas 1/Sprint 1 | [IOOPM/Meeting] <Grupp> Fas 1/Sprint 1 |
| Fas 1/Sprint 2 | [IOOPM/Meeting] <Grupp> Fas 1/Sprint 2 |
| Fas 2/Sprint 1 | [IOOPM/Meeting] <Grupp> Fas 2/Sprint 1 |
| Fas 2/Sprint 2 | [IOOPM/Meeting] <Grupp> Fas 2/Sprint 2 |
| Projekt | [IOOPM/Meeting] <Grupp> Fas 3 |
Till varje uppföljningsmöte skall du ta med dig åtminstone:
- Planeringen för den aktuella sprinten (inlämningsuppgiften)
- Burndown chart för måluppfyllnad hela kursen (det räcker med den som tillhandahålls av AU-portalen)
Under uppföljningsmötet kommer vi att gå igenom den aktuella sprinten (hur har du planerat = vilka deluppgifter har du identifierat, vad har du klarat av, vad har du för styrfart, etc.) och takten för måluppfyllnad för hela kursen.
Under mötet får varje kodpar några minuter på sig att presentera sina framsteg. Börja med att visa planeringen för den aktuella sprinten. Vilken uppgift jobbar ni med, vad har ni gjort, vad tänker ni göra härnäst? Fråga gärna om ni är osäkra på något i er egen planering. Om det andra paret jobbar med samma uppgift har de kanske också kommentarer eller tips! Visa sedan båda era burndown charts för den aktuella sprinten och förklara vilka mål ni har tagit och vilka ni planerar att ta. I samband med detta kan andra komma med tips på passande mål! Avsluta med att visa era burndown charts för hela kursen och säg något om er nuvarande styrfart.
Teamet skriver en rapport för varje möte som lämnas in via mail till coachen och till funktionsadressen ioopm@it.uu.se, och CC:as till samtliga i teamet. Ämnesrad på mailet enligt tabell ovan! Rapporten skall vara mycket kortfattad och innehålla:
- Antalet kodpar som håller åtminstone avsedd styrfart respektive som inte gör det
- Antalet studenter som avser att satsa på högre betyg än 3
- En stressindikator i intervallet
$[1,7]$ (där 1 är sömn och 7 är maxpuls) som teamet enats om[fn::Ni kan t.ex. rösta och ange min, max, medel och median – eller enbart median eller medel, etc. Men var tydliga med hur siffran kommits fram till!] - Summan av antalet mål som tagits av enskilda medlemmar i teamet
- En lista på namn på medlemmar i teamet som åtminstone någon i teamet anser behöver en knuff i rätt riktning
- Eventuella förslag till kursledning (t.ex. saker att ta upp extra, deadlines att flytta, önskemål, etc.)
- Samtliga närvarandes “underskrifter” och en lista på frånvarande (som idealiskt skall vara tom!)
OBS! Listan i den 4:e punkten ovan är inte till för att “sätta dit” någon som det går dåligt för, utan tvärt om – för att hjälpa den eller de att komma vidare. Alla som arbetar på kursen är på din sida och har som uppgift att leda dig i rätt riktning innan det är för sent. Du lurar bara dig själv om du fejkar dina framsteg eller undviker mötena. Även om det känns som att det går bra för dig kan uppföljningsmötet också vara ett sätt att bekräfta att din planering är realistisk. Om du siktar på ett högre betyg kan du också få hjälp att hitta mål som passar din nuvarande uppgift.
Mot kursens slut kommer du att göra “en retrospektiv” över hur styrfart, stress, förväntat/eftersträvat betyg, etc. har ändrats under kursens gång i samband med C7: Planering och uppföljning.
- Ta mötet på allvar. Låt det ta tid. Träffas gärna nere på stan på ett fik, eller över en öl på en nation.
- Det är viktigt att du skaffar en relation till de andra personerna i din grupp. Det är bland dessa som du kommer att välja partners till kodparen.
- Gå en runda och låt alla presentera sig kort! Berätta litet om vem du är och vad du vill åstadkomma med din utbildning generellt, och vad du har för ambitioner med denna kurs specifikt. Beskriv kort din programmeringsbakgrund. Vad vill du jobba med? Kanske kan ni komma överens om att träffas regelbundet och plugga/programmera/etc.?
Tillägg till första rapportmailet:
Under fyra separata rubriker:
- Sammafatta kort vad ni har för förhoppningar och farhågor inför kursen
- Sammafatta kort vad ni vill få ut av kursen
- Sammafatta kort om ni har önskemål på oss som ger kursen
Tillägg till rapportmailet:
Under tre separata rubriker:
- Hur upplever ni programspråket C?
- Hur upplevde ni styrning kontra frihet i inlämningsuppgift 1 och 2?
- Vad bör vi göra annorlunda nästa år (eller i fas 2)?
Tillägg till rapportmailet:
Under två separata rubriker:
- Hur upplever ni programspråket Java?
- Vad bör vi göra annorlunda nästa år (eller i fas 2)?