Hva er de største problemene med softwareprosjekter? Vi aner ikke hvor mye det koster, eller når det er ferdig Vi har ingen plan, eller planen følges ikke Beslutningsprosessen er preget av handlingslammelse, beslutningsvegring, ansvarsfraskrivelse og kommunikasjonsvansker Levert programvare har uforutsigbar kvalitet Mange feil Vanskelig å endre

Aftenposten 4 mars: Offentlig IT-sprekk for 6 mrd. hvert år Forskere fra Simula Research Laboratory har funnet ut at offentlige IT-prosjekter i gjennomsnitt sprekker med 67 prosent, mens IT-prosjekter i privat regi "bare" sprekker med 21 prosent. Dette koster skattebetalerne inntil 6 milliarder kroner i året. Aftenposten 4 mars: Offentlig IT-sprekk for 6 mrd. hvert år ”Mye tyder på at de offentlige kundene gjør for dårlig forarbeid når de lager kravspesifikasjonen og når de inngår kontraktene. Samtidig opplever mange av leverandørene at det underveis er mye sendrektighet og lange beslutningsprosesser i offentlige etater”, sier Moløkken. Aftenposten 4. mars

Vanlige reaksjoner: Bli grundiger Aftenposten: IT-konsulent Helge Gundersen i selskapet Objectnet kjenner seg igjen i konklusjonene fra undersøkelsen. ”Det er alltid en viss risiko i IT-prosjekter, og det vil av og til oppstå overskridelser. For oss som leverandører er det ikke minst viktig at kravspesifikasjonen i oppstarten er så detaljert som mulig. Her er nok private selskaper flinkere enn de offentlige etatene”, sier han. Computerworld: Aftenposten skriver at "de offentlige kundene gjør for dårlig forarbeid når de lager kravspesifikasjonen og inngår kontraktene". Avisen anbefaler at kundene skal lage meget detaljerte kravspesifikasjoner i starten av prosjektet og deretter følge dem til punkt og prikke. Denne tankegangen gikk ut på dato for ti år siden.

Hvorfor? Forsøkene på kur har fungert mot sin hensikt Langvarige estimering, analyse, design uten forankring i erfaringsdata Formelle overhendinger mellom personer eller organisasjoner preget av ansvarsfraskrivelse og beslutningsangst Endring håndteres som unormalt, mens endring er normen i softwareprosjekter Er programvareutvikling uforutsigbart? Nei, mener vi Men man trenger gode erfaringstall fra denne teknologien, i dette løsningsområdet, med disse personene!

Hva trenger vi? Erfaringsdata som forbedres underveis – forbedrer beslutningsgrunnlaget Mulighet til å endre mening for en rimelig penge – forhindrer beslutningsvegring Teknikker for å forbedre kvalitet

Hvordan får vi det? Metafor – prosjektmotoren Input – oppgaver i prioritert rekkefølge Implementerbare - leverbare Sammenlignbare i omfang Kan implementeres i relativt vilkårlig rekkefølge Output – ferdig testet (helst produksjonssatt) programvare Bi-output – kostnadsstatistikk Jo bedre programvaren en, desto mer realistisk blir prosessen

Resultat Vi kan endre oppgavelisten, så lenge vi ikke ønsker å endre det som er tatt inn i motoren Vi kan bruke erfaringsdata til å spå hvor hurtig vi kommer gjennom oppgavelisten

Å bruke prosjektmotoren Kunden/forretningsansvalig spesifiserer krav til oppgaveliste Utviklingsteamet grupperer oppgaver i størrelseskategorier Kunden/forretningsansvalig prioriterer oppgaver Erfaringsdata brukes til å forutsi framdrift (”yesterday’s weather”) Kunde/markedsansvalig bruker fremdrift og forretningskunnskap til å bestemme eksterne leveranser The planning game

Forutsetninger – det er her XP kommer inn i bildet Produktet kan endres uten høy kostnad Kvaliteten på levert programvare er høy Oppgaver må ha relativt liten avhengighet til hverandre eller til spesifikke ressurser Unngå masse tid på aktiviteter som ikke er leverbare Det som er levert fra prosjektmotoren kan produktsettes ”Produktansvarlig” må være involvert i prosjektet Dette er naturligvis noe vi veldig gjerne vil ha uansett!

Å gjøre programmer endringsdyktige Forbedre designet etter behov – refactoring Et enkelt design, som kun gjør det det skal – simple design Støttet opp av gode enhetstester – test-driven design Alle kan endre det de trenger – collective code ownership (don’t own code, own tasks) All kode er revidert av et annet par øyne – pair-programming

Å forbedre kvaliteten Enhetstester Integrerte testere/brukere – on-site customer All kode er revidert – pair programming All kode brukes til noe nå – ingen tidsbomber - simple design + test driven development

Å gjøre seg ressursuavhengig Mer enn en person kjenner all kode – pair programming Ingen må vente på andre for å endre kode – collective code ownership En utviklers kode avviker skjelden fra felleskoden – continous integration

Typisk implementasjonsløp Utvikler tar første oppgave Utvikler avklarer eventuelle spørsmål når de oppstår med bruker/forretningsansvarlig Utvikler integrerer med resten av gruppen Utvikler refaktorerer tilgrensende kode for å forenkle oppgaven Utvikler bruker test-driven development til å utvikle oppgaven Utvikler refaktorerer resultatet Utvikler samarbeider med en tester for å verifisere akseptansekrav (helst automatisk)

XPs 12 teknikker Refactoring Simple design Test-driven development Collective code ownership Pair programming The planning game Continous integration Whole team (was: Customer on-site) Sustainable pace Frequent releases Metaphor (ubiquitous language) Coding standards

4 verdier Feedback Enkelhet Snakke sammen Mot Uten data kan vi ikke ta informerte avgjørelser Enkelhet Hold mulighetene oppe Bruk ikke tid på spekulative ting Snakke sammen Ikke kast dokumenter og ansvar til neste person på andre siden av veggen! Mot Til å starte med noe selv om vi ikke vet alle detaljene for hele prosjektet Til å møte problemene nå, i stedet for senere

Noen støtteteknikker Uformelle visuelle modeller (Ambler, Fowler) CRC cards for analyse Daglige stand-up møter Big Visible Charts – burn-down charts

Hva jeg hadde snakket om dersom jeg hadde hatt 5 timer til Testing Enhetstesting – hvordan fungerer test-driven development? Test-utfordringer – GUI, databaser, nettverk, legacy Akseptansetesting Bugsrapporter Estimering Hvordan oppnå en hensiktsmessig oppgaveliste? Hvordan gi tilbud på fastprisprosjekter Utfordringer rundt parvis programmering