5.3 Suunnittelu, kehittäminen ja validointi

Uuden tai olemassa olevan tuotteen, ratkaisun tai palvelun kehittämiseen on olemassa monenlaisia menetelmiä. Jokaisessa menetelmässä on omat säännöt, periaatteet, prosessit ja käytännöt. Parhaan menetelmän valitseminen riippuu kehittämisen tarkoituksesta, organisaation valmiuksista, liiketoiminnan luonteesta, taidoista ja kyvykkyyksistä.

Tuottaakseen halutut tulokset eri kehittämismenetelmät joutuvat tasapainoilemaan laajuuden, resurssien, ja aikataulun välillä.

Kuva 5.3.1 Kehittämisen eri lähestymistavat

 

BT-standardi suosittaa kahta lähestymistapaa: projektoitua vaiheistettua (eng. sequential) ja jatkuvaa täydentävää (eng. incremental) kehitysmenetelmää. Seuraava taulukko esittelee näiden kahden menetelmän ominaisuudet:

Projektoitu vaiheistettu kehityskulku Jatkuva täydentävä kehityskulku
Selkeät määräajat: Kehityskustannusten ennustaminen etukäteen, projektin aikataulut ja selkeät tuotosten välitavoitteet. Sopeutumiskyky: Lyhyemmät kehityskierrokset tuovat joustavuutta ja mahdollistavat suunnanmuutokset tarvittaessa.
Suunnitelmallisuuteen perustuva kurinalaisuus: Jokaisessa vaiheessa on määrätty aloitus- ja tarkistuspiste. Kaikki tehtävät täytyy olla tehtynä ennen etenemistä projektin seuraavaan vaiheeseen. Välitön käyttäjäpalaute: Tavoitteena on tuotteiden saaminen käyttäjille nopeasti. Vähentää riskiä rakentaa tuotteita, jotka eivät vastaa käyttäjien todellisia tarpeita, ja toisaalta mahdollistaa varhaisten liiketoimintahyötyjen saavuttamisen.
Huolellisesti dokumentoitu: Jokainen kehitysvaihe vaatii hyvin täytetyt dokumentit, jolloin on helpompi seurata aiempien projektien kulkua ja luoda pohja tuleville projekteille. Testaukseen perustuva: Kehittäminen ja testaaminen tapahtuvat samalla iteraatiokierroksella, joten toimiva ratkaisu on olemassa jokaisen kehitysiteraation jälkeen.
Selkeä kommunikointi: Ajanhallinta on ennakoitua ja hyvin dokumentoitua. Tilannepäivitykset johdolle ja sidosryhmille on helposti tuotettavissa. Nopea ja korkealaatuinen toimitus: Iteraatiopohjainen kehittäminen auttaa havaitsemaan virheet varhain ja tuottaa korkealaatuisia tuotejulkaisuja nopeasti.
Helposti opittavissa: Kehittämisen aloittaminen vaatii vähemmän osaamista tai koulutusta, koska jokaisella on tarkasti määritellyt roolit selkeästi kuvatuissa prosesseissa. Tiimityötä: Edellyttää tiivistä viestintää, kasvokkain tapahtuvaa vuorovaikutusta ja päivittäisiä kohtaamisia bisneksen kanssa.

 

DevOps-kehitysmenetelmä

Kuva 5.3.2 DevOps-kehitysmenetelmä

 

DevOps-kehitysmenetelmä yhdistää kehittämisen (eng. development) ja tuotannon (eng. operations) ja sopii hyvin jatkuvan kehityskulun ajattelumalliin ja menetelmiin. DevOps kykenee nopeaan palvelutuotantoon käyttämällä ketteriä ja lean-pohjaisia käytäntöjä ohjelmistokehittämisen kontekstissa. DevOps on kokoelma käytäntöjä, joilla voidaan automatisoida ohjelmistotuotannosta vastaavien tiimien prosesseja.

