Ketterien ohjelmistokehitysmallien analyysi käyttäen SEMS 4CC viitekehystä

T-76.650 Ohjelmistotuotannon seminaari, TKK, kevät 2002. 1 Ketterien ohjelmistokehitysmallien analyysi käyttäen SEMS 4CC viitekehystä Extreme Programming, Microsoft Synch-and-Stabilize, SCRUM, Dynamic Systems Development Method Seppo Sahi 48027S

2 T-76.650 Ohjelmistotuotannon seminaari, TKK, kevät 2002. Tiivistelmä Kirjoittaja: Tutkielman nimi: Seppo Sahi Ketterien ohjelmistokehitysmallien analyysi käyttäen SEMS 4CC viitekehystä Päiväys: 15.4.2002 Sivuja: 26 Tutkimuksen aiheena on tutkia voidaanko ketteriä ohjelmistokehitysmetodologioita kuvata käyttäen 4CC Tutkimuksen kohteeksi valittiin metodologiat Microsoft Synch-and-Stabilize, Extreme Programming, Scrum ja Dynamic Systems Development Method. 4CC viitekehys yhdistää ohjelmistoyrityksen liikkeenjohdon ja tuotekehityksen näkökulmat toisiinsa. Sitä voidaan käyttää sekä yrityksen nykyisen ohjelmistokehitystoiminnan arviointiin, että sen kehittämiseen. Tutkimuksessa havaittiin, että Microsoftin Synch-and-Stabilize on tutkielman metodologioista selvästi kaikkein kokonaisvaltaisin. Se on metodologioista ainoa joka määrittelee keinot tuotteen julkaisujen pitkäaikaissuunnitteluun. Tämä saattaa kuitenkin kaventaa kyseisen metodologian sovellusaluetta, koska kaikkia sen käytäntöjä ei varmaankaan voi sellaisenaan soveltaa monessakaan yrityksessä. Tutkielman analyysista saatiin myös tukea kokemuksille joiden mukaan Extreme Programming ja Scrum tukevat toisiansa. Yleisesti ottaen ketterien ohjelmistokehitysmetodologioiden kuvaaminen 4CC viitekehyksellä onnistui kiitettävästi sillä suurin osa tutkimukseen valittujen metodologioiden tärkeimmistä ominaisuuksista pystyttiin sijoittamaan viitekehyksen mukaiseen jakoon. Avainsanat: Four Cycles of Control, 4CC, Synch-and-Stabilize, Extreme Programming, Scrum, Dynamic Systems Development Method

T-76.650 Ohjelmistotuotannon seminaari, TKK, kevät 2002. 3 Sisällysluettelo Tiivistelmä... 2 Sisällysluettelo... 3 1 Johdanto... 5 1.1 Tutkielman tausta... 5 1.2 Tutkimusongelma ja tutkimuksen tavoitteet... 5 1.3 Tutkielman rajaukset... 6 1.4 Tutkimusmenetelmät... 6 1.5 Tutkielman rakenne... 6 2 Aikaisemman tiedon kuvaus... 7 2.1 Mikä tekee metodologiasta ketterän?... 7 2.2 4CC viitekehys... 7 2.3 Extreme Programming... 9 2.4 Microsoft Synch-and-Stabilize... 11 2.5 Scrum 12 2.6 Dynamic Systems Development Method... 13 3 Analyysi... 16 3.1 Strateginen tuotejulkaisujen ohjaussykli... 16 3.1.1 Extreme Programming... 16 3.1.2 Synch-and-Stabilize... 16 3.1.3 Scrum... 16 3.1.4 Dynamic Systems Development Method... 16 3.2 Julkaisuprojektin ohjaussykli... 17 3.2.1 Extreme Programming... 17 3.2.2 Synch-and-Stabilize... 17 3.2.3 Scrum... 17 3.2.4 Dynamic Systems Development Method... 18 3.3 Iteraation ohjaussykli... 18 3.3.1 Extreme Programming... 18 3.3.2 Synch-and-Stabilize... 19 3.3.3 Scrum... 19 3.3.4 Dynamic Systems Development Method... 19 3.4 Mini-milestone... 20 3.4.1 Extreme Programming... 20 3.4.2 Synch-and-Stabilize... 20 3.4.3 Scrum... 20 3.4.4 Dynamic Systems Development Method... 20 4 Johtopäätökset... 22 5 Tutkielman arviointia... 24

4 T-76.650 Ohjelmistotuotannon seminaari, TKK, kevät 2002. 6 Yhteenveto...25 Lähdeluettelo...26

T-76.650 Ohjelmistotuotannon seminaari, TKK, kevät 2002. 5 1 Johdanto 1.1 Tutkielman tausta Tutkielma tehdään Teknillisessä korkeakoulussa järjestettävän Ohjelmistotuotannon seminaarikurssin seminaarityönä. Seminaarikurssin aiheena keväällä 2002 on ketterä ohjelmistokehitys. SEMS on Ohjelmistotuotannon- ja liiketoiminnan instituutin vuonna 2001 alkanut projekti, jonka tavoitteena on parantaa pienten ja keskikokoisten ohjelmistotuoteyritysten ohjattavuutta ja ohjelmistotuotantoprosesseja sekä tätä kautta parantaa niiden kannattavuutta ja auttaa niitä kasvamaan. Tavoitteena on myös auttaa yrityksiä itseään sekä niiden potentiaalisia rahoittajia arvioimaan yrityksen käyttämien ohjelmistotuotantometodien kypsyyttä ja laatua. Tutkielman kirjoittaja ei ole itse mukana tässä projektissa. Four Cycles of Control (4CC) on SEMS projektin kehittämä viitekehys joka on suunniteltu pienten ja keskisuurten yritysten ohjelmistotuoteliiketoiminnan ja ohjelmistokehitystoiminnan analysointiin ja kehittämiseen. Viitekehys pyrkii yhdistämään yrityksen liiketoiminta- ja ohjelmistokehitysnäkökulmia toisiinsa yksinkertaisella, käytännöläheisellä ja nimenomaan pieniä ja keskisuuria yrityksiä hyödyttävällä tavalla. 4CC kehittäjien motivoivana voimana on ollut olemassa olevien referenssimallien, lähinnä CMM:n ja SPICE:n sopimattomuus pienten yritysten tarpeisiin johtuen kyseisten mallien massiivisuudesta. 1.2 Tutkimusongelma ja tutkimuksen tavoitteet Tutkimusongelmana on selvittää voidaanko ketteriä ohjelmistokehitysmetodologioita kuvata käyttäen 4CC viitekehystä? Kysymys on mielenkiintoinen, koska sen kautta voidaan saada ymmärrystä tutkimuksen koohteena olevien metodologioiden ominaisuuksista. Tämä puolestaan mahdollistaa metodologioiden vertailemisen. Toisaalta 4CC viitekehys on hyvin nuori joten tutkimuksen avulla voidaan myös testata sen soveltuvuutta nimenomaan tähän sovellusalueeseen. Tavoitteena on osaltaan antaa vastauksia seuraaviin kysymyksiin: Mihin viitekehyksen osaan metodologia ottaa kantaa ja millä tavalla? Mitä tämän jaottelun perusteella voidaan päätellä valituista metodologioista? Miten valitut metodologiat eroavat toisistaan viitekehyksen läpi analysoituna? Tutkielman tavoitteena on yhtäältä laajentaa tutkielman tekijän näkemystä ketteristä ohjelmistokehitysmetodologioista sekä toisaalta parantaa hänen taitojaan tieteellisen tutkimuksen tekemisessä.

6 T-76.650 Ohjelmistotuotannon seminaari, TKK, kevät 2002. 1.3 Tutkielman rajaukset Tutkielma rajataan käsittelemään seuraavia metodologioita: Extreme Programming (XP), Microsoft Synch-and-Stabilize, Scrum sekä Dynamic Systems Development Method (DSDM) Tällä rajauksella halutaan saada tutkimuksen tekemiseen käytetty työmäärä vastaamaan seminaarikurssin työmäärävaatimuksia. 1.4 Tutkimusmenetelmät Tutkimus suoritetaan kokonaisuudessaan kirjallisuustutkimuksena. 1.5 Tutkielman rakenne Kappale 2. Aikaisemman tiedon kuvaus selventää valittujen metodologioiden pääominaisuudet sekä kertoo 4CC viitekehyksestä sen mitä lukija tarvitsee ymmärtääkseen tutkielman loppuosan. Kappale 3. Analyysi jakaa valittujen metodologioiden ominaisuudet 4CC viitekehyksen mukaisiin kokonaisuuksiin. Kappale 4. Johtopäätökset sisältää tutkielman kirjoittajan näkemyksiä ja johtopäätöksiä edellisessä kappaleessa suoritetusta jaosta. Kappale 5. Tutkielman arviointia sisältää tutkielman kirjoittajan subjektiivisen mielipiteen tutkimuksen onnistumisesta. Kappale 6. Yhteenveto sisältää yhteenvedon tutkielman pääkohdista.

T-76.650 Ohjelmistotuotannon seminaari, TKK, kevät 2002. 7 2 Aikaisemman tiedon kuvaus 2.1 Mikä tekee metodologiasta ketterän? Ketterien metodologioiden päällimmäisenä tavoitteena on tuottaa asiakkaalle toimivia ohjelmistojulkaisuja. Kyseisissä metodologioissa toimivaa ohjelmistoa pidetään sekä onnistumisen, että edistymisen mittarina (Cockburn, 2001). (Cockburn, 2001) määrittelee ketterän metodologian olevan mahdollisimman kevyt, mutta silti tarkoitukseensa riittävä. Samalla sen tulisi olla hyvin pitkälle itseohjautuva sekä ympäristöön ja vaatimuksiin mukautuva. Ketterät ohjelmistokehitysmallit olettavat, että ohjelmistolle asetetut vaatimukset muuttuvat ja kehittyvät jatkuvasti koko kehitystyön ajan. Kehitystyö on yleensä iteratiivista, jotta tuotettuja inkrementtejä voidaan käyttää palautteena ja vaatimuksien tarkentajina. Ketterät metodologiat pitävät kehitystiimin kommunikaation saumattomuutta tärkeänä menestystekijänä ja luottavat hyvin pitkälle tiimien kykyyn ratkaista ongelmia. Dokumentointi nähdään kommunikointimenetelmänä muiden joukossa ja se koetaan yleensä tarpeelliseksi vain jos kommunikaatiolle halutaan pysyvyyttä (Cockburn, 2001). 2.2 4CC viitekehys Seuraavassa esitellään 4CC viitekehyksen pääkohdat (Rautiainen et al., 2002) kerrottu. niinkuin ne on lähteessä Four Cycles of Control (4CC) on viitekehys ohjelmistotuotekehityksen johtamiseen ja suunniteluun pienissä ja keskisuurissa yrityksissä. Kehittäjiensä mukaan viitekehys yhdistää yrityksen liikkeenjohdon ja ohjelmistokehityksen näkökulmat toisiinsa kokonaisvaltaisella, yksinkertaisella ja käytännönläheisellä tavalla. Viitekehystä voidaan käyttää sekä yrityksen nykyisen ohjelmistotuotekehitystoiminnan arviointiin, että sen kehittämiseen. Motivaationa viitekehyksen kehittäjillä on ollut olemassa olevien referenssimallien, kuten CMM:n ja SPICE:n sopimattomuus pienten yritysten tarkoituksiin. Kyseiset mallit ovat turhan mahtipontisia pienille yrityksille eivätkä itseasiassa anna riittävää ratkaisua pienten yritysten liiketoiminnan suunnitteluun. Lisäksi nämä mallit on suunniteltu lähinnä projektiliiketoiminnan tarpeisiin. Kuva 1 visualisoi viitekehyksen pääosat. Kunkin kontrollisyklin tarkoitus on suunnitella tavoitteet kuvassa oikealla olevalle syklille jonka jälkeen oikealla oleva sykli toteuttaa nämä suunniteltujen raamien puitteissa. Kaaviokuvassa palaute edistymisestä kulkee oikealta vasemmalle ja esimerkiksi markkinaympäristön vaatimukset vasemmalta oikealle. Syklien koot ilmentävät syklin läpiviemiseen kuluvaa aikaa.

8 T-76.650 Ohjelmistotuotannon seminaari, TKK, kevät 2002. Kuva 1. 4CC viitekehys (Vähäniitty, 2002) Strateginen tuotejulkaisujen ohjaussykli (engl. Strategic release management) muodostaa rajapinnan liikkeenjohdon ja ohjelmistokehitystoiminnan välille, sillä sen aikana tuotteen eri sidosryhmät päättävät tuotejulkaisujen ajoituksesta ja sisällöstä, resurssien jakamisesta sekä teknologisista pääsuuntaviivoista. Syklin aikana tehtäviin päätöksiin vaikuttaa ennenkaikkea yrityksen suunniteltu strategia sekä resurssien saatavuus. Sykliin liittyy olennaisena osana vaatimusten pitkäaikaishallinta. Kuvasta 1. nähdään eri sidosryhmät vaatimusten lähteinä. Julkaisuprojektin ohjaussyklissä (engl. Release project management) hallitaan yksittäistä julkaisuprojektia. Syklin tehtävänä on määrittää esim. iteraatiosyklien määrä, sisältö, ajallinen pituus ja budjetti strategisessa tuotejulkaisujen ohjaussyklissä asetettujen vaatimusten toteutumiseksi. Julkaisuprojektin ohjaussykli antaa strategiselle tuotejulkaisujen ohjaussyklille palautetta edistymisestä ja onnistumisesta. Iteraation ohjaussyklin (engl. Iteration management) tarkoituksena on tuottaa vakaa ja toimiva tuotejulkaisun inkrementti jota voidaan käyttää palautteen saamiseksi ja vaatimusten tarkentamiseksi. Jokaisen iteraation aikana jokin joukko määriteltyjä vaatimuksia muutetaan toimivaksi toiminnallisuudeksi tuotteeseen. Jotta iteraation hallitseminen olisi helpompaa Iteration management syklissä suunnitellaan myös iteraation jakaminen pienempiin askeliin joita kutsutaan viitekehyksessä termillä mini-

T-76.650 Ohjelmistotuotannon seminaari, TKK, kevät 2002. 9 milestone. Iteraation ohjaussykli tuottaa myös yksityiskohtaisen tehtäväluettelon iteraation läpiviemiseksi. Mini-milestonejen (engl. Mini-milestones) tarkoitus on helpottaa kokonaisuuden hallintaa sekä auttaa mittaamaan edistymistä iteraation aikana. Tarkoitus on siis synkronoida yksittäisten kehittäjien tuotokset suuremmaksi kokonaisuudeksi. Minimilestoneja voivat olla esimerkiksi päivittäiset buldit. Kuvan 1. alaosan nuolilla on kuvattu ohjelmistotuotannon eri aktiviteettikategoriat joihin syklien aikana tapahtuva toiminta voidaan jakaa. Suunnittelulla ja seurannalla (engl. Planning and monitoring) tarkoitetaan prosessin aikataulutuksen ja toteutuksen suunnittelua sekä seuraamista. Käytännössä tämä tarkoittaa esimerkiksi vastuujakojen suunnittelua, aikataulujen suunnittelua ja seurantaa sekä tuotejulkaisujen ja projektien onnistumisen arviointia. Ohjelmistosuunnittelulla ja toteutuksella (engl. Design and implementation) tarkoitetaan kaikkea ohjelmistotuotteen arkkitehtuurin suunnitteluun ja toteutukseen liittyvää toimintaa. Tuotehallinto (engl. Product management) käsittää ohjelmiston komponenttien, konfiguraatioiden ja versioiden hallinnan. Vaatimusten hallinnan (engl. Requirements engineering) päällimmäinen tavoite on varmistaa, että lopputuote vastaa asiakkaiden vaatimuksia. Tämä sisältää vaatimusten kartoittamisen, analysoinnin, priorisoinnin sekä vaatimusmuutosten hallinnan. Testauksella ja laadunvarmistuksella (engl. Verification and validation) tarkoitetaan tuotteen laatutavoitteiden määrittämistä ja seurantaa sekä toisaalta näihin laatutavoitteisiin pääsemiseksi suoritettua toimintaa. 4CC mallia tarkasteltaessa tulee muistaa, että mikäli jokin yksittäinen metodologia ei ota kantaa kaikkiin viitekehyksen ohjaussykleihin ei automaattisesti tarkoita, että kyseinen metodologia olisi huono vaan pikemminkin kyse on painotuksesta ja fokusoitumisesta johonkin tiettyyn ohjelmistokehityksen osa-alueeseen. 2.3 Extreme Programming Extreme Programming (XP) lähtee yksinkertaisesta olettamuksesta, että ohjelmiston vaatimukset ovat muuttuvia ja muutosten määrä sekä ominaisuudet ovat ennalta arvaamattomia. XP:n filosofian mukaan on turhaa suunnitella arkkitehtuuria tulevaisuutta varten, koska tulevaisuudessa suunnittelulähtökohdat saattavat kuitenkin olla täysin erilaiset. XP pyrkii hallitsemaan tätä kaaosta kahdentoista käytännön avulla (Beck, 2000). Näitä ovat suunnittelupeli (engl. planning game), pienet julkaisut (engl. small releases), metafora (engl. metaphor), yksinkertainen design (engl. simple design), testaus (engl. testing), refaktorointi (engl. refactoring), pariohjelmointi (engl. pair programming), kollektiivinen koodin omistaminen (engl. collective ownership), jatkuva integrointi

10 T-76.650 Ohjelmistotuotannon seminaari, TKK, kevät 2002. (engl. continious integration), 40-tuntinen viikko (engl. 40-hour week), on-site asiakas (engl. on-site customer), ohjelmointistandardit (engl. coding standards). Ohessa auki kirjoitettuna tämän tutkielman kannalta olennaisimmat käytännöt. Muut käytännöt ovat käytäntöjä joita ei voida sioittaa 4CC mallin mihinkään osaan. XP on iteratiivinen metodologia. XP:ssa iteraation pituus vaihtelee viikosta kolmeen viikkon. XP:n terminologian mukaisilla pienillä julkaisuilla tarkoitetaan nimenomaan sitä, että ohjelmistoinkrementtejä tulisi julkaista mahdollisimman usein. XP:n suunnittelupelissä asiakas päättää seuraavan toteutettavan inkrementin laajuuden ja aikataulun. Käytännössä tämä tapahtuu siten, että asiakas valitsee ostoskoriinsa haluamiansa käyttäjätarinoita. Kehittäjät ovat ennen suunnittelupeliä hinnoitelleet käyttäjätarinat sen mukaan kuinka paljon he arvioivat niiden toteuttamiseen kuluvan aikaa. Ennen ohjelmiston toteutuksen aloittamista määritellään metafora. Sillä tarkoitetaan ohjelmistosuunnittelun lähtökohtana käytettävää tarinaa. Koska suurin osa ohjelmistosuunnittelutyöstä tehdään ikäänkuin hajautetusti ohjelmointityön yhteydessä, niin on perusteltua käyttää metaforaa arkkitehtuurisuunnittelun korvaajana. Metafora tarkentuu sitä mukaa mitä enemmän ohjelman koodista on valmiina. Itse kehitystyö tehdään XP:ssä aina pariohjelmointina. Pariohjelmoinnissa kaksi ohjelmoijaa työskentelee käyttäen työkaluna yhtä tietokonetta. Eräs ohjelmointiparin paivittäisistä rutiineista on uuden koodin integroiminen suurempaan kokonaisuuteen vähintään kerran päivässä. XP:n termien mukaan puhutaan jatkuvasta integroinnista. Integroinnin yhteydessä kaikki yksikkötestit on ajettava onnistuneesti tai muutokset on hylättävä. Jatkuvan integroinnin ansiosta saatavilla on koko ajan toimiva versio ohjelmasta. XP:n prinsiippien mukaan ohjelmiston design tulisi säilyttää mahdollisimman yksinkertaisena. Toisinsanoen yksinkertainen design tarkoittaa XP:ssä sitä, että ohjelmistosuunnittelussa ei tulisi ajatella tulevaisuutta liikaa vaan ohjelmoida niin yksinkertaisesti kuin vain on mahdollista toteuttaa vaaditut ominaisuudet. Refaktoroinnilla eli vanhan ohjelmakoodin ajoittaisella uudelleen organisoinnilla varmistetaan, että yksinkertaisen designin periaatetta noudattamalla tuotettu koodi on arkkitehtuurisesti laadukasta ja vakaasti toimivaa. Testaus on eräs XP:n ydintekniikoista. Jokainen tuotantoon menevä ominaisuus on testattava yksikkötesteillä. Ohjelmoijat kirjoittavat itse yksikkötestit omille ohjelmakokonaisuuksilleen ennen itse ohjelmakoodin kirjoittamista. Tällöin testien kirjoittaminen toimii myös suunnittelun apuvälineenä. Yksikkötesteistä tehdään automaattisia ja niiden tulee toimia aina siitä lähtien kun ne on kirjoitettu. Funktionaaliset testit ohjelmistoinkrementille kirjoittaa asiakas. On-site asiakas toimii fyysisesti kehitystiimin läheisyydessä ja vastaa kehitystyön aikana nouseviin kysymyksiin. On-site asiakkaan avulla pienennetään kommunikaatiokustannuksia kehitystiimin ja asiakkaan välillä.

T-76.650 Ohjelmistotuotannon seminaari, TKK, kevät 2002. 11 Osa näistä käytännöistä on ollut olemassa jo pitkään ennen XP:n kehittämistä. XP:ssa on uutta se, että käytännöt yhdistetään toisiansa tukevaksi kokonaisuudeksi. Esimerkiksi yksikkötestaus ja pariohjelmointi tukevat toisiaan sillä pareittain yksikkötestien suunnittelu ja kirjoittaminen on nopeampaa (Beck, 2000). 2.4 Microsoft Synch-and-Stabilize Microsoftin Synch-and-Stabilizea voidaan pitää ketteränä metodologiana siinä mielessä, että se pyrkii sopeutumaan nopeasti markkinoiden muuttuviin vaatimuksiin. Synch-andstabilize ei myöskään ole dokumenttivetoinen niinkuin perinteinen vesiputoismalli. Lähteen (Cusumano & Smith, 1997) mukaan kehitysmalli etenee seuraavasti. Synchand-Stabilize lähtee liikkeelle suunnitteluvaiheella, jonka aluksi määritellään tuotevisio. Sen tarkoituksena on kertoa kehitettävän tuotteen tavoitteet ja se perustuu priorisoituihin käyttäjävaatimuksiin. Tuotevisio korvaa osittain vesiputousmallin funktionaalisen määrittelyn. Synch-and-Stabilize sisältää myös funktionaalisen määrittelyn, mutta se elää ohjelmiston koko kehityskaaren ajan ja sen oletetaan olevan lopullinen vasta kun tuote on valmis. Tämän jälkeen tehdään suunnitelma työn jakamisesta kehityssykleihin, joita Synch-and-Stabilizessa kutsutaan alisykleiksi (engl. subcycle). Kunkin syklin aikataulu on lyöty lukkoon ja toteutettavat ominaisuudet on priorisoitu, jotta alhaisimman prioriteetin ominaisuuksia voidaan jättää pois mikäli kaikkea ei ehditä toteuttaa. Toiminnallisuuskokonaisuuksille määritetään vastuulliset tiimit, joiden koko on yleensä kymmenen hengen molemmin puolin. Tiimi sisältää yleensä yhtä paljon testaajia kuin kehittäjiä. Kunkin alisyklin aikana kehittäjät suunnittelevat, toteuttavat ja debugaavat suunnitellut toiminnallisuudet. Testaajat toimivat pareittain kehittäjien kanssa ja testaavat heidän työtään jatkuvasti. Kehittäjät synkronoivat joka päivä tuottamansa koodin päivittäisten buildien muodossa. Syklin loppuvaiheessa julkaisu stabiloidaan eli uusien toiminnallisuuksien toteuttaminen lopetetaan ja keskitytään ainoastaan testaamiseen ja debugaamiseen. Jokaisen syklin lopputuloksena julkaistaan tuotejulkaisu. Viimeisessä syklissä tämä julkaisu on lopullinen markkinoille tuleva tuote ja muissa se on alpha- tai betajulkaisu. Viimeinen kehityssykli on samanlainen kuin sitä edeltävätkin, mutta se sisältää ylimääräisen stabilointivaiheen jota ennen käyttöliittymä jäädytetään, jotta tuotteen dokumentaatio voidaan saattaa valmiiksi.

