lu.se

Datavetenskap internt

Lunds Tekniska Högskola

Denna sida på svenska This page in English

Att vara kund på XP-kurserna

Lite tips om vad man kan tänka på när man är kund i XP-projekten (EDA260). Tänk på att teamen inte kommer att göra allt rätt från början, men vi har 6 iterationer så att misstag som görs kan rättas till i kommande iterationer.

Kurshemsidor:

  • EDAF45 (Utvecklarnas kurshemsida). Se speciellt under Projekt.
  • EDA270 (Coachernas kurshemsida)

Information här som är intressant för kunderna är t.ex

  • teamen med salar och tider
  • stories (läggs upp efter hand)
  • Eventuellt kan du som kund vara intresserad av teamets Repo och Wiki. Eventuellt använder sig teamet också av den Issue tracker som finns kopplad till repot (I Atlassian-serien finns även Jira för de som vill ha ett mer avancerat system för sin planeing och uppföljning), men det kan också hända att de sköter det manuellt med storykort. Det är enkelt att följa teamets commits (om du är intresserad av den detaljnivån).

Projektstartsmöten

Första måndagen i projektets läsperiod har teamet ett 2-timmars projektstartmöte som coacherna leder. Det är internt för coacherna och utvecklarna. Som kund kan du hälsa på och presentera dig om du önskar, men det förväntas inte. Du kan presentera dig på första planeringsmötet i stället.

Coachingmöten

Tisdagar 10:15-12:00, E:2116.

Dessa möten är primärt till för coacherna. Som kund kan du vara intresserad av att lyssna på den del där Boris presenterar nya stories, speciellt om du är ny som kund.

Planeringsmöten

Onsdag 10:15-12:00 eller 13:15-15:00. Här förväntas du delta aktivt och besöka dina team. Tidsåtgång: 6 stycken a 2 timmar + 2 timmars för och efterarbete. Totalt 24 timmar.

Du har 2-3 team som du besöker 1-2 gånger under planeringsmötet. För- och efterarbete tillkommer genom att hålla reda på hur långt de olika teamen har kommit, vilka stories de klarat av osv. Ibland vissa mailkontakter med teamen. Ibland att provköra releaser.

Huvudsakliga uppgiften här är att diskutera oklarheter i stories med teamet, samt att prioritera stories för nästa iteration (efter att teamet har estimerat dem). Boris ger grundtips till vad som är viktigt att prioritera (på tisdagsgenomgångarna), men detaljprioriteringen gör du själv. Teamet håller själv reda på hur många estimeringspoäng de tror de kommer att hinna med under nästa iteration.

Några tips:

  • Tänk högt när du prioriterar stories.
  • GUI Om utvecklarna frågar om hur du vill att användargränssnittet skall se ut, be dem göra tre olika förslag på papper. Då får de tänka lite själva, och det är lättare för dig som kund att förklara vilket du tyckte var bäst och hur det kan förbättras ytterligare.
  • Planering Fundera på hur du själv lättast kan hålla ordning på teamets planering och vad de är färdiga med. Håller du själv ordning på detta, eller ser du till att de gör sådan information lätt tillgänglig, exempelvis genom att maila dig eller att de har det på en wiki? Vad är enklast för dig?
  • Beroenden. Ibland finns det beroenden mellan stories. Det är teamets sak att reda ut det och presentera det för dig. Eventuellt kan detta påverka din prioritering.
  • Eventuell senarelagd prioritering. Teamet behöver göra en bra estimering för att du skall kunna prioritera mellan stories. Ibland hinner de inte det på planeringsmötena. En variant vi ibland använt är att bara diskutera storykraven på planeringsmötet, och att kunden istället gör en snabb prioritering i långlabbens början. Teamet kan då ha gjort estimeringen som hemarbete i mellantiden.

Långlabbar

Måndagar 8:15-17:00, med start läsvecka 2. Kundens arbete: 6 stycken långlabbar med cirka 5 timmars arbete på varje. Totalt 30 timmar.

Huvudsaklig uppgift är att gå runt till sina team och diskutera med dem. Teamen jobbar 8 timmar, men vi tror att cirka 5h är vad kunderna lägger ner på detta, inklusive eventuellt för och efterarbete.

