Ketterät menetelmät soveltuvat myös laiteohjelmistojen kehittämiseen

Scrum ja muut ketterät menetelmät ovat vakiinnuttaneet paikkansa ohjelmistokehityksessä projektinhallinnan viitekehyksenä. Isoissa it-projekteissa työskennellessäni olen oppinut arvostamaan läpinäkyvyyttä, joka ketterillä menetelmillä saavutetaan: Kaikilla kehitystyöhön osallistuvilla on aina ajantasainen tieto siitä, miten projekti etenee. Siksi oikeat asiat tehdään ajallaan.

Olen toiminut projektipäällikkönä it-alalla pian 15 vuotta. Viimeisen 1,5 vuoden aikana olen päässyt ensimmäistä kertaa mukaan projekteihin, jossa kehitetään laiteohjelmistoja biotekniikan alan laboratoriolaitteisiin. Kokemuksen myötä olen huomannut, että scrum sopii mainiosti sovellettavaksi myös tällaisiin projekteihin, kunhan pidetään mielessä muutama asia.

Tekemisen priorisointi on avain onnistumiseen

Laiteohjelmistoprojektin lähtökohta on samanlainen kuin minkä tahansa muunkin softaprojektin: on olemassa joukko toiminnallisuuksia, jotka ohjelmistoon pitää toteuttaa, sekä aikaikkuna niiden tekemiseen.

Kun työskentelyä ohjaa ketterä malli, voidaan aina keskittyä joko kaikista bisneskriittisimpiin toiminnallisuuksiin tai vaikeimpiin asioihin, jotka tulevat vaatimaan paljon testausta. Ketterä kehitys mahdollistaa joustavan reagoinnin projektin aikaisiin muutoksiin ja kaikkien olennaisimpien toiminnallisuuksien toteutumisen ilman projektiaikataulun venymistä.

Yhtenä ketterän kehityksen tärkeänä kulmakivenä on tiimin sulava yhteistyö. Scrumin ideologiaan kuuluvat avoin tiedon jakaminen ja yhdessä ongelmiin tarttuminen johtavat hyviin tuloksiin myös laiteohjelmistokehityksen maailmassa. Mitä paremmin jokainen tiimin jäsen on perillä muiden tekemisistä, sitä nopeammin pystytään näkemään ongelmat ja löytämään niihin ratkaisu. Tämä johtaa väistämättä laadukkaampaan lopputulokseen ja kenties myös tuotteen nopeampaan valmistumiseen.

Aktiivisesta vuoropuhelusta huolimatta tiimissä on oltava nimettynä henkilö, jonka vastuulla on seurata tehtyjen priorisointien toteutumista ja tehdä nopeaa reagointia vaativat päätökset.

Laiteohjelmiston MVP ei synny hetkessä – huomio testaukseen

Scrumille on tyypillistä pyrkimys mahdollisimman nopean MVP:n eli minimum viable productin (vapaasti suomennettuna pienin toimiva tuote) aikaansaamiseen. Laitteiden maailmassa valmis ohjelmisto saadaan loppuasiakkaalle hitaammin, sillä itse laite näyttelee kehitystyössä yhtä tärkeää roolia kuin sille kehitettävä ohjelmistokin. Jälkimmäistähän ei voi käyttää, mikäli ei käytä myös laitetta. Niinpä laiteohjelmiston jokaista kehitysversiota ei voi päivittää samantien asiakkaalle.

Tällaisen tuotteen testauksessa korostuu ennen kaikkea loppukäyttäjän tarpeiden syvällinen ymmärrys. On myös tärkeää huomioida, että sekä ohjelmisto- että laitetestaus aloitetaan riittävän aikaisin, sillä väärään aikaan tehty testaus voi johtaa projektin aikataulun huomattavaan venymiseen.

Kuvitellaan tilanne, jossa tuotteen loppuvaiheen testauksessa ilmenee muutostarve, jonka seurauksena myös laitteen piirilevy pitää uusia. Uuden osan saaminen valmistajalta vie useita viikkoja, mikä lykkää kehityksen alla olleen tuotteen lopullista lanseerausta. Tilanne olisi ollut vältettävissä tarkemmalla toteutuksen priorisoinnilla ja testauksen suunnittelulla. Laiteohjelmistoprojekteissa olisi aina pystyttävä ennakoimaan, mikä on se piste, jonka jälkeen ei enää ilmene ns. isoja ja syvälle meneviä ongelmia.

Sopiiko Scrum itse laitteen valmistukseen?

Samassa yhteydessä pääsin seuraamaan kokeilua, jossa itse laitteen valmistuksessa työskentelevä tuotekehitystiimi otti käyttöön Scrumin prosesseja. Mukana kokeilussa oli niin mekaniikan, optiikan kuin elektroniikan parissa työskenteleviä henkilöitä.

Sen aikana monialainen tiimi kokoontui säännöllisesti katselmointeihin ja vuoropuhelu kehitti tiimin sisäistä yhteistyötä selkeästi. Ongelmat tulivat aiemmin ilmi ja ratkaisuvaihtoehtoja käsiteltiin yhdessä. Samalla voitiin ketterän ajatusmallin mukaisesti kehittää toimintatapoja tukemaan paremmin tiimin työtä.

Kokeilu osoitti, että Scrumista voivat hyötyä myös muut kuin ohjelmistokehitystiimit. Toivottavasti pääsen oppimaan lisää tästä aiheesta tulevissa projekteissa.