Rima saa olla korkealla, kun kehittäminen on ketterää

Miten Cinia toteuttaa vaativia ohjelmistoprojekteja? Laadukas arkkitehtuuri ja asiakaslähtöinen kehittäminen onnistuvat vaihe vaiheelta ketterien menetelmien avulla. Kysyimme projektityöskentelystä lisää ohjelmistoarkkitehti Markus Pohjolalta, joka on työskennellyt Cinialla viiden vuoden ajan.

Ohjelmistoarkkitehdeilla ja -kehittäjillä on usein kokemuksia ketterien menetelmien soveltamisesta. Esimerkiksi scrumiin kuuluvat daily-palaverit ja sprinteissä koodaaminen ovat tuttuja tapoja työn järjestämiseen. Cinialla on viime vuosien aikana keskitytty luomaan entistä vahvemmat puitteet ketterille ohjelmistokehitysprojekteille. Mitä se tarkoittaa koodarin näkökulmasta – palaamme siihen pian. Lähdetään ensin liikkeelle jokaisen projektin alkupisteestä eli asiakkaasta.

Sopiva rytmi löytyy asiakkaan tarpeiden perusteella

Kuvitellaan lähtötilanne: Asiakasyrityksen tai -organisaation sydämessä sykkivä järjestelmä on tullut käyttöikänsä päähän, ja tilalle tarvitaan uusi. Asiakas saattaa myös haluta digitalisoida toimintaansa, ja tarvitsee siksi uuden, räätälöidyn ohjelmiston. Cinian asiakas edustaa tyypillisesti yhteiskunnan kannalta tärkeää palvelua tai toimintoa, esimerkiksi terveydenhuoltoa, liikennettä, turvallisuutta tai teollisuuden vientiyritystä.

Tarpeet ohjelmistolle ovat siis olemassa valmiiksi, mutta täsmällisiä vaatimuksia, rajauksia sekä sopivia teknisiä ratkaisuja ohjelmiston toteuttamiseen harvoin tiedetään heti lähtötilanteessa. Usein myös ymmärretään, että kaikkea ei voida etukäteen määrittelemällä selvittää, vaan mielekkäämpää on ryhtyä suunnitelmallisesti toteuttamaan ja kokeilemaan sekä keräämään tehdyn kehitystyön tuotoksista ohjaavaa palautetta.

Siksi juuri ketterät menetelmät ovat tehokas reitti kohti asiakkaan maalia – vaikka aivan joka projektiin agile ei toki sovikaan. Onnistuminen edellyttää asiakkaan sitoutumista työtapaan ja sen rytmiin. “Meille ketterä tekeminen on tuttua, mutta asiakkaille ketterien projektien ostaminen voi olla vieraampaa”, ohjelmistoarkkitehti Markus Pohjola kertoo.

Alkuvaiheessa asiakas sekä Cinian ratkaisuarkkitehti, ohjelmistoarkkitehti ja projektipäällikkö muodostavat yhdessä ylätason kokonaiskuvan projektista ja sen tavoitteista. Sen jälkeen on aika muodostaa projektitiimi, johon voi kuulua ohjelmistoarkkitehdin, kehittäjien ja testaajien lisäksi esimerkiksi palvelumuotoilija. Samalla sovitaan tarkemmin menetelmän, tyypillisesti scrumin, syklistä: sprinttien kestoista ja yhteisistä palavereista. Sopivaan etenemisen rytmiin vaikuttavat muun muassa asiakkaan mahdollisuudet osallistua ketterään työskentelyyn, hankkeen koko ja sille asetetut aikataulutavoitteet sekä mahdolliset sidonnaisuudet projektin ulkopuolelle, esimerkiksi integraatiot kolmansien osapuolten kanssa.

Sanotaan, että ketterän kehittämisen periaatteet on helppoa ymmärtää, mutta vaikeaa hallita hyvin. Miten menetelmiä sitten toteutetaan Cinialla käytännössä?

Riittävät lähtötiedot saavat pyörät pyörimään

“Ketterä menetelmä ei saa olla syy sille, ettei projektia speksata kunnolla”, Markus Pohjola painottaa. “Määrittelytyötä pitää tehdä, mutta se tehdään sopivissa palasissa, iteratiivisesti edeten.”

