Ketterän omistajuuden ABC, Agile Finland: Kettterä omistajuus aamuseminaari 22.5.2014, Helsinki.

1. Ketterän omistajuuden ABC
Kokemuksia ketterän ostamisen ja omistajuuden
aloittamisesta: CASE: Avoindata.fi
Jani Ruuskanen

2. Sisältö
• Sähköisen asioinnin palvelut Valtorissa
• Avoindata.fi -hankkeesta
• Kilpailutuksesta opittua
• Kouluttautuminen, sopiminen
• Työkalut ja kehittäminen
• Positiivista ja negatiivista

3. Vetuma
Asiointitili Lomake.fi
Palvelutieto-
varanto
Uusi
lomakealusta
Kansalais-
näkymä
Kansallinen palveluväylä
Yhteentoimivuus.
fi
Dataportaali
Sähköisen asioinnin tukipalvelut
Julkisen hallinnon yhteentoimivuus
Valtorin sähköisen
asioinnin yksikkö
tuottaa yhteisiä
palveluja koko
julkiselle
hallinnolle.
Metatietopalvelu
Käytössä Kehityksessä Suunnitteilla
Ketterä kehittäminen
Kansainväliset hyvät käytännöt
Uusien palvelujen konseptointi Käytettävyys ja esteettömyys
Avoin data
Hallinnon asiointiprosessien
kehittämisen ja sähköistämisen tuki
Sähköisen asioinnin palvelut Valtorissa
20.05.2014Valtori
3

4. Taustaa: ketterä hanke ja ketterä hankinta
• VM:n määräyskirje kolmen eri palvelun toteuttamisesta ja päätös käytettävästä teknologiasta (CKAN)
keväällä 2013
• Dataportaali
• Palvelutietovaranto
• Yhteentoimivuus.fi- portaalin uusi versio
• Tehtävä ketteränä kehitystyönä, avoimen lähdekoodin tuottein
• Aiempaa kokemusta ketterästä hankinnasta ei ollut > tuotettiin ensin ketterän hankinnan malli
yhdessä Codenton kanssa
• Ketterän tiimin kilpailutus Hanselin minikilpailutuksena kesällä 2013
• Käytettävyysasiantuntijan kilpailutus erikseen
• Kehittäminen käynnistyi 0-sprintillä lokakuun lopussa 2013. Kehittäminen jatkuu edelleen.
20.05.2014Valtori
4

5. Avoindata.fi:n tuotevisio: yksi päätarve, yksi
perustietomalli, yksi käyttöliittymä
• ”Palvelun käyttäjänä haluan löytää helposti tiedot ja työkalut
kehittäessäni julkisen hallinnon sähköisiä palveluja.”
• Näitä tietoja ovat avoimen datan lisäksi kaikki nykyisessä yhteentoimivuus.fi –
palvelussa olevat sisällöt, yhteiskäyttöiset sovellukset sekä
palvelutietovarannossa olevat määrämuotoiset metatiedot julkisista palveluista
• Palvelussa tulee olla avoimet tekniset rajapinnat tietoaineistojen
julkaisuun, ylläpitoon ja hakemiseen
• Kaikkien tietoaineistojen julkaisu, ylläpito ja haku tulee olla mahdollista
myös manuaalisesti
• Palvelulla on yksi yhteinen käyttöliittymä
• Palvelu julkaistaan tuotantokäyttöön Avoin Suomi 2014 –messuille (15-
16.9.2014).
20.05.2014Valtori
5

