Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

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.

Liknende presentasjoner


Presentasjon om: "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."— Utskrift av presentasjonen:

1

2 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

3 •Aftenposten: –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

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

5 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!

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

7 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

8 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

9 Å 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

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

11 Å 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

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

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

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

15 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

16 4 verdier •Feedback –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

17

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

19 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


Laste ned ppt "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."

Liknende presentasjoner


Annonser fra Google