On siis etsittävä sopiva tasapaino riittävien lähtötietojen ja toisaalta nopean alkuun pääsemisen välillä. Tavoitteena on saada asiakkaalle jo ensimmäisten sprinttien tuloksena konkreettista näytettävää.

Tarkemmin kuvattuna se tapahtuu näin:

• Ratkaisuarkkitehti jättää projektin dokumentaatioon ensimmäiset jäljet. Hankkeen suuntaviivat ja raamit perustuvat varhaisen vaiheen konsultointi- ja neuvonantotyöhön ja pohjautuvat asiakkaan strategiaan sekä tyypillisesti tekniseen tai toiminnalliseen esiselvitystyöhön. Samalla kehitysjonoon eli backlogille alkaa kertyä ensimmäisiä tehtäviä.
• Suunnittelu alkaa: kuka tekee mitä, ja kuinka paljon siihen varataan aikaa?
• Arkkitehtuurin piirteet alkavat muotoutua ja sopivimmat teknologiat hahmottua, kun vaatimuksia tarkennetaan.
• Ensimmäisessä sprintissä tehdään pohjatyöt, jotta täysipainoinen kehitystyö voi alkaa, ja tartutaan ensimmäisiin työjonossa oleviin tehtäviin sovitussa järjestyksessä.
• Jo ensimmäisessä sprinttikatselmoinnissa asiakkaan tuoteomistaja eli product owner saa nähdä konkreettisen demon, jonka perusteella tehtäviä kertyy backlogiin lisää, ja näin jatkuvan kehityksen pyörä on valmiina rullaamaan.

Kun työskentely alkaa välittömästi ja konkreettista pureskeltavaa on tarjolla alusta alkaen, asiakas huomaa nopeasti ketterän työskentelyn hyödyt. Koodia muokataan sitä mukaa, kun asiakkaan ja tiimin yhteinen näkemys projektista syvenee, aina toimivaan lopputuotteeseen asti. “Projektin aikana pitää antaa koko tiimille, kehittäjät mukaan lukien, jatkuva mahdollisuus asiakkaan kanssa keskusteluun”, Markus Pohjola tähdentää. Näin vältetään väärinkäsityksiä ja pidetään loppukäyttäjän näkökulma koko ajan käden ulottuvilla.

Selkeät raamit auttavat keskittymään olennaiseen

Ketteryyden varjolla ei siis saa jättää kehittäjien tiimiä oman onnensa nojaan. Projektipäällikön vastuulla on huolehtia siitä, että sprinttien aikataulut pitävät ja esimerkiksi scrum-palaverit toteutuvat ajallaan: oli kyseessä sitten sisäinen daily, sprintin suunnittelu asiakkaan kanssa, tuotteen kehitysjonon työstäminen ja priorisointi (backlog grooming) tai sprintin tulosten läpikäynti ja demoaminen.

Cinialla ketteryyttä auttaa myös eri osaajien löytyminen omasta talosta, jopa oman projektitiimin sisältä. Aikaa ei kulu ostopalvelujen koordinointiin ja vastausten odotteluun. Ohjelmistoarkkitehdin ja palvelumuotoilijan saumaton yhteistyö hyödyttää kaikkia ja tuo tekemiseen ammattimaisuutta, samoin koodarin ja testaajan parityöskentely. Myös automaation hyödyntäminen testaamisessa ja tuotantoonviennissä esimerkiksi pilveen helpottavat kehitystiimien työtä Cinialla. Lisäksi asiakastarpeita voidaan ratkaista ohjelmistorobotiikan avulla.

“Meillä on käytössä Cinia Agile Project Playbook, joka on nytkin tässä pöydälläni laminoituna”, Pohjola kuvailee kaksipuolisen A4:n kokoista dokumenttia. Tiivis pelikirja avaa työntekijöille syklin eri vaiheet ja yhteiset periaatteet, backlogin käytöstä aina tuotteen julkaisuun. Sen lisäksi käytössä on yksityiskohtaisempi cook book siitä, mitä kaikkea ketterissä ohjelmistoprojekteissa tulisi sujuvan prosessin ja korkean laadun rakentamisen näkövinkkelistä huomioida.

