Kun uuden ohjelmistoratkaisun esiselvitystyö on tehty ja asiakkaan tarpeet ovat selvillä, on aika kääriä hihat. Karkea teknologiapino ohjailee käytännön ratkaisuja projektin alkuvaiheessa.
“Cinialla iso osa-alue back-endin puolella on Java-ekosysteemi – ei tietysti siihen rajoittuen”, Joni Helin sanoo antaen esimerkin ympäristöstä, jota varten talossa on kertynyt runsaasti hyviä toimintamalleja.
Projektin resursointivaiheessa pohditaan näitä kysymyksiä:
“Haluamme välttää sitä, että ihmiset naulattaisiin kiinni projekteihin. Silloin osaavat tekijät kyllästyvät ja lopulta vaihtavat työnantajaa. Ilmiö on tullut aiemmin urallani vastaan moneen otteeseen, mutta Cinialla tämä on mielestäni tiedostettu hyvin. Pyrimme huolehtimaan siitä, että jokaisella on oikeasti mahdollisuus vaikuttaa siihen, miten he voivat edetä projektista toiseen.”
“Projektit ovat yksilöllisiä, tiimit ovat yksilöllisiä. Siksi emme Cinialla sanele erityisen tiukkoja käytäntöjä valmiiksi. Jokainen tiimi käy läpi tietyt, organisaatiotasolla määritellyt asiat. On projektin asia, millä tavalla ne huomioidaan”, Helin kertoo.
Esimerkiksi nämä check-listat auttavat sisäisten pelisääntöjen sopimisessa:
Cinian omien pelisääntöjen lisäksi asiakkaalta voi toki tulla reunaehtoja käytännön työskentelyyn, etenkin silloin, jos on kyse monitoimittajaprojektista ja scrum of scrums -metodologiasta tai työ tapahtuu turvatiloissa.
Lue lisää: “Rima saa olla korkealla” – Näin toimii ketterä kehittäminen Cinialla
“Me Cinialla haluamme, että koodi on laadukasta ja tasokasta. Se on meidän oma etumme. Kun koodi on yhtenäisesti tehtyä, kaikkien on helpompaa ymmärtää se ja kontribuoida olemassa olevaan koodipohjaan. Siksi panostamme laadun kehittämiseen sekä projekteissa että projektien ulkopuolella jatkuvasti”, Helin painottaa.
Esimerkiksi aiemmin mainitussa Java-ekosysteemissä parhaita käytäntöjä on monen tasoisia: 1) Javasta itsestään lähteviä, 2) maailmalla hyväksyttyjä sekä 3) Googlen tai muiden suurten organisaatioiden ohjaamia käytäntöjä. Miten Cinialla sitten käytännössä seurataan eri teknologioiden best practices -ohjeita ja niiden päivittymistä?
Mattermostin kaltaiset, sisäiset keskustelukanavat ovat CV-pankkia nopeampi keino silloin, kun ongelmien ratkomiseen tarvitsee viisaita päitä oman tiimin ulkopuolelta.
“Cinia on sen kokoinen organisaatio, että meillä voi hyvin kysyä apua kaikilta.” Lead Developer Joni Helin
Ei riitä, että ohjelmakoodi itsessään on laadukasta. Miten sitä tuotetaan ja säilötään, millainen sen historia on? Millaisista inkrementeistä se koostuu? Kun projektin elinkaarivaihe alkaa olla tuotantopisteen takana eli se tuottaa jo lisäarvoa asiakkaalle, on laadukas historia erittäin tärkeä mahdollisten ongelmien selvittelyssä ja muutoksien impaktin analysoinnissa.
Cinialaiset käyttävät koodimassan ja workflown hallintaan GitLabia. Kukin projekti sopii parhaiden käytänteiden pohjalta muun muassa haaroituskäytännöistä ja kytkennöistä automatioistuun CI/CD-putkeen (continuous integration and continuous deployment). Käsillä olevaa hanketta voi verrata koestettuihin, toimiviin ratkaisuihin, poimia kirsikat kakusta ja hillota ne sopivaan muotoon. Millaisia repositoryja perustetaan mihinkin tarkoitukseen? Miten koodia ja komponentteja versioidaan? Kuinka siitä julkaistaan valmiita lopputuotoksia eri ympäristöihin?
Ohjelmistoratkaisun vaatimusten mukaisesti työskentelyyn tarvitaan kehitys-, testaus-, staging-, tuotanto- ja koulutusympäristöjä, ja niitä varten taas joko rautaa tai pilvestä nostettua infrastruktuuria.
Projekti päättää ja sopii infrastruktuurista asiakkaan kanssa huomioiden sen, minne ohjelmistoratkaisun käyttöönotto kohdistuu: onko käytössä in-premises -konesali, hyödynnetäänkö privaatti-, julki- tai hybridipilveä tai käytetäänkö serverless-arkkitehtuuria. Käytäntöjen on oltava kaikille selkeät ja yhtenäiset.
“Tänä päivänä mahdollisuuksia on paljon”, Helin muistuttaa. “Siksi on tärkeää, että kerrytämme organisaationa kokemusta hyväksi havaituista toimintamalleista, emmekä tee samaa joka kerta atomeista asti uusiksi. Pyrimme minimoimaan manuaalisen työn, ja sen sijaan toteutamme infrastruktuuria monistettavina, skriptattuina tai muuten mekanisoituina ratkaisuina, oli teknologia mikä tahansa, esimerkiksi Terraform, AWS CDK tai CloudFormation.”
”Perinteinen koodin katselmointi on aivan ok, ja teemme sitä, mutta haluan korostaa jatkuvaa, ohjauksellista katselmointia sitä ennen”, Helin tähdentää. Nimettyjä reviewereitä, tarkistuslistoja ja testausautomaatiota ei siis unohdeta, mutta ne eivät riitä turvaverkoksi. Ei ole kenellekään mielekästä puurtaa viikkoa yksin ja todeta sitten, että työ on tehtävä alusta asti uudelleen.
Siksi uutta kehitystä ei tehdä pääkehityshaaraan, vaan se elää väliaikaisissa feature-haaroissa, kunnes riittävä kypsyystaso on saavutettu. Jokainen julkaisee omaa edistymistään jatkuvasti feature-haaraan, ja työ tulee heti näkyväksi muulle tiimille. Näin minimoidaan yhdessä harha-askelien määrä ja vaikutus.
Koodin kommentointi tähtää toimivaan kokonaisuuteen. Kun muodollisesti pätevät, mutta pitkällä tähtäimellä heikot ratkaisut huomataan ajoissa, projektille ei synny teknistä velkaa.
“Meitä ei kuormiteta sillä, ovatko koodin muotoilut oikeat. Sitä varten otetaan työkalut käyttöön jo projektin alussa. Ne muotoilevat, analysoivat ja poistavat mekaanisesti tunnistettavia heikkouksia. Näin katselmoinnissa ja kommentoinnissa pystytään keskittymään asioihin, joita vain ihminen voi huomata.”
Ohjelmistoratkaisuja ostava asiakas ilahtuu korkeasta laadusta, budjetissa pysymisestä ja siitä, ettei aikatauluihin tule odottamattomia muutoksia. Mutta mitä hyötyjä valmiit toimintamallit ja käytännöistä sopiminen tuovat itse projektityöhön? Lead Developer Joni Helin näkee edut selkeästi: