vaatimus jäätyy
putoukseen, pyrähtää
sulaen scrumiin
rup ruoppaa pienen
palan valmiiksi, muuttaa
lennossa suuntaa
Nykyaikaiset ohjelmistokehityksen mallit olivat aiheena Sytyken MallinnusOsyn jäsentilaisuudessa 17.9.07 SYSOPENDIGIAlla.
Paula Salmi Osuuspankkikeskuksesta (OPK), nykyisestä OP-Pohjolasta esitteli heidän kehittämänsä V5-mallin, Allan Halme Accenturalta pureutui RUPin teoriaan ja Lasse Koskela Reaktor Innovationsista pohdiskeli Scrumin taustaa ja todellisuutta tänään.
Yleisössä istuneet kokeneet systeemityöläiset toisaalta kritisoivat Allan Halmen turhan teoreettista esitystä RUPista, toisaalta täydensivät Lasse Koskelan esitystä omilla kokemuksillaan scrumista.
V5-malli kehittää
OP-Pohjolan organisaatiouudistus pyrki eroon eri palvelualueilla toimineiden järjestelmäkehittäjien erillisten ratkaisujen koordinointiongelmista. Ict-palvelut ostetaan keskitetystä ict-organisaatiosta, vaikka liiketoiminnan tavoitteet määritetään edelleen palvelualueilla ja liiketoiminnan edustajat päättävät hankkeiden priorisoinnista ja etenemisestä.
Kehitysprosessin vaiheet noudattelevat perinteistä systeemityömallia idean kiteyttämisestä pilotointiin, jalkauttamiseen ja hyötyjen mittaukseen. Malli on ryhdistänyt ja selkeyttänyt prosessia ja vastuunjakoa, mutta haasteet eivät ole kadonneet: tehtävät ja dokumentit ovat vielä osin päällekkäisiä ja riittävän informaation takaaminen kapulanvaihtotilanteissa eri yksiköissä toimivien määrittelijöiden ja testaajien välillä vaatii ponnisteluja.
Paula Salmi kevensi esitystään kuvalla näppikseen nojaavasta pääkallosta, jota näytöltä tuijotti teksti ”Waiting for reply”. Hän kertoi ketterän kehittämisen käynnistyneen OP-Pohjolassa sertifioitujen projektipäälliköiden ja OWASP-tietoturvaan erikoistuneiden testaajien myötä.
RUP palastelee
Allan Halme vertasi RUPia vesiputousmalliin. RUPissa vaatimuksia ei jäädytetä, mutta koodaus kannattaa aloittaa vasta kun neljä viidesosaa järjestelmästä on määritelty. Kiinteähintainen tilaus edellyttää mahdollisimman hyvää vaatimusmääritystä.
Systeemityötä voi verrata Firenzen katedraalin kupolin rakentamiseen 1400-luvulla: järjestelmästä saa todellisen kuvan vasta, kun toteutus on jonkin matkaa edennyt ja nähdään, pysyykö toteutus sovituissa raameissa ja onko järjestelmän suorituskyky riittävä.
Kun tilaajalta tulee uusia tarpeita kesken projektin, RUPissa osa järjestelmästä on valmiina ja suuntaa voidaan muuttaa kohti uusia tavoitteita. Vesiputousmallissa taas kaikki olisi levällään eikä suunnan muuttamiseen löytyisi kiintopistettä.
Yleisö oli aktiivinen: Vastaava palasteleva suunnittelu-toteutus-idea kehitettiin jo 1990-luvun alussa Sytyken STST-työryhmässä, nykyisen Rela-yhteisön edeltäjässä. OP-Pohjolan V-malli ei tietenkään noudata vaihejakoa vesiputousmaisesti, kuten Allan Halme tulkitsi, vaan sisältää luonnollista iteraatiota, kun käyttäjät, ongelma, teknologia tai markkinat saattavat muuttua projektin aikana. Esitetyt RUPin työmääriä kuvaavat käyrät eivät toimi versioivassa tuotekehityksessä, jossa vaatimusmäärityksen työmäärä ei vähene työn edetessä.
Scrum pyrähtää
Lasse Koskela esitti Scrumin tausta-ideat kuvaamalla Toytan toisen maailmansodan jälkeisestä innovoivaa tuotekehityksestä, jossa pienin askelin tehokkaasti tehtiin jotain konkreettista, mikä tuotti lyhimmän kehitysajan ideasta valmiiseen tuotteeseen. Tältä pohjalta kehitettiin Scrum 1990-luvun alussa.
Asiakkaan priorisoimat tärkeät kehittämistoimenpiteet kootaan Product Backlogiin, josta kahdesta neljään viikkoon kestävän pyrähdyksen työmäärä poimitaan Sprint Backlogiin. Pyrähdyksen jälkeen tuotos on valmis eikä vaadi hiomista.
Ict-ammattilaisten velvollisuus on selvittää asiakkaalle priorisointiin ja toteutusjärjestykseen vaikuttavat tekniset asiat. Yleisön joukosta todettiin, että Scrumissa käytetään jatkuvasti aikaa Backlogin kampaamiseen, ettei se happane.
Scrumia opitaan tekemällä, ei kurssilla. Prosessi on yksinkertainen, mutta vaikea soveltaa. Scrumin toimijoita ovat tuotteen omistaja, moniosaava ja itseohjautuvat tiimi, johon kuuluu 5-9 henkilöä sekä Scrum-master. Scrum-master on kuin voi leivän välissä, poistaa esteitä ja ylimääräisiä välikäsiä sekä huolehtii prosessin järkevästä soveltamisesta.
Asiakkaiden kanssa keskustellaan heidän ymmärtämällään kielellä. Siihen ei kuulu pariohjelmointi eikä Scrum-master.
Vastaa