Bugit pois Lean Six Sigmalla?

Ensimmäinen Lean Six Sigma -harjoitukseni on loppusuoralla: jäljellä on enää vaikein osa eli parannusten keksiminen ja aikaansaaminen! Projektini aiheena on ollut ohjelmistovirheiden ehkäiseminen ja havaitseminen. Edellisissä vaiheissa kaivoimme dataa muutostietokannasta ja versionhallinnasta sekä tutkimme virheiden juurisyitä ja niiden esiintymistä ohjelmiston eri osissa.

Mitä mieltä olen Lean Six Sigmasta? Kokemuksen syvä rintaääni syntyisi vasta usean erityyppisen projektin myötä, mutta pari ajatuksenraakiletta sallittakoon:

DMAICin kaltainen vaihemalli tuo ryhtiä parannushankkeeseen: osapäiväiset projektit tuppaavat hiipumaan hiljaa pois alkuinnostuksen jälkeen, jollei niillä ole selvää rakennetta.

Päätöksenteon perustuminen faktoihin ja tilastotieteeseen eikä mieleenjuolahduksiin on kaunis periaate, mutta Six Sigman tilastolliset menetelmät jäivät omassa hankkeessani vähälle käytölle, koska dataa ei ollut ihan tarpeeksi. Lisäksi ohjelmistovirheet ovat alttiita tulkinnalle: Mikä on virhe, mikä puuttuva ominaisuus? Onko virheet kuvattu samalla tavalla kaikissa projekteissa? Miten erilaisia juurisyyanalyyseja syntyisi, jos saman datan antaisi analysoitavaksi kahdelle eri porukalle? Vähäinenkin data voi silti estää hyttysen ampumisen tykillä.

Käytänkö Lean Six Sigmaa seuraavassa parannushankkeessani? Aika näyttää.

My Excellency

How did Scrum affect different aspects of the project?

Vaihdoin maanantaina toimenkuvaa ja titteliä: melkein yhdentoista vuoden rupeama ohjelmistokehityspäällikkönä on ohi, ja keskityn nyt yksikkömme tuotekehityksen parantamiseen. (Mitä hieman koominen titteli R&D Excellence Manager voisi olla suomeksi?) Nyt pitää vain hillitä intoaan ja miettiä suurempia linjoja eikä vain syöksyä heti yksittäisten parannuskohteiden kimppuun.

Vantaan-yksikkömme on nyt muuttumassa nopeasti, kun kasvamme ja kehitämme Sonalleve MR-HIFU -tuotteen rinnalle uutta liiketoimintaa. Kaksi ohjelmistokehitystiimiämme on käyttänyt Scrumia vuoden ajan, ja kokemukset ovat olleet enimmäkseen myönteisiä: ensimmäisen projektin jälkeen kukaan ei olisi halunnut palata vanhaan toimintatapaan, vaikka Scrumin päivärytmi onkin välillä tuntunut liian intensiiviseltä vanhaan viikkopalaverikäytäntöön verrattuna. Nyt pääsen tarkastelemaan koko tuotekehityksen toimintatapoja ja miettimään niiden parantamista. Mielenkiintoisia aikoja edessä!

Scrum ja jäljitettävyys

Jäljitettävyys vaatimuksista versionhallintaan

Lupasin kirjoittaa Scrumin taipumisesta lääkintälaitteiden kehittämisessä vaadittavaan jäljitettävyyteen. Meillä on oltava vaatimustenhallinta-, riskinhallinta-, muutoksenhallinta-, versionhallinta- ja testauskäytännöt, joiden tuotokset on linkitettävä toisiinsa standardien ja viranomaisvaatimusten mukaisesti. Tärkeimmät jäljitettävyystyökalumme ovat DOORS, ClearQuest ja Subversion.

Kuvittelin tässä aiheessa olevan enemmän pureskeltavaa, mutta oikeastaan Scrum ei ole toistaiseksi muuttanut jäljitettävyysketjujamme miksikään, vaan vain tuonut niiden hallintaan uutta selkeyttä: vaatimuksia on päivitettävä sprintin tehtävälistan mukaan, ja ketjujen on oltava kunnossa joka sprintissä. Scrumin teemat ja käyttäjätarinatkin mäppäytyivät aika mukavasti vanhan muutostietokantamme kaksitasoiseen rakenteeseen.

Isoin haaste puhtaalle iteratiivisuudelle tuntuu olevan lääkintälaitealan mallien mukainen lopullisen tuotteen testaus. Sprinttien aikana testaamme tietenkin kaikki muutokset, mutta hankkeissamme on käytännössä pakko olla erillinen julkaisusprintti, jonka aikana periaatteessa julkaisuvalmis tuote käy vielä läpi kattavan regressiotestauksen. Onkohan kukaan lukijoistani (sikäli kuin teitä on :) löytänyt tähän kevyitä ratkaisuja? Testauksen automatisointi voi tietysti keventää taakkaa, mutta kaikkea emme pysty automatisoimaan.