12 T-76.650 Ohjelmistotuotannon seminaari, TKK, kevät 2002. Kuva 2. Microsoft Synch-and-Stabiize kehitysmalli (Cusumano & Yoffie, 1999) 2.5 Scrum Seuraavan kuvauksen tiedot ovat kokonaisuudessaan lähteestä (Beedle et al., 2001). Scrum on metodologia 6-8 hengen tiimeille. Scrumissa tuotepäällikkö (engl. Product owner) ylläpitää tuotteen käsiteltävien asioiden listaa (engl. Product backlog). Tähän on listattu prioriteettijärjestyksessä tuotteen käyttäjävaatimukset. Kaikki muutokset tähän listaan kulkevat tuotepäälikön kautta. Itse kehitystyö tehdään tasan 30 päivän mittaisissa iteraatioissa joita kutsutaan sprinteiksi. Ennen sprinttiä pidetään suunnittelupalaveri (engl. Sprint planning meeting) jossa on läsnä asiakkaat, käyttäjät, johto, tuotepäällikkö ja Scrum tiimi. Palaverissa päätetään seuraavan sprintin laajuus eli täytettävät käyttäjävaatimukset sekä sprintin tavoite (engl. Sprint goal). Tämän jälkeen iteraation laajuutta ei voida enää muuttaa ja scrum tiimille on taattava työrauha tavoitteeseen pääsemiseksi. Suunnittelupalaverin jälkeen scrum tiimi pitää oman palaverin jossa hahmotellaan arkkitehtuurisia suuntaviivoja sekä luodaan tarkempi tehtäväluettelo sprintin tekemättömistä tehtävistä. Sprintin aikana Scrum tiimi pitää kerran päivässä palaverin jota kutsutaan nimellä päivittäinen scrum (engl. Daily Scrum). Päivittäisen scrumin tarkoituksena on auttaa

T-76.650 Ohjelmistotuotannon seminaari, TKK, kevät 2002. 13 tiimiä ja projektin johtoa seuraamaan edistymistä, tukea tiimin kommunikaatiota sekä autaa johtoa tunnistamaan ja poistamaan kehitystyötä haittaavia esteitä. Sprintin päätyttyä pidetään sprintin tarkastelupalaveri (engl. Sprint review meeting). Palaverissa katselmoidaan sprintin aikana tuotettu ohjelmistoinkrementti. Palaverin jälkeen tuotteen käsiteltävien asioiden lista päivitetään vastaamaan nykytilannetta. Scrum mestari (engl. Scrum master) on henkilö joka on vastuussa scrumin mukaisten käytäntöjen toteutumisesta. Mestari mm. johtaa päivittäiset scrum palaverit. Hänen tehtävänään on myös valvoa, että scrum tiimi saa työskennellä rauhassa. Ei nimittäin ole lainkaan harvinaista, että kehitystiimin jäseniltä tullaan kyselemään, että voisiko vielä tämän ominaisuuden toteuttaa kuluvan sprintin aikana. Sscrum ottaa huomioon ohjelmistokehityksen kaaottisuuden ja olettaa jokaisen ohjelmistoprojektin olevan erilainen. Scrum on niin kutsuttu empiirinen prosessimalli jossa Scrum tiimi kehittyessään ja tiivistyessään löytää yhdessä tien jolla sprintin tavoitteet täyttyvät. Scrum tiimissä ei varsinaisesti ole rooleja vaan jokainen jäsen tekee sitä mitä parhaiten osaa. 2.6 Dynamic Systems Development Method DSDM on kehittäjiensä (Stapleton, 1997) mukaan kokoelma parhaaksi katsottuja käytäntöjä laadukkaan ohjelmiston nopeaan kehittämiseen. DSDM pohjautuu yhdeksään pääperiaatteeseen: 1. käyttäjien tulee osallistua aktiivisesti kehitysprosessiin, 2. DSDM tiimeillä pitää olla tarpeeksi valtaa tehdä päätöksiä, 3. kehitysprosessin tulee fokusoitua tuottamaan uusia tuoteinkrementtejä mahdollisimman usein, 4. tuoteinkrementtejä arvioidaan pääosin käyttäjätarpeiden täyttymisen perusteella, 5. kehitystyössä käytetään iteratiivista ja inkrementaalista mallia, 6. kaikki kehitystyön aikana tehdyt muutokset on pystyttävä perumaan, 7. vaatimukset on pystyttävä lyömään lukkoon karkealla tasolla projektin alussa, 8. testaus tulee integroida jatkumaan koko tuotteen kehityskaaren ajan ja 9. onnistunut yhteistyö sidosryhmien välillä on elintärkeää. Näistä ensimmäiset neljä on kivijalka jonka varaan DSDM on rakennettu ja loput viisi on periaatteita joita tulee noudattaa DSDM prosessissa. Kuva 3. visualisoi DSDM prosessin kulun. Jokainen DSDM prosessi alkaa esitutkimuksella (engl. feasibility study) jonka aikana päätetään kannattaako projektia ryhtyä toteuttamaan. Esitutkimusvaiheessa harkitaan myös kannattaako DSDM mallia käyttää kyseisessä projektissa. Vaihe kestää tyypillisesti muutaman viikon. Businesstutkimusvaiheessa (engl. Business study) kartoitetaan ja priorisoidaan toiminnalliset ja ei toiminnalliset vaatimukset karkealla tasolla. Yleensä tämä tehdään sidosryhmien ryhmätyönä. Myös arkkitehtuurinen suunnitelma (engl. System architecture definition) sekä prototypisointisuunnitelma (engl. Prototyping plan) tehdään tässä vaiheessa. Prototypisointisuunnitelma sisältää alustavan suunnitelman kaikista kehitystyön aikana tehtävistä prototyypeistä. Kaikki dokumentit ovat luonnoksia joiden tarkentaminen kehitystyön edetessä on sallittua ja suositeltavaa. Businesstutkimusvaiheen tulisi kestää alle kuukauden.

