Mikä on DSDM (dynaamisten järjestelmien kehitysmenetelmä)?

Mikä on DSDM?

Dynaamisten järjestelmien kehitysmenetelmä (DSDM) on ketterä projektien toimituskehys, joka syntyi ensimmäisen kerran vuonna 1994 ja jota käytettiin tuolloin ohjelmistokehitykseen. Sen tarkoituksena oli parantaa nopean sovelluskehityksen (RAD) menetelmää, jossa painotettiin nopeaa prototyyppien luomista ja käyttäjäpalautteeseen perustuvaa iterointia. Kuten monet ketterät projektien toimitusmenetelmät, DSDM:n ketterä projektikehys kehittyi lopulta ohjelmistokohtaisesta ratkaisusta yleisemmäksi projektinhallintatyökaluksi.

Dynaamisten järjestelmien kehitysmenetelmän keskeisiä elementtejä ovat:

• Erottuu muista menetelmistä vahvoihin perustuksiin ja hallintoon tukeutumisensa ansiosta
• Edistymisen vaiheittainen ja iteratiivinen lähestymistapa 
• Käyttäjien tai asiakkaiden palaute on jatkuvien parannusten kannalta keskeistä 
• Perustuu tiukkoihin kustannus-, laatu- ja aikarajoituksiin 
• Asettaa laajuuden tärkeysjärjestykseen sen mukaan, onko ominaisuus välttämätön, suositeltava, mahdollinen vai toteutuksen ulkopuolelle jäävä

Itse menetelmän lisäksi DSDM johti myös DSDM-konsortion perustamiseen vuonna 1994. Ohjelmistoinsinöörit ja muut asiantuntijat yhdistivät voimansa kehittääkseen ja parantaakseen kehystä pätevänä vaihtoehtona yleisemmille nopean sovelluskehityksen menetelmille. Tuolloin ryhmään kuului edustajia muun muassa British Airwaysilta, American Expressiltä, Oraclelta, Logicasta, Data Sciencesilta ja Allied Domeqcilta. Ryhmä on sittemmin uudelleenbrändätty, ja sen nimi on nykyään Agile Business Consortium.

DSDM-käsikirja julkaistiin vapaasti verkossa katseltavaksi ja käytettäväksi vuonna 2014.

DSDM vs. RAD vs. ketterä kehitys

RAD-menetelmä oli erittäin suosittu 1990-luvun alussa järjestelmien kehitysmenetelmänä ohjelmistokehityksessä ja muissa IT-projekteissa. Tuolloin perinteisestä ”vihreän ruudun” käyttöliittymästä siirryttiin graafisiin käyttöliittymiin, joista on sittemmin tullut kaiken teknologian synonyymi. Tämä muutos tarkoitti, että myös kehityssykli saattoi muuttua, kun uudenlaista visuaalista käyttöliittymää käytettiin viestintään, nopeaan prototyyppien luomiseen ja iterointiin. 

RAD-menetelmä oli jokseenkin kaoottinen ketterä järjestelmänkehitysmalli. Sillä ei ollut yhtä sovittua lähestymistapaa tai määritelmää. Ketterä DSDM oli rakenteellisempi lähestymistapa tämäntyyppiseen ohjelmistokehitysmalliin. Dynaamisten järjestelmien kehitysmenetelmä keskittyi erittäin vahvasti aika- ja kustannusbudjetteihin tiukan laajuuden priorisoinnin avulla. Se painottaa myös kaikkien sidosryhmien välistä viestintää ja siitä seuraavia toimenpiteitä. 

DSDM ei ole tiukka ainoastaan määräaikojen ja budjetin suhteen, vaan siinä on yleensä myös kiinteä tapahtumajärjestys: projektia edeltävä vaihe, projektin elinkaarivaihe ja projektin jälkeinen vaihe. RAD-ohjelmistokehitysmenetelmissä on enemmän kyse vapaamuotoisesta työskentelystä, jossa luovuuden ja itsenäisyyden annetaan vallita jopa resurssien ehtymisen kustannuksella. 

Scrum vs. DSDM

Scrumilla ja DSDM:llä on monia yhtäläisyyksiä, mutta myös muutamia tärkeitä eroja. Jotkin erot liittyvät vain terminologiaan. Esimerkiksi DSDM jakaa työn ”suunnittelutoimintaan” (eli kehitysvaiheeseen) ja ”kehittyvään ratkaisuun” (eli tuotokseen). Scrumissa tuotosta kutsutaan sen sijaan nimellä ”mahdollisesti julkaistava inkrementti”. 