Ensimmäinen sprintti takana

Eka neljän viikon Scrum-sprintti sujui paremmin kuin odotimme: kumpikin tiimi saavutti tavoitteensa, vaikka tarinoiden valinta ja pilkkominen ei mennytkään vielä ihan putkeen. Kehittäjät taisivat puhua tuotteen ominaisuuksista ja teknisistä ratkaisuista tämän kuukauden aikana enemmän kuin parin aiemman vuoden aikana yhteensä. Osa porukasta koki kuitenkin päivittäisen tehtävien läpikäynnin mikromanageeraukseksi ja tiimin itseorganisoituvan toimintatavan kaoottiseksi, ja tavat ovat selvästi vasta muotoutumassa: esimerkiksi Definition of Done oli tässä sprintissä vielä pikemminkin vanhan projektiorganisaation Scrum-tiimeille laatima tarkistuslista kuin tiimien omistama dokumentti.

Tarina on vasta alussa ja rotkokin ylitettävänä alkuinnostuksen jälkeen. Ensi kerralla muutama sana Scrumista ja lääkintälaitteiden kehityksessä vaadittavasta jäljitettävyydestä.

Ensikosketukseni Scrumiin

”Scrum = Variation of Evolutionary Delivery + some additional practices.” Näin tyhjentävästi analysoin Scrumin esityksessäni Äyritien ohjelmistoryhmälle elokuussa 2002.

Olin tavannut edellisessä työpaikassani Tom Gilbin, Obi-Wan Kenobia muistuttavan vaatimustenhallintagurun, ja tutustunut tämän Evolutionary Delivery -malliin, joka oli jonkinlainen ketterien menetelmien kantamuoto jo 1970–1980-luvulla. Kun sitten selailin Schwaberin ja Beedlen kirjaa Agile Software Development with Scrum, ihmettelin, mitä uutta tässä nyt oikein oli Evo-malliin verrattuna. Vasta paljon myöhemmin aloin ajatella, että inkrementaalinen ohjelmistokehitys taitaa vaatia toimiakseen juuri jonkinlaiset fiksut tiimikäytännöt. Ihmettelen silti vieläkin, miksei Gilbiä mainittu tuon Scrum-kirjan lähdeluettelossa.

Miksi aloimme siirtyä inkrementaaliseen ohjelmistokehitykseen vasta tänä vuonna? Olin kai laiska kärsivällinen enkä halunnut yrittää puskea mallia käyttöön ylhäältä annettuna vaan odottaa ensin kriittisen massan syntymistä kehittäjien joukossa. Lisäksi Philipsissä oli käynnissä aikaa ja energiaa vienyt CMM- ja CMMI-pohjainen prosessinkehityshanke. Mutta parempi myöhään!

Ensi kerralla vaikutelmia ensimmäisestä sprintistämme, joka päättyy parin viikon kuluttua.

Vanhakin nyt ketteröityy

Huomaan, etten ole kirjoittanut aikoihin ohjelmistotuotannosta, mutta tänä syksynä kertyy kerrottavaa. Kyllästyimme nimittäin keväällä ohjelmistoprojektiemme lopussa olleeseen stabilointihässäkkävaiheeseen ja mietimme, millä siitä pääsisi eroon. Oikealta lääkkeeltä vaikutti iteratiivinen ja inkrementaalinen ohjelmistokehitys, jossa hässäkät jaetaan pieniksi palasiksi matkan varrelle eikä julkaisukelpoisesta laadusta koskaan erkaannuta liian kauaksi.

Kesän aikana päätimme sitten nauttia seuraavassa projektissamme Scrumia suoraan purkista. Monen yrityksen Scrum-toteutus näyttää karahtaneen siihen, että mallista on otettu vain omassa firmassa helpoiten toteutettavat osat (esimerkiksi niin, että tuotteen omistajan roolia ei ole hoitanut yksi ihminen vaan sama komitea kuin ennenkin), mutta me päätimme lähteä liikkeelle ihan oppikirjatoteutuksella. Oman pikantin lisänsä tuovat lääkintälaitteen jäljitettävyysvaatimukset ja IEC 62304 -standardi, mutta oikeastaan niiden noudattaminen on monin osin helpompaa, kun projektin lopussa tapahtunut kiireinen dokumentointityö jakautuu tasaisemmin koko projektin ajalle. Veikkaan, että suurin haaste on vanhojen rakenteiden ja ajattelutapojen muuttaminen kuten missä tahansa muussakin ketteriin menetelmiin siirtyvässä yrityksessä.

