Oikeusrekisterikeskus on valinnut Goforen Roti-hankkeen määrittely- ja arkkitehtuuripalveluiden toimittajaksi. Roti-hanke on oikeusministeriön hallinnonalaan kuuluvan Rikosseuraamuslaitoksen laaja toiminnan kehittämishanke. Hankkeen tavoitteena on luoda Rikosseuraamuslaitokselle uusi asiakastietojärjestelmä nykyisten kahden erillisen järjestelmän tilalle.
Roti-järjestelmän määrittelytyötä on tehty vuodesta 2012 alkaen useassa eri vaiheessa. Gofore on osallistunut järjestelmän määrittelyyn ja hankinnan valmisteluun tuottamalla mm. Rikosseuraamuslaitoksen asiakastietojen hallinnan kohdearkkitehtuurin sekä järjestelmän vaatimusmäärittelyn ja kustannus-hyötyanalyysin.
Nyt tehdyllä hankinnalla Oikeusrekisterikeskus hankkii määrittely- ja arkkitehtuurityön tukipalvelua täydentämään omaa panostustaan toiminnan määrittelytyöhön ja hankinnan kohteen täsmälliseen kuvaamiseen. Hankinta kattaa Roti-järjestelmän ensimmäisen vaiheen hankinnan tuen sekä hankkeen aikaisen jatkuvan määrittely- ja arkkitehtuurituen elokuuhun 2016 asti.
Hankinta vahvistaa Goforen asemaa oikeusministeriön hallinnonalan keskeisten tietojärjestelmähankkeiden määrittelyn ja arkkitehtuurin asiantuntijapalveluiden toimittajana. Gofore ja Oikeusrekisterikeskus tekevät vastaavanlaista yhteistyötä myös Oikeusministeriön aineistopankkihankkeessa (AIPA).
Oikeusrekisterikeskus kilpailutti toimeksiannon Hansel Oy:n Teknisen IT-konsultoinnin määrittely- ja arkkitehtuuripalveluiden puitejärjestelyn kautta.
Lisätietoja:
Gofore Oy
Erkki Salminen
Kehitysjohtaja
040 738 5650
erkki.salminen@gofore.com

Avatar

Erkki Salminen

Goforen kulttuurista ja osaamisista vastaavana johtajana Erkin vastuulla on Gofore Crew Services, jonka tehtäviin kuuluvat mm. rekrytointi, osaamisen kehittäminen ja työviihtyvyys. Erkki haluaa huolehtia, että Goforella on Suomen osaavimmat ja parhaiten työssään viihtyvät työntekijät.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

Kallispalkkainen konsultti numeroa liian suuressa pikkutakissa julistaa Leanin olevan ratkaisu kaikkiin ohjelmistoalan ongelmiin. Esittelykalvoissa vilahtavat tasaisin väliajoin erilaiset nelikentät ja prosessikuvat. Välillä konsultti toistelee mystisiä japanilaisia termejä. Kuulijat pälyilevät kelloa hermostuneesti ja miettivät mitä naposteltavaa seuraavalla tauolla olisi tarjolla. Tilanne on valitettavan tuttu monelle Lean-seminaarissa olleelle. Mutta Lean-ajattelua on myös mahdollista hyödyntää konkreettisesti. Seuraavissa kappaleissa annan muutamia vinkkejä, joita on helppo soveltaa sekä Kanban että Scrum -pohjaisissa ohjelmistoprojekteissa. Varasta vapaasti.

Just In Time

Just In Time (JIT) -menetelmä on suunniteltu alun perin kaupan ja teollisuuden varastonhallinta- ja tuotannonohjausstrategiaksi. JIT-ajattelun lähtökohta on toimittaa vain ja ainoastaan tarvittavat raaka-aineet asiakkaalle vasta silloin kun niitä tarvitaan ja vain sen verran kuin niitä tarvitaan. JIT-ajattelun avulla välivarastojen arvo ja tuotteiden läpäisyaika minimoituu. Ohjelmistokehityksen raaka-aineita ovat luonnollisesti kaikki vaatimusmäärittelyt ja keskeneräiset ominaisuudet.

Näin hyödynnät:

  • Kirjoita käyttäjätarina ja siihen liittyvät määrittelyt vasta juuri ennen tehtävän toteuttamista.
  • Rajoita backlogin koko esimerkiksi vain kahden viikon työtä vastaavaksi.
  • Korjaa löydetyt bugit heti.
  • Vältä projektivaiheistuksia, jossa lopputuloksena on vain suuri määrä dokumentaatiota.
  • Hallitse tuotteen vaatimuksia karkealla ominaisuustasolla, älä yksittäisillä käyttäjätarinoilla.

Kaikki työ näkyville