Tällä tavalla ohjelmistojen rakentaminen, testaaminen ja tuotantoon siirto on nopeampaa ja tuotteista saadaan käyttövalmiimpia. Menetelmä myös rohkaisee rakentamaan yhteistyökulttuuria sellaisten tiimien, jotka työskentelisivät perinteisissä organisaatioissa siiloissa, välille. Organisaatio hyötyy DevOps-menetelmien käyttöönotosta muun muassa seuraavilla tavoilla:

  • parantunut liiketoiminnan luottamus
  • nopeampi ohjelmistotuotanto
  • kyky ratkaista kriittisiä haasteita nopeasti
  • suunnittelemattoman työn parempi hallinnointi.

BT-standardissa DevOps-menetelmät näkyvät konkreettisesti kehitys- ja tuotantotiimien englanninkielisissä roolinimissä DEV- ja OPS-etuliitteinä.

 

Parhaan kehitysmenetelmän valinta

Seuraavia arviointikriteereitä voidaan käyttää ohjeistuksena kehitysmenetelmän valitsemisessa:

Arviointikriteeri Projektoitu vaiheittainen kehityskulku Jatkuva täydentävä kehityskulku
Onko kehityspyyntö määritelty täysin? Kyllä Ei
Pitäisikö omistajan pystyä tekemään suuria laajuutta koskevia muutoksia projektin alettua? Ei Kyllä
Onko ratkaisun rajaus/laajuus avain projektin onnistumiseen kehittämisen nopeuden sijaan? Kyllä Ei
Onko kehitysaloitteella korkean tason riippuvuuksia muihin aloitteisiin? Kyllä Ei
Onko odotettavissa, että ratkaisu kehittyy paljon tulevaisuudessa? Kyllä Yes

 

Suunnittelu

Projektoidussa kehittämisessä käytetään vaatimuksia sekä korkean tason että yksityiskohtaisten suunnitelmien tuottamisessa ennen kuin ratkaisun varsinainen kehittäminen alkaa. Suunnitteluvaiheeseen liittyvät myös tietyt tuotokset ja katselmointiprosessit. Mallin kurinalainen luonne tekee kehittämisestä siten selkeätä johtaa. Lähestyminen sopii hyvin esimerkiksi infrastruktuurin kehittämiseen, jossa vaatimukset ja suunnitteluvaihe pitää olla tehtyinä ennen kuin toteuttaminen voi alkaa.

Jatkuvassa kehittämisessä alustava korkean tason suunnitelma tuotetaan usein etukäteen, jotta voidaan rajata ratkaisun suuntaviivat. Yksityiskohtaiset suunnitelmat laaditaan kehittämisen ohessa sprinteissä. Sprintteihin voidaan myös liittää joitakin suunnittelutarinoita, jotka tukevat tai fasilitoivat myöhempien sprinttien kehittämistä.

 

Validointi

Kun uusi tai muutettu palvelu on kehitetty ja tuotantovalmis, on vielä tarkistettava, vastaako se sovittuja toimintavalmiusvaatimuksia. Näin varmistetaan, että tuote ei aiheuta häiriöitä ja sille löytyy tarvittava tuki.

Tuotantovalmiuden varmistamisen tavat vaihtelevat kehitysmenetelmän mukaan seuraavasti:

  • Projektoidussa kehityskulussa on määritelty erillinen vaihe tuotantovalmiuden varmistamiseen ennen käyttöönottoa. Laadunvarmistukseen liittyvä työ ja testaus toteutetaan tämän vaiheen aikana. Tuotantovalmiuden validoinnin tekee yleensä kehittämistiimistä erillinen testitiimi tai laadunvalvontayksikkö.
  • Jatkuvassa kehityskulussa testaus ja tuotantovalmiuden validointivaihe, samoin kuin mahdolliset korjaukset, sisältyvät yleensä jokaiseen tuoteversioon (eng. increment). Jos korjaukset eivät ole kiireellisiä, ne voidaan myös lisätä kehitysjonoon. Joskus on mahdollista, että uusia ominaisuuksia tuovan tuoteversion sijaan tehdään niin kutsuttu kovennettu sprintti (eng. hardening sprint), jossa kaikki tekeminen kohdistetaan perusteellisempaan testaamiseen ja vikojen korjaamiseen ilman uusia kehitysosia. Kehitystiimillä on ideaalitapauksessa tarvittava validointiosaaminen itsellään.

