130 likes | 277 Vues
Å omfavne forandringer med ekstrem programmering(XP). Brukt i In140 Skrevet av Ola Bø Bygger på Kent Becks artikkel " Embracing change with extreme programming ." IEEE Computer, 32(10) 70-77, 1999. Fossefallsmodellen. Inkrementell (Trinnvis) utvikling.
E N D
Å omfavne forandringer med ekstrem programmering(XP) Brukt i In140 Skrevet av Ola Bø Bygger på Kent Becks artikkel "Embracing change with extreme programming." IEEE Computer, 32(10) 70-77, 1999.
Inkrementell (Trinnvis) utvikling • Mellom fossefalls- og evolusjonsmodellen • Prioritert oversikt over tjenestebehov • Definisjon av leveringstrinn • Detaljert spesifikasjon til første trinn • Trinnet utvikles, integreres og leveres. • Samtidig videre behovsanalyse for neste trinn • Trinnet tas umiddelbart i bruk og gir grunnlag for klarere spesifikasjon av de neste trinnene og en eventuell ny spesifikasjon for det som allerede er levert. • Et trinn kan utføres som fossefall eller evolusjonært
Ekstrem programmeringBakgrunn • Fossefallsmetoden • Kunden ikke i stand til å uttrykke endelige krav • Forandring kostet mer jo senere den kom • Forskernes svar • Relasjonsdatabaser • Modulær programmering • "Information hiding" • Hva om våre nye metoder faktisk virker? • Utnytte forandringskapasiteten
Planleggingsspill Mange utgaver. Lite nytt for hver gang Enkel utforming Testing Omforming Likeverdig programmering Kontinuerlig integrering Kollektivt eierskap Kunden på stedet 40-timers uker Kontorlandskap Bare regler XP i praksis
XP hakker opp ff-metoden i små biter og snur demUtviklingssyklus • Kunden velger nytt innhold for neste utgave • Behov og kostnad • Historier • Programmererne • deler historien i biter • velger • anslår • testtilfeller • koding med partner til testene fungerer • utforming endres stadig enkelhet
Historier • Første fase er kritisk • Hvor starter vi • Alle bruksområder for systemet føres på kartotekkort: "historier" • må være formålsrettet, testbart og mulig å anslå • En måned er mer enn nok til å lage historiene for et prosjekt på ti årsverk.
Utgaver • Kunden plukker først ut den minste samling av verdifulle historier som kan kjøres sammen • Senere kan han velge rekkefølg. Hver historie har pris og nytte. • Prisen er anslått utviklingstid for hver historie. • Begrenses av penger eller tid.
Iterasjon • Tidsskala uker • Målet er å sette i drift en eller flere historier • Plan for arbeidet • Bryte ned i oppgaver • Velge oppgaver • Anslå eget tidsforbruk. Ubalanse gir omfordeling • Implementering • Testing • Mens programmererne utvikler, lager kunden godkjenningstester. • Når testen fungerer er gruppa klar til ny iterasjon
Programmering av oppgaver • Uklarhet avklares direkte med kunde • All produksjonskode skrives i samarbeid • Oppgaven deles opp i testtilfeller • Testkode skrives før produksjonskode
Testing i sentrum • Skrive tester før kode • Alle tester dokumenteres • Noen tester er automatiske • Alle tester kjøres for hver utgave • Testene gir tiltro og forståelse • fra utvikler • fra kunde
Når noe går galt • For lave anslag • Kunder som ikke samarbeider • Utviklere som slutter • Endrede krav
Eksempler • Acxiom – kampanjesystem • – ti personer, tre år • Daimler/Chrysler – stort lønningssystem • 15 personer, 4 år • Ford Motor – kostnadsanalysesystem • 17 personer, 6 år • Fraktprisberegning • tre personer tre måneder