Molemmissa menetelmissä on luettelo alitehtävistä, jotka suoritetaan tiukkojen määräaikojen mukaisesti. Molemmissa menetelmissä rakennetaan myös kohti valmista projektia, jonka Scrum merkitsee saavutetuksi, kun projekti saavuttaa ”valmiin määritelmän”. Tälle ”valmiin määritelmälle” ei kuitenkaan ole projektissa tiettyä ajankohtaa, jolloin siitä sovitaan. Tämä on keskeinen ero Scrumin ja DSDM:n välillä. 

DSDM:ssä on määritetty vaihe, jossa työn määritelmä (ja valmiin työn määritelmä) sovitaan: projektin perustamisvaihe. Tämä tapahtuu suhteellisen varhain, mikä voi joskus tarkoittaa, että vielä vahvistamattomat oletukset vaikuttavat suunnitteluprosessiin. Tämän huomioimiseksi ”valmiin” työn määritelmä tarkistetaan säännöllisesti projektin elinkaaren aikana. Lisäksi haasteena on, että tiiminvetäjien tulee välttää heti projektin alussa tehtävän yksityiskohtaisen suunnittelun (BDUF) lähestymistapaa, joka on tyypillisempi vesiputousmenetelmille eikä ketterälle kehitykselle. 

DSDM:n periaatteet

DSDM:n ketterät periaatteet ohjaavat jokaista projektia. Periaatteita on yhteensä kahdeksan.

1. Keskittyminen liiketoiminnan tarpeeseen
2. Toimita ajallaan
3. Tee yhteistyötä
4. Älä koskaan tingi laadusta
5. Rakenna vaiheittain vankkojen perustusten pohjalta
6. Kehitä iteratiivisesti
7. Viestitä jatkuvasti ja selkeästi
8. Osoita hallitsevasi kokonaisuuden

DSDM-tekniikat ja käytännöt

DSDM:n erottaa muista järjestelmäkehitysmenetelmistä seuraavat # tekniikkaa ja käytäntöä. 

Aikarajaus: DSDM noudattaa tiukkoja määräaikoja. Tätä varten koko projekti on jaettava pienempiin osiin, joilla kullakin on kiinteä budjetti ja aikataulu. Tämän hallitsemiseksi vaatimukset priorisoidaan. Jos aika tai raha on loppumassa, alhaisimman prioriteetin vaatimukset poistetaan. Valmis projekti muodostuu tällöin vain tärkeimmistä vaatimusosista. 

MoSCoW: Näillä priorisointiryhmillä kohteet asetetaan tärkeysjärjestykseen tärkeimmistä vähiten tärkeisiin. Priorisointiryhmät ovat Pakollinen, Pitäisi olla, Voisi olla ja Ei tarvita. Kokoonpanonhallinta auttaa hallitsemaan kaikkia näitä keskenään kilpailevia toimitettavia kokonaisuuksia, joita kehitetään usein samanaikaisesti.

Mallintaminen ja iteratiivinen kehitys: Mallintaminen auttaa visualisoimaan projektin eri osa-alueita sen edetessä. Sen avulla voidaan esitellä jokainen kehitettävä kohde ja mahdollistaa iteratiivinen kehitys tarjoamalla säännöllistä palautetta ja toteuttamalla parannuksia. 

Prototypointi: Kuten monissa ketterissä menetelmissä, prototypointi on olennaista projektin testaamiseksi varhaisessa, käsitteellisessä vaiheessa. Sen avulla voidaan hahmotella perustoiminnot, löytää ilmeiset heikkoudet ja antaa käyttäjille mahdollisuus testata ohjelmistoa. 

Työpajat: Käyttäjät ja sidosryhmät tuodaan yhteen keskustelemaan vaatimuksista, ongelmista, tuloksista ja testauksesta. DSDM perustuu vahvaan käyttäjien osallistumiseen heti alusta lähtien. Testaus on DSDM:ssä erittäin tärkeää, sillä se varmistaa laadukkaat tulokset. 

DSDM-roolit

Kaikissa ketterissä järjestelmäkehityshankkeissa on luettelo täytettävistä rooleista. Sama koskee DSDM:ää. Sen käsikirjan mukaan nämä ovat olennaiset roolit kaikissa DSDM-ympäristöissä. 

