Göm menyn

TDDI02 Programmeringsprojekt

Erfarenhetsrapport (obligatoriskt)


Erfarenhetsrapport, Reflektionsdokument, Efterstudie

Detta dokument ska ni skriva för att få anledning att begrunda den process ni gått igenom, samla ihop de tankar den givit upphov till, och summera erfarenheter som kan ligga till grund för framtida projekt/verksamhet. Rapporten i sin helhet bör vara ett par A4-sidor.

Relatera till den 'tidsplan' ni (väl?) satt upp, eller de förväntningar ni med all säkerhet haft. Reflektera annars om hur en bättre planering kunde undvikit några problem ni haft eller hjälpt er på annat sätt.

Gå igenom projektets olika faser (krav, design, implementation, leverans), en i taget. Skriv för var och en ner hur er plan sett ut, och huruvida ni lyckats hålla er till den eller ej. Analysera orsakerna till att ni eventuellt blev sena, och beskriv hur ni löste de problem ni stötte på. Eller tvärtom; av vilket skäl gick det bättre än ni förväntat er. Blev slutprodukten från denna fas bra nog för att ligga till underlag för nästa fas, eller inte? Vad bestod dess brister i? Vad kunde gjorts bättre, sett ur det perspektivet?

Blev till sist slutprodukten vad ni från början hade hoppats? Vilka faktorer bidrog till att det gick som det gick?

Slutligen ska varje gruppmedlem för sig (ange vem!) beskriva den allra viktigaste personliga erfarenheten/kunskapen som projektarbetet bidragit till, och som säkerligen kommer till nytta i kommande programmeringsprojekt (eller vidare yrkesliv).

Sammanlagt bör detta bli minst 8 erfarenheter, individuella och gemensamma sammanräknade.

OBS! Dokumentet är INTE en kursutvärdering, utan en samling arbetserfarenheter som är värda att komma ihåg till nästa projekt ni är med i. En form av "självutvärdering". Har ni synpunkter på kursen lämnar ni dem separat till examinator.

Vad räknas som en dokumenterad erfarenhet?

Att skriva ned sina erfarenheter kräver lite eftertanke. Det gäller att skriva ned tillräckligt för att en oinsatt läsare skall kunna göra samma positiva erfarenhet i ett eget projekt, alternativ kunna undvika en negativ erfarenhet. Det bör för varje erfarenhet framgå:

  • Hur ni gick tillväga, vad ni gjorde, hur ni gjorde, och varför ni valde den metoden?
  • Vad resultatet blev, om tillvägagångssättet ledde till något positivt eller negativt?
  • Varför ni är nöjda eller missnöjda med resultatet och varför det blev som det blev?
  • Hur kommer det här påverka hur ni närmar er en liknande situation i framtiden? Det vill säga, vad blir det långsiktiga lärdommen från detta?

Exempel på en intetsägande "erfarenhet": "Revisionshantering via Git har fungerat mycket bra och hjälpt alla utvecklare i projektet."

Exempel på en bättre formulerad erfarenhet: "Vi använde revisionshantering via Git. Detta hjälpte alla utvecklare hålla reda på senaste versionen och underlättade distributionen av färdiga moduler mellan utvecklarna. Vid två tillfällen kunde vi snabbt hitta fel som uppstod tack vare historiken. Ett problem var att kod som inte fungerade checkades in vid flera tillfällen och det slarvades även med att kommentera vad som checkades in. Detta gjorde att utvecklare spenderde onödig tid på felsökning. Vi borde kommit överens om att bara checka in testad och fungerande kod, men ändå ofta, en modul i taget. I framtida projekt kommer vi försöka använda revisionshantering, med ett gruppkontrakt där vi kommer överens om att bara checka in fungerande kod för att underlätta samarbetet."

Döm själv vad som saknas i de två exemplen enligt punkterna ovan. Döm vilket exempel ni själv helst skulle vilja läsa i förberedelsefasen för ett projekt.


Sidansvarig: Jonas Lindgren
Senast uppdaterad: 2014-10-05