Børre Stenseth, Høgskolen i Østfold
Børre Stenseth, Høgskolen i Østfold
Børre Stenseth, oktober 2007
Faget informatikk har alltid hatt en løpende diskusjom om metoder for system/programutvikling. Ytterpunktene i denne diskusjonen har vært.
XP faller i den siste kategorien og er seneste variant av denne metodiske angrepsvinkelen.
XP er interessant fordi metoden opprettholder den kreativiteten som følger av en iterativ metodikk, samtidig som metoden beskriver noen føringer som sikrer systematikk og kvalitet i arbeidet.
Spørsmålet er om XP er et egnet styringsverktøy for prosjektbasert læring generelt
XP beskrives vanligvis ved disse punktene. Det finnes noen varianter av dette, men disse synes å gi en grei ramme for metoden.
En oppdragsgiver og en prosjektgruppe
Når XP beskrives som metode i systemutvikling er oppdragsgiverrollen i utgangspunktet en kunde som ikke har faglig innsikt. Oppdragsgiverens rolle er en som bestiller og som er i stand til å beskrive hva han vil ha og som kan vurdre underveis om han har fått det han har bestilt.
I en mer generell kontekst, der XP brukes som et pedagogisk stillas, må denne "oppdragsgiverrollen" analyseres nærmere. han har fått det han har bestilt.
Rollefordelingen er viktig
Rollebeskrivelsen er viktig (kunde / veileder / oppdragsgiver / ?)
Skaper forpliktelser og forventninger
Systematisk planlegging med korte etapper (1 - 2 uker).
Den iterative arbeidsformen kombinerer systematikk og kreativitet
Dette betyr planlegging på 3 nivåer:
Dette synes i første omgang komplisert, men den faller ut som en naturlig måte å tenke på i en prosess som er såpass oppdelt som XP. Det er imidlertid slik at forholdet mellom det endelige målet og de hyppige delmålene ikke er uproblematisk, både fordi vi kan komme til å drive suboptimalisering og fordi vi kan miste kontrollen over tidsfaktoren. For å si det enkelt kan vi risikere å vandre en lang kronglete vei uten å nå målet. Dette framheves naturlig nok ofte som en svakhet med XP. Dersom vi ser XP i en mer generell pedagogisk sammenheng, hviler det et ansvar på oppdragsgiver/veileder og holde fast i et langsiktig perspektiv når deloppgavene beskrives.
Åpen prosess
Styrt arbeidsdeling i tid og mellom gruppemedlemmer
Små, oversiktlige endringer fra gang til gang
Kontrollert progresjon
Prosjektet, komponenter og aktiviteter skal omtales i et språk som alle forstår og som det er lett å assosiere (riktig) til.
Begrepsavklaring og terminologi
Design skal aldri være mer komplisert enn det som er nødvendig for neste versjon.
Styrt progresjon
Overblikkbare arbeidsoppgaver
Ting skal testes. testene skal lages før løsningene.
Kvalitetskontroll (referanser, beregninger etc.)
Kast og restrukturer.
Endringer er en kontrollert og (mentalt) overkommelig jobb
All kode skal skrives av to personer.
Samarbeid og deling
Alle (i gruppa) står kollektivt og personlig ansvarlige for alt som er produsert.
Samarbeid og deling
Forpliktende
Endringer integreres kontinuerlig.
Det skal alltid finnes en seneste versjon av prosjektet
Planleggingen skal være slik at en unngår "skippertak".
Jevn arbeidsbelastning
Kunden, oppdragsgiveren skal være tilgjengelig til en hver tid.
Forpliktelse for oppdragsgiver / veileder
Gruppa enes om noen standarder som skal følges
Normer og former