Å 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

Kravspesifikasjon

System ogprogramvareutforming

Implementering ogdeltesting

Drift og vedlikehold

Integrasjon ogsystemtesting

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

XP i praksis

• 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 hakker opp ff-metoden i små biter og snur dem

Utviklingssyklus

• 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