Et projekt til undersøgelse af udviklingsmetodologi

eXtreme Programming Principper Par Programmering Fælles ejerskab af kode Enkelt Design Planning Game Hyppige Afleveringer Kundestilstedeværelse Løbende Systemintegration Test Refaktorering Metafor 40 timers arbejdsuge

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 til rådighed under hele projektet. Dårlig kundekontakt tvang udviklerne til at drage forhastede 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: Det er optimalt at kunden er i samme lokale under hele projektforløbet. Fokusere på at inddrage kunden under planning game og få verificeret prioriteringen.

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

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: Udviklerne fandt sig hurtigt til rette i ekspert roller pga. forskellig erfaring med teknologien Tidskrævende at sætte sig ind i noget en anden udvikler 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 skiftes til at skrive på forskellige områder af programmet (planlægning).

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 Dette projekt i forhold til UP Skalerbarhed Stabilitet

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.