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  Specielle forhold.  Hvad betød det for det videre forløb.  Hvad kunne være gjort anderledes.

Kunde tilstedeværelse Specielle forhold:  Urealistisk at forvente kunden er tilstede under hele projektet.  Dårlig kundekontakt kan skabe forhastede eller egne konklusioner.  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 planlægningsforlø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ælles ejerskab  Specielle forhold.  Hvad betød det for det videre forløb.  Hvad kunne være gjort anderledes.

Fælles ejerskab Specielle forhold:  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 fælles ejerskab således at alle kunne rette fejl og refaktorere i alt koden.  Vi endte med et system hvor vi hver især havde hver vores ansvarsområde.

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).

• Vores oplevelser. • Hvad betød det for det videre forløb. • Hvad kunne være gjort anderledes. Par Programmering

Par Programmering Oplevelser:  Unaturligt for os at arbejde i par da vi arbejdede i en lille gruppe omkring ét bord.  Svært at sætte sig ind i en mentor og lærlinge rolle.  Svært at overholde navigator og driver rollerne.

Par Programmering Hvad betød det for det videre forløb:  Fælles ejerskab bliver betydeligt sværere at inddrage (falder tilbage i ekspert roller).  Kodestandarder bliver mere problematisk at overholde.  XP’s rigiditet gør, at hvis et princip som parprogrammering fejler, så har det indflydelse på de andre princippers kvalitet.

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”)

Konklusion  Gode principper i teorien, dog svært at implementere i praksis  Brugbar fremgangsmåde til planlægning  Godt til mindre projekter med erfarne udviklere

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 de fag der går videre til næste fase blandt de indkommende forslag.  Her kan der med fordel lægges mere information ind om faget så det ikke bare er titel.

User Story 3  Eleven logger ind i systemet og vælger to 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.