14 T-76.650 Ohjelmistotuotannon seminaari, TKK, kevät 2002. Kuva 3. DSDM prosessi (Stapleton, 1997) Esitutkimus ja businesstutkimusvaihe suoritetaan peräkkäin. Seuraavat kolme vaihetta ovat luonteeltaan iteratiivisiä joten niitä kutakin voidaan suorittaa useampia kertoja. Vaiheita voidaan myös suorittaa osittain päällekkäin ja aikaisemmin suoritettuun vaiheeseen voidaan palata. Kuvassa 3. takaisin palaamista on merkitty harmaalla nuolella ja eteenpäin menemistä mustalla. Varsinainen kehitystyö tehdään näistä kolmesta kahden ensimmäisen aikana. Kolmas vaihe on tarkoitettu lopputuotteen toimittamiseen asiakkaalle. Ensimmäinen näistä on toiminnallinen malli iteraatio (engl. Functional model iteration). Vaiheen tarkoituksena on tuottaa prototyyppi suunnitelluista toiminnallisista vaatimuksista sekä erityisesti käytettävyyteen liittyvistä ei-toiminnallisista vaatimuksista. Prototyypin avulla tarkennetaan businesstutkimusvaiheessa kerättyjä vaatimuksia. Design ja rakennus iteraation (engl. Design & build iteration) tarkoituksena on tuottaa vakaa ja testattu ohjelmistotuote joka voidaan antaa loppukäyttäjien käsiin. Mikäli vaiheen aikana tulee vielä tarvetta testata käyttäjillä jotain toiminnallista vaatimusta, voidaan palata edelliseen iteraatioon niinkuin harmaa nuoli Kuvassa 3. osoittaa.

T-76.650 Ohjelmistotuotannon seminaari, TKK, kevät 2002. 15 Käyttöönottoiteraation (engl. Implementation) aikana ohjelmistolle tehdään hyväksymistestaus ja ohjelmisto luovutetaan asiakkaalle. Lisäksi käyttäjille järjestetään koulutus ennen käyttöönottoa. Projektin päätyttyä tuotetaan projektin tarkasteludokumentti (engl. Project review document) missä arvioidaan projektin onnistumista eli vertaillaan kehityskaaren aikana määriteltyjä vaatimuksia ja tarpeita siihen mitä on saavutettu. Tätä kuvastavat Kuvassa 3. käyttöönottoiteraatiosta lähtevät harmaat nuolet.

16 T-76.650 Ohjelmistotuotannon seminaari, TKK, kevät 2002. 3 Analyysi Analyysissä jokaiselle metodologialle on tehty 4CC viitekehyksen mukainen jaottelu. Yhteenveto jaottelusta on esitetty Taulukossa 1. Tämän kappaleen sisältämät yläviitteet viittaavat Taulukon 1. sisältämiin juoksevasti numeroituihin metodologioiden ominaisuuksiin. Jaottelu on tehty käyttäen seuraavien lähteiden tietoja: XP (Beck, 2000), Synch-and- Stabilize (Cusumano & Smith, 1997), Scrum (Beedle et al., 2001) ja DSDM (Stapleton, 1997). 3.1 Strateginen tuotejulkaisujen ohjaussykli 3.1.1 Extreme Programming Extreme Programming ei ota kantaa tähän ohjaussykliin. 3.1.2 Synch-and-Stabilize Synch-and-Stabilizessa tuotteelle laaditaan kolmivuotinen tuotesuunnitelma 2 (engl. three-year product plan) jonka tarkoitus on suunnitella ja jaksoittaa tuotteen julkaisuja pitkällä aikavälillä. Suunnitelman tekee tuotepäällikkö yhdessä markkinoinnin kanssa. Kunkin tuotepäällikön suunnitelmat katselmoidaan ja hyväksytään tuoteohjelman katselmuksissa 1 (engl. Program review), joissa on paikalla myös yrityksen ylin johto Bill Gatesia myöten. Synch-and-stabilizessä käytetty tuotevisio 3 määrittää tuotteen pääfokuksen, miten tuotetta markkinoidaan, seuraavan julkaisun tarkoituksen sekä tarkeimmät osa-alueet joihin seuraava julkaisu pureutuu. Visio toimii myöhemmin toiminnallisen määrittelyn pohjana. 3.1.3 Scrum Scrumissa tuotepäällikkö hallitsee käyttäjävaatimuksia ylläpitämällä tuotteen käsiteltävien asioiden listaa 1. Sääntönä on, että tuotepäällikön tulee hyväksyä listalle kaikki ehdotukset, mutta tuotepäällikön mielipiteellä suuri vaikutus siihen mitkä käyttäjävaatimukset täytetään, sillä yksin hänellä on valta muuttaa listan priorisointia. 3.1.4 Dynamic Systems Development Method DSDM ei ota kantaa tähän ohjaussykliin.

T-76.650 Ohjelmistotuotannon seminaari, TKK, kevät 2002. 17 3.2 Julkaisuprojektin ohjaussykli 3.2.1 Extreme Programming Suunnittelupeli 1 on XP:n tapa suunnitella seuraavan iteraation laajuus ja aikataulu. Koska suunnittelupeli ei ota kantaa muuhun kuin nimenomaan seuraavaan käsillä olevaan iteraatioon, sitä ei voida sijoittaa stragiseen tuotejulkaisujen ohjaussykliin. XP:ssä ei tehdä varsinaista arkkitehtuurisuunnitelmaa vaan arkkitehtuuri määritellään karkealla tasolla XP:ssä metaforan 2 avulla. Metafora on yksinkertainen kaikenkattava tarina siitä miten järjestelmän tulisi toimia Osa XP:n vaatimusten hallintaa sekä verifikointi ja validointia on on-site asiakas 3.Onsite asiakas auttaa kehittäjiä päivittäisissä käyttäjävaatimuksiin liittyvissä kysymyksissä. Sillä välin kun kehittäjät työskentelevät seuraavan tuoteinkrementin parissa, on-site asiakas valmistelee hyväksymistestejä samalle inkrementille. 3.2.2 Synch-and-Stabilize Synch-and-Stabilizessa osa suunnitteluvaihetta on funktionaalisen määrittelyn tuottaminen 4. Tämän tekee julkaisuprojektin päällikkö yhteistyössä kehittäjien kanssa. Määrittely kirjoitetaan käyttäjän näkökulmasta ja se sisältää kaikki käyttöliittymän menut, dialogit, näkymät sekä virheilmoitukset. Suunnitteluvaiheessa määritellään myös kehitystiimit 13 (engl. Feature team) sekä kehitysaikataulu 5 (engl. Development schedule) mikä sisältää suunnitelman iteraatioiden aikataulutuksesta. Synch-and-Stabilizessa näkyvin palaute strategiselle tuotejulkaisujen ohjaussyklille tulee valmiin ohjelmistotuotteen 7 muodossa. Valmista tuotetta käytetään seuraavien julkaisujen suunnittelussa. 3.2.3 Scrum Scrumin sprintin suunnittelupalaverissa 2 asiakkaat, käyttäjät, johto, tuotepäällikkö ja Scrum tiimi yhdessä määrittävät seuraavalle sprintille laajuuden ja tavoitteen 3. Sijoitan palaverin tähän ohjaussykliin, koska siinä päätetään ainoastaan seuraavan sprintin tavoitteista ja laajuudesta. Mikäli palaverin tarkoitus olisi suunnitella sprinttien suhdetta toisiinsa pidemmällä aikavälillä sijoittuisi se ensimmäiseen ohjaussykliin. Sprintin katselmuksessa 7 asiakkaat, käyttäjät, johto, tuotepäällikkö ja Scrum tiimi katselmoivat sprintin aikana tuotetun tuoteinkrementin. Sprintin onnistumista mitataan vertaamalla sprintin tavoitetta ja käsiteltävien asioiden listaa sprintin aikana saavutettuihin todellisiin tuloksiin. Päähuomio on kuitenkin tuotetussa inkrementissä, josta saatua palautetta käytetään hyväksi seuraavan sprintin suunnittelupalaverissa.