Det som framförallt diskuteras är oklarheter i stories. Några tips:

  • Demo Be att få en demo av systemet.
  • Frågelista Coacherna har fått tipset att se till att teamet skriver ner frågor till kunden efterhand. Om de inte verkar ha något sådant system kan du påminna dem om det. Det är väldigt lätt hänt att utvecklarna funderar på småsaker, men sedan inte gitter fråga/diskutera med kunden.
  • Prata inte bara med coacherna Coacherna skall försöka få hela teamet att kommunicera med kunden. Försök underlätta detta och prata inte bara med coacherna.
  • Klara stories Egentligen är det du som kund som skall godkänna att en story är klar. I början kommer nog teamen att själva ha en "klar-status", baserad på egna tester och på acceptanstester de får av Boris. Men efter första releasen är det dags att du explicit får avgöra när en story verkligen är klar. Du kan antingen testa den själv, eller be att få en demo av den. Om det är något som du tycker fattas i en story kan du antingen säga att den inte är klar, eller säga att storyn är klar och formulera en ny story baserat på dina önskemål. Avgör detta från fall till fall.
  • Kvalitet Kräv hög kvalitet på det de gör: Lättanvända system, inga uppenbara buggar eller konstigheter, tydlig dokumentation, professionell attityd. Är du missnöjd med något, be att de rättar det till nästa gång. De är i en läroprocess, så det är inget konstigt om saker går fel ibland. Är du nöjd, tala om det för dem.
  • Kommunikation En viktig sak är att de kommunicerar ordentligt. Om de är på väg att bli försenade och inte hinna med det de lovat bör de kontakta dig så du har möjlighet att tala om för dem vad som är viktigast för dig att de gör. Om de undrar över hur en story skall tolkas så bör de också kontakta dig. Om de inte kontaktar dig i dessa lägen bör du diskutera med dem, så att de i fortsättningen gör det.

Releaser

4 releaser per team och 2-3 team, 1 timma per release. Detta ger totalt 8-12 timmar.

Det planeras för en release varannan vecka (totalt 3), men första releasen går nästan alltid snett och får göras om veckan efter. Så totalt blir det 4 releaser.

Som kund skall du gå igenom releasen och ge feedback till teamet. Vanligtvis, och speciellt i början, rekommenderar vi att du packar upp, installerar och provkör medan några i teamet ser på. Passa på under långlabben.

  • Tänk högt medan du packar upp, installerar och provkör. Iden är att teamet på så sätt skall inse vad som är svårt och besvärligt med produkten.
  • Teamet antecknar Se till att teamet antecknar allt som behöver ändras: i installation, funktion, användargränssnitt, dokumentation, etc.
  • Teamet återberättar Be teamet återberätta det de antecknat för dig, så du kan kontrollera att de uppfattat dina önskemål rätt.
  • Extra stories Be teamet skriva ner dessa saker som extra stories, så kan du sedan prioritera dem på nästa planeringsmöte.

Plattform

Produkten skall implementeras i Java och kunna köras på valfri plattform. Studenterna utvecklar normalt på Linux, men redovisningen och tävlingen sker på Mac. Kanske kommer eventuella problem med plattformsoberoende att märkas redan under första releasen. Under långlabb 5 och 6 kommer Mac:ar att finnas bokade som du kan låna ut till dina team, så att de kan se till att produkten fungerar på Mac.

Redovisning

På sista planeringsmötestiden redovisar kundens 2-3 team för varandra och kunden är examinator. Sker i annan (större) sal än planeringsmötena. Förarbete: 4h, salstimmar: 2h. Totalt antal timmar: 6. Görel har bokat projektorer och laptops för detta som du skall ta med.

Avslutning

Teamen använder sina produkter i en tävling. Det brukar vara på fredagen 10-12 sista veckan på läsperioden. Vi behöver hjälp av 1-2 kunder med logistiken på tävlingen (datorer, bord, etc.). För och efterarbete: 4 h, salstimmar: 2h. Totalt antal timmar: 6.

Godisometer

Lars har på frivillig basis använt en "Godisometer" till sina team: När de gör bra saker (håller sina estimeringar, gör programvara med hög kvalitet, kommunicerar på ett bra sätt, agerar professionellt, etc.) så får de pluspoäng. När de gör dåliga saker får de minuspoäng. I denna poängutdelning agerar han lärare snarare än kund. Han uppdaterar poängen på en webbsida så teamen kan se hur de ligger till jämfört med de andra teamen. På redovisningen får de en påse godis motsvarande sina poäng. Detta har varit mycket uppskattat av studenterna och fungerat mycket motiverande för dem. Vill någon mer prova på detta, prata gärna med Lars.

Mer info:

Tips

Här kommer tips på vad man kan tänka på:

Planeringsmöte 1

  • Hälsa på alla teamen kort i början av planeringsmötet. Antag att planeringsmötet börjar 13:15. Säg att du återkommer en viss tid, t.ex. 14:00, 14:15, eller 14:30 för att diskutera prioriteringen, och att de då skall ha en estimering klar.
  • Tänk igenom i förväg hur du vill prioritera stories. I denna iteration behöver story 3 och 7 prioriteras först, enligt beroendegrafen. Därefter är det mer öppet.
  • När du återkommer till teamet för att prioritera, titta först på deras estimering. Resonera sedan högt om hur du tänker när du prioriterar. Eftersom detta är första gången de estimerar är det svårt för dem att säga hur mycket de kommer att hinna. Man kan låta dem implementera "så mycket de hinner" denna första iteration.
  • Be dem dokumentera estimeringen och prioriteringen på sin wiki.

Fler tips

Har du själv fler tips till andra kunder? Lägg in dem här, eller maila kursansvarig (Ulf), så lägger jag eventuellt in dem.

Sidansvarig: