Betan valmistelu
Beta edellyttää tuoteohjausta
Jos kokeilun onkin onnistunut tekemään ilman riittäviä palvelun tai tuotteen ohjausmenettelyjä, niin viimeistään betan teossa tuoteohjaus ja tuotekehityksen peruselementtien on oltava paikallaan.
Kokeilut eivät siis yksin riitä onnistuneen beta-vaiheen toteuttamisen pohjaksi. Kokeilut ovat keveitä, koska niissä ei vielä tarvitse huomioida täysimittaisen tuotannon toimivuutta, eivätkä kokeilut varsinaisesti vielä vaikuta kaupungin tietojärjestelmäkokonaisuuteen ja teknologiakokonaisuuteen. Kun lähdetään kehittämään beta-ratkaisua, samalla sitoudutaan siihen, että ratkaisu lähtökohtaisesti tulee aitoon käyttöön oikeille asiakkaille.
Ohjaavat edellytykset kuntoon
Visiolakana
Alfa-vaiheen visiolakana oli rajattu kokeilun tarkoitusperiin. Viimeistään betaan siirryttäessä visiolakana on tehtävä niin, että se kattaa tuotannolliselta ratkaisulta edellytettävät asiat kokonaisuudessaan.
Tiekartta kommunikointiin
Kehitettävällä ratkaisulla on oltava yksinkertainen ja helposti ymmärrettä tiekartta kokonaisuudesta. Tiekartta on erityisen tärkeä työväline haettaessa johdolta valtuudet toteuttamiseen sekä kommunikoidessa sidosryhmiin. Hyvä tiekartta antaa luotettavan leiman hyvästä ja laadullisesta toiminnasta. Se helpottaa päätöksentekoa ja nopeuttaa betan-vaiheen toteuttamisen käytännön käynnistämistä.
Kustannusten ja hyötyjen kuvaaminen
Virkavastuullinen taho (yleensä johto/ohjausryhmän puheenjohtaja) joutuu kantamaan beta-vaiheen kustannusvaikutukset sekä onnistumisen tai epäonnistumisen. Siksi on tärkeää kuvata yksinkertaisesti ja luotettavasti, minkälaisia kustannuksia betan kehittämisestä syntyy suoraan sekä tulevaisuudessa ns. elinkaarikustannuksina. Päättäjä joutuu arvottamaan saatua hyötyä suhteessa kustannuksiin, kun hän antaa luvan edetä beta-vaiheen toteutukseen tai katsoo parhaaksi priorisoida jotain toista kehittämisen osa-aluetta.
Linkki kustannus-hyötylaskelma-sivulle
Käyttäjätarinakartta
Siirryttäessä täysimittaisen ratkaisun toteuttamiseen, myös ketterän toteutuksen laajuuden määritelmä eli käyttäjätarinakartta on saatettava sille tasolle, että se kattaa kaiken täysimittaiselta tuotannolliselta ratkaisulta edellytettävän sisällön.
Reunaehdot
Kokeilun nauttimat vapausasteet liittyen kaupungin kokonaisarkkitehtuuriin eivät enää päde beta-ratkaisua toteutettaessa. Onhan toteutettava beta-ratkaisu tulossa oikeasti käyttöön. Silloin ratkaisusta tulee osa kaupungin kokonaisarkkitehtuuria ja ratkaisun on myös oltava dokumentoituna kaupungin tietojärjestelmä- ja teknologialuetteloihin.
Ratkaisu alkaa samalla mahdollisesti käsittelemään henkilötietoja tai muita tietoja, joilta edellytetään tietosuojaa ja tietoturvaa ohjaavien lakien, asetusten ja sisäisten ohjeiden noudattamista. Ratkaisulta myös aletaan edellyttämään kaupungin tai ulkoisen reguloinnin mahdollisesti etukäteen määrittelemien linjausten, ohjeiden ja määräysten noudattamista. Nämä voivat liittyä esimerkiksi teknologiavalintoinhin ja toimittajasuhteisiin, rajapintojen avoimuuteen, tietojen avoimuuteen ja niin edelleen.
Ratkaisulla tulee myös olla saatavilla riittävä tuki ja ratkaisun operoimiseksi on oltava määriteltynä ratkaisun omistava organisaatio, jonka määrärahoista ratkaisu ylläpidetään, tuotetaan ja henkilöresursoidaan. Näihin seikkoihin ei olla alfa-ratkaisujen toteutuksissa vielä sitouduttu.
Linkki tietoturvan riskienkäsittelysuunnitelmaan
Linkki tietosuojan vaikutustenarviointiin ja riskianalyysiin sekä tietosuojan tarkistuslistaan
Linkki tietosuojaan sopimuksissa ja hankinnoissa
Valmiin määritelmä
Ylin tahtotila ratkaisusta, johon myös johto/ohjausryhmä on sitoutunut sekä sen laajuuden, että laadullisten seikkojen osalta tulee tässä vaiheessa kääntää toteutuksen ohjenuoraksi. Ketterässä mallissa tätä kutsutaan valmiin määritelmäksi (definition of done eli DoD). Tätä ei tule tulkita laajuusmäärittelyksi. Kyse on toteutustiimin kannalta riittävän selkeästä laatukriteeristöstä, jotta toteutustiimi tietää, minkä kaltaista lopputulosta kehitettäviltä ominaisuuksilta edellytetään.
Linkki valmiin määritelmä -sivulle
Työnohjaus kuntoon
Tuotteen kehitysjono
Tuoteomistajan lista toteutettavista ominaisuuksista, eli kehitysjono, pohjaa käyttäjätarinoin tehtyyn laajuusmääritelmään, sekä ratkaisuja rajaaviin reunaehtoihin. Beta-toteutuksessa kehitysjonossa olevien ominaisuuksien kuvaamiselta edellytetään enemmän formaalisuutta ja laajempaa sisältöä kuin alfa-vaiheessa.
Sprinttien kehitysjono
Siirryttäessä alfa-vaiheesta beta-vaiheeseen kokoluokka kasvaa lähtökohtaisesti niin paljon, että kehittämisen ohjaamisessa kannattaa siirtyä Kanban:sta Scrumiin. Toteutuksen ohjaaminessa otetaan silloin käyttöön 1-4 viikon sprintit. Kehitysjonon koon kasvaessa myös tarvitaan tarkempaa kehitysjonokortin formaalisuutta ja sisältöä.
Linkki Scrum-menetelmäkuvaukseen
Käyttöönotto kuntoon
Jatkuva tuotantoon siirto vai kertarysäys
Perinteiset projektit tuottavat yleensä lopputuotoksensa kerralla. Ketterissä toteutuksissa yleensä pyritään jatkuvaan käyttöönottoon sitä mukaa, kun tulee valmista (MVP). Tämä ei ole pikkujuttu. Se tarkoittaa sitä, ettei enää riitäkään varmistaa tietosuoja, tietoturva, arkkitehtuurin mukaisuus ja muut reunaehdot vasta lopussa. Ne täytyy varmistaa joka kerta, kun jotain siirretään aitoon ja oikeaan käyttöön, eli tuotantoon. Siksi nämä varmistukset yleensä automatisoidaan, jotta jatkuva käyttöönotto ylipäätään voi olla mahdollista. Se taas edellyttää merkittäviä panostuksia automaatioteknologiaan ja prosesseihin. Jos näitä peruselementtejä ei ole paikallaan, jatkuva tuotantoon siirto on vain haave ja käytännössä ketterä kehittäminen muistuttaa lopulta perusprojektia yhdellä käyttöönotolla aivan lopussa.
On siis elintärkeää ketterälle betalle sopia heti alkuun, miten ja millä sykleillä tuloksia siirretään käyttöön ja mitä teknologiaa ja menetelmiä valitulle lähestymistavalle on ensin hankittava, opeteltava ja otettava käyttöön, ennenkuin valittu toimintatapa on mahdollinen. Jos kehitettävä tuote on tietoteknologinen, jatkuva käyttöönotto edellyttää käytännössä investoimista ns. DevOps CI/CD putken rakentamiseksi ensin. Yksinkertaistettuna se tarkoittaa automatisoitua komponentti-integraatioteknologian hankintaa, opettelua ja käyttöönottoa ennen minkään kehittämisen aloittamista.
Joudut mahdollisesti hankkimaan
Alfa-vaiheen toteuttamiseksi on mahdollisesti tarvittu vain osa niistä kaikista osaamisista ja kyvykkyyksistä, mitä beta-vaiheessa tullaan tarvitsemaan. Koko toteutusteknologia saattaa vaihtua ja samalla myös käytettävä konsultointiosaaminen. Vähintäänkin kokoluokan kasvaminen ja ylläpitovastuiden ratkaisutarve helposti johtavat siihen, että olemassa olevia puitesopimusjärjestelyjä joudutaan ainakin tarkastelemaan tai jopa kilpailuttamaan uusia. On mahdollista, että joudutaan hankkimaan järjestelmätoimittajia, ylläpidon toimittajia ja osaamisen toimittajia. Jos näin on, ennen beta-toteutukseen siirtymistä on toimittava hankintalain mukaisella tavalla, jotta varsinainen ketterä tiimi ja toteuttaminen voidaan sitten hankittujen resurssien kanssa pystyttää.