18 T-76.650 Ohjelmistotuotannon seminaari, TKK, kevät 2002. Mikäli tuotteen julkaisut on jaettu useampaan julkaisuprojektiin, ylläpitää scrumin tuotepäällikkö myös julkaisun käsiteltävien asioiden listaa 4 (Release backlog). Lista kuvaa käyttäjävaatimuksia samalla tarkkuudella tuotteen käsiteltävien asioiden lista. 3.2.4 Dynamic Systems Development Method DSDM prosessi hallitsee tuotejulkaisun vaatimuksia priorisoimalla ja kirjaamalla tärkeimmät toiminnalliset ja ei-toiminnalliset vaatimukset 3 omaan dokumenttiinsa prosessin businesstutkimusvaiheen aikana. Businesstutkimusvaiheessa kirjoitetaan prototypisointisuunnitelma 1 mikä sisältää suunnitelman kaikista kehitystyön aikana tehtävistä prototyypeista. Suunnitelma toisinsanoen antaa aikataulut ja tavoitteet kullekkin iteraatiolle. Businesstutkimusvaiheessa tehdään myös arkkitehtuurinen suunnitelma 2. Suunnitelma määrittelee kehitys- ja tuontantoympäristöt sekä tuotettavan ohjelmiston arkkitehtuuriset pääsuuntaviivat. Suunitelmaa tarkennetaan kehitysprosessin edetessä. DSDM määrittelee explisiittisesti, että julkaisuprojektin lopuksi on tehtävä hyväksymistestaus 8 asiakkaalla. 3.3 Iteraation ohjaussykli 3.3.1 Extreme Programming XP määrittää, että kehitystyön tulee olla iteratiivistä ja että julkaisusyklin tulisi lyhyt. XP:n terminologian mukaan puhutaan pienistä julkaisuista 4. Termin sijoittaminen Taulukkoon 1. on hankalaa, sillä kyse on enemmänkin ohjenuorasta kuin ohjelmistotuotantoaktiviteetistä. Mikäli pienet julkaisut kuitenkin ymmärretään iteraatioiden lopputuotteena jota verifioidaan ja validoidaan, niin voidaan se sijoittaa taulukkoon. XP:ssä iteraation sisällä suoritettavat tehtävät suunnitellaan ja jaetaan iteraation suunnittelupelissä 6 (engl. Iteration planning game). Aikaisemmin mainittiin, että metafora toimii arkkitehtuurin suunnannäyttäjänä. XP:ssä arkkitehtuuri muodostuu ja hioutuu ohjelmistoon ajan myötä kun ohjelmoijat toteuttavat yksenkertaisen designin ja refaktoroinnin periaatteita. Täten yksinkertainen design ja refaktorointi 7 voidaan yhtenä kokonaisuutena sijoittaa Taulukkoon 1. Toisaalta myös XP:n käyttämä yksikkötestaus 8, missä testit suunnitellaan ennen varsinaista koodia on myös osa ohjelmiston suunnittelua, koska yksikkötestejä tehtäessä suunnitellaan itseasiassa samalla itse ohjelmistoa. XP:n käyttämä pariohjelmointi 9 voidaan käsittää myös toimenpiteenä laadun varmistamiseksi, koska pareittain ohjelmoitaessa koodiin eksyy todennäköisesti vähemmän virheitä, sillä pari saattaa huomata virheitä mitä ohjelmoija ei itse huomaa.

T-76.650 Ohjelmistotuotannon seminaari, TKK, kevät 2002. 19 3.3.2 Synch-and-Stabilize Kuten aikaisemmin mainittiin on Synch-and-Stabilizen kehitystyö on jaettu tyypillisesti kolmeen iteraatioon joita metodologia kutsuu termillä alisykli (engl. subcycle). Alisyklin aikana kehittäjät toteuttavat määrittellyt toiminnallisuudet. Ennen tuoteinkrementin julkaisua seuraa ns. stabilointivaihe 10 (engl. Stabilation period). Stabilointivaiheessa uuden koodin tuottaminen lopetetaan ja kehittäjät yhdessä testaajien kanssa keskittyvät tuotetun koodin integroimiseen, testaamiseen ja debuggamiseen. Jokainen alisykli sisältää aikapuskurin 8 (engl. Buffer time), jonka tarkoitus on pehmentää ominaisuuksien lisäämisestä tai arvaamattomista ongelmista aiheutuvia viivästyksiä. Viimeinen alisykli eroaa hieman tavallisesta. Sen aikana ohjelmiston sisältämät ominaisuudet lyödään lukkoon 14 (engl. Feature complete) ja käyttöliittymä jäädytetään 9 (engl. UI freeze). Tämän jälkeen seuraa vaihe jossa ohjelmakoodin katsotaan olevan valmis (engl. Code complete). Tätä voidaan ajatella ikäänkuin ylimääräisenä stabilointivaiheena ja siksi sitä ei ole merkitty erikseen Taulukkoon 1. Vaihe sisältää viimeisen testauksen ja debuggauksen ennen virallisen tuotejulkaisun tekemistä. Koko tuotteen kehityskaaren ajan julkaisuprojektin päällikkö ja kehitystiimi päivittävät funktionaalista määrittelyä 12. Siksi siitä onkin järkevää lisätä maininta Taulukkoon 1. Kunkin alisyklin lopputuotteena valmistuu joko lopullinen tuotejulkaisu tai alpha- tai betajulkaisu 6. Julkaisuprojektin ohjaussykli ja strateginen tuotejulkaisujen ohjaussykli käyttävät näitä julkaisuja palautteen saamiseksi tuotteesta. 3.3.3 Scrum Scrumissa sprintin suunnittelupalaverin jälkeen scrum tiimi pitää oman suunnittelupalaverinsa, jossa se tuottaa sprintin tehtävälistan 5 (engl. Sprint backlog) sprintin suunnittelupalaverissa määriteltyjen tavoitteiden täyttämiseksi. Tehtävälistaa hallitsee yksinomaan scrum tiimi. Tehtävälista elää jätkuvasti sprintin edistyessä ja se saattaa aluksi olla vailinainen esimerkiksi mikäli käytettävä teknologia tunnetaan huonosti. 3.3.4 Dynamic Systems Development Method DSDM:n toiminnallinen malli iteraatio ja design ja rakennus iteraatio seuraavat kumpikin samanlaista kaava, jonka vaiheet ovat seuraavat: prototyypin identifiointi 4 (engl. Identify prototype), aikataulun sopiminen 5 (engl. Agree schedule), prototyypin rakentaminen 6 (engl. Build prototype) ja prototyypin katselmointi 7 (engl. Review prototype). Ensimmäisessä vaiheessa mietitään prototypisointisuunnitelman ja vaatimusten pohjalta millainen prototyyppi ollaan rakentamassa ja toisaalta arkkitehtuurisuunnitelman pohjalta miten tämä prototyyppi rakennetaan. Tässä vaiheessa tulee muistaa, että DSDM sallii kummankin äsken mainitun suunnitelman päivittämisen ja tarkentamisen mitä varmasti myös tapahtuu.

20 T-76.650 Ohjelmistotuotannon seminaari, TKK, kevät 2002. Toisessa vaiheessa määritellään jaksotus iteraation sisällä sekä sitoutetaan kehitysryhmä aikatauluun. Kolmannessa vaiheessa vaiheessa rakennetaan prototyyppi edellisissä vaiheissa tehtyjen sunnitelmien mukaisesti. Viimeisessä vaiheessa katselmoidaan tuotettu prototyyppi ja siihen liittyvät dokumentit. 3.4 Mini-milestone 3.4.1 Extreme Programming XP:ssä projektin johdolla on kokoajan käsitys edistymisestä iteraatiosyklin aikana, koska kehittäjät integroivat ohjelmakoodinsa osaksi suurempaa kokonaisuutta useampia kertoja päivässä. XP:n terminologian mukaan toimintaa kutsutaan jatkuvaksi integroinniksi. 3.4.2 Synch-and-Stabilize Synch-and-Stabilizessa kehittäjät synkronoivat tekemänsä ohjelmakoodin päivittäin keskitetylle palvelimelle. Useimmissa projekteissa palvelimen koodista tehdään päivittäinen build 11 (engl. Daily build). Samalla integroidulle koodille tehdään joukko testejä 15. Mikäli virheitä havaitaan ne tulee korjata välittömästi. Koska koodi käännetään joka päivä on virheiden paikallistaminen käytännössä helppoa. 3.4.3 Scrum Scrumin päivittäisessä scrum palaverissa 6 kaikki tiimin jäsenet vastaavat kolmeen kysymykseen: Mitä olet tehnyt edellisen Scrumin jälkeen? Mitä teet ennen huomista Scrumia? Onko työskentellyssä jotain esteitä tai hankaluuksia? Palaveri pidetään joka päivä samassa paikassa samaan aikaan. Palaverin on tarkoitus kestää alle 15 minuuttia ja kaikki näiden kysymysten ulkopuoliset keskustelut järjestetään palaverin jälkeen. Päivittäisen scrumin tarkoituksena on auttaa tiimiä ja projektin johtoa seuraamaan edistymistä, tukea tiimin kommunikaatiota sekä autaa johtoa tunnistamaan ja poistamaan kehitystyötä haittaavia esteitä. 3.4.4 Dynamic Systems Development Method DSDM ei ota kantaa tähän ohjaussykliin.

