tirsdag 7. desember 2010 Softwareutvikling
I går kom jeg over en liten blogpost fra lederen på Institutt for Informatikk i Oslo hvor jeg via noen linker oppdaget at det pågår en liten debatt om smidig vs. fossefall som inneholder endel missoppfatninger om hva smidig er for noe. I et forsøk på å spre det jeg mener er et riktigere syn på smidig skrev jeg følgende kommentar til posten, som jeg tenkte jeg skulle gjengi her.
Når vi snakker om smidig så kan vi befinne oss på ulike nivåer. Det kan bl.a. være snakk om en filosofisk innstilling, praktisk programmering, eller prosjektstyring.
Filosofisk sett er smidig det å ta inn over seg at man aldri sitter med nok kunnskap om prosjektet før det er ferdig. Det dreier seg om en anerkjennelse av at softwareutvikling ikke har så mye til felles med bygging av broer likevel.
Dyktige utviklere har dessuten i praksis drever smidig programmering siden programmeringens begynnelse. Prøving og feiling er en naturlig del av å skape noe nytt, og å skape noe nytt gjør man hver gang i dette faget.
Og når det dreier seg om prosjektstyring så er ren fossefall desverre en utopi. Ingen prosjekter over en viss størrelse har blitt gjennomført i ren fossefall, hvor arbeidsflyten kun går én vei. Fordi man må forholde seg til realitetene fører fossefall til en stor grad av merarbeide, og ble aldri en løsning på budskjettsprekkene - hvilket det var ment å være.
Smidig vil alltid ha elementer av fossefall i seg. Man gjør ting i riktig rekkefølge når man kan. Det smidige manifestet sier f.eks. at det er verdi i å følge en plan - det er bare det at det er viktigere å reagere på endringer om/når de måtte manifistere seg. Smidig som metode er på mange måter en videreutvikling/forfining av vannfall. På det filosofiske nivået er det en større endring.
Utviklingsmetodikken jeg lærte på Universitetet på 90-tallet (RUP) er et godt eksempel på en god blanding av stereotypisk fossefall og det vi i dag ser på som moderne smidig.
Når vi snakker om praktiske prosjekter som gjennomføres i Norge i dag så vil nok hybrid-prosjektene være i flertall. Som oftest vil prosjekter arte seg som vannfall utad; kunder skal ha en fastpris, de leverer en spesifikasjon, og vil ha en leveranse ved prosjektets slutt. Internt brukes det derimot som regel smidige metoder - og man forsøker gjerne også å "undervise" kunden og få dem med seg for å få tilbakemelding underveis.
Fossefall ser ut til å fungere når man starter med en veldig god spesifikasjon. Problemet er at den strengt tatt må være 100% perfekt - hvis ikke ville man hatt fordeler med å innføre smidige metoder. Det andre problemet er at om man har en så detaljert og gjennomtenkt spesifikasjon så har det meste, eller i alle fall mye av prosjektet allerede blitt gjennomført FØR man SIER at det har startet. Derfor er fossefall ofte en illusjon.