Ketterää ja virtaviivaista - Ari Turunen
Ohjelmistosuunnittelussa on olennaista hahmottaa projektin edistymistä haittaavat tekijät. Kun ryhmätyössä pyritään avoimuuteen ja läpinäkyvyyteen sekä nopeasti saavutettaviin välituloksiin, saadaan tekijät ja asiakas luottamaan toisiinsa paremmin. Näin saadaan hyvää tekemisen meininkiä ja parempia tuloksia. Cloud Software -hanke luo hyviä käytäntöjä ketterälle ja virtaviivaiselle ohjelmistokehitykselle.
Ketterillä (agile) ja virtaviivaisilla (lean) menetelmillä pyritään poistamaan turhat välivaiheet ja saamaan työtehtäviin selkeä omistajuus.Yhteistä sekä ketterille että virtaviivaisille menetelmille on, että kasvokkain tapahtuvaa viestintää pidetään tärkeämpänä kuin pelkkien kirjallisten dokumenttien laatimista. Ennen kaikkea työryhmä pystyy itse vaikuttamaan työskentelytapoihinsa.Ihmiset ja tiimit kehittävät toimintaansa tietyissä raameissa ja tietyn yhteisesti sovitun tavan mukaan organisaation johdon tukemana. Yhdessä ja jatkuvasti vuorovaikuttaen pystytään hyvään tuotekehitykseen.
Ohjelmistotoimittajien ja asiakkaiden välisten kytkösten määrä lisääntyy, kun pilvipalvelut yleistyvät ja erikoistuvat. Puhutaan tietotekniikkapalvelujen ekosysteemistä, jossa älykkäät sovellukset toimivat yhdessä ja toisiaan täydentäen käyttäjälle helpolla, mutta näkymättömällä tavalla. Palvelujen toimivuudelle ja kilpailukyvylle on ratkaisevaa, että niitä voidaan kehittää nopeasti ja kustannustehokkaasti. Tähän on yhtenä ratkaisuna ketterät ja virtaviivaiset ohjelmistosuunnittelun menetelmät.
Suomalaisista ohjelmistotaloista Reaktor on tehnyt jo useita vuosia ohjelmistokehitystä näillä menetelmillä. Menetelmävalmentaja Panu Liira on mukana Reaktorin asiantuntijana Cloud Software -hankkeessa, jonka tavoitteena on yhdistää ketteryys ja virtaviivaisuus pilvipalveluihin.
”Koko tekemisen tapa syntyy iteratiivisesti,oppien ja osallistuen. Ne, jotka tekevät työn, saavat itse suunnitella sen. Näin saadaan ryhmä johtamaan itse omaa kasvuaan. Tämä on omiaan sitouttaman tekijät yhteisiin tavoitteisiin sekä työtapoihin”, Liira selventää
”Toimintatavat sopeutetaan tilanteeseen sopiviksi. Lisäksi huomataan nopeasti, jos punaiset valot alkavat vilkkua.”
Liira haluaa olla mukana kehittämässä näiden menetelmien valmennusosaamista, jotta Suomesta saataisiin maailman paras maa niiden hyödyntämisessä.
”Tietoa on helppo jakaa koulutuksella, mutta oikea oppi ja osaaminen syntyvät ja jakaantuvat tehdyn työn kautta, koska vastasilloin tietoa ja oppia päästään soveltamaan.”
LUOTTAMUS JA AVOIMUUS TAKAAVAT HYVÄN LOPPUTUOTTEEN
Panu Liira asettelee sanansa tarkasti ja näkökulma on selvä: kaiken perustana on avoimuus ja luottamus, mikä synnyttää luovuutta. Liira huomasi jo uransa alkutaipaleella, miten sopimukset ja pykälät, kirjalliset vastuujakojen määrittelyt veivät aimo annoksen työiloa ja luovuutta.
Liiran ensimmäinen työnantaja, lupaavaan kasvuvaiheeseen päässyt ohjelmistoyritys, kaatui sopimuksiin, joihin oli määritelty liian tiukat ehdot. Sopimukset sitoivat asioihin, joita ei pystytty tekemään. Karvaat kokemukset antoivat Liiralle kimmokkeen miettiä, miten hyviä ohjelmistoja voitaisiin suunnitella hyvällä yhteistyöllä. Hän alkoi tutkia ohjelmistokehityksen historiaa. Hän analysoi, minkälaisia ohjelmistomenetelmiä oli formalisoitu ja minkälainen oli tilaajan ja toimittajan suhde.
”Kun palveluja ulkoistetaan, aika harvoin firmojen välisen luottamussuhteen rakentamista osataan arvostaa. Sen sijaan työn tekemisen suhde yritetään muodollistaa lainvoimaiseen muotoon, jossa on määritelty suhteen luonne, sisältö ja toimintatavat. Se karsii joustavuuden tekemisestä ja luo pikemminkin ristiriitoja osapuolten kesken, vaikka tavoitteet olisivat samat. Tiukasti määritellyt sopimukset tappavat luovuuden, koska tekemisen suuntaa ei voi enää muuttaa, vaikka se projektin aikana olisikin tarpeellista. Harvoilla yrityksillä on kykyä lähteä enää muuttamaan sitä, mitä on kertaalleen sovittu”, Liira väittää.
PERINTEINEN TEHOKK UUSAJATTELU ALKOI KAUHISTUTTAA LIIRAA
”Liian mekanistinen näkemys pilaa luovuuden. Puhutaan innovoinnista ja luovuudesta, mutta samalla pitäisi ennakoida, mitä innovoidaan. Se osoittaa lähinnä luottamuksen puutetta.”
Liira on kriittinen mekaaniselle kilpailutukselle. Varsinkin, jos kilpailutetaan halvin tuntihinta eikä mietitä kokonaisuutta.
”Kovien kilpailutusten jälkeen kyky toteuttaa palvelu ja jatkokehitys on tyypillisesti heikoin. Tällä alalla tehokkuuserot yksittäisten työntekijöiden välillä voivat tutkitusti olla jopa 30-kertaisia. Ainoastaan kokemus ja pätevyys takaavat laadun.”
Liira siirtyi vuonna 2004 ohjelmistoyritys Reaktorin palvelukseen ja löysi paikkansa.
”Reaktor oli Suomessa ensimmäinen firma, joka teki ketterillä menetelmillä softakehitystä asiakasprojekteissa.”
Myös Ixonos on tehnyt näillä menetelmillä jo pitkään ohjelmistokehitystä mobiilisovelluksista yritysjärjestelmiin. Ixonosin liiketoiminnan kehityspäällikkö Arto Saari jatkaa Panu Liiran työtä Cloudin ketterän ohjelmistokehityksen vetäjänä.
Saaren mukaan toimittajan ja asiakkaan välistä suhdetta voi mitata kahdella akselilla: ensimmäinen on toimeksiannon kriittisyys ja toinen osapuolten välinen vallitseva luottamussuhde.
”Lähtökohtaisesti asiakas ei voi antaa toimittajalle suurempaa toimeksiantoa kuin mitä luottamussuhde sallii. Kun luottamuksen toimittajan kyvykkyyteen ei ole riittävä,paikataan tätä vajetta sopimusehdoin, mutta tällöin päädytään monesti molempien osapuolten onnistumista rajoittavaan malliin, koska yleiset sopimusmallit nojaavat hankkimiseen, eivät yhteistoimintaan.”
Saaren mukaan ongelmia sopimusmalleissa tulee erityisesti projekteissa, joiden tavoitteena on kehittää asiakkaan liiketoimintaa IT:n keinoin. Tämä johtuu siitä, että tällaiset projektit edellyttävät jatkuvaa ja avointa vuorovaikutusta osapuolten välillä.
”Huonoin mahdollinen lähtökohta on rakentaa projektiyhteistyö pelkkien sopimusehtojen varaan, koska näin yleensä parhaiten varmistetaan että osapuolten välinen vuorovaikutus kuolee hankintakäytäntöjen alle. Kun osapuolet vain keskittyvät oman riskin minimointiin, molemmat yleensä häviävät.”
MUDA JA KANBAN: JAPANILAISTA OPPIA VIRTAVIIVAISUUTEEN
Yksi menetelmä hukkatyön välttämiseen on Kanban. Ohjelmistokehityksessä Kanbania on sovellettu esimerkiksi rakentamalla seinätaulu, johon on kuvattu ohjelmistokehityksen eri vaiheita. Taululla olevat sarakkeet on suunniteltu niin, että kussakin vaiheessa oleva keskeneräisen työn määrä on rajoitettu. Rajoitteet estävät keskeneräisen työn kasautumista ja näin kehitettävä ohjelmisto valmistuu pienissä osissa tasaista tahtia toiminto kerrallaan. Rajoitteet myös kehittävät tiimin kykyä tehdä yhteistyötä haasteiden voittamiseksi, koska uusia osia ei oteta työn alle ennen kuin keskeneräiset työt ovat saatu yhdessä valmiiksi. Rajoittamalla kerrallaan työn alla olevan työn määrää myös onnistumisia ja tuloksia syntyy nopeammin ja useammin. Tämä yleensä näkyy myös suoraan menetelmää käyttävien tiimien motivaation tasossa.
Arto Saaren mukaan Cloud Software -hankkeessa näitä menetelmiä sovelletaan monissa projekteissa. Näiden koordinaatio on onnistumisen edellytys.
Lean-ajattelu on virtaviivaisuuteen pyrkivä johtamisfilosofia, joka pyrkii minimoimaan hukkatyötä. Toyotan tuotantoprosessissa hukkatyöstä käytetään perinteistä japanilaista termiä ”muda”. Turhaa työtä ovat kuljetukset, varastot, liikkuminen, odotusaika, ylituotanto, yliprosessointi ja viallinen tuote.
Arto Saaren mukaan Cloud Software-hankkeessa näitä menetelmiä sovelletaan monissa projekteissa. Näiden koodinaatio on onnistumisen edellytys.
”Ketteryys vastaa monelta osin monimutkaisuuden hallintaan muuttamalla suhtautumistapaa suunnitteluun. Ketteryydelle ja virtaviivaisuudelle yhteinen tavoite on lyhentää kehitys- ja julkaisusyklejä."
Saaren mielestä virtaviivainen lähestymistapa sopii erityisen hyvin pilvipalvelujen liiketoimintamalleihin. Palvelurajapinnan muuttuessa organisaatioiden välillä päädytään tarkastelemaan sekä tuottamisettä hyödyntämisketjua uudelleen.
”Jos tarkastelu voidaan tehdä yli organisaatioiden, saavutetaan vieläkin suurempi kokonaisymmärrys arvoketjusta ja organisaatioiden välisestä vallitsevasta palvelurajapinnasta.”
OHJELMISTOTOIMITTAJA JA ASIAKAS TYÖSKENTELEVÄT YHDESSA
Panu Liiran mielestä hyvä ohjelmistosuunnittelu riippuu organisaation rakenteesta ja etenkin organisaatiokulttuurista. Organisaation rakenteet ja kulttuuri ratkaisevat työntekijöiden kyvyn oppia ja tehdä yhteistyötä yhteisien tavoitteiden eteen. Hyvä ohjelmistokehitys edellyttää sekä asiakkaan että kehittäjän sitoutumista.
”Pätevistä työntekijöistä ei ole hyötyä, jos ne istuvat omilla hiekkalaatikoillaan. Projekti ei onnistu, jos lopputuloksen omistava asiakas ei ole siitä aktiivisesti kiinnostunut, eikä ryhmä saa riittävän nopeaa palautetta. Hyvin harva kiinnittää tähän huomiota. ”Liiran mukaan tapa, jolla organisaatiot
ja ihmiset tekevät töitä keskenään on ratkaiseva. ”Parhaat projektini, joissa olen ollut, ovat olleet sellaisia, joista ei roolijaon perusteella pystynyt päättelemään, missä firmassa joku on töissä.”
SCRUM: KUIN RUGBYN PELAAMISTA
Yksi suosituimmista ketteristä menetelmistä on scrum. Scrum-sana tarkoittaa rugbyjoukkueen aloitusryhmitystä. Scrum on kuin rugby-peli: ohjelmistoa kehittävä joukkue sopeutuu erilaisiin tilanteisiin nopeasti ja on jatkuvasti liikkeessä ja etenee itseohjautuvasti ja itse määrittelemiensä vaiheiden kautta. Scrum-menetelmässä haetaan mahdollisimman aikaisin palaute työlle.
”Näin luottamus syntyy tekojen kautta.Scrumia käytettäessä pystytään tuottamaan jotakin käsin kosketeltavaa yleensä paljon nopeammin kuin perinteisiä menetelmiä käytettäessä.”
Yksi ryhmän jäsenistä on ns. scrummestari, jolla ei ole suoranaista päätösvaltaa ryhmään. Hän valmentaa ja tukee tiimiä menetelmän käytössä ja oman toimintatapansa kehittämisessä. Tavoite on saada tiimi itse valvomaan, että se noudattaa itselaatimiaan pelisääntöjään ja toisaalta kyseenalaistaa ja kehittää niitä. Hän myös auttaa tiimiä löytämään ja poistamaan tiimin työtä hidastavia esteitä ja ulkoisia häiriötekijöitä. Scrum Master ei siis ole projektipäällikkö tai tiimin sihteeri, vaan valmentaja.
”Softakehityksen ongelma on odotusten hallinta eli mitä on realistista odottaa”, toteaa Panu Liira. ”Tavoitteena oleva ohjelmisto muuttuu pikku hiljaa täydellisemmäksi ja valmiimmaksi useiden toteutuskierrosten aikana. Toteutuskierrosta kutsutaan pyrähdykseksi eli sprintiksi. Sprintin kesto on yleensä yhdestä neljään viikkoon. Sprintti päättyy demo-tilaisuuteen, jossa voidaan esitellä esimerkiksi seuraava ohjelmistoversio.”
Arto Saari muistuttaa, että mielipiteiden ja näkemysten keskellä unohtuu usein perusajatus projektityöskentelystä. Pohjimmiltaan on kyseessä ennustettavuuden ja muutoskyvykkyyden oikeasta soveltamisesta.
Kyse ei Saaren mielestä kuitenkaan ole täydestä valinnanvapaudesta näiden välillä, vaan projektin toimintaympäristö määrittää toteutumismahdollisuuden.
”Uudet innovatiiviset kehityshankkeet tarvitsevat muutoskykyisen lähestymistavan onnistuakseen, kun taas monet monimutkaiset, mutta ennustettavat toimitusprojektit hyötyvät tarkoista tehtävätason suunnitelmista. Koska maailma on harvoin näin mustavalkoinen, ovat parhaat mallit
pitkäaikaisen osaamisen ja jatkuvan kehittämisen tuloksena syntyneitä yhdistelmämalleja, joissa ennustettavuus ja muutoskyvykkyys kohtaavat oikeassa suhteessa ja oikeilla tasoilla.”
KESKENERÄISYYS EI OLE SYNTI
Scrumin ajattelutapaan kuuluu että ei tehdä yhtään enempää kuin mitä ehdottomasti tarvitaan. Scrumissa pyritään tekemään tuoteparannus jokaisessa sprintissä. Yksi kerrallaan aletaan luoda valmiita toiminnallisuuksia, jotka ovat osa toimivaa järjestelmää.
”Tällaisten osakokonaisuuksien näyttäminen luottamuksellisessa suhteessa on äärimmäisen arvokasta, koska silloin saadaan välitön palaute. Ensisijaisesti on tärkeää saada palaute siitä, oliko tuo ko. ominaisuus sitä mitä haettiin. Kun jokin asia on epäselvä, se pitää selvittää heti.”
Asiakkaan kanssa tiimi itse rakentaa oman ymmärryksensä. Läpinäkyvyys on siksi tärkeätä. Kaikki ymmärtävät miten tehtävien toteutus onnistuu.
Scrum-ajattelussa ovat tietyt seremoniat ja säännöt. Tekemistä ja menetelmiä pitää ajatella periaatteiden kautta: toteuttava porukka omistaa tekotapansa. Liika formalisointi tuhoaa sen. Siksi tiimillä on oma sessio työnsä päivittäiseen suunnitteluun, jossa ulkopuoliset saavat kuunnella, mutta eivät saa kommentoida. Iteraatiokierrosten jälkeen tiimi näyttää työnsä tulokset ja silloin myös muut saavat kommentoida.
Samalla määritellään myös asiakkaan kanssa, mikä on valmista. Scrum-filosofiaan kuuluu myös, että mikä on kulloinkin nsvalmiin määritelmä. Koska ihmiset työskentelevät koko ajan läheisessä vuorovaikutuksessa, he ymmärtävät, milloin ohjelmisto on valmis.
”Verkkoon tehtävä sovellus, jonka käyttäjäkunta osallistuu jatkuvasti kehityksen suunnan määritykseen, sallii huomattavasti nopeamman julkaisusyklin kuin esimerkiksi fyysisen maailman tuote, jossa uusi versio tarkoittaa kokonaan uutta tuotantosarjaa. Tässä on kuitenkin hyvä muistaa, että julkaiseminen
voidaan tehdä myös pienimuotoisemmin prototyyppien avulla, jolloin saadaan lisää oppimiskokemusta myös muuten vaikeammin muutettavista tuotteista", Arto Saari huomauttaa.
Saaren mukaan virtaviivaisuudella on paljon annettavaa varsinkin mobiilituotteiden kehityskaareen, jossa on otettava huomioon rauta, alustasovellus ja käyttäjäpalvelut. Tällöin optimointia aletaan johtaa lopputuotteen näkökulmasta koordinoidulla tavalla yli kehitysosastojen.
MENETELMIEN AVULL A LÄPIMURTOJA
Panu Liiran mielestä ketterien ja virtaviivaisten menetelmien avulla on mahdollista saavuttaa läpimurtoja. Cloud Software -konsortiossa olevat suuryritykset ovat alkaneet toteuttaa näitä periaatteita. Esimerkiksi Suomen Ericsson on perustanut 20 ohjelmistokehitystiimiä ja muuttanut täysin tapansa organisoida tekemisensä tyylin ja tapansa tehdä ohjelmistoja.
”Monessa organisaatiossa on kokeiltu ketteriä menetelmiä. On lähdetty jalkauttamaan niitä tuotekehitykseen. Aika harva on kuitenkaan ottanut niitä käyttöön kokonaisena arvoketjuna, jolloin ongelmana on usein selkeän omistajuuden puute.”
Se on Liiran mielestä erityisesti isojen firmojen ongelma. Kun tekemisen johtaminen on liiaksi viipaloitu, ei tiedetä kuka on kehitettävän palvelun tai tuotteen omistaja tai kuka pystyy ottamaan siitä vastuun.
”Isoilla firmoilla vastuut on usein jaettu pieniin kokonaisuuksiin, eivätkä ne palaudu yhteen omistajaan. Kun tuotekehitys silputaan osiin, niin silloin kadotetaan jokaiselta työntekijältä vaikutusmahdollisuus omaan tuotteeseen. Tällöin kukaan ei myöskään omista kokonaisuutta ja palasia on vaikea laittaa yhteen. Puuttuu intohimo ja tekemisestä tulee puuroutunutta, ei saada välitöntä palautetta eikä tunnu siltä että saisi jotakin aikaiseksi.”
Silloin näkymä tuotteeseen katoaa. Kun vastuu on selkeä ja palaute on välitöntä, on se omiaan ruokkimaan intohimoista asennoitumista.
”Ideana on luottamuksen synnyttäminen oman firman sisälle. Ei harrasteta mikromanageerausta
vaan luotetaan alaisiin. Lean-filosofiassa johtaja on mahdollistaja, joka kannustaa oppimaan ja itsenäistymiseen.”
Arto Saaren mielestä organisaation toiminta muistuttaa jalkapallojoukkuetta, mutta sen sijaan, että organisaatio pelaisi yhtenä joukkueena, pelaavat sen eri osat omaa peliään.
”Vähän kuin puolustus syöttelisi vain keskenään ja yrittäisi aina itse laukoa maaleja kentän omasta päästä. Siksi lean-ajattelu
on tuulahdus tervettä järkeä toiminnan kehitykseen: siinä keskitytään maksimoimaan arvontuotto kaikille sidosryhmille oikeassa suhteessa ja valjastetaan koko organisaatio palvelemaan tätä yhtä tarkoitusta. Muutos on dramaattinen monille organisaatioille koska niissä ei ole totuttu laajaan, avoimeen ja yhdessä kehittävään toimintaan oman tuotealueen ulkopuolelle. Myös asiakas on usein kovin etäinen ja huonosti ymmärretty, mikä kuulostaa lähes absurdilta, kun mietitään liiketoiminnan perusteita. Lean onkin näistä syistä loistava lähestymistapa oman liiketoiminnan uudistautumista tarkasteleville
organisaatioille."
Saaren mielestä virtaviivaisuutta ei kannata tarkastella pelkästään mekanistisesti malleina, työkaluina ja prosesseina.
”Todellinen arvo on sen motivoiva ja yhteenliittävä voima, joka tarjoaa paljon kaivattua potkua organisaation kulttuurin kehitykseen, aihealueeseen, joka on usein aliarvostettu, helposti menetettävissä mutta vain vaivoin rakennettavissa. Kulttuuria ei voida määrätä, se voidaan vain luoda. Tämä on sidoksissa luovan työn johtamisen kehitykseen, joka on vielä monelle organisaatiolle ja johtajalle verrattain uusia asia.”
TIVIT Oy yksi stragisen huippuosaamisen keskittymistä
Tieto- ja viestintätekniikan tutkimus Oy eli Tivit Oy:n omistavat 46 yritystä ja julkisyhteisöä. Se on yksi Tekesin rahoittamista Strategisen huippuosaamisen keskittymistä (SHOK, jotka) tarjoavat huipputason tutkimusyksiköille ja tutkimustuloksia hyödyntäville yrityksille uuden tavan tehdä tiivistä ja pitkäjänteistä yhteistyötä keskenään. Yksi Tivitin ohjelmista on Cloud Software.
Cloud Software jäsenorganisaatiot
Aalto-yliopisto, CSC – Tieteen tietotekniikan keskus, Digia, EB Elektrobit Corporation, ECE (European Communications Engineering), Ericsson, Exfo Nethawk, F-Secure, Gearshift Group, IPSS (Intelligent Precision Solutions and Services), Vaadin Oy, IT Mill, Ixonos, Movial, Nokia, Nokia Siemens Networks, PV (PacketVideo), Reaktor, RM5 Software, Tampereen teknillinen yliopisto, Tekes, TeliaSonera, Tieto, Helsingin yliopisto, JAMK, Jyväskylän yliopisto, Oulun yliopisto, Vincit, VividWorks, VTT, Åbo Akademi.
Info
https://www.cloudsoftwareprogram.org/
https://www.cloudsoftwareprogram.org/lean-sw-enterprise
https://agilemanifesto.org/
Raportteja:
Vähäniitty, Heikkilä, Rautiainen & Vlaanderen: Towards Agile Product Portfolio Management, Aalto University
Kuusela, Huomo, Korkala: VTT Research Summary: Lean Thinking Principles for Cloud Software
https://www.cloudsoftwareprogram.org/results
Read the article in PDF format by clicking on file below:
|