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ä.