Valg av Riktig Prosjektmetodikk: Smidig eller Fossefall?
Før vi går direkte inn på spørsmålet i overskriften, er det viktig å definere de overordnede målene for prosjektet. Hvordan skal produktet se ut om én måned, seks måneder eller ett år fra nå? Å ha en klar visjon gir perspektiv og etablerer forventninger knyttet til forutsigbarhet, fleksibilitet, hurtighet til markedet og kostnadsstyring.
Selv om det kan virke gammeldags å bruke fossefallsmetodikken i dagens marked, der smidighet er ofte avgjørende for å reagere raskt på endringer, kan det fortsatt være relevant i visse situasjoner. Hvis målet ditt er å levere et produkt om et år med klart definerte funksjoner og et team uten tidligere erfaring med smidig metodikk, kan en konservativ fossefallsmetode være et godt valg.
Det er ikke alltid like lett å velge riktig metode. La oss se på hvordan man kan vurdere hvilken metodikk som passer best for ditt prosjekt.
Hvordan fungerer et fossefallsprosjekt?
I stedet for å gå i dybden på definisjoner som er velkjente, beskriver vi det praktiske resultatet av et typisk fossefallsprosjekt:
- Start med å planlegge ønsket sluttprodukt og estimere de potensielle kostnadene.
- Gjennomfør en grundig kravinnsamlingsprosess. Diskuter detaljer, still spørsmål, argumenter, kom til enighet, og bekreft kravene.
- Estimere kostnadene og bekrefte budsjettet.
- Design løsningen. Involver interessenter, lag dokumentasjon, la interessenter gjennomgå den. Bekreft det endelige funksjonelle og tekniske designet.
- Implementer løsningen basert på designet. Utvikle det komplette sluttproduktet.
- Gjennomfør ulike tester: enhetstester, systemtester, funksjonstester, integrasjonstester, ytelsestester, regresjonstester, brukertester. Dokumenter alt og la interessentene godkjenne det.
- Distribuer løsningen til produksjonsmiljøet. Målbrukerne begynner å bruke det ferdige produktet.
- Planlegg for en supportfase der utviklingsteamet retter potensielle feil i løsningen.
Denne prosessen kan ta fra noen måneder til flere år, og brukerne ser ikke resultatet før helt på slutten. Hvis noe endrer seg underveis, må designet endres, noe som forlenger tidsplanen. Hver endring krever en omstart av prosessen. På den positive siden gir fossefallsmetoden en solid fasedefinisjon, et fast budsjett og en fast tidsplan. Hvis det er liten sannsynlighet for endringer, kan dette være en foretrukken tilnærming.
Hvordan fungerer et smidig prosjekt?
Slik kan et prosjekt fungere i en smidig tilnærming:
- Definer forretningsvisjonen for sluttproduktet, med klare krav og forventninger.
- Lag en liste over funksjonelle epos og tekniske oppgaver.
- Gjør en overordnet estimering av eposene, etabler et budsjett og en tidslinje. Definer MVP (Minimum Viable Product) og de resterende funksjonene.
- Sett sammen et scrum-team og planlegg sprintene. Bryt ned epos i funksjoner og historier. Estimer historiene og planlegg dem basert på prioritering.
- Arbeid med historiene i hver sprint, inkludert design, utvikling, test og distribusjon. Presenter resultatene for brukerne og be om tilbakemelding.
- Juster funksjonene eller historiene basert på tilbakemeldinger og endringer. Reflekter dette i de neste sprintene.
- Etter at MVP er fullført, slipp det til brukerne for å samle tilbakemelding.
- Fortsett å utvikle de resterende funksjonene og ta hensyn til tilbakemeldinger.
Forskjellen fra fossefall er tydelig. Rask tilbakemelding, tilpasning, refleksjon av endrede behov, og et verdifullt produkt levert på kort tid. Dette er fordeler som ikke finnes i et fossefallsprosjekt.
Smidig vs. Fossefall
For å lykkes med et prosjekt er en passende prosjektledelsesmetodikk viktig. Det innebærer å definere prosesser, målinger, evalueringer og arbeidsmåter. Teamene må vite hvilke regler de skal følge, hva som definerer milepæler, og hvordan man måler suksess. Interessenter må forstå hva de kan forvente og når de vil se resultater.
Prosjekter i skybaserte miljøer er mer tilbøyelig til å bruke smidige metoder, mens prosjekter med lokal infrastruktur ofte foretrekker fossefallsprosesser. Skymiljøet er bygget for å tilpasse seg raskt, mens lokale miljøer ofte er forhåndsdefinert og vanskelige å endre.
Oppsummering av smidig vs. fossefall:
| Funksjon | Fossefall | Smidig |
| Håndtering av brukerkrav | Endringer behandles som en formell prosess. Arbeid må kanskje gjøres om, noe som påvirker kostnader og tidslinjer. | Endringer er en del av standardprosessen uten store innvirkninger på kostnader eller tidslinjer. |
| Prosjektplanlegging og omfang | Omfanget defineres i starten og holdes fast. Fasene er rigide og følger den opprinnelige planen. | Har en klar visjon om sluttproduktet, men tillater endringer. Arbeidet er organisert i sprints med fleksibilitet. |
| Prosjektfremdriftssporing | Fremdrift spores innenfor hver fase. Forsinkelser i en fase kan påvirke hele prosjektet. | Fremdriften spores gjennom demoøkter etter hver sprint. Fokuserer på det gjennomførbare produktet. |
| Teamsamarbeid | Forskjellige personer i ulike faser, begrenset interaksjon. | Tverrfaglig team med konstant kommunikasjon mellom teammedlemmer og interessenter. |
| Risikostyring | Statussporing basert på fasefremdrift. Reagerer på risikoer i etterkant. | Fokuserer på å løse avhengigheter proaktivt. Tilpasser planen for å eliminere risikoer. |
| Implementeringsramme | Tradisjonell metodikk. | Krever transformasjonspraksis for å tilpasse seg den smidige tilnærmingen. |
Valget av metodikk definerer mange aspekter ved prosjektgjennomføringen.
#1. Prosjektkrav og endringsledelse
Et viktig aspekt er hvordan man håndterer brukerkrav og endringer i disse kravene.
I et fossefallsprosjekt er alle krav definert og godkjent av interessentene i begynnelsen. Endringer behandles som en endringsforespørsel, som må valideres og godkjennes på nytt. Dette kan føre til at arbeid må gjøres om, kostnader må justeres, og tidslinjer kan forlenges.
I et smidig oppsett er endringer velkomne. De behandles som en del av den daglige driften. Endringer planlegges for de kommende sprintene, og det er ingen tap i tid eller kostnader. Man tilpasser seg den nye virkeligheten og erstatter den opprinnelige planen. Det er ikke behov for spesiell administrasjon av endringsforespørsler.
#2. Prosjektplanlegging og omfang
Et fossefallsprosjekt setter og fikserer omfanget i starten, og deler prosjektet opp i faser. Målet er å holde seg til den opprinnelige planen så mye som mulig.
Et smidig prosjekt har en visjon om sluttproduktet, men veien for å nå det er fleksibel. Tidslinjen er definert basert på et estimat, men planen har ingen separate faser. Hver sprint er en liten fase som inneholder alle nødvendige aktiviteter. Et fossefallsprosjekt behandler endringer som en komplikasjon, mens et smidig prosjekt behandler det som vanlig forretningsvirksomhet.
#3. Sporing av prosjektfremdrift
Fossefallsprosjekter sporer fremdriften innenfor de ulike fasene. Forsinkelser i én fase påvirker de resterende fasene. Det er derfor viktig å sørge for at aktivitetene utvikler seg lineært.
Smidige prosjekter sporer fremdriften med demoøkter etter hver sprint. Det ferdige produktet er det viktigste målet. Det er enklere å se den generelle fremdriften når man kan prøve produktet og gi tilbakemelding direkte.
#4. Team Samarbeid
Fossefallsprosjekter har ofte forskjellige personer som jobber i ulike faser, mens smidige team fokuserer på konstant samarbeid og kommunikasjon.
Smidige team skal være tverrfaglige og kunne utføre alle produktlivssyklusaktiviteter. Kommunikasjon mellom teamet og eksterne interessenter er viktig for et vellykket smidig prosjekt.
#5. Risikostyring
Både fossefall og smidige prosjekter trenger prosesser for å spore risikoer og problemer.
I fossefallsprosjekter brukes statusrapportering for å vise om prosjektet er i rute. Ved et smidig prosjekt løser man avhengigheter mellom team og aktiviteter for å unngå risiko. Man endrer planen for å eliminere risikoer, i stedet for å prøve å løse dem samtidig som man holder seg til planen.
En smidig tilnærming er proaktiv i risikostyring, mens man i et fossefallsprosjekt reagerer på risikoer i etterkant.
#6. Implementeringsramme
Implementering av fossefallsprosjekter er ofte enklere fordi det er en tradisjonell metodikk. Smidige prosjekter krever derimot transformasjonspraksis for å endre vaner, tankesett og arbeidsmåter. Det er en vanskelig prosess som krever investering av tid og ressurser.
Fordelene med rask tilpasning til endrede behov er store, men å endre folks tankesett er den vanskeligste delen. Det er likevel nødvendig for å være konkurransedyktig i markedet.
Siste ord
Med mindre du har en konservativ kunde uten motivasjon for raske resultater, er smidige metoder det beste alternativet. Dette gjelder også for tradisjonelle on-premise systemoppsett. Det er fornuftig å tilpasse prosessene til smidige metoder, spesielt for nye team.
Det finnes fortsatt prosjekter der man nekter å følge smidige prosesser, og i stedet velger en streng fasedelt organisering av arbeidet. De forventer at prosjektet skal følge planen uten avvik. Dette er et valg de har rett til å ta, men det kan føre til at de blir værende i fortiden. Det kan fungere en stund, men det er bare et spørsmål om tid før det ikke lenger vil fungere.
Du kan også lese mer om livssyklusen for smidig testing.