1 / 17

eXtremeProgramming

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

erica-monroe
Download Presentation

eXtremeProgramming

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. eXtremeProgramming Et projekt til undersøgelse af udviklingsmetodologi

  2. eXtremeProgrammingPrincipper Par Programmering Fællesejerskab af kode Enkelt Design Planning Game Hyppige Afleveringer Kundestilstædeværelse Funktionalitets Test Løbende Systemintegration Test Driven Refaktorering

  3. 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. Hvad 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 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. Hvad kunne være gjort anderledes? • Som XP også foreskriver så er det optimale at kunden er i samme lokale.

  4. Fællesejerskab Hvorfor fungerede det ikke. • Faldt hurtigt tilbage i ekspert rollerne • Tidskrævende at sætte sig ind i noget de andre har lavet 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 Hvad kunne være gjort anderledes? • Få styr på par-programmering • Mere fokus på at skifte områder i koden (planlægning).

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

  6. Par ProgrammeringHvorfor 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.

  7. Par ProgrammeringHvad 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.

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

  9. Applikationen Fremvisning og test af projektets slutprodukt

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

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

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

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

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

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

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

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

More Related