1. Vastuullinen toimeksiantaja (”projektin puolestapuhuja”) - Käyttäjäorganisaatio ja/tai asiakas nimeää tähän rooliin henkilön. Hän voi myös myöntää tarvittavat varat ja resurssit. Hänellä on päätöksenteossa ”viimeinen sana”.

2. Visionääri - Visionääri käynnistää projektin konkreettisten tavoitteiden ja käyttäjäorganisaation liiketoiminnan ymmärryksen pohjalta keskittymällä tärkeimpiin vaatimuksiin heti alussa ja ohjaamalla tiimiä niiden perusteella. 

3. Käyttäjäedustaja - Ihanteellinen ”testikäyttäjä”, joka tuo käyttäjäyhteisön näkökulman projektiin. Hänestä tulee tärkeä palautteen lähde koko prosessin ajaksi. 

4. Neuvonantajakäyttäjä - Toinen käyttäjätyyppi, jonka tulisi tuoda olennaisia näkökulmia käsiteltävään projektiin. Hänellä voi olla ainutlaatuista tietämystä tai muuta asiantuntemusta, joka tekee hänestä ihanteellisen ehdokkaan. 

5. Projektipäällikkö - Projektipäällikkö on henkilö, joka hallinnoi koko projektia. 

6. Tekninen koordinaattori - Hän suunnittelee järjestelmäarkkitehtuurin ja vastaa kaikkien teknisten elementtien laadunvalvonnasta. 

7. Tiiminvetäjä - Tiimin johtaja, joka vastaa koordinoinnista ja yhteistyön edistämisestä. 

8. Ratkaisukehittäjä - Hän hallitsee järjestelmän vaatimuksia, mallintaa järjestelmän, kehittää toimitettavan koodin ja luo prototyyppejä.

9. Ratkaisun testaaja - Testaa tuotteen ja antaa kommentteja sekä dokumentaatiota, kun virheitä ilmenee. Hän testaa tuotteen uudelleen myös korjausten käyttöönoton jälkeen. 

10. Kirjuri - Kirjaa projektin edistymisen kannalta olennaiset vaatimukset, sopimukset, päätökset ja muut hyödylliset tiedot. 

11. Fasilitaattori - Hän vastaa työpajan motivoinnista ja valmistelusta, jotta edistyminen pysyy johdonmukaisena ja vakaana. Hänen on oltava erinomainen viestijä ja pidettävä kaikki oikealla tiellä. 

12. Asiantuntijaroolit - Näissä rooleissa toimivat oman alansa tai toimialansa asiantuntijat, jotka tarjoavat lisätukea projektin tarpeiden mukaan. Roolit voivat vaihdella projektista ja tiimistä toiseen. Tällaisia rooleja voivat olla esimerkiksi liiketoiminta-arkkitehti, laadunhallintapäällikkö ja järjestelmäintegraattori. 

DSDM-projektinhallinnan vinkit

Nämä vinkit auttavat saamaan DSDM-projektista parhaan hyödyn, vaikka kaikki ketterät järjestelmät voivat myös hyötyä tämän tiedon osien hyödyntämisestä. 

1. Ylimmän johdon ja kaikkien työntekijöiden on ymmärrettävä projektiin valittu menetelmä ja sitouduttava siihen. 

2. Projektia johtavan tiimin on sitouduttava käyttäjätestaukseen, palautteeseen ja osallistumiseen koko prosessin ajan – ideasta julkaisuun.

3. Projektilla on oltava vakaa ja valtuutettu ydintiimi. Tiimin jäsenillä on oltava päätösvaltaa, jotta prosessi ei juutu tarpeettoman monimutkaisiin ehdotus- ja hyväksyntämenettelyihin. Tiimillä on myös oltava kaikki tarvitsemansa toimintaedellytykset, kuten sopiva teknologia, terve kehitysympäristö, projektinhallintatyökalut ja muuta. 

4. Asiakkaan ja toimittajan välillä on oltava tukea antava ja ennakoiva suhde riippumatta siitä, kehitetäänkö projektit sisäisesti vai teetetäänkö ne ulkopuolisella taholla. 

5. Tiimin on osoitettava pelottomuutta, kun on kyse projektin tarpeiden rehellisestä priorisoinnista ja matalan prioriteetin asioiden karsimisesta tarpeen mukaan. Näin aikataulussa ja budjetissa pysytään.