Hva er DSDM (metoden for dynamisk systemutvikling)?

Hva er DSDM?

Metoden for dynamisk systemutvikling (DSDM) er et smidig rammeverk for prosjektleveranser som først ble utviklet i 1994, og som på den tiden ble brukt til programvareutvikling. Den var ment som en forbedring av rask applikasjonsutvikling (RAD), som prioriterte rask prototyping og iterasjon basert på tilbakemeldinger fra brukerne. I likhet med mange smidige metoder for prosjektleveranser gikk DSDMs smidige prosjektrammeverk etter hvert fra å være en programvarespesifikk løsning til å bli et mer generelt verktøy for prosjektstyring.

Elementene i metoden for dynamisk systemutvikling omfatter:

• Skiller seg fra andre metoder ved å være avhengig av et solid grunnlag og god styring
• Inkrementell og iterativ tilnærming til fremdrift 
• Tilbakemeldinger fra brukere eller kunder er avgjørende for kontinuerlige forbedringer 
• Basert på strenge begrensninger for kostnader, kvalitet og tid 
• Prioriterer omfanget i henhold til Må ha, Bør ha, Kan ha eller Skal ikke ha

I tillegg til selve metoden førte DSDM også til opprettelsen av DSDM Consortium i 1994. Programvareingeniører og andre eksperter slo seg sammen for å utvikle og forbedre rammeverket som et gyldig alternativ til de mer utbredte metodene for rask applikasjonsutvikling. På den tiden omfattet gruppen representanter fra blant annet British Airways, American Express, Oracle, Logica, Data Sciences og Allied Domecq. Gruppen har nå fått nytt navn og går under navnet Agile Business Consortium.

DSDM-håndboken ble gjort gratis tilgjengelig for visning og bruk på nettet i 2014.

DSDM kontra RAD kontra smidig utvikling

RAD-metodikken var svært populær tidlig på 1990-tallet som en metode for systemutvikling innen programvareutvikling og andre IT-prosjekter. I denne perioden gikk man fra det tradisjonelle brukergrensesnittet med «grønn skjerm» til grafiske brukergrensesnitt, som nå har blitt synonymt med all teknologi. Denne endringen innebar også at utviklingssyklusen kunne endres, ved å bruke denne nye typen visuelle brukergrensesnitt til kommunikasjon, rask prototyping og iterasjon. 

RAD-metodikken var en noe kaotisk smidig systemutviklingsmetode. Den hadde ingen enkelt, omforent tilnærming eller definisjon. Smidig DSDM var en mer strukturert tilnærming til denne typen programvareutviklingsmodell. Metoden for dynamisk systemutvikling hadde et sterkt fokus på tids- og kostnadsbudsjetter gjennom streng prioritering av omfanget. Den prioriterer også kommunikasjon (og påfølgende handling) mellom alle interessenter. 

DSDM er ikke bare streng når det gjelder tidsfrister og budsjett, men har også en fast rekkefølge på hendelsene: førprosjektfasen, prosjektets livssyklusfase og etterprosjektfasen. RAD-metoder for programvareutvikling handler i større grad om arbeid i fri form, der kreativitet og selvstendighet får råde selv når det fører til at ressursene tømmes. 

Scrum kontra DSDM

Scrum og DSDM har mange likheter, men også noen viktige forskjeller. Noen av dem er kun terminologiske. DSDM deler for eksempel arbeidet inn i «utviklingsaktiviteten» (også kalt utviklingsfasen) og «den fremvoksende løsningen» (også kalt resultatet). I Scrum er resultatet derimot kjent som det «potensielt leveringsklare inkrementet». 

Begge metodene har lister over deloppgaver som fullføres basert på at stramme tidsfrister overholdes. Begge metodikkene arbeider også mot et ferdig prosjekt, noe Scrum markerer når prosjektet når «Definisjonen av ferdig». Det finnes imidlertid ikke noe spesifikt tidspunkt i prosjektet der denne «Definisjonen av ferdig» blir avtalt. Dette er en viktig forskjell mellom Scrum og DSDM. 

I DSDM finnes det en fast fase der definisjonen av arbeidet (og det ferdige arbeidet) blir avtalt: prosjektets grunnlagsfase. Dette skjer relativt tidlig, noe som noen ganger kan bety at antakelser som ennå ikke er underbygget, påvirker planleggingsprosessen. For å ta høyde for dette skal definisjonen av «ferdig» arbeid gjennomgås regelmessig gjennom hele prosjektets livssyklus. Et annet stridspunkt er at teamledere skal unngå omfattende design på forhånd (BDUF), som i større grad kjennetegner fossefallsmetodikk og ikke smidig utvikling. 

DSDM-prinsipper

De smidige DSDM-prinsippene er den styrende kraften bak hvert prosjekt. Det finnes totalt 8 prinsipper.

1. Fokuser på virksomhetens behov
2. Lever i tide
3. Samarbeid
4. Gå aldri på kompromiss med kvaliteten
5. Bygg inkrementelt fra et solid grunnlag
6. Utvikle iterativt
7. Kommuniser kontinuerlig og tydelig
8. Vis at du har kontroll

DSDM-teknikker og -praksiser

Det som skiller DSDM fra andre systemutviklingsmetoder, er følgende # teknikker og praksiser. 