Agile-työskentely on jo pitkään ollut Cinialla valtavirtaa. Prosesseja, menetelmiä ja parhaita käytäntöjä on harmonisoitu ja levitetty tiimien ja toimipisteiden yli järjestämällä kaikille työntekijöille koulutuksia ketterien menetelmien soveltamisesta. Puitteet tiedon tehokkaaseen ja hallittuun siirtämiseen osaajalta toiselle ovat kunnossa, mutta esimerkiksi uudet scrum masterit käyvät edelleen ulkopuolisissa koulutuksissa.

Cinialla voi luottaa omaan ja työkavereiden ammattitaitoon

Vaikka ketterään työskentelyyn on luotu yhteiset puitteet, ne jättävät kuitenkin tiimille tilaa käyttää omaa harkintaa ja tulkintaa menetelmien soveltamisessa. Samalla tavalla Cinia haluaa laajemmin rohkaista ohjelmistoarkkitehteja ja -kehittäjiä tuomaan omaa osaamistaan mukaan projekteihin. Jos jokin uusi teknologia tai nouseva ohjelmointikieli on lähellä sydäntä, omaa näkemystä pääsee tuomaan tiimissä avoimesti esiin.

“Kehittäjä saa vapauksia oman ammattitaitonsa ja luovuuden suhteen”, Markus Pohjola tiivistää. “Meillä on totta kai tiettyjä teknologioita, joiden käyttämisestä on talossa laajasti kokemusta, mutta valinnateivät ole etukäteen kiveen kirjoitettuja. Tehtävämme on löytää jokaisen projektin ja asiakkaan tarpeisiin parhaiten soveltuvat, modernit tekniset ratkaisut. Samalla opimme koko ajan itsekin uutta ja viemme osaamistamme eteenpäin yhdessä ja yksilöinä.”

“Mielestäni Cinialla huolehditaan hyvin avoimesta keskustelukulttuurista”, Pohjola jatkaa. “Meillä on paljon erilaisia kanavia, joissa pystyy keskustelemaan mistä tahansa työntekoon liittyvästä.” Taskforcejen kautta kehitetään yhteisöllisesti eri osaamisalueiden toimintaa. “Esimerkiksi itse mietin muiden kehittäjien ja arkkitehtien kanssa ryhmässä, miten yhteistä tekemistä voisi entisestään parantaa.”

Myös aiemmin mainittu dialogi asiakkaan kanssa on osa Cinian projektikulttuuria, Pohjola kertoo: “Itse rohkaisen jokaista tiimiläistä pitämään yllä keskusteluyhteyttä asiakkaaseen. Se tuo osaltaan lisää tarkoitusta jokaisen omaan työhön.” Blogistamme voit lukea lisää projektista, jossa Cinian koodarit pääsivät päivän ajaksi tutustumaan lääkärien ja muun hoitohenkilökunnan työhön!

Laadukas tekeminen tuo aitoa arvoa asiakkaalle

Jos cinialaisten joukkoon nyt liittyisi uusi ohjelmistoarkkitehti, mistä hän erityisesti ilahtuisi taloon tullessaan? “Meillä halutaan tehdä asiat parhaalla mahdollisella tavalla. Emme mene heti siitä, mistä aita on matalin, vaan meillä pääsee kokeilemaan uusia keinoja parempien ratkaisujen löytämiseksi”, Markus Pohjola vastaa.

Juuri kiinnostavat projektit ja asiakkuudet toivat ohjelmistoyrittäjänä aiemmin työskennelleen Markus Pohjolan Cinialle töihin. “Arvostin alusta alkaen sitä, että teemme vaativia ohjelmistoja eri toimialoille ja keskitymme oleelliseen. Cinialla pääsin tekemään aiempia isompia kokonaisuuksia leveämmillä hartioilla.”

Pohjolalla itsellään on juuri nyt käynnissä logistiikkaan ja sen toiminnanohjauksen modernisaatioon liittyvä projekti, jossa uudistetaan tiensä päähän tullutta vanhaa järjestelmää. “Olen arkkitehtina päässyt suunnittelemaan uutta, saanut paljon vastuuta, päässyt hyödyntämään aiempaa kokemustani ja ideoinut muun muassa pilvipalvelujen tuomia mahdollisuuksia.”

Monipuoliset osaajat ja tilaa luovuudelle. Vahva framework, jossa ketteriä projekteja viedään eteenpäin jatkuvasti arvioiden. Näistä ainesosista syntyy ohjelmistoprojekti, johon asiakas on tyytyväinen, ja jossa tiimin jäsenten on hyvä työskennellä.