T-76.650 Ohjelmistotuotannon seminaari, TKK, kevät 2002. 21 Synch-and- Stabilize < Metodologia Extreme programming Scrum DSDM 4CC:n ohjaussykli > 4CC:n aktiviteettikategoria v Suunnittelu ja seuranta Ohjelmistosuun. ja toteutus Tuotehallinto Vaatimustenhallinta Testaus ja laadunvarmistus Suunnittelu ja seuranta Ohjelmistosuun. ja toteutus Tuotehallinto Vaatimustenhallinta Testaus ja laadunvarmistus Suunnittelu ja seuranta Ohjelmistosuun. ja toteutus Tuotehallinto Vaatimustenhallinta Testaus ja laadunvarmistus Suunnittelu ja seuranta Ohjelmistosuun. ja toteutus Tuotehallinto Vaatimustenhallinta Testaus ja laadunvarmistus Strateginen tuotejulkaisujen ohjaussykli Julkaisuprojektin ohjaussykli Iteraation ohjaussykli Mini-milestonet Synch-and-Stabilize 1 Tuoteohjelman katselmus 2 Kolmivuotinen tuotesuunnitelma 3 Tuotevisio 4 Funktionaalinen määrittely 5 Kehitysaikataulu 1 5 13 11 6 Alpha ja beta julkaisut 3 8 14 7 Valmiin tuotteen julkaisu 2 3 9 8 Aikapuskuri 3 4 12 9 Käyttöliittymän jäädyttäminen 7 6 10 15 10 Stabilointivaihe 1 6 5 11 Päivittäiset buildit 2 7 8 9 12 Funktionaalisen määrittelyn päivittäminen 13 Kehitystiimien määrittäminen 3 14 Ominaisuuksien lyöminen lukkoon 3 4 8 9 15 Päivittäinen testaus 7 2 3 5 6 Extreme Programming 1 4 1 Suunnittelupeli 7 2 Metafora 1 5 3 On-site asiakas 2 4 6 4 Pienet julkaisut 5 Jatkuva integrointi 3 6 Iteraation suunnittelupeli 8 7 7 Yksinkertainen design ja refaktorointi 8 Yksikkötestaus Taulukko 1. Yhteenveto analyysistä Metodologioiden ominaisuudet on lueteltu ja numeroitu oikealla puolella olevaan listaan. Tämän jälkeen ominaisuudet on asetettu analyysitaulukkoon. Sijoittelun perustelut löytyvät kappaleesta 3. Analyysi. Selitykset 4CC:n ohjaussykleille ja aktiviteettikategorioille löytyvät kappaleesta 2.2 4CC viitekehys. 9 Pariohjelmointi Scrum 1 Tuotteen käsiteltävien asioiden lista 2 Sprintin suunnitelupalaveri 3 Sprintin tavoite 4 Julkaisun käsiteltävien asioiden lista 5 Sprintin tehtävälistä 6 Päivittäinen scrum 7 Sprintin katselmus DSDM 1 Prototypisointisuunnitelma 2 Arkkitehtuurinen suunnitelma 3 Priorisoitu lista vaatimuksista 4 Prototyypin identifiointi 5 Aikataulun sopiminen 6 Prototyypin rakentaminen 7 Prototyypin katselmointi 8 Hyväksymistestaus

22 T-76.650 Ohjelmistotuotannon seminaari, TKK, kevät 2002. 4 Johtopäätökset Microsoftin Synch-and-Stabilize on tutkielman metodologioista selvästi kaikkein kokonaisvaltaisin. Se määrittää yrityksen toiminnan suhteelisen tarkasti myös strategisessa tuotejulkaisujen ohjaussyklissä. Tutkimuksen muiden metodologioiden käytännöt ovat kyseisessä syklissä kevyitä tai jopa olemattomia. Toisaalta tätä ei pidä laskea muiden metodologioiden heikkoudeksi, sillä useissa tapauksissa yrityksen on helpompaa ottaa käyttöön metodologia joka sallii tuotteen julkaisujen pitkäaikaissuunnittelukäytäntöjen säilyttämisen samanlaisena kuin ne ovat aina olleetkin. Synch-and-Stabilizen tapauksessa on kyse metodologiasta joka on kehitetty yksittäisen yrityksen, Microsoftin tarkoituksiin. Sen kehittämisessä ja dokumentoinnissa ei todennäköisesti ole mietitty metodologian käytettävyyttä muissa yrityksissä. XP, Scrum ja DSDM ovat tässä mielessä yleispätevämpiä, että ne sallivat julkaisujen pitkäaikaissuunnittelussa käytettävän kullekkin yritykselle sopivimpia työkaluja. Toisinsanoen viitekehysanalyysin perusteella huomataan, että kaikki muut metodologiat paitsi Synch-and-Stabilize tarvitsevat aika paljon lihaa luidensa ympärille mikäli niitä ruvetaan käytännössä implementoimaan. Seikka mikä kannattaa muistaa aina Synchand-Stabilizea tarkasteltaessa on se, että siitä kertovat lähteet ovat suhteellisen vanhoja eikä allekirjoittaneella ole tietoa mihin suuntaan kyseinen metodologia on kehittynyt lähteiden kirjoittamisen jälkeen. Scrum määrittää paljolti miten ohjelmistotyötä pitäisi suunnitella ja seurata. XP:ssä tämä puoli on jätetty vähemmälle ja keskitytty määrittelemään yksittäisiä käytännön ohjelmointitekniikoita joita käyttämällä ohjelmistotyön tuottavuutta ja laatua voidaan nostaa. Kuten analyysitaulukosta huomataan on XP:n painopiste testauksen ja laadunvarmistuksen sekä ohjelmistosuunnittelun ja toteutuksen puolella. Scrumissa painopiste on puolestaan suunnittelussa ja seurannassa sekä vaatimustenhallinnassa. Analyysin perusteella metodologiat voisivat täydentää ja tukea toisiaan hienosti. Näin käytännössä onkin sillä (Beedle et al., 2001) kertoo XP:n ja Scrumin olevan yhdessä käytettynä hyperproduktiivinen yhdistelmä. Mikäli metodologioita vertaillaan viitekehysanalyysin perusteella huomataan, että itseasiassa osa eri metodologioiden tavoista toimia on samoja, mutta niillä on eri nimet. Tästä esimerkkinä XP:n jatkuva integrointi ja Synch-and-Stabilizen päivittäiset buildit. Tämä pienentää metodologioiden eroavaisuuksia jonkin verran. Silti metodologiat eroavat kuitenkin toisistaan selvästi. 4CC viitekehyksen suurin käyttösovellus on varmasti yritysten käytössä olevien ohjelmistokehityskäytäntöjen analysoinnissa. Ajan myötä voidaan saada näppituntumaa siitä millainen metodologia soveltuu mihinkin liiketoimintaympäristöön ja yrityksen sisäisiin ominaisuuksiin. Tällöin tämän tutkimuksen tapaista analyysia voidaan puolestaan käyttää päätöksenteon tukena siinä vaiheessa kun arvioidaan etukäteen paperilla jonkun metodologian soveltuvuutta käytäntöön. Ketterien ohjelmistokehitysmetodologioiden kuvaaminen 4CC viitekehyksellä onnistui kiitettävästi sillä suurin osa tutkimukseen valittujen metodologioiden tärkeimmistä ominaisuuksista pystyttiin sijoittamaan viitekehyksen mukaiseen jakoon. Tämä ei

