240 likes | 335 Views
eXtremeProgramming. 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
E N D
eXtremeProgramming Et projekt til undersøgelse af udviklingsmetodologi
eXtremeProgrammingPrincipper 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ærelseSpecielle 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ærelseHvad betød det for det videre forløb: • Kundens tilstedeværelse er ”makeor 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ærelseHvad 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 ejerskabSpecielle forhold: • Faldt hurtigt tilbage i ekspert rollerne • Tidskrævende at sætte sig ind i noget de andre har lavet
Fælles ejerskabHvad 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 ejerskabHvad 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 ProgrammeringOplevelser: • 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 ProgrammeringHvad 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 ProgrammeringHvad 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
Applikationen 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 hurtigtoverblik over den overordnedetilfredshed
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 email notificerer eleverne om deres kommende valgfag.