Työtehtävien tuominen kaikkien näkyviin on hyvä tapa soveltaa Lean-ajattelun läpinäkyvyysperiaatetta. Tilannetietojen varmistamisen tarve vähentyy, koska tiimi ja sidosryhmät tietävät jatkuvasti projektin tilanteen. Projektin ennustettavuus myös parantuu, koska töiden edistyminen on jatkuvasti seurattavissa. Töiden tuominen näkyviin nostaa esille lisäksi prosessin pullonkaulat ja paikalliset tukokset. Kaikkien töiden ollessa näkyvissä asiakas ymmärtää usein myös monen yhtäaikaisen työn vaaran.

Näin hyödynnät:

  • Tee tuotteelle arvoketjuanalyysi (value stream mapping) ja luo tähän pohjautuva Kanban-taulu.
  • Vakioi projektissa käytettävät tehtävätyypit (esimerkiksi käyttäjätarinat, tekniset tarinat ja bugit).
  • Varmista, että uusien tehtävien luominen on riittävän helppoa ja nopeata.
  • Luo loogiset säännöt tehtävien etenemiselle taululla.
  • Tarkista aika ajoin, että kaikki projektissa tehtävä työ on näkyvissä taululla.

Läpimenoaika ja teho

Jatkuva parantaminen on ehkä Lean-ajattelun tärkein yksittäisen teesi. Usein jatkuva parantaminen jää projektissa pelkiksi post-it -lapuiksi projektitilan seinälle. Oppimista on kuitenkin helppo seurata läpimenoajan (lead time) ja tehon (throughput) avulla. Läpimenoaika mittaa tehtävän ajallista kestoa prosessin läpi. Teho taas mittaa valmistuneiden tehtävien lukumäärää haluttua aikayksikköä kohti. Projektissa tapahtuva oppiminen näkyy väistämättä läpimenoaikojen keskimääräisenä laskuna ja tiimin kasvavana tehona. Mittarit helpottavat myös projektin ennustamista ja esimerkiksi tulevien julkaisujen suunnittelua.

Näin hyödynnät:

  • Käytä tehon seurantaan tehtävien lukumäärää, älä tarinapisteitä.
  • Ilman sähköistä työkalua läpimenoaikojen seuranta on työlästä.
  • Pyri ajan myötä yhtenäistämään tehtävien koot, jolloin ennustaminen tarkentuu.
  • Tuo kiertonopeuden ja tehon tarkastelu osaksi esimerkiksi retrospektiiviä.
  • Älä johda mittareilla projektia.

Yhteenveto

Lean-ajattelu ei tule ratkaisemaan ohjelmistoprojektien suuria aikataulu- ja laatuongelmia, mutta tarjoaa työkaluja helpottamaan ohjelmistotyöläisen arkea. Tärkeää on muistaa, että itse Lean ei suunnittele, toteuta tai testaa yhtään palvelun ominaisuutta – If you meet the lean-buddha on the road kill him.

Termien selitykset

  • Value Stream mapping= Visuaalinen kuvaus kaikista niistä aktiviteeteista, joita tarvitaan tuotteen tai palvelun toimittamiseksi asiakkaalle. Ohjelmistoprojekteissa tyypillisiä aktiviteetteja ovat esimerkiksi määrittely, toteutus ja testaus.
  • Pullonkaula = Prosessin hitain vaihe, joka hidastaa koko prosessin etenemistä.
  • Paikallinen tukos = Yksittäinen tehtävä, joka ei edisty syystä tai toisesta
  • Tekniset tarinat = Teknisillä tarinoilla osaltaan varmistetaan tuotteen ylläpidettävyys, käytettävyys ja skaalautuvuus. Teknisiä tarinoita ovat mm. erilaiset selvitys-, refaktorointi- ja migraatiotehtävät. Teknisten tarinoiden tarkoitus on minimoida järjestelmän tekninen velka.

Lähteet / luettavaa

Kniberg – Lean from the Trenches: Managing Large-Scale Projects with Kanban (http://www.amazon.com/Lean-Trenches-Managing-Large-Scale-Projects/dp/1934356859)
http://www.netobjectives.com/blogs/why-kanban-board-value-stream-map-scrum-board-isnt-and-what-tells-us
http://en.wikipedia.org/wiki/Just_in_time_(business)
http://softwaredevelopmenttoday.blogspot.pt/2012/01/story-points-considered-harmful-or-why.html

Avatar

Juhana Huotarinen

Juhana on kokenut ohjelmistoprojektien vetäjä, joka on erikoistunut Lean-ajattelun ja ketterien menetelmien käyttöönottoon suurissa julkisen sektorin tietojärjestelmähankkeissa. Viime vuosina hänet on pitänyt kiireisenä mm. Trafi, Valtori (Valtiokonttori), Opetushallitus, Kela ja Liikennevirasto. Aiemmin työurallaan Juhana on toiminut myös projektipäällikkönä ja ohjelmistosuunnittelijana. Juhanan ajatuksia voi lukea lisää hänen asiantuntijablogeistaan sekä Twitteristä.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.