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. |
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:
BT-standardissa DevOps-menetelmät näkyvät konkreettisesti kehitys- ja tuotantotiimien englanninkielisissä roolinimissä DEV- ja OPS-etuliitteinä.
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ä | Kyllä |
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ä.
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:
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.
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. |