En ole itse mukana Scrum-tiimissä, vaan roolini on enemmänkin sponsorin, mutta kerron silloin tällöin kokemuksiamme tässä blogissa. Tiimit on muodostettu, ensimmäiset pokerit pelattu Tukholmasta tilatuilla korttipakoilla ja Sonalleve MR-HIFU -ohjelmiston työlista hahmottunut, mutta ensimmäinen sprintti on vielä edessä. Mielenkiintoinen syksy tulossa!

Ultraäänellä kasvaimia vastaan

En ole tainnut viime vuosina hiiskahtaakaan kehittämistämme tuotteista, mutta nyt Philips Healthcaren MR-HIFUsta on jo jonkin aikaa puhuttu julkisesti, joten uskallan raottaa salaisuuden verhoa: kehitämme terapialaitetta, joka tuhoaa kasvaimia kohdennetulla ultraäänellä. Toimenpidettä ohjataan magneettikuvauslaitteen avulla. Ensimmäisenä kohteenamme ovat kohdun myoomat.

HIFU-hankkeemme on mielestäni myös kiehtovimpia Suomessa viime vuosina tehtyjä ohjelmistokehitysprojekteja. Tällaisen lääketieteellisen laitteen kehittäminen vie vuosia, ja ohjelmiston koodirivien määrä taitaa kasvaa tälläkin kertaa seitsennumeroiseksi, joten tuotteen arkkitehtuurin pitää olla tiptopkunnossa. Hankkeen kuluessa on pitänyt ratkaista useita haastavia tieteellisiäkin ongelmia, ja lisäksi kaikissa suunnitteluvaiheissa on muistettava potilasturvallisuus. On tämä ollut mielenkiintoisempaa kuin jokin Facebook-kikkareiden kehittäminen (vaikka kaikki kunnia niille)!

Agile-seminaari Helsingissä ensi viikolla

Ketterän kehityksen harrastajat kokoontuvat taas Helsingissä keskiviikkona 3.10.2007: Agile Seminar Helsinki, Fall 2007. Vielä 178 paikkaa vapaana!

Toyotan opetuksista ja hukan poistosta olen kyllä nähnyt jo kaksi esitystä ennestään. Ekalla kerralla reaktioni oli ”hei, tämähän on mielenkiintoista” ja toisella kerralla (luettuani Poppendieckeja) ”hohhoijaa, tämä on jo kuultu”, mutta olisikohan Craig Larmanilla jotain uutta sanottavaa aiheesta? Muiden firmojen kokemuksista on joka tapauksessa aina mielenkiintoista kuulla.

IBM ostamassa Telelogicin

Digitodayn mukaan IBM aikoo ostaa Telelogicin ja yhdistää sen tuotteet Rational-tuoteperheeseensä. En tiedä, onko tämä hyvä uutinen asiakkaan kannalta: yritykset olisivat voineet hyvin toimia toistensa kirittäjinä, mutta nyt tuloksena saattaa olla laiskahko monopoli.

Mielenkiintoista nähdä, millainen ryminä suurelta osin päällekkäisten tuoteperheiden yhdistämisestä seuraa. No, ainakin IBM saa piristystä vaatimustenhallintatuotteisiinsa, joissa Rational RequisitePro on ollut DOORSia heikompi esitys.

CMMI-esiarviointi valmistui

Tuotekehityksemme CMMI-esiarviointi on onnellisesti ohi. Mitään suuria yllätyksiä ei löytynyt, vaan ehdotetut parannuskohteet olivat samoja, joista olemme itsekin puhuneet. Kiitostakin saimme mm. DOORS-pohjaisesta vaatimustenhallinnastamme ja testaustiimimme tuottamista automaattisista tilastoista intranetissä: ohjelmiston laadun kehittymistä ja vaatimusten valmiusastetta on nykyään varsin näppärä seurata.

Vielä ei sentään oltu CMMI:n kakkostasolla, vaan kaikkia käytäntöjä pitäisi hieman skarpata. Saisikohan käyttötapaukset ujutettua yhdeksi tekniikaksi vaatimustenhallintaamme?

Löysin CMMI-mallin kätketyn tason

...ja sain miljoona bonuspistettä!

(Aprillia! Pitihän tähän jotain piristystä keksiä.) Valmistelen töissä yksikkömme ensimmäistä CMMI-esiarviointia. Kaksi Philipsin arvioijaa saapuu Vantaalle haastattelemaan tuotekehittäjiämme muutaman päivän ajaksi ja lausuu sitten arvionsa työtapojemme toimivuudesta ja CMMI-mallin mukaisuudesta.