Tidsbokser: DSDM følger strenge standarder for tidsfrister. For å oppnå dette må hele prosjektet brytes ned i mindre elementer, som hver har et fast budsjett og en fast tidsramme. For å håndtere dette prioriteres kravene. Hvis tiden eller pengene begynner å ta slutt, fjernes kravene med lavest prioritet. Et ferdig prosjekt består dermed bare av de mest nødvendige kravene. 

MoSCoW: Dette er prioriteringsgruppene som brukes til å rangere elementer fra høyest til lavest viktighet. Prioriteringsgruppene er Må ha, Bør ha, Kan ha og Skal ikke ha. Konfigurasjonsstyring bidrar til å håndtere alle disse konkurrerende leveransene, som ofte utvikles samtidig.

Modellering og iterativ utvikling: Modellering bidrar til å visualisere ulike aspekter ved prosjektet underveis. Dette gjør det mulig å presentere hvert element som er under utvikling, og legge til rette for iterativ utvikling ved å gi regelmessige tilbakemeldinger og gjennomføre forbedringer. 

Prototyping: Som i mange smidige metoder er prototyping avgjørende for å prøve ut prosjektet på et tidlig, konseptuelt stadium. Det er en måte å kartlegge de grunnleggende funksjonene på, oppdage åpenbare svakheter og la brukerne prøve ut programvaren. 

Arbeidsmøter: Brukere og interessenter samles for å diskutere krav, problemer, resultater og testing. DSDM er avhengig av høy grad av brukerinteraksjon helt fra starten. Testing er svært viktig for DSDM, ettersom det sikrer resultater av høy kvalitet. 

DSDM-roller

All smidig systemutvikling vil ha en liste over roller som må fylles. DSDM er ikke noe unntak. Ifølge håndboken deres er dette de viktigste rollene i ethvert DSDM-miljø. 

1. Prosjekteier (den «prosjektansvarlige») - Brukerorganisasjonen og/eller kunden stiller med noen til denne rollen. Denne personen kan også tildele midler og ressurser etter behov. Vedkommende har «det siste ordet» når det gjelder beslutninger.

2. Visjonær - Med konkrete mål og forståelse for brukerens virksomhet starter den visjonære prosjektet ved å fastsette de høyest prioriterte kravene tidlig og veilede teamet basert på disse. 

3. Brukerambassadør - En ideell «testbruker» som bringer brukerfellesskapets perspektiv inn i prosjektet. Denne personen blir en viktig kilde til tilbakemeldinger gjennom hele prosessen. 

4. Brukerrådgiver - En annen type bruker som bør tilføre prosjektet viktige perspektiver. Personen kan ha unik innsikt eller annen kompetanse som gjør vedkommende til den ideelle kandidaten. 

5. Prosjektleder - En prosjektleder er enhver som leder det overordnede prosjektet. 

6. Teknisk koordinator - Vedkommende utformer systemarkitekturen og har ansvar for kvalitetskontroll av alle tekniske elementer. 

7. Teamleder - Teamets leder, med ansvar for koordinering og tilrettelegging av samarbeid. 

8. Løsningsutvikler - Håndterer systemkrav, modellerer systemet, utvikler leveransekoden og lager prototyper.

9. Løsningstester - Tester produktet og gir kommentarer og dokumentasjon når det oppstår feil. Vedkommende tester også på nytt etter at korrigeringer er gjennomført. 

10. Referent - Registrerer krav, avtaler, beslutninger og annen nyttig informasjon for prosjektets fremdrift. 

11. Tilrettelegger - Vedkommende har ansvar for å motivere og forberede arbeidsmøtet, slik at fremdriften forblir jevn og stabil. Personen må være en dyktig kommunikator og sørge for at alle holder kursen. 

12. Spesialistroller - Dette er roller som fylles av spesialister innen sitt fag- eller bransjeområde, og som gir ekstra støtte avhengig av prosjektets behov. De kan variere fra prosjekt til prosjekt og fra team til team. Slike roller kan omfatte virksomhetsarkitekt, kvalitetsleder, systemintegrator og flere. 

Tips for prosjektledelse med DSDM

Disse tipsene kan hjelpe deg med å få mest mulig ut av DSDM-prosjektet ditt, selv om alle smidige systemer også kan dra nytte av deler av denne kunnskapen. 

1. Ledelsen og alle ansatte må forstå og være innforstått med metoden som er valgt for et prosjekt. 

2. Teamet som leder prosjektet, må forplikte seg til brukertesting, tilbakemeldinger og involvering gjennom hele prosessen – fra idé til lansering.

3. Det må finnes et stabilt og bemyndiget kjerneprosjektteam. Teammedlemmene må ha beslutningsmyndighet for å sikre at prosessen ikke blir fastlåst i unødvendig omstendelige forslags- og godkjenningsprosesser. Teamet må også ha alt de trenger for å fungere, for eksempel riktig teknologi, et godt utviklingsmiljø, prosjektstyringsverktøy og mer. 

4. Det må være et støttende og proaktivt forhold mellom kunden og leverandøren, enten prosjektene utvikles internt eller settes ut. 

5. Teamet må vise mot når det gjelder å prioritere prosjektbehov ærlig og skrote elementer med lav prioritet etter behov. Det er slik man holder tidsplanen og budsjettet.