6. 20.05.2014Valtori
6
Palvelujen
käyttäjät
Tiedon
tuottajat
”Yhteentoimivuus-
palvelut”
Kansallinen avoimen datan
portaali
Julkishallinnon avoimen
tiedon hakemisto
Palvelutietovaranto
Julkisten palvelujen
kuvailutietorekisteri
Yhteentoimivuus.fi
Yhteentoimivuuden noudattamisen
sekä edistämisen suunnittelu-, tuki-
ja ohjemateriaalin julkaisualusta
Metatieto
Avoimen datan tarjoajatJulkisten palvelujen tuottajat/
järjestäjät
Julkisen hallinnon
yhteentoimivuuden edistäjät
Kunnat
Valtion
virastot
Välillinen
hallinto
Julkis-
hallinto
Alueelliset
toimijat
…
KA:n
toteuttajat
Juhta …
Materiaali +
Metatieto
Palvelujen käyttökohteet
Sähköisten
asiointipalvelujen
kehittäminen
Tiedon
analysointi,
tulkinta j a
laadunhallinta
Tiedon jalostus,
yhdistely ja
harmonisointi
Sovellusten
kehittäminen
Uuden
liiketoiminnan
innovointi
Julkishallinnon
KA:n
kehittäminen
Tietojen ja
tietojärjestelmien
yhteentoimivuu-
den edistäminen
. . .
YhteisötKansalaiset Yritykset EU:n käyttäjäTutkijatViranomaiset
Julkishallinnon
toiminnan
yhdenmukainen
ja tietoturvallinen
kehittäminen
Metatieto
Yhteiskunnan
läpinäkyvyys ja
demokratia
Markkinat ja
innovaatiot
Hallinnon sisäisen
tehokkuus
. . .

7. 20.05.2014Valtori
7
Alue-/paikallistaso
EU-taso
Kansallinen taso
Helsingin alueen
datakatalogi
(data.hri.fi)
Yhteentoimivuuspalvelut
EU:n datakatalogi
(Publicdata.eu)
MMLn
paikkatieto-
aineistot
. . .
datakatalogi
( . . .)
Metatieto
Dataportaali
(Julkishallinnon avoimen tiedon
hakemisto)
Yhteentoimivuus.fi
(Yhteentoimivuuden
noudattamisen ja edistämisen
tuki- ja ohjemateriaalien varanto)
Metatieto
EU:n yhteentoimivuus-
portaali
(Joinup.eu)
Tausta-
järjestelmät
(JHKA-kuvausportaail)
Materiaali+
metatieto
Kunnat
Valtion
virastot
Muut julkisten
palvelujen
tuottajat/
järjestäjät
EU-laajuinen
palveluhaku?
Palvelutietovaranto
(Julkisten palvelujen
kuvailutietovaranto)

8. Avoindata.fi:n toteutus
• Tietomallit pohjautuvat yleisiin suosituksiin
• DCAT (W3C:n suositus), on myös CKANin oma tietomalli / Avoin data
• ADMS (Asset Description Metadata Scheme) / Yhteentoimivuus
• JHS-183 / julkisen palvelun tiedot palvelutietovarannossa
• Kehitetään ketterästi
• Scrum by Valtori, 4+1 scrum team, käytettävyysasiantuntija ja tuoteomistaja / tuotetukiryhmä
• Kaikki lähdekoodi lisensoitu vapaasti GNU Affero General Public License (AGPL) v3.0
(github.com/yhteentoimivuus)
• Ominaisuuksia: rekisteröityminen, sanastojen nouto finto.fi –palvelusta, hierarkkiset organisaatiot,
avoimet rajapinnat, tietojen harvestointi muista palveluista (esim. hri.fi, mml paikkatietoaineistot,
avoimen datan metatietojen vastaanotto, EU-tasoinen tietojen federointi jne.)
20.05.2014Valtori
8

9. Ketterän tiimin kilpailutus
• Ymmärrys ketterästä kehittämisestä ja sen vaatimuksista ostajalle oleellista ennen
hankintaa
• Tuoteomistajuus
• Tuotetukiryhmän toiminta
• Ohjausmalli (operatiivisen vastuun antaminen tuoteomistajalle)
• Ilman selkeitä rooleja ei kannata lähteä ostamaan työtä, kaikkien osapuolien tulee sitoutua
ketterään kehittämiseen
• Hankinta on henkilöiden rekrytointia
• Osaamisprofiilit osattava tehdä oikein, älä rekrytoi väärää osaamista
• Hanketta on myytävä, parhaat osaajat tietävät arvonsa myös yritysten sisällä ja valitsevat
itsekin kiinnostavat hankkeet > Vastaa kysymykseen: Mitä hyötyä tästä on minulle
koodarina jo hankkeen kilpailutusaineistoissa (me teimme mm. esitteen osaksi hankintaa)
20.05.2014Valtori
9