Philips on käyttänyt ohjelmistokehitysprosessin parantamisessa mittatikkuna jo pitkään vanhaa SW-CMM-mallia, mutta nyt on tulossa käyttöön CMMI koko tuotekehityksessä. Pari vuotta sitten silloisen ohjelmistoprojektin työtavat olivat omasta mielestämme suurin piirtein SW-CMM:n kakkostason mukaisia ja olimme jopa suht tyytyväisiä prosesseihimme, mutta nykyinen projektimme on erilainen kuin entiset monellakin tapaa. Mielenkiintoista nähdä, millaisen tuomion saamme.

Ohjelmistotuotantoblogi ryhmätyönä?

Nimimerkki Teme ehdotti ryhmätyönä kirjoitettavan ohjelmistotuotantoblogin perustamista. Olisikohan sellaiselle sosiaalista tilausta? Ja olisiko suomalaisessa blogosfäärissä (tulipa tuokin sana kerran kirjoitettua) tarpeeksi kirjoittajia tällaiseen hankkeeseen? Vaikka ehkä kaikki haluavat säästää nerokkaimmat ideat omiin julkaisuihinsa.

IEC 62304 tulee

Lueskelen taas standardia IEC 62304: Medical device software – Software life cycle processes. Standardissa kuvataan, millaista lääketieteellisten laitteiden ohjelmistokehityksen, testauksen, ylläpidon, riskinhallinnan, konfiguraationhallinnan jne. tulisi olla potilasturvallisuuden takaamiseksi.

Suurin uutuus tässä standardissa lienee ohjelmiston ja sen osien jakaminen turvaluokkiin A, B ja C sen mukaan, millaisia seurauksia ohjelmiston viasta voi olla potilaan terveydelle. Vähemmän vaaralliset osat voidaan sitten dokumentoida ja testata hieman kevyemmin. C-luokassa pitää jo miettiä sitäkin, voisiko riskejä pienentää jakamalla ohjelmisto pyörimään eri suorittimille.

Alan standardit ovat menossa yksityiskohtaisempaan suuntaan, mutta taataanko tiptop-kunnossa olevalla prosessilla turvallisuus? Olennaista on myös tuotteen kehittäjien ja projektinjohdon ammattitaito ja asenne turvallisuutta kohtaan, mutta niitä olisikin jo vaikeampi standardoida.

Olisi joskus mielenkiintoista verrata kehitysprosessiamme muiden turvakriittisten alojen prosesseihin. Miten kehitetään koodia vaikka ydinvoimaloiden järjestelmiin?

Telelogic DOORS -projekti

Pitäisi kirjoittaa projektisuunnitelma firman Telelogic DOORS -vaatimustenhallintaohjelmiston käyttötapojen ja koulutuksen kehittämisestä ja pohdiskella DOORS/Net-liittymän käyttöönottoa.

Käyttääkö kukaan lukijoistani DOORSia tai jotakin muuta Microsoft Officea edistyneempää vaatimustenhallintatyökalua? (Ja onko minulla yhtään lukijaa? :) SoftQA:n suomenkielinen Vaatimustenhallinnan työkalut -foorumi on ainakin ollut varsin hiljainen. Armeija sentään marssii Telelogicin tahtiin: Maanpuolustuskorkeakoulun Vaatimusten hallinta -kurssilla esitellään DOORSin käyttöä.

Maailman käytetyin vaatimustenhallintaohjelmisto on kuulemma Microsoft Excel, mutta lääketieteellisen tai muun turvakriittisen laitteen kehittäminen olisi kovin tuskaista ilman kunnon linkitystyökaluja, kun laitteen riskilistasta pitää päästä helposti vaatimuksiin, toteutukseen ja testaukseen. Olemme olleet suht tyytyväisiä DOORSiin, vaikka sen käyttöliittymä voisikin olla intuitiivisempi. Ohjelmasta puuttuu oikeastaan yksi abstraktiotaso, joka tekisi sen helpommin ymmärrettäväksi vaatimusten kirjoittajalle. Tämä puute toki lisää konsulttien ja kouluttajien työllisyyttä.

Hyvät, pahat ja ketterät

Ketterä ohjelmistokehitys ja varsinkin XP pariohjelmointeineen saivat eilen täyslaidallisen Steve Yeggeltä: ”Up until maybe a year ago, I had a pretty one-dimensional view of so-called ‘Agile’ programming, namely that it’s an idiotic fad-diet of a marketing scam making the rounds as yet another technological virus implanting itself in naive programmers who’ve never read ‘No Silver Bullet’” jne. jne.

Osa haulikkoammunnasta osuu maaliin, osa vähän sinne päin, mutta Steven oma firma Google on niin poikkeuksellinen puuhamaa, että sen käytäntöjä voi olla aika vaikea matkia firmoissa, joissa ei ole valtavaa kassavirtaa riskiprojektien rahoittamiseen.