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.