10. Ketterän tiimin kilpailutus
• Sopimukset kannattaa tehdä joustavaksi ja jälkikäteen tarkasteltuna
meidänkin olisi kannattanut tehdä suurempi hankinta kerralla (esim.
kilpailuttaa useita yrityksiä pooliksi, tarpeita syntyy koko ajan lisää uusille
tehtäville). Pakko ei ole ostaa mitään mutta jos rajaa valmiiksi niin sitten
joutuukin uuteen kilpailutukseen
• Paperilla kilpailutuksen lisäksi seuraavalla kerralla hyödynnämme
myös haastattelut
• Nykyisessä hankinnassa kävi ehkä hieman hyvä tuuri, eli saimme todella
hyviä tekijöitä, pelkkien paperien perusteella olisi voinut käydä toisinkin
• Sopimukset kannattaa tehdä siten että on mahdollista hankkia tarpeen
mukaan myös osaamista jota ei ole suoraan henkilöiden profiileissa
(tarpeet muuttuvat matkan varrella)
20.05.2014Valtori
10

11. Hankintatavasta
• Me kilpailutimme Hanselin puitejärjestelyn sisällä
• Läheskään kaikki toimijat eivät kuitenkaan ole puitejärjestelyssä, erityisosaamista halutessa kannattaa harkita avointa
kilpailutusta
• Yhden yrityksen sijaan olisi järkevämpää kilpailuttaa useampia toimija joilta on mahdollista ostaa joustavasti osaamista
(huom. Voiko edes tehdä monen toimittajan hankintaa Hanselin puitejärjestelyn kautta?)
• Hankintaan tarvitsee useimmiten sisällyttää erikseen myös esim. kehitysympäristöt (meillä toimittaja vastaa
siis sekä alpha että public-beta ympäristöistä, mahdollisesti myös tuotannosta jatkossa). Anna kehitystiimin
päättää työkalut, ympäristöt, teknologia jne. mikäli vain mahdollista (eli älä määritä niitä hankinnassa).
• Sopimuksiin selkeät sanktiot henkilöiden vaihtamisesta, uusien maksuttomasta perehdyttämisestä jne.
Näihin siis sitoudutaan aluksi ja sitten vain toimitaan niiden mukaan jos muutoksia tulee (ei riitelyä).
• Yllättävää että puitejärjestelyn kautta ketterä hankinta ei aiheuttanut paljoakaan kiinnostusta, me saimme
vain kaksi tarjousta!!?
20.05.2014Valtori
11

12. Kouluttautuminen, sopiminen
• Tuoteomistaja ja tuotetukiryhmä kannattaa kouluttaa ketterään
kehittämiseen, meillä käyty scrum masterin ja product ownerin
koulutukset
• Ymmärrys siitä että ketterällä kehittämisellä pyritään ensisijaisesti hallitsemaan
muutosten ja tarkentuvien käyttäjätarpeiden aiheuttamaa riskiä hankkeelle, ei
ole mitään valmista joka vain toteutetaan!
• Varsinkin aiemmin vesiputousmallilla toimineille voi olla todella vaikea tottua
siihen että asiat valmistuvat pieni pala kerrallaan ja loppu pitää kuvitella työn
aikana jotta tavoitetta voidaan koko ajan tarkentaa ja muuttaa
• Tuotevisioon sitoutuminen on avain onnistumiseen
• Ohjausryhmä kannattaa perehdyttää ketterään kehittämiseen heti aluksi
• Ohjausryhmän kanssa tulee sopia tehtävien jaosta virallisesti
20.05.2014Valtori
12

13. Hanki omat työkalut!
20.05.2014Valtori
13
Jatkuva viestintä (flowdock)
Omat työkalut: Jira, jira agile ja confluence
CI-palvelut (jatkuva integraatio)
GitHub
-koodi avoimesti
(https://github.com/yhteentoimivuus
Axure käyttöliittymien mallintamiseen
2 viikon sprintit

14. Kehittäminen
• Tuo tiimi samoihin tiloihin tuoteomistajan ja tuotetukiryhmän kanssa
• Meillä vai teillä?
• läheisyys pitää olla todellista ja tehtäväkeskeistä, ei riitä että ollaan
vierekkäin jos ei ole yhteistä tekemistä
• vierekkäin = vähintään samassa tilassa (meillä ei onnistunut, vaan ollaan eri
kerroksissa, heikentää heti tehokkuutta hieman)
• tilajärjestelyihin varattava aikaa, resursseja (myös ergonomia!) ja johdon
tahtotila oltava varmistettuna etukäteen
• kilpailutuksessa huomioitava henkilöstön sijoittuminen ja varauduttava
sopimuksella sopimaan matkakustannuksista ja esim. etätöistä
• Viestintää ei ole koskaan liikaa
• Onlinetyökalut ihan must (meillä esim. flowdock käytössä)
20.05.2014Valtori
14

15. Kehittäminen
• Tuoteomistajuus usealla henkilöllä on mahdollista mutta hankaloittaa
asioita huomattavasti (kokemusta on)
• Tärkeää sopia yhteisesti miten käyttäjätarinat kirjoitetaan ja pitäytyä
mallissa
• Myös definion of done määrittely tärkeää (meillä esim. sovittiin että
kehittäjä dokumentoi aina kaiken testitapauksia ja päivittää sitten vain
aina tapauksia, ei erillistä dokumentointia muuten)
• Viikoittainen yhteinen läpikäynti koodarin tai scrum masterin kanssa
tärkeää (ei pelkästään daily scrum)
• Tehtävien priorisointi on yllättävän haastavaa vaikka olisi kuinka sisällä
tuotevisiossa, itsensä ulkoistaminen olisi tärkeää välillä mutta miten se
tapahtuisi?
20.05.2014Valtori
15

16. Strömsön nurja puoli
• PO 100% ajankäyttö ei vaan millään onnistu, tuotetukiryhmän aika ei riitä > ongelmia tehtävien
priorisoinnissa, ei riittävästi aikaa suunnitteilla käyttäjätarinoita (laatu heittelee), tiimi ei aina ymmärrä
mitä pitäisi tehdä tai kokee että tehdään vääriä asioista
• Osittainen ratkaisu: enemmän valtaa tiimille, kuuntele mitä he sanovat, et näe enää itse muutaman
kuukauden jälkeen mikä on tärkeintä
• Toisaalta, PO:lla tulee olla se vastuu tuotevisiosta, tiimi voi haluta viedä asioita tekniikka edellä
• Public-beta malli: kovasti julkaisemme kahden viikon välein versioita mutta käyttäjäpalautetta tulee
todella vähän. Viestintää ja markkinointia pitäisi olla paljon enemmän.
• Ketterä kehittäminen herättää organisaatioissa ns. akuutteja tarpeita, mekin olemme joutuneet
tekemään muuta kuin projektissa oli ajateltu, toisaalta antaa siis joustoa ja tuottaa säästöä mutta
samalla syö juuri tämän hankkeen resursseja
• Myös sidosryhmätyö vaatii välillä tiimin resurssia, meillä ei huomioitu alun perin tätä ollenkaan
20.05.2014Valtori
16

17. Positiivista
• Ensimmäinen ketterä hankkeemme, kuitenkin asia etenee
aikataulussa ja jopa budjetissa, priorisointi tuottaa paljon parempaa
palvelua kuin olimme alun perin kuvitelleet (ja ihan uusia
ominaisuuksia ja mahdollisuuksia)
• Tiimi oppii koko ajan, samoin omistaja, seuraava hanke taatusti taas
hieman parempi
• Omistaja pysyy paljon paremmin iholla tekniikassa, käytännöissä jne.
ja oppii samalla paljon ihan konkreettisesta tekemisestä. Suoria
hyötyjä mitattavissa tätä kautta myös muissa, ei-ketterissä hankkeissa
jossa toimittajien ohjaaminen helpottuu (ei voi niin helposti vetää
hatusta työmääriä jne.)
20.05.2014Valtori
17

18. Kysymyksiä ja siirtyminen pienryhmiin
20.05.2014Valtori
18