Yleensä sidosryhmät huolehtivat lopullisesta hyväksynnästä hyväksyttämistestausvaiheen (eng. User Acceptance Test, UAT) aikana. Tuotanto-organisaatio yhdessä palveluintegraatiotiimin kanssa testaa ratkaisun palveluunsiirtovalmiuden.

 

Laajasti käytetyt kehitysmenetelmät

BT-standardi mahdollistaa laajasti käytettyjen kehitysmenetelmien, kuten PRINCE2 ja Scrum, käytön. Alla oleva taulukko esittelee eri kehitysmenetelmiä. Lista ei ole täydellinen, ja on suositeltavaa tehdä erillinen arvio oikean menetelmän valitsemiseksi.

Projektoitu kehittäminen
PRINCE2 Antaa perustiedot onnistuneeseen projektijohtamiseen projektin tyypistä tai laajuudesta riippumatta. Rakentuu seitsemän periaatteen, teeman ja prosessin ympärille, ja voidaan muokata tarpeiden mukaan.
PMI / PMBOK PMI on projektijohtamisen tutkinto, joka tarjoaa vakioterminologiasta ja projektijohtamisen ohjeista koostuvan PMBOK-kokoelman. Se perustuu viiteen prosessivaiheeseen: asettaminen, suunnittelu, toteutus, seuranta ja kontrolli sekä päättäminen.

Huomaa, että PMI tunnetaan ennemmin viitekehyksenä kuin varsinaisena projektijohtamisen metodologiana. Sitä voi kuitenkin käyttää parhaiden käytäntöjen soveltamiseen projekteissa.

 

Jatkuva kehittäminen
Scrum Scrumin päämääränä on kehittää, toimittaa ja ylläpitää monimutkaisia tuotteita yhteistyön, vastuunjaon ja iteratiivisen edistymisen periaatteita noudattamalla. Scrum käyttää avainrooleja, tapahtumia ja tuotoksia, mitkä erottavat sen muista jatkuvan kehittämisen projektijohtamisen menetelmistä.
Kanban Kanban, samoin kuin Scrum, tähtää nopeaan julkaisuun yhteistyötä tekevien ja itseohjautuvien tiimien avulla. Kyseessä on hyvin visuaalinen menetelmä, jonka tavoitteena on taata korkealaatuiset tuotokset visualisoimalla koko työnkulun prosessi siten, että pullonkaulat voidaan tunnistaa kehityksen alkuvaiheessa.
Scaled Agile Framework (SAFe) SAFe auttaa isoja yrityksiä hyödyntämään ketterän kehittämisen menetelmiä pitäen samalla kiinni jonkinlaisista organisaatiorakenteista ja prosessien kontrolloinnista. Se on suositeltu vaihtoehto suurissa, ohjelmistopainotteisissa projekteissa, joissa tiimit toimivat hyvin itsenäisesti.
DevOps DevOps on menetelmä, joka yhdistää kehitys- ja tuotantotiimien tekemiset vuorovaikutuksen, integraatioiden ja yhteistyön kautta. Se mahdollistaa koodin käyttämisen tuotannossa nopeammin ja automaattisesti. Se parantaa organisaation nopeutta toimittaa ratkaisuja ja palveluja.
Dynamic Systems Development Method (DSDM) DSDM on viitekehys, joka on rakennettu kahdeksasta periaatteesta, elinkaaren hallinnasta, tuotteista, rooleista ja vastuista sekä useista parhaista käytännöistä. Menetelmä tarjoaa nelivaiheisen viitekehyksen, joka koostuu tarkoituksenmukaisuudesta ja liiketoimintakartoituksesta, toiminnallisesta mallista / prototyypin testaamisesta, suunnittelun ja kehitysversion iteroinnista sekä käyttöönotosta.