T-76.650 Ohjelmistotuotannon seminaari, TKK, kevät 2002. 23 sinänsä ole yllätys sillä osaa näistä metodologioista on käytetty viitekehyksen suunnittelun lähtökohtana (Rautiainen et al., 2002).

24 T-76.650 Ohjelmistotuotannon seminaari, TKK, kevät 2002. 5 Tutkielman arviointia Allekirjoittaneen mielestä tutkielman tavoitteet täyttyivät. Tutkimusongelmaan saatiin selkeästi vastaus. Oma tietämykseni sekä tutkimuksen metodologioista, että ketteristä metodologioista ylipäätänsä otti varmasti suuren harppauksen eteenpäin. Toisaalta nyt tehty tutkielma oli hyvin teoreettinen. Silti se antaa hyvät lähtökohdat tutkia seuraavaksi jotain käytännönläheisempää aihetta. Tavoitteet täyttyivät myös siinä mielessä, että valmiuteni tieteelliseen kirjoittamiseen paranivat. Eräs tutkimuksen aikana ilmennyt ongelma oli se, että alunperin tutkimuksen yhdeksi kohteeksi oli valittu Feature Driven Development (FDD). FDD jouduttiin kuitenkin vaihtamaan DSDM:n, koska kirjallisuutta FDD:stä oli vaikea löytää. Toinen ongelma oli 4CC mallin nuori ikä ja siitä johtuva lähdedokumenttien muuttuminen tutkimuksen edetessä.

T-76.650 Ohjelmistotuotannon seminaari, TKK, kevät 2002. 25 6 Yhteenveto Tutkimuksen aiheena on tutkia voidaanko ketteriä ohjelmistokehitysmetodologioita kuvata käyttäen 4CC Tutkimukseen kohteeksi valittiin metodologiat Microsoft Synch-and-Stabilize, Extreme Programming, Scrum ja Dynamic Systems Development Method. 4CC on viitekehyksen on suunniteltu pienten ja keskisuurten ohjelmistoyritysten tuotekehitystoiminnan analysointiin ja kehittämiseen. Viitekehys jakaa yrityksen toiminnan neljään ohjaussykliin. Strategisessa tuotejulkaisujen ohjaussyklissä tuotteen eri sidosryhmät päättävät tuotejulkaisujen ajoituksesta ja sisällöstä, resurssien jakamisesta sekä teknologisista pääsuuntaviivoista. Julkaisuprojektin ohjaussyklissä puolestaan suunnitellaan julkaisuprojektin jakaminen iteraatioihin ja määritetään iteraatioille laajuus, aikataulu ja budjetti. Iteraation ohjaussyklin tarkoituksena on puolestaan hallita itse iteraatiota ja tuottaa vakaa sekä toimiva tuotejulkaisun inkrementti jota voidaan käyttää palautteen saamiseksi ja käyttäjävaatimusten tarkentamiseksi. Edistystä iteraation aikana puolestaan seurataan mini-milestonejen avulla. Analyysissä tutkimukseen valituttujen metodologioiden käytännöt jaettiin äsken esiteltyihin sykleihin. Taulukko 1. sivulla 21 vetää yhteen tämän analyysin. Analyysin perusteella huomattiin, että Microsoftin Synch-and-Stabilize on tutkielman metodologioista selvästi kaikkein kokonaisvaltaisin. Se määrittää yrityksen toiminnan suhteelisen tarkasti myös strategisessa tuotejulkaisujen ohjaussyklissä. Tutkimuksen muiden metodologioiden käytännöt ovat kyseisessä syklissä kevyitä tai jopa olemattomia. Scrum määrittää paljolti miten ohjelmistotyötä pitäisi suunnitella ja seurata. XP:ssä tämä puoli on jätetty vähemmälle ja keskitytty määrittelemään yksittäisiä käytännön ohjelmointitekniikoita joita käyttämällä ohjelmistotyön tuottavuutta ja laatua voidaan nostaa. Kuten analyysitaulukosta huomataan on XP:n painopiste testauksen ja laadunvarmistuksen sekä ohjelmistosuunnittelun ja toteutuksen puolella. Scrumissa painopiste on puolestaan suunnittelussa ja seurannassa sekä vaatimustenhallinnassa. Analyysin perusteella metodologiat voisivat täydentää ja tukea toisiaan hienosti. Näin käytännössä onkin sillä (Beedle et al., 2001) kertoo XP:n ja Scrumin olevan yhdessä käytettynä hyperproduktiivinen yhdistelmä. Ketterien ohjelmistokehitysmetodologioiden kuvaaminen 4CC viitekehyksellä onnistui kiitettävästi sillä suurin osa tutkimukseen valittujen metodologioiden tärkeimmistä ominaisuuksista pystyttiin sijoittamaan viitekehyksen mukaiseen jakoon. Tämä ei sinänsä ole yllätys sillä osaa näistä metodologioista on käytetty viitekehyksen suunnittelun lähtökohtana (Rautiainen et al., 2002).

26 T-76.650 Ohjelmistotuotannon seminaari, TKK, kevät 2002. Lähdeluettelo Julkaisut (Beck, 2000) Beck K. 2000. Extreme programming explaned: embrace change. Reading (MA). Addison-Wesley. 190 s. ISBN 0201616416. (Beck, 1999) Beck K. 1999. Embracing change with extreme programming. IEEE Computer. Vol. 32, Issue 10. s. 70. ISSN 0018-9162. (Beedle et al., 2001) Beedle M., Schwaber K., Martin R. 2001. Agile Software Development with SCRUM. Paperback. 150 s. ISBN 0130676349. (Cockburn, 2001) Cockburn A., 2001. Agile Software Development. Addison-Wesley. Reading (MA). 256 s. ISBN 0201699699. (Cusumano, 1995) Cusumano M.A. 1995. Microsoft secrets: how the world's most powerful software company creates technology, shapes markets, and manages people. New York. Free Press. 512 s. ISBN 0028740483. (Cusumano & Yoffie, 1999) Cusumano M.A., Yoffie D.B. 1999. Software development on Internet time. IEEE Computer. Vol. 32, Issue 10. s. 60. ISSN 0018-9162. (Cusumano & Selby, 1997) Cusumano M., Selby R. 1997. How Microsoft builds Software. Communications of the ACM. Vol. 40, Issue 9. s. 53. ISSN 0001-0782. (Cusumano & Smith, 1997) Cusumano M., Smith S. 1997. Beynd the Waterfall: Software Development at Microsoft. Teoksessa: Yoffie D. Competing in the age of digital convergence. USA. ISBN 0875847269. (Haikala, Märijärvi 1998) Haikala I., Märijärvi J. 1998. Ohjelmistotuotanto. 5. painos. Suomen Atk-kustannus Oy. Jyväskylä. 385 s. ISBN 951-762-666-5. (Rautiainen et al., 2002) Rautiainen K., Lassenius C., Sulonen R., 2002. 4CC: Balancing flexibility and control: A framework for Product Development Management in Small Software Companies, Helsinki University of Technology. EI VIELÄ JULKAISTU. (Stapleton, 1997) Stapleton J. 1997. Dynamic Systems Development Method. DSDM Consortium. Reading. 163 s. ISBN 0201178893. Muut kirjalliset lähteet (Vähäniitty, 2002) Vähäniitty J. 2002. SEMS Software Engineering Management System for SME s in the SW Product Business. Tekesin Spin-teknologiaohjelman vuosiseminaari. Helsinki 3.4.2002. Saatavilla www:stä <http://www.swbusiness.fi/portal/?cid=650026962>