Et projekt til undersøgelse af udviklingsmetodologi

eXtreme Programming Principper • Par Programmering • Fællesejerskab af kode • Enkelt Design • Planning Game • Hyppige Afleveringer • Kundestilstædeværelse • Funktionalitets Test • Løbende Systemintegration • Test Driven • Refaktorering

Kunde tilstedeværelse  Hvorfor fungerede det ikke.  Hvad betød det for det videre forløb.  Hvad kunne være gjort anderledes?

Kunde tilstedeværelse Hvorfor fungerede det ikke?  Urealistisk at forvente kunden er tilstede under hele projektet.  Dårlig adgang til kunden betyder man tager nogle konklusioner og modificerer dem alt efter hvordan kunden i sidste ende svarer tilbage.  Planning game var overstået på forhånd inden projekt start.

Kunde tilstedeværelse Hvad betød det for det videre forløb?  Kundens tilstedeværelse er ”make or break” for det videre forløb. Det er ikke nok kunden kun er med til det første planning game.  Der var meget lidt dynamik i projektforløbet. Alt var på plads inden projekt start.  Projektet fik nemt et snært af ”vandfald” da det meste af planlægningen var gjort på forhånd.

Kunde tilstedeværelse Hvad kunne være gjort anderledes?  Som XP også foreskriver så er det optimale at kunden er i samme lokale.

Fællesejerskab  Hvorfor fungerede det ikke.  Hvad betød det for det videre forløb.  Hvad kunne være gjort anderledes?

Fælles ejerskab Hvorfor fungerede det ikke?  Faldt hurtigt tilbage i ekspert rollerne  Tidskrævende at sætte sig ind i noget de andre har lavet

Fælles ejerskab Hvad betød det for det videre forløb?  Vi opnåede ikke den ønskede grad af at alle kan rette fejl og refaktorere hvor man ønsker i koden.  Vi endte med et system hvor vi hver især havde hver vores del

Fælles ejerskab Hvad kunne være gjort anderledes?  Få styr på par-programmering  Mere fokus på at skifte områder i koden (planlægning).

• Hvorfor fungerede det ikke • Hvad betød det for det videre forløb? • Hvad kunne være gjort anderledes? Par Programmering

Par Programmering Hvorfor fungerede det ikke?  Kom os ikke naturligt at arbejde i par da vi arbejde i en lille gruppe omkring ét bord.  Svært at sætte sig ned i en mentor og lærlinge rolle.  Svært at holde navigator og driver rollerne.

Par Programmering Hvad betød det for det videre forløb?  Fællesejerskab bliver betydeligt mere svært (falder tilbage i ekspert roller)  Kodestandarter bliver mere problematisk at implementere.  XP’s rigiditet betyder at hvis et princip som parprogrammering fejler så kaskader det ind i de andre principper.

Par Programmering Hvad kunne være gjort anderledes?  Bedre planlægning af hvilke par der laver hvad  Alternative måder at parprogrammere på kan gøre det nemmere hvis de traditionelle metoder ikke fungerer (fx "ping pong pair programming”)

Fremvisning og test af projektets slutprodukt

Valgfagssystem Præsentation af userstories • Tilføj valgfagsforslag • Udvælg fag til første pulje • Udvælgelse af prioriteter • Placering af fag i puljer • Pulje prioritering • Tildeling af fag til eleverne

User Story 1  Muligheden for at tilføje forslag til nye fag  Vil i sidste ende kræve login fra elevens side

User Story 2  Valgfags leder udvælger iblandt de indkommende forslag de fag der går videre til næste fase  Her kan der med fordel ligges mere information ind om faget så det ikke bare er titel

User Story 3  Eleven logger ind i systemet og vælger 2 første og anden prioriteter  Igen kan der med fordel stå udvidet information om faget eller linkes til ekstern side med informationen.

User Story 4  Uddannelses leder udvælger hvilke fag der skal i pulje 1 eller 2  Tilfredsheden blandt eleverne vises vha. Farver for at give et hurtigt overblik over den overordnede tilfredshed

User Story 5  Eleven logger på og vælger en første og anden prioritet fra både pulje 1 og 2  Igen kan der linkes til en side om hver valgfag for at give eleven yderligere information om faget

User Story 6  Uddannelseslederen vælger hvilke fag der endeligt skal vælges. Elevens tilfredshed vises i kolonnen til venstre  Lederen vælger nu hvilke fag eleverne skal have, farven på feltet viser hvor tilfreds eleven vil være for det valg.  Valgfagene gemmes

User Story 7 og 8 User Story 7 og 8 blev ikke implementeret da vi bestemte os for at koncentrere os om de andre  User Story 7 beskriver processen hvor lederen printer listen ud og afleverer den til sekretæren  User Story 8 beskriver processen hvor sekretæren via notificerer eleverne om deres kommende valgfag.