Tietokoneohjelman toteuttaminen GUIDe
Aalto-yliopisto Teknillinen korkeakoulu Informaatio- ja luonnontieteiden tiedekunta Informaatioverkostojen tutkinto-ohjelma Jakub Järvenpää Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Diplomityö Espoossa 14. kesäkuuta 2010 Valvoja Ohjaaja Professori Tapio Takala FM Vesa-Matti Mäkinen Aalto-yliopisto Teknillinen korkeakoulu Informaatio- ja luonnontieteiden tiedekunta Informaatioverkostojen tutkinto-ohjelma Diplomityön tiivistelmä Tekijä Jakub Järvenpää Työn nimi Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Sivumäärä 62 Päiväys 14. kesäkuuta 2010 Professuuri Vuorovaikutteinen digitaalinen media ja sisällöntuotanto Julkaisukieli suomi Koodi T-111 Työn valvoja Professori Tapio Takala Työn ohjaaja FM Vesa-Matti Mäkinen Monien tietokonesovellusten käyttöliittymäongelmat tulevat usein esille vasta sovelluksen käyttöönoton yhteydessä, kun sovelluksen käyttäjät yrittävät suorittaa sovelluksella niitä tehtäviä, johon ko. sovellus on suunniteltu. GUIDe-prosessimalli on suunniteltu siten, että käyttäjien todelliset tavoitteet toimivat käyttöliittymäsuunnittelun pohjana. GUIDe-prosessimallilla luodulla käyttöliittymällä pystyy suorittamaan tehokkaasti ne tehtävät, johon käyttöliittymä on suunniteltu. GUIDen oleellinen piirre on käyttäjien oikeiden käyttötilanteiden simulointi suunnittelutyössä. Työn ensimmäinen tavoite on osoittaa, että GUIDe tuottaa tehokkaampia käyttöliittymiä kuin sellaiset menetelmät, joissa ei käytetä simulointia suunnittelutyössä. Ohjelmistoyritys Reaktorilla on vuosina 2005–2010 toteutettu sisäisissä ja asiakashankkeissa noin 30 sovellusta GUIDe-määrittelyn pohjalta. Toteutustyötä on tehty kahdella eri tavalla, Guide-Scrumilla ja Guidedflow’lla. Guide-Scrum on näistä kahdesta pidempään harjoitettu tapa. Työn toinen tavoite on analysoida molempia tapoja ja löytää syitä, miksi Guided-flow on Reaktorilla hiljalleen saamassa jalansijaa Guide-Scrumilta. Analysoin tapoja mm. lean-ajattelun hukkakäsitteillä. Totean, että GuideScrumissa on monia hukan lähteitä, joita on eliminoitu Guided-flow’ssa. Täten Guided-flow on lean-ajattelun näkökulmasta tehokkaampi tapa toteuttaa tietokoneohjelmia GUIDe-määrittelyn pohjalta, mikä osaltaan selittää Guided-flow’n hiljalleen kasvavaa suosiota Reaktorin hankkeissa. Lean-ajattelu paljastaa Guided-flow’ssa myös puutteita, joita dokumentoin tässä työssä. Joihinkin ongelmiin esitän ratkaisuehdotuksia. Asiasanat Käyttöliittymäsuunnittelu, GUIDe, Scrum, lean-ajattelu Aalto University School of Science and Technology Faculty of Information and Natural Sciences Degree programme of Information Networks Abstract of the Master’s Thesis Author Jakub Järvenpää Title Implementing a software application based on a GUIDe specification Number of pages 62 Päiväys 14 June 2010 Professorship Interactive Digital Media and Contents Production Language Finnish Code T-111 Supervisor Professor Tapio Takala Instructor Vesa-Matti Mäkinen, M.Sc. The user interface (UI) problems of many software applications become evident when the users attempt to accomplish tasks for which the application has been designed for. GUIDe is a UI design process which incorporates the users' real goals as the basis of user interface design. A user interface designed using GUIDe is efficient for executing the tasks for which it has been designed for. The simulation of the users' real use situations during the design of the user interface is the discerning feature of GUIDe. The first goal of this thesis is to demonstrate that GUIDe produces more efficient user interfaces than design processes that do not integrate simulation into the design process. Approximately 30 applications based on a GUIDe specification have been implemented in internal and customer ventures by the software company Reaktor during 2005-2010. The implementation work has been managed using two processes, Guide-Scrum and Guided-flow. The second goal of this thesis is to analyse both processes and find reasoning for the growing popularity of Guided-flow at Reaktor. I analyze both processes using the notions of waste, a concept originating from Lean thinking. I conclude that Guide-Scrum has many sources of waste that have been eliminated in Guided-flow. In terms of Lean thinking, Guided-flow is a more efficient way to implement applications based on GUIDe specifications, which, for its part, accounts for the growing popularity of Guided-flow at Reaktor. Lean thinking detects shortcomings in Guided-flow as well. I document these shortcomings and propose corrective actions for some of them. Asiasanat User interface design, GUIDe, Scrum, Lean thinking Alkulause Kiitän professori Tapio Takalaa työn laadukkaasta ja kannustavasta valvonnasta. Kiitän Vesa-Matti Mäkistä ja Karri-Pekka Laaksoa työn virallisesta ja epävirallisesta ohjaamisesta ja myös ammatillisesta valmentamisesta, joka toivottavasti jatkuu vielä pitkään. Kiitän suunnittelija Outi Hölttää tutkintooni liittyvien asioiden kärsivällisestä hoitamisesta vuosien varrella. Kiitän työnantajaani Reaktoria, jolle tämä työ on tehty. Kiitän myös kaikkia reaktorilaisia, joiden kanssa olen tehnyt töitä ja käynyt lukemattomia keskusteluja siitä, miten tietokoneet voisivat olla hyödyllisempiä meille ihmisille. Tämä työ on omistettu mamalle. Käsitteitä ja lyhenteitä GUIDe. Käyttötilanteiden simulaatioon perustuva tietokonesovellusten määrittelymenetelmä Lean. Johtamisfilosofia, joka pyrkii toiminnan jatkuvalla parantamisella minimoimaan valmistuksessa syntyvän jätteen määrän ja maksimoimaan asiakkaalle tuotetun arvon. Pull-periaate. Lean-valmistusprosessi tuottaa artefaktin vain jos sille on todettu kysyntä. ROI. Return on investment, sijoitetun pääoman tuotto Scrum. Iteratiivinen ohjelmistokehitysprosessi Sprintti. Scrum-prosessin vakiopituinen työrupeama WIP. Work in progress, keskeneräinen työ Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää Sisällysluettelo 1. Johdanto 2. Guided-flow’n taustalla vaikuttavat prosessit 2.1. GUIDe 2.1.1. Tavoitepohjaisten käyttötapausten selvittäminen 2.1.2. Käyttöliittymän suunnittelu 2.1.3. Käyttöliittymäratkaisun arviointi 2.2. Lean-ajattelu 2.2.1. Lean-ohjelmistokehityksen seitsemän periaatetta 2.2.2. Muri, mura ja muda-hukkakäsitteet 2.2.3. Wardin tietämyshukan kolmas variaatio: toiveajattelu 2.3. Luotetun neuvonantajan malli 2.4. Scrum-prosessikehys 2.4.1. Filosofia ja fokus 2.4.2. Peruskäsitteet 3. Käyttöliittymien tehokkuudesta 3.1. Tehokkuusjärjestys 3.2. Esimerkkejä käyttöliittymien tehokkuuseroista 3.2.1. Toisu 3.2.2. Lakipalvelut 3.2.3. Johtopäätöksiä 4. Guided-flow 4.1. Guide-Scrum ja sen ongelmat 4.2. Guide-Scrumin ongelmien korjaaminen lean-käsitteiden avulla 4.2.1. Työlistan sisältö vastaamaan käyttäjien tarpeita 4.2.2. Sprintin suunnittelu pois 4.2.3. Toiminnallinen katsaus valmiin määritelmäksi 4.2.4. Sprintin käsite pois 4.3. Guided-flow tiivistetysti 4.4. Guided-flow yksityiskohtaisesti 4.5. Syitä Guided-flow’n suosiolle 4.6. Havaittuja puutteita Guided-flow’ssa 4.6.1. Riippuvuus toiminnallisesta määrittelijästä 4.6.2. Tutkivan testauksen käynnistyskulut 4.6.3. Retrospektion ajoitus 5. Johtopäätökset 6. Yhteenveto 1 4 4 5 9 10 10 10 12 14 14 16 17 17 24 24 26 26 36 37 38 39 40 40 40 41 41 42 44 50 51 52 54 55 57 60 Viitteet 61 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää 1. Johdanto Ohjelmistoyritys Reaktorilla aloitettiin ketterien menetelmien käyttöönotto vuonna 2004. Ensimmäiset tekniikat, jotka otettiin järjestelmällisesti käyttöön asiakasprojekteissa, olivat testivetoinen ohjelmistokehitys (TDD) (Järvenpää 2006) ja Scrum-prosessikehys (Lindström 2006). Reaktorin Scrumilla ja TDD:llä toteutetuissa hankkeissa toteutui usein seuraava riski: “Monet käyttöliittymäongelmat tulevat usein esille vasta ohjelmiston valmistumisen jälkeen, kun järjestelmällä yritetään ensimmäistä kertaa saada tehtyä käyttäjien todellisia työtehtäviä. Pahimmassa tapauksessa käyttötarkoituksen kannalta keskeistäkin toiminnallisuutta voi puuttua järjestelmästä kokonaan. Osa eteen tulevista ongelmista puolestaan on käytettävyysongelmia: tehottomista ja vaikeaselkoisista käyttöliittymäratkaisuista syntyvää ajanhukkaa, virheitä ja turhaa koulutustarvetta. Osa käyttöliittymän puutteista on niin pahoja, että ne on joka tapauksessa korjattava ennen käyttöönottoa.” (Laakso et Laakso 2004, sivu 1) Yksi esimerkki tästä on ammattikorkeakoulujen toiminnansuunnittelujärjestelmä Toisu, joka määriteltiin rautalankamalleilla, toteutettiin Scrumilla ja todettiin käyttöönotossa käyttäjien toimesta pääosin käyttökelvottomaksi. Toisun ensimmäinen versio oli määritelty väärin, koska sillä ei pystynyt tekemään niitä tehtäviä, joihin se oli suunniteltu. Ohjelmistotuotantoon pätee 1:10:100-sääntö: virheen korjaamisen kustannus kasvaa kertaluokilla mitä myöhäisemmässä vaiheessa virhe korjataan. Ei ole samantekevää, missä vaiheessa ohjelmistokehityshanketta virheet korjataan. Halvinta on huomata virheet suunnitteluvaiheessa. Ohjelmiston vaatimusten oikeellinen määrittely projektin alkuvaiheessa on vaikeaa. On arvioitu, että jopa 25–70 prosenttia valmiiden ohjelmistojen ongelmista johtuu määrittelyvaiheen virheistä tai puutteista, ja näistä ongelmista kaksi kolmasosaa havaitaan vasta ohjelmiston valmistuttua (Robinson et al. 2003). GUIDe-menetelmä (Laakso et Laakso 2004) on suunniteltu siten, että käyttäjien todelliset tavoitteet toimivat käyttöliittymäsuunnittelun pohjana. GUIDe-menetelmällä luodulla käyttöliittymällä pystyy suorittamaan tehokkaasti ne tehtävät, johon käyttöliittymä on suunniteltu. 1 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää Käyttöliittymien tehokkuuden järjestelmällinen mittaaminen on jäänyt vähälle huomiolle. GUIDe-määrittelyjen pohjalta tehtyjen tietokoneohjelmien tehokkuus ja hyödyllisyys on ollut selvää GUIDea käyttäville käyttöliittymäsuunnittelijoille ja GUIDella suunniteltujen sovelluksien käyttäjille, mutta vertailua oikeassa käytössä olevien tietokoneohjelmien tehokkuuseroista ei ole dokumentoitu. Työn ensimmäinen tavoite on osoittaa, että GUIDe tuottaa tehokkaampia käyttöliittymiä kuin sellaiset menetelmät, joissa ei käytetä simulointia suunnittelutyössä. Ehdotan määritelmää käyttöliittymän tehokkuudelle ja käytän määritelmää samoihin tehtäviin tarkoitettujen käyttöliittymien tehokkuuden vertailuun. Vertailen ammattikorkeakoulujen toiminnansuunnittelujärjestelmä Toisun eri versioita keskenään ja kahta online-lakipalvelua keskenään. Molemmissa tapauksissa GUIDella määritelty sovellus on huomattavasti tehokkaampi annetun tehokkuuden määritelmän puitteissa. Jotta Reaktorin tekemissä hankkeissa ei kärsittäisi virheellisistä ja puutteellisista määrittelyistä johtuvista ongelmista, GUIDe-menetelmä otettiin käyttöön vuonna 2005. Reaktorilla on viimeisen viiden vuoden aikana (vuosina 2005–2010) toteutettu sisäisissä ja asiakashankkeissa noin 30 sovellusta GUIDe-määrittelyn pohjalta. GUIDe-prosessi ei kuitenkaan ota kantaa, miten syntyneen määrittelyn pohjalta toteutetaan järkevällä tavalla toimiva tietokoneohjelma. Toteutustyötä on Reaktorilla tehty pääasiassa kahdella eri tavalla, Guide-Scrumilla ja Guidedflow’lla. Guide-Scrum on pidempään harjoitettu tapa. Työn toinen tavoite on analysoida molempia tapoja ja löytää syitä, miksi Guided-flow on Reaktorilla hiljalleen saamassa jalansijaa Guide-Scrumilta. Analysoin Guide-Scrumia mm. lean-ajattelun hukkakäsitteillä. Totean, että Guide-Scrumissa on monia hukan lähteitä, joita on eliminoitu Guided-flow’ssa. Täten Guided-flow on lean-ajattelun näkökulmasta tehokkaampi tapa toteuttaa tietokoneohjelmia GUIDe-määrittelyn pohjalta, mikä osaltaan selittää Guidedflow’n hiljalleen kasvavaa suosiota Reaktorin hankkeissa. Tehokkaampi ja ennustettavampi prosessi on mieluisampi alalla, jonka hankkeissa budjetit tyypillisesti ylittyvät ja ennustettavuus on huono. Guided-flow’n eräs erityispiirre on se, että tietokonesovelluksen tilaavan tahon (asiakkaan) ja käyttöliittymäsuunnittelijan (toiminnallisen määrittelijän) interaktioon on kiinnitetty erityistä huomiota. Guided-flow’n kehityskaaren 2 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää aikana on huomattu, että erityisesti toiminnallisen määrittelijän ja asiakkaan on pystyttävä luomaan jo hankkeen alkuvaiheessa luottamukselliset suhteet, jotta riittävä jaettu ymmärrys ongelmasta ja sen ratkaisutavoista saavutetaan. Tämän osan käytäntöjä analysoidaan David Maisterin luotetun neuvonantajan mallin (Maister 1988) käsittein. Lean-käsittein analysointi paljastaa myös puutteita Guided-flow’ssa, joita dokumentoin tässä työssä. Joihinkin ongelmiin esitän ratkaisuehdotuksia. 3 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää 2. Guided-flowʼn taustalla vaikuttavat prosessit 2.1. GUIDe Hyvä käyttöliittymä saadaan aikaan selvittämällä käyttäjien tavoitteet ja käyttötilanteet ja tekemällä tilanteiden hoitamisesta mahdollisimman suoraviivaista ja itsestään selvää. Käyttäjille päivittäin eteen tulevat tilanteet ovat testitapauksia, joiden suorittamista tarkastelemalla hyvät käyttöliittymäratkaisut erottuvat huonoista (käytettävyys), tarvittava tietosisältö erottuu tarpeettomasta ja hyödylliset toiminnot hyödyttömistä. (Laakso et Latva-Koivisto 2006, esipuhe) GUIDe-prosessimallilla tietokoneohjelma saadaan suunniteltua siten, että se ratkaisee mahdollisimman hyvin niitä tosielämän tilanteita, joita käyttäjillä tulee vastaan. Keskeisenä työkaluna käytetään käyttötilanteiden simulointia ja konkreettisia käyttöliittymäkuvia, jotka visualisoivat vaatimusmäärittelyn testauskelpoiseen muotoon: järjestelmässä tarvittava toiminnallisuus ja tietosisältö sekä käyttäjän kannalta optimaalinen järjestelmän rajaus näkyvät käyttöliittymäsuunnittelun tuloksena syntyvistä kuvasarjoista. Käyttäjän näkökulmasta tehty käyttöliittymän kuvaus toimii havainnollisena kommunikointivälineenä tilaajan, toimittajan ja käyttäjien välillä. Käyttöliittymän kuvauksen valmistuttua kaikille on selvää, minkälaisesta tietokoneohjelmasta on kyse: mitä tarkalleen se ratkaisee ja mitä se ei ratkaise. GUIDe-mallin keskeisimmät vaiheet (kuva 1) ovat • konkreettisiin käyttötilanteisiin perustuvien käyttötapausten määrittely, • käyttöliittymän simulointipohjainen suunnitteluprosessi ja • käyttöliittymän testaus. GUIDe-mallissa käyttöliittymän kuvauksen valmistumisen jälkeen alkaa toteutusvaihe. GUIDe ei itsessään kuitenkaan ota kantaa, miten käyttöliittymän kuvauksen mukainen tietokoneohjelma toteutetaan. 4 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää Kuva 1. GUIDen vaiheet. 2.1.1. Tavoitepohjaisten käyttötapausten selvittäminen Projektin alussa käyttöliittymäsuunnittelijat selvittävät käyttäjien konkreettisia työnkulkuja ja tavoitteita tyypillisesti kenttätutkimusten avulla. Tässä vaiheessa ei ryhdytä laatimaan luetteloita järjestelmän toiminnoista, vaan tarvittava toiminnallisuus selviää myöhemmin käyttöliittymän kuvauksesta. Kenttätutkimusvaiheessa tehdään tyypillisesti kontekstuaalisia käyttäjähaastatteluja (contextual interviews) ja käyttäjätarkkailuja (user observations), jotka paljastavat käyttäjien olemassa olevia työnkulkuja, työtehtäviä ja niiden takana olevia tavoitteita. Selville saaduista työnkuluista poimitaan tavoitepohjaisia käyttötilanteita, jotka havaitun työnkulun lisäksi sisältävät käyttäjän tavoitteen. Tavoitteen tunnistaminen on tärkeää, koska pelkästään työnkulkukuvausten avulla on vaikeaa päästä irti nykykäytännöistä ja suunnitella samojen tavoitteiden saavuttamiseksi tehokkaampia työtapoja ja käyttöliittymäratkaisuja. Skenaarioiden takaa on osattava katsoa riittävän (muttei liian) korkean tason tavoitteita, jotka ovat juuri ja juuri suunniteltavan järjestelmän toimintojen yläpuolella. Käyttäjää tarkkaillessa ei siis pyritä selvittämään, millä tavalla hän käyttää jotain tiettyä työkalua, vaan mitä hän pyrkii saamaan aikaan kaikilla käyttämillään työkaluilla ja tiedoilla, jotka hänellä on käytössään. 5 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää Tavoitepohjaisten käyttötapausten tyypilliseksi formaatiksi on vakiintunut seuraavanlainen kuvaus: Tarkkaillun henkilön titteli tai työnkuva Hyvin lyhyt kuvaus tilanteesta Tavoitteen tai ongelman kuvaus Tilatietoja Tarkkailussa havaittu toteuma Tarkkailun aikana otetut valokuvat Alla on esimerkki tavoitepohjaisesta käyttötapauksesta, joka on laadittu onlinelakipalvelun käyttöliittymäsuunnittelua varten. Tämän työn tekivät toiminnalliset määrittelijät Jakub Järvenpää ja Eero Anttila keväällä 2009. Käyttötapauksessa ei jäädä erilaisten juridisten dokumenttien tai muun materiaalin löytämisen tasolle, vaan etsitään järjestelmän yläpuolella oleva konkreettinen tavoite. Tarkkailun aikana otetut kuvat on tässä jätetty pois tilanpuutteen vuoksi. 6 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää Sopimusjuristi #2 Reaktorin uuden brandin suojaaminen Tavoite Reaktor Innovations (RI) on vaihtamassa brandiaan pelkäksi Reaktoriksi. RI haluaa varmistaa, että ainakaan Suomen markkinoilla kukaan ei voi toimia nimellä Reaktor IT-konsultoinnin alalla. Ben Steinpilz on saanut soiton RI:n toimitusjohtaja Vesa Lauroselta, joka tiedustelee mahdollisista muutokseen liittyvistä ongelmista. Vesa on kertonut Benille, että Norjasta löytyy Reaktor-niminen IT-konsultoinnin huippuasiantuntijayritys. Ben ei tiedä liittyykö asiaan juridisia ongelmia. Tilatietoja Ben tietää, että brandin suojaamiseksi kannattaa selvittää, ovatko seuraavat toimenpiteet mahdollisia: Voiko sanamerkin Reaktor rekisteröidä EU-tuotemerkiksi? Jos ei, voiko sanamerkin Reaktor rekisteröidä Suomessa? Ben tietää, että EU-tasoisen kuviomerkin rekisteröinti ei ole ongelma. Toteuma Ben miettii, että voisiko asian ratkaista muttaa yrityksen nimi Reaktor Oy:ksi, mutta hänen kollegansa Hans Ahlström muistuttaa, että reaktor on ruotsinkielinen vastine suomenkielen sanalle reaktori, joten yleisnimenä se ei kelpaa yrityksen nimeksi. Ben ilmoittaa Vesalle, että yrityksen nimi ei voi olla Reaktor. Vesa ehdottaa aputoiminimen Reaktor rekisteröimistä. Ben selvittää PRH:n sivuilta mitä rajoituksia tai ongelmia aputoiminimen käyttöön voi liittyä. Selviää, että aputoiminimellä voi harjoittaa vain osaa toiminnasta. Seuraava vaihtoehto on rekisteröidä tavaramerkkeinä sanamerkki Reaktor sekä kuviomerkki uudelle logolle (logo + mahdollinen teksti) EU:n laajuisesti. Suomesta Ben tarkistaa samankaltaisten sanamerkkien olemassaoloa seuraavista paikoista: Yritys- ja yhteisötietojärjestelmä: löytyykö Suomesta samankaltaisella nimellä rekisteröityjä yrityksiä, joilla on sama yritysmuoto? Sellaisia ei löytynyt. 7 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää PRH:n tavaramerkkitietokanta: löytyykö nimellä "reaktor" tai "reactor" sanahaulla tai asiakasnimellä rekisteröityä tavaramerkkiä? Ei löytynyt täältäkään. Kansainvälisistä palveluista hän käy läpi seuraavat: Office for Harmonization in the Internal Market: Onko yhteysömerkki Reaktor varattu IT-toimialalta EU:n alueella? Ei samalta alalta. World Intellectual Property Organization: Onko yhteysömerkki Reaktor varattu IT-toimialalta kansainvälisesti? Ei samalta alalta. Ben toteaa, ettei edellä olevista lähteistä ole löytynyt mitään mikä estäisi Reaktor-sanamerkin rekisteröimisen Suomessa. Ben ottaa käsiinsä Tavaramerkki-kirjan ja kertaa sieltä tavaramerkin vakiintumisen edellytykset sekä tarkistaa viitteen TMerkkiL 2 §:n 3 mom Finlexistä. Tavaranerkki-teoksesta selviää, että Reaktor-nimen vakiintuminen voidaan osoittaa esim. lehtileikkeillä. Niinpä hän pyytää RI:n tiedotusjohtajalta tapausta puoltavia lehtileikkeitä. Seuraavaksi hän katsoo, mitä tavaramerkkilaki sanoo tuotemerkin erottuvuudesta. Ben toteaa, ettei edellä olevista lähteistä ole löytynyt mitään mikä estäisi Reaktor-sanamerkin rekisteröimisen Suomessa. Ben ottaa käsiinsä Tavaramerkki-kirjan ja kertaa sieltä tavaramerkin vakiintumisen edellytykset sekä tarkistaa viitteen TMerkkiL 2 §:n 3 mom Finlexistä. Tavaramerkki-teoksesta selviää, että Reaktor-nimen vakiintuminen voidaan osoittaa esim. lehtileikkeillä. Niinpä hän pyytää RI:n tiedotusjohtajalta tapausta puoltavia lehtileikkeitä. Lopuksi Ben kirjoittaa Vesalle sähköpostin, jossa em. asiat ovat tiivistetty toimintaohjeiksi. Tavoitepohjaisia käyttötapauksia laadittaessa saattaa aluksi vaikuttaa siltä, että näin konkreettisten käyttötapausten määrittely on turhaa, koska erilaisia käyttötapauksia näyttää löytyvän kymmeniä tai satoja. Todellisuudessa kuitenkin käyttötapaukset kategorisoituvat hämmästyttävän pieneen edustavaan otokseen, jolla on yllättävän suuri kattavuus (Laakso et Laakso 2004). 8 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää Havaitut käyttötilanteet kategorisoidaan. Esimerkiksi käyttötilanteet “Opiskelija: Tavaramerkkilaki 4 §” ja “Yritysjuristi: Osakeyhtiölaki: 22. luku, 1 §” kuuluvat samaan kategoriaan; kategorian yksittäiset käyttötilanteet ovat variaatioita. Tyypillisesti tarkkailut lopetetaan, kun kahdessa viimeisimmässä tarkkailussa ei enää havaita juuri muuta kuin aikaisemmin havaittujen käyttötilanteiden variaatioita. Esimerkiksi Online-lakipalvelun tapauksessa määrittelijät totesivat kahdeksannen tarkkailun jälkeen, että käyttötilanteista on riittävä tietämys. Käyttötilanteita näistä kahdeksasta tarkkailusta kertyi 17 kappaletta, joiden pohjalta syntyi kahdeksan käyttötilannekategoriaa. 2.1.2. Käyttöliittymän suunnittelu Käyttöliittymän suunnittelu alkaa siten, että toiminnallinen määrittelijä valitsee yhden käyttötilanteen ja suunnittelee käyttöliittymäratkaisun simuloimalla ko. käyttötilannetta. Tavoitteena on käyttökäyttöliittymäratkaisu, jossa ko. käyttötilanteen tavoitteen saavuttaminen on mahdollisimman tehokasta. Kun käyttötilanteen voi suorittaa tehokkaasti käyttöliittymäratkaisussa, sanotaan että käyttötilanteelle on tuki käyttöliittymäratkaisussa. Kun tuki ensimmäiselle käyttötilanteelle on saavutettu, käyttöliittymäsuunnittelija valitsee seuraavan käyttötilanteen ja toistaa edellä mainitun prosessin olemassaolevan käyttöliittymäratkaisun päälle. Tavoitteena on käyttöliittymäratkaisu, jossa ensimmäiselle ja toiselle käyttötilanteelle on tuki. Kun toinenkin käyttötilanne on tuettu, varmistetaan, että syntyneet muutokset eivät ole huonontaneet edellisten käyttötilanteiden tukea. Tämä varmistus tehdään simuloimalla kaikki tuetut käyttötilanteet. Näin jatketaan, kunnes kaikki käyttötilanteet ovat tuettuja käyttöliittymäratkaisussa. Suunniteltavaan järjestelmään ei voi syntyä toimintoja (features), joita ei tarvita minkään käyttötilanteen suorittamisessa, koska jokaisen käyttötilanteen kohdalla laaditaan vain ko. tavoitetta palvelevat toiminnot ja niiden käyttöliittymäratkaisut. Jos suunnitteluryhmälle tai asiakkaalle tulee projektin aikana mieleen muita potentiaalisia hyödyllisiä toimintoja, ne asetetaan toiminnallisten määrittelijöiden tutkittavaksi: onko löydettävissä jokin huomiotta jätetty tavoitepohjainen käyttötapaus, jossa tätä uutta toimintoa tarvittaisiin? Jos tarvetta toiminnon käytölle ei ole, se dokumentoidaan tarpeettomaksi, kunnes joku pystyy osoittamaan käyttötilanteen, jossa ko. toiminto tuo lisäarvoa käyttäjälle. (Laakso et Laakso 2004) 9 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää Käyttöliittymäsuunnittelu tehdään pääasiassa kynällä ja paperilla ja siinä käytetään aina havaittujen käyttötilanteiden realistista dataa. Syntyvä käyttöliittymäratkaisu on paperiprototyyppi, jolla voidaan simuloida yksityiskohtaisesti havaittujen käyttötilanteiden tukea. 2.1.3. Käyttöliittymäratkaisun arviointi Koska toiminnalliset määrittelijät ovat hyvin harvoin suunniteltavan järjestelmän potentiaalisia käyttäjiä, he eivät ole suunniteltavan järjestelmän erikoisalan asiantuntijoita. Kun kyse on vähänkin vieraammasta erikoisalasta, toiminnallisten määrittelijöiden ymmärrys alasta saattaa hyvinkin rajoittua käyttäjätarkkailuiden aikana kertyneeseen ymmärrykseen. Puuttuvat toiminnallisuudet, puutteet ratkaisussa olevassa toiminnallisuudessa ja tehokkuusongelmat saadaan selville kustannustehokkaasti käyttäjien kanssa tehtävien käyttöliittymän läpikäyntien avulla. Läpikäyntipalaverin aikana tulee hyvin esille puutteita ja väärinkäsityksiä työtehtävien ymmärtämisessä sekä mm. sellaisia poikkeustapauksia, joihin ei olla aiemmissa käyttäjätarkkailuissa osuttu. (Laakso et Laakso 2004) Jokaisen läpikäynnin jälkeen löytyneet ongelmat korjataan ja käyttöliittymäratkaisua päivitetään. Käyttöliittymäratkaisut ja järjestelmässä tarvittava toiminnallisuus on edelleen olemassa vain paperiprototyyppinä, jonka muuttaminen testitulosten perusteella on nopeaa. Kun läpikäynneissä löytyneet ongelmat on korjattu, on saavutettu riittävä varmuus siitä, että prototyypin mukainen tietokoneohjelma tulee olemaan hyödyllinen käyttötilanteissa esitettyjen tavoitteiden saavuttamiseen. Tällöin toteutustyö voidaan aloittaa. 2.2. Lean-ajattelu Lean-ajattelussa keskitytään arvoketjuihin eli toisiinsa liittyviin aktiviteetteihin jotka luovat arvoa. Keskeistä on luoda käyttäjille arvokkaita asioita ja minimoida valmistuksesa syntyvä jäte tai hukka. (Ward, 2007) 2.2.1. Lean-ohjelmistokehityksen seitsemän periaatetta Mary ja Tom Poppendieck ovat formalisoineet Lean-ajattelun soveltamisen ohjelmistokehitykseen. Poppendieckit esittävät seitsemän periaatetta, jotka ovat ajattelun apuvälineitä parhaiden käytäntöjen löytämiseksi (Poppendieck et 10 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää Poppendieck, 2003). Tiivis esitys löytyy Wikipediasta (Wikipedia: Lean software development). Eliminoi jäte. Jäte on mitä tahansa, joka ei lisää asiakkaan havaitsemaa arvoa tuotteessa. Ohjelmistokehityksessä tyypillistä jätettä ovat määrittelydokumentit, joista ei seuraa mitään, vastuun siirrot, osittain toteutetut ominaisuudet tai täysin käyttämättömät ominaisuudet. Vahvista oppimista. Tuotekehityksen ja tuotteen valmistamisen eroa voidaan kuvata reseptin kehittämisen ja reseptin mukaan kokkaamisen metaforalla. Vaikka molempia prosesseja voidaan parantaa (reseptiä voidaan parantaa ja reseptin mukaan tehtyä ruokaa voidaan tehdä nopeammin tai raaka-aineiden suhteen tehokkaammin), toimenpiteet ovat aivan erilaiset. Parhaan reseptin löytymiseksi on tehtävä monta kokeilua ja opittava kokeilujen tuloksista. Sama pätee tuotekehitykseen. Parhaiten menestyvät tuotekehitysorganisaatiot pystyvät luomaan ympäristöjä, joissa kokeilua tehdään ja kokeilujen tuloksista opitaan. Päätä mahdollisimman myöhään. Ohjelmistokehitykseen liittyy aina tietty määrä epävarmuutta: tietyllä hetkellä on tietynlainen näkemys siitä, mitä ominaisuuksia tarvitaan seuraavaksi tuotteeseen; tämä tietämys saattaa muuttua radikaalisti päivienkin aikavälillä. Niinpä on hyvä rakentaa ohjelmistokehitysprosessi siten, että siinä voidaan tehdä sitovia päätöksiä mahdollisimman myöhään. Mitä myöhempään sitovia päätöksiä voidaan tehdä, sitä paremmalla liiketoiminnallisella tietämyksellä nämä päätökset voidaan tehdä. Toimita mahdollisimman nopeasti. Jokainen tietokoneohjelmaan toteutettu toiminnallisuus on tehty investointi, jonka tuotto on nolla, kunnes se saatetaan käyttäjien käyttöön. Toiminnallisuuksiin tehdyillä investoinneilla on sitä parempi tuotto (ROI), mitä aikaisemmin ne saadaan käyttäjille. Valtuuta tiimi. Etenkin ohjelmistokehityksessä detaljit ratkaisevat. Abstraktit, korkean tason kuvaukset järjestelmästä ovat joko toivottoman riittämättömiä tai mahdottomia kommunikoida muuten kuin toimivan tietokoneohjelman muodossa. Lean-ohjelmistokehityksessä tunnustetaan se käytännön tosiasia, että hyvän tietokoneohjelman tuottamiseen liittyvä detaljien tuntemus voi olla vain toteuttavan tiimin jäsenillä. Tällöin valta detaljeista tulee olla tiimillä. Tiimi tunnustetaan primääriksi arvoa tuottavaksi yksiköksi, jolloin mm. projektinhallinta nähdään tiimiä tukevana toimintona, ei ohjaamisena tai käskyttämisenä. 11 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää Sisällytä eheys järjestelmään. Tuotekehitysorganisaatiolla on kaksi eheyden käsitettä. 1) Havaittu eheys tarkoittaa sitä, miten hyvin tuotekehitystä tilaava taho ymmärtää tuotekehitysorganisaation. Tämä kattaa sen, miten tuotekehitystä esitellään, miten tuotekehityksen tuloksia toimitetaan, miten tuotekehitystä tilataan, minkälaisia kuluja tuotekehityksesta seuraa ja minkälaisia ongelmia organisaatio ratkaisee. 2) Käsitteellinen eheys tarkoittaa sitä, että organisaation palat toimivat hyvin yhteen ja että organisaatio on riittävässä määrin joustava, ylläpidettävä, tehokas ja responsiivinen. Näe kokonaisuus. Tietokoneohjelmia ei enää kannata tarkastella itsenäisenä yksikkönä vaan suhteessa ympäristöönsä: tietokoneohjelma on se itse ja sen interaktio ympäristönsä kanssa. Mitä isompi järjestelmä, sitä enemmän on osia, joiden on toimittava yhdessä, jotta tavoitteet saavutetaan. Kokonaisuuden tunnistaminen ja toimivien rajapintojen muodostaminen on oleellista. 2.2.2. Muri, mura ja muda-hukkakäsitteet Toyota-tapa on Toyota-autovalmistajan kehittämä johtamiskulttuuri, jolla johdetaan autojen valmistusprosessia (Wikipedia: Toyota production system). Toyota-tapa on geneerisemmän Lean-ajattelun esimuoto. Toyota-tapa tuntee kolme erilaista hukan käsitettä. Muri (Wikipedia: Muri) on japanikielinen termi ylikuormitukselle, kohtuuttomuudelle ja absurdiudelle. Murilla tarkoitetaan hukan muotoa, joka johtuu työn standardoinnin puutteesta. Jotta työ voidaan standardoida, työn tulokselle tulee määritellä standardiehto. Kun standardiehto on olemassa, työ voidaan standardoida ja ohjeistaa siten, että kaikki työn tulos tähtää standardiehdon täyttämiseen. Jos jonkun henkilön vastuulla on vaihtaa sairaalan vuodeosaston lakanat kerran päivässä, muri-hukkaa olisi esimerkiksi se, että vuodevaatevarastosta ei löydy puhtaita lakanoita ja ko. henkilö joutuu selvittämään, mistä niitä löytyy (Rosenthal 2008). Mura on japaninkielinen termi epätasaisuudelle ja epäjohdonmukaisuudelle. Mura-hukka vältetään rakentamalla tuotantojärjestelmä, joka takaa sen, että tuotantoprosessi saa tarvitsemansa komponentit oikeaan aikaan kuitenkaan rakentamatta suuria varastoja. (Wikipedia: Mura) Muda (Wikipedia: Muda) on japaninkielinen termi toiminnalle, joka tuhlaa resursseja tai ei tuota arvoa. Erityisesti muda on hyödyllinen hukkakäsite 12 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää ohjelmistotuotannon kannalta. Mudalla on seitsemän erilaista tunnistettua muotoa: Ylituotanto on joko liikaa tai liian aikaisin tuottamista. Pyrkimys on tuottaa juuri sen verran, että tarve saadaan tyydytettyä. Tällöin resursseja käytetään tuotannossa optimaalisesti. Ylituotanto ohjelmistokehityksessä kattaa erityisesti määrittelydokumentit, joista ei seuraa mitään ja käyttämättömät ominaisuudet. Tarpeettomat varastot syntyvät ylituotannon myötä. Asiakkaan tarvetta mukaillaan rakentamalla tuotantojärjestelmä vetäväksi eikä työntäväksi. Kun tuote valmistetaan esim. vasta tilauksen synnyttyä, varasto voidaan minimoida. Tällöin varastoon sidottu pääoma saadaan minimoitua. Ohjelmistokehityksessä varasto on käytännössä keskeneräiset (eli työn alla olevat) ominaisuudet. Keskeneräisestä työstä käytetään yleisesti kirjainlyhennettä WIP (work in progress). Turhat liikkeet ovat tuotannot puolella tyypillisesti ergonomiaan liittyviä puutteita. Valaistus on huono, työkalut eivät ole saatavilla helposti jne. Ohjelmistokehityksen ergonomia on abstraktimpi mutta perusteltu käsite. Kaikenlaiset automatisoitavissa olevat manuaaliset toimenpiteet, jotka liittyvät esimerkiksi ohjelmointityöhön, voidaan nähdä turhina liikkeinä. Tällaisia ovat esimerkiksi testien suorittaminen manuaalisesti tai monimutkainen, ihmisen väliintuloa vaativa tuotantoonsiirto. Tehtävien vaihtuminen voi häiritä merkittävästi henkilön keskittymistä ja täten tuottavuutta. Tehtävien vaihdolla on keskittymisen menettämisen ja uudelleen hankkimisen kustannuksen lisäksi aina arvoketjun katkaisemiseen liittyvä kustannus: potentiaalisesti koko arvoketju saattaa kärsiä. Virheet ohjelmistotuotannossa tarkoittavat sitä, että tietokoneohjelma ei toimi tarvittavalla tavalla, jolloin se ei tuota optimaalisella tavalla arvoa käyttäjälleen. Odottaminen katkaisee arvoketjun. Ohjelmistotuotannossa tyypillisiä syitä odotukselle ovat toiminnallisuuden hyväksynnän viivästyminen, määrittelyiden puuttuminen, prioriteettien puuttuminen ja tekniset esteet. Turhaa kuljettamista ohjelmistotuotannossa vastaavat tietämyksen siirrot. Ward painottaa, että tietämyksen siirtoon liittyvät tietämyshukat ovat merkittävimpiä (Ward, 2007). Tietämyksen, vastuun, toiminnan ja palautteen erottaminen toisistaan on suurin tietämyshukan lähde. Jos esimerkiksi yksi henkilö tekee vaatimusanalyysiä, toinen vaatimusmäärittelyä ja kolmas 13 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää toiminnallisuuksien toteutusta määrittelyn pohjalta, näiden kolmen henkilön välillä tapahtuu tietämyksen siirtoa, jossa on kaikelle ihmiskommunikaatiolle luonnollista virhealttiutta ja tehottomuutta, kun kommunikoidaan monimutkaisia käsitteitä. 2.2.3. Wardin tietämyshukan kolmas variaatio: toiveajattelu Ward esittelee mallin, jolla tuotekehityksessä kerätyn tietämyksen piirissä olevaa hukkaa voidaan luokitella (Ward, 2007). Mallissa tietämyshukka jaetaan kolmeen eli kategoriaan: hajontaan, siirtoihin ja toiveajatteluun. Toiveajattelu kattaa kaikenlaisen päätöksenteon perustuen puutteelliseen tietämykseen. Toiveajattelu on erityisen relevantti käsite tietokonesovellushankkeiden määrittelymateriaalin validiuden analyysissä. On tyypillistä, että määrittelymateriaalia pidetään valmistuttuaan lähtökohtaisesti validina, vaikka liiketoimintaympäristö on ehtinyt määrittelytyön aikana ehtinyt muuttua merkittävästi. 2.3. Luotetun neuvonantajan malli Guided-flow’ssa olennaista on se, että tietokonesovelluksen tilaavan tahon (asiakkaan) ja käyttöliittymäsuunnittelijan (toiminnallisen määrittelijän) interaktion syvyys nähdään kriittisenä hankkeen onnistumisen kannalta. Erityisesti toiminnallisen määrittelijän ja asiakkaan on pystyttävä luomaan jo hankkeen alkuvaiheessa luottamukselliset suhteet, jotta riittävä jaettu ymmärrys ongelmasta ja sen ratkaisutavoista saavutetaan. Luotetun neivonantajan malli (Maister, 1988) on merkittävällä tavalla vaikuttanut Guided-flow’lla tehtävien hankkeiden alkupään käytäntöihin. David Maister esittää teoksessaan The Trusted Advisor asiantuntijuuden päälle rakennettavaa luotetun neuvonantajan mallia (Maister, 1988). Mallin perusolettamus on se, että mitä syvempi luottamus asiakkaan ja toimittajan välillä on, sitä laajemmista ja syvemmistä asioista asiakas on valmis puhumaan asiantuntijan kanssa. Tämä on molemmille osapuolille hyödyllistä: Asiakas voi löytää vaikeisiin ongelmiinsa ratkaisuja, jolloin suuren lisäarvon syntyminen hänelle voi olla mahdollista. Asiantuntija voi päästä käyttämään asiantuntemustaan koko laajuudessaan. Mallissa tunnistetaan neljä asioimisen tasoa: palvelun tarjoamiseen perustuva taso, tarpeeseen perustuva taso, ihmissuhteeseen perustuva taso ja luottamukseen perustuva taso (kuva 2). 14 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää Kuva 2. Luotetun neuvonantajan mallin asioinnin tasot (Maister, 1988). Tyypillisesti asiantuntijaorganisaatiot tyytyvät palvelun tarjoamisen tai tarpeeseen perustuvan asioinnin tasoon (tasot 1 ja 2). Tällöin asiantuntija tarjoaa ja asiakas on valmis vastaanottamaan vastauksia, asiantuntemusta tai ratkaisuja asiakkaan määrittelemiin ongelmiin. Hyödyllisimmillään asiantuntija voi olla asiakkaalleen, kun hän pystyy tarjoamaan näkemyksiään ja todella ymmärtää asiakkaan ongelmia. Jotta asiakas pystyy vastaanottamaan näkemyksiä tai jakamaan todella vaikeita ongelmia asiantuntijan kanssa, tietty määrä luottamusta pitää olla osapuolien välillä (tasot 3 ja 4). Mitä enemmän asiakas luottaa asiantuntijaan, sitä useammin asiakas muun muassa • pyytää asiantuntijan neuvoa, • on taipuvainen toimimaan asiantuntijan neuvojen mukaan, • on halukas jakamaan arkaluontoista informaatiota, joka helpottaa ongelmien ratkaisemisessa, • on valmis antamaan anteeksi, kun virheitä tapahtuu ja • pyytää asiantuntijaa riittävän aikaisessa vaiheessa mukaan ongelmanratkaisuun. Luotetun neuvonantajan malli tarjoaa työkaluja luottamuksen systemaattiseen rakentamiseen. Esimerkkejä: • Kuvaile ja kerro, älä sanele. 15 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää • Yritä selvittää, mikä tässä tapauksessa on erityislaatuista, ei tuttua. • Varmista, että neuvoasi halutaan. • Ansaitse oikeus antaa neuvoja. • Kysy. • Ole kiinnostunut itse henkilöstä. • Pyydä apua, kun sitä tarvitset. Reaktorin kaltaisessa ohjelmistoalan konsultointiyrityksessä on liiketoiminnan kannalta hyödyllistä, että asiakassuhteissa luottamus syvenee ajan myötä. Tyypillisesti Reaktorin asiakkaiden vaikeimmat ongelmat liittyvät pitkäaikaisten liiketoimintaprosessien tukemiseen tietokoneiden avulla, jolloin onnistuakseen asiakassuhteet ovat pitkiä ja ratkaistavat ongelmat ovat vaikeita. Luottamus on tällöin kanssakäymistä ja asioiden aikaansaamista merkittävästi helpottava tekijä. Maister painottaa, että luottamus on aina kahden henkilön välisen suhteen ominaisuus; organisaatiot tai yritykset eivät luota toisiinsa (Maister, 1988). Tietokoneilla ratkaistavia ongelmia tyypillisesti ratkotaan usein kokonaisen asiantuntijatiimin toimesta ja asiakkaana on joukko asiakasyrityksen edustajia. Tästä huolimatta luottamuksen rakentaminen on edelleen henkilöiden välinen prosessi. Tämä on otettava luottamuksen rakentamisen jaksottamisessa. Erityisen tärkeää on hankkeiden alussa tunnistaa, keiden tulee muodostaa nopeasti luottamusta toisiinsa. 2.4. Scrum-prosessikehys Scrum on prosessikehys, jonka Ken Schwaber ja Jeff Sutherland formalisoivat vuonna 1993. Scrum on saanut erittäin paljon vaikutteita artikkelista “New new product development game” (Takeuchi et Nonaka, 1986), joka vertailee perinteisiä tuotekehitysmenetelmiä viestijuoksuksi ja esittää paremman metodin analogiaksi rugbya. “Scrum” on rugbyn käsite, joka tarkoittaa rugbyjoukkueen etenemistä yhdessä pelikentällä. Scrum on yleisimmin käytetty ketterä prosessikehys. Sitä käyttävät pienet startup-yritykset ja globaalit suuryritykset (Sutherland et Schwaber, 2007; VersionOne, 2008). 16 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää Tässä osassa esittelen Scrumin perustan. Lähteenä on käytetty teoksia (Deemer et al., 2009) ja (Schwaber et Sutherland, 2009). Vaikka Scrumin variaatioita on yhtä monta kuin sen käyttäjiä, alla kuvataan ne yhteiset piirteet ja peruskäsitteet, jotka ovat Scrumin perusedellytykset. Erityistä painoa kuvauksessa annetaan niille piirteille, jotka ovat Guided-flow’hun erityisen relevantteja. 2.4.1. Filosofia ja fokus Scrum nojaa empiirisen prosessikontrolliteoriaan (Schwaber et Sutherland, 2009). Perusolettamus on, että tuotekehitystyön ympäristö ei ole vakaa vaan jatkuvasti muuttuva. Perinteiset mallit keskittyvät hankkeisiin, jotka saattavat sisältää useita tuotteita. Scrum on tiukasti tuotekeskeinen ja määrittelee, miten yksittäistä tuotetta kehitetään jatkuvasti. 2.4.2. Peruskäsitteet Scrumissa työ on organisoitu vakiopituisiin työrupeamiin, joita kutsutaan pyrähdyksiksi tai sprinteiksi (engl. sprint); jälkimmäinen on vakiintunein suomenkielinen nimitys. Tyypillinen sprintin kesto on yhdestä neljään viikkoa. Jokaisen sprintin päätteeksi oletetaan uusia ominaisuuksia tuotteeseen. Työ organisoidaan siten, että työtahti on kestävä. Kestävällä työtahdilla (engl. sustainable pace) tarkoitetaan sitä, että sprinttejä voidaan tehdä toistensa perään määrämättömän monta ja niiden väliin ei tarvita taukoja. Kuvassa 3 on esitetty Scrumin perustyösyklit. 17 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää Kuva 3. Scrumin perustyösyklit. Tuoteomistajan (engl. product owner) vastuu on maksimoida tuotekehitykseen tehtyjen investointien tuotto. On tunnettua, että ohjelmistotuotteen kehityksen kulujen valtaosa muodostuu henkilökuluista ja ne ovat varsin ennustettavia lyhyellä aikavälillä. Tuoteomistajan vastuu on tietyin väliajoin päättää, miten ohjelmistokehitystiimin tehty investointi käytetään. Tuoteomistaja päättää, mitä tehdään. Ohjelmistokehitystiimin tekemän työn tuottoa on suoraan vaikea mitata. Tuoton arviointi on monitahoinen ongelma, joka vaatii ymmärrystä tarvituista inkrementeistä, teknisistä riskeistä ja inkrementtien välisistä riippuvuuksista. Tuoteomistajan näkemyksiin saattaa vaikuttaa suurikin joukko tahoja. Scrum sanelee kuitenkin yhden säännön: tuoteomistaja on yksi henkilö, ei koskaan ryhmä henkilöitä. Tähän on kaksi tärkeää syytä: 1) Tiimi tarvitsee ristiriidatonta informaatiota, jotta se voi keskittyä arvon tuottamiseen (eikä informaation kaivamiseen). 2) Koska kasvokkain käytävällä keskustelulla on keskeinen funktio prosessissa, tiimillä tulee olla päivittäinen mahdollisuus keskustella tuoteomistajan kanssa. Tämä on helpointa järjestää yksittäisen henkilön kanssa. 18 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää Tiimi on keskeisin arvoa tuottava yksikkö Scrumissa. Tiimi luo tuotteen, josta asiakas on valmis maksamaan. Tiimien täysivaltaisuus ja itseorganisoituminen tarkoittaa sitä, että tiimillä on oikeus päättää, miten tuoteomistajan toivoma tietokoneohjelman toiminnallisuus rakennetaan. Koska toimivat inkrementit tietokoneohjelmassa ovat edistyksen mittari, tiimin taitopaletissa tulee olla ne kaikki tekijät, jotka tarvitaan toivotun tietokoneohjelman tekemiseen. Tiimin koko ei määräydy pelkästään teknisillä ja aikatauluvaatimuksilla vaan myös ihmisten kommunikaatiorajoitteilla. Itseorganisoitumisen perusedellytys on, että yhdessä työskentelevät ihmiset pystyvät tehokkaasti kommunikoimaan hankkeen nykytilaa toisilleen. Tämä kommunikointi alkaa menettää nopeasti tehoaan, kun tiimin koko on yli yhdeksän. Scrum suositteleekin optimaaliseksi tuotekehitystiimin kooksi seitsemää. Scrum-mestari (engl. Scrum master) on henkilö, joka pitää huolta siitä, että prosessia noudatetaan ja omista toimista oppimista tapahtuu tuotekehitysprosessin aikana. Kokemattoman tiimin kanssa scrum-mestarin pääasiallinen vastuu on pitää huolta siitä, että Scrumin työskentelytapojen noudatetaan. Tiimin kehittyessä päävastuu on enemmänkin toiminnan parantamisen fasilitointi. Keskeisin informaatiorakenne Scrumissa on tuotteen työlista (engl. product backlog). Sen avulla kommunikoidaan mihin investointeja ollaan tekemässä ja mitä on saatu aikaiseksi. Työlista muuttuu koko tuotteen kehityskaaren ajan liiketoiminnallisten tarpeiden mukaan. Jollei työlista heijasta parasta ymmärrystä siitä, millä inkrementeillä on paras tuotto, työlista ei ole ajantasainen. Tällöin päätöksenteko siitä, mitä seuraavaksi tulee toteuttaa, ei perustu parhaaseen tietämykseen. Työlista on priorisoitu lista tuotteen ominaisuuksia. Listan järjestys kuvaa näkemystä siitä, mikä ominaisuuksien tuotto on suhteessa toisiinsa: mitä ylempänä ominaisuus on, sitä parempi tuotto sillä on suhteessa muihin ominaisuuksiin. Ominaisuuden tuotto on periaatteessa hyvin yksinkertainen: ominaisuuden arvo asiakkaalle jaettuna ominaisuuden kehityskululla. Käytännössä ominaisuuden arvoa asiakkaalle on tyypillisesti vaikea arvioida. Tällöin liiketoiminnallisella näkemyksellä on suuri vaikutus työlistan järjestykseen. 19 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää Scrumin suosittelema formaatti ominaisuuksille on käyttäjätarina (engl. user story) (Cohn, 2004). Käyttäjätarinat koostuvat kolmesta osasta: kortista, keskustelusta ja vahvistuksesta. Kortissa on virke, joka kirjoitetaan tietyn formaatin muotoon ja joka identifioi kyseessä olevan ominaisuuden, mutta ei dokumentoi sitä. Täysi tieto ominaisuuden yksityiskohdissa saavutetaan sprintin suunnittelussa, jossa tiimi ja tuoteomistaja keskustelevat. Ominaisuuden lopullinen dokumentointi on itse toteutettu ja vahvistettu ominaisuus. Valmiin määritelmä (engl. definition of done). Scrum vaatii, että työlistan jokainen ominaisuus on joko valmis tai ei-valmis. Scrumissa ei siis hyväksytä esimerkiksi 95-prosenttisesti valmiita ominaisuuksia. Toki ei-valmis ominaisuus voi olla jossain työvaiheessa, jonka tunnistaminen on arvokasta kehitysvaiheessa, mutta tämä on tiimin sisäinen käytäntö. Scrum vaatii siis valmiin määritelmän, mutta ei ota millään tavalla kantaa, mikä se on. Julkaisun edistymiskaavio (engl. release burndown chart). Ennustaminen Scrumissa perustuu empiiriseen mittaan, jota kutsutaan vauhdiksi (engl. velocity). Tuotekehitystyön alussa tapahtuvan oppimisen jälkeen oletetaan, että tiimin tuottavuus vakioituu tietylle tasolle. Ominaisuuksille annetaan pistearvio, joka kuvastaa ominaisuuden suhteellista toteutuskustannusta muihin ominaisuuksiin verrattuna. Jos ominaisuus A on yhden pisteen kokoinen ja ominaisuus B kolmen pisteen kokoinen, ominaisuuden B toteuttamiseen kuluu tiimin arvion mukaan kolme kertaa enemmän resursseja. Tiimin vauhti on sprintissä valmiiksi saatujen ominaisuuksien pisteiden summa. Julkaisulla tarkoitetaan sellaista joukkoa ominaisuuksia, jonka valmistumisen myötä tuotteesta tehdään uusi versio käyttäjille. Kun julkaisuun sisältyvät ominaisuudet on pisteytetty, voidaan tiimin vauhdilla arvioida, kuinka monta sprinttiä pitää tehdä, jotta toivotut julkaisun ominaisuudet ovat valmiita. Kuvan 4 esimerkissä on tehty seitsemän sprinttiä ja niiden aikana on toteutettu 180 pisteen edestä toiminnallisuuksia. Koko julkaisun laajuus on 400 pistettä, jolloin tarvitaan arviolta 15 sprinttiä julkaisun toiminnallisuuden valmistamiseksi. 20 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää Kuva 4. Esimerkki julkaisun edistymiskaaviosta. Sprintin suunnittelussa (engl. sprint planning) tuoteomistaja ja tiimi määrittelevät seuraavan sprintin sisällön ja sitoutuvat siihen. Sprintin suunnittelu pidetään välittömästi edellisen sprintin loputtua. Tuoteomistalla on tuotteen (priorisoitu) työlista. Ominaisuuksia käydään läpi työlistan kärjestä lähtien. Tuoteomistaja selittää ominaisuuksien liiketoiminnalliset perusteet ja hyödyt käyttäjälle. Avoimella keskustelulla pyritään varmistamaan mahdollisimman nopeasti yhteisymmärrys siitä, mitä ominaisuus tarkoittaa. Jos keskustelun aikana ilmenee jotain sellaista, joka estää tiimiä toteuttamasta ko. toiminnallisuutta, ominaisuus palautetaan tuoteomistajalle tarkennettavaksi. Perustuen edellisten sprinttien vauhtiin suunniteltuun sprinttiin otetaan sopiva määrä toiminnallisuuksia työlistasta. Valinnan jälkeen tiimi analysoi ominaisuudet pienemmiksi tehtäviksi. Kun sprintin sisältö on päätetty, tiimi saa sprintin ajaksi työrauhan. Sprintin sisältöä ei muuteta paitsi erityisellä poikkeusmenettelyllä eli abnormaalilla sprintin keskeytyksellä (engl. abnormal sprint termination). Tällöin tuoteomistaja ottaa sen riskin, että kaikki sprintin aikana jo tehty työ menee hukkaan. 21 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää Sprintin koskemattomuuden idea on luoda tiimille edellytykset keskittyä lisäarvon tuottamiseen. Jos tätä rauhaa ei ole, tyypillisesti tiimin työtä keskeytetään lukemattomilla eri tavoilla. Tiimi ei voi sitoutua tavoitteisiin, jos käytettävissä oleva työpanos ei ole ennustettavissa. Kun sprintti on keskeytyksetön, tuoteomistaja menettää kontrollin sprintin sisällä, mutta vastineeksi hän saa luotettavampia arvioita tulevaisuudesta ja suuremman toimitusvarmuuden. Tiimi kokoontuu joka päivä samaan aikaan palaveriin, jota kutsutaan päivittäiseksi palaveriksi seisten (engl. daily standup), jossa ollaan tyypillisesti seisten ja jokainen tiimin jäsen vastaa vain seuraaviin kysymyksiin: 1. Mitä tehtäviä olen saanut valmiiksi sitten viime dailyn? 2. Mitä tehtäviä aion tehdä ennen seuraava dailya? 3. Mitä esteitä työlleni on? Palaverin vakiintunut nimi on daily. Vain tiimin jäsenet osallistuvat dailyyn. Dailyn tarkoitus on ylläpitää työn tekemisen rytmiä ja poistaa ominaisuuksien valmistumisen esteitä. Dailyjen pohjalta tiimi voi myös arvioida sprintin työmäärän realistisuutta. Jos työtä on selvästi liikaa, tuoteomistajaa pyydetään valitsemaan, mikä ominaisuus jätetään tekemättä. Sprinttikatsaus (engl. sprint review). Sprintillä on aina määrätty pituus, joten se myös loppuu aina ennalta määrätyllä hetkellä. Katsauksessa tiimi esittelee tuoteomistajalle ja muille sidosryhmille valmistuneet ominaisuudet. Tiimi ei saa esittää keskeneräisiä toiminnallisuuksia. Katsauksen jälkeen tuoteomistaja merkitsee tehdyt ominaisuudet tuotteen työlistassa valmiiksi. Sprintin retrospektiivi (engl. sprint retrospective). Sprinttikatsaus on kaikille sidosryhmille avoin tilaisuus, jossa edistymistä voidaan arvoida ja käydä läpi monien tahojen toimesta. Sprintin retrospektiivi on tiimin keino parantaa toimintatapojaan tarkastelemalla kuluneen sprintin tapahtumia ja oppimalla niistä. Tyypillisesti tiimit käyttävät ulkopuolisia fasilitaattoreita luomaan strukturoitua keskustelua menneistä tapahtumista ja auttamaan tiimiä sitoutumaan konkreettisiin tiimin toimintaa parantaviin tavoitteisiin. Tiimi pyrkii fasilitaattorin avulla tunnistamaan työskentelytavoissaan asioita, joista halutaan pitää kiinni ja joita halutaan parantaa. Tyypillisesti tiimi sitoutuu tekemään pieniä kontrolloituja muutoksia toimintaansa, jotta niiden efektiä voidaan 22 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää arvioida seuraavan sprintin retrospektiivissa. Tämä on fundamentaalein osa Scrumin empiirisen prosessikontrolliteoriaan perustuvaa filosofiaa. Muutoksia ei tehdä, ellei niiden efektiä voida todeta. 23 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää 3. Käyttöliittymien tehokkuudesta 3.1. Tehokkuusjärjestys Jotta eri käyttöliittymiä voidaan vertailla keskenään, tarvitaan olla suureet työnkulkujen vaativuudelle. Määritän seuraavat mitat: Mekaaninen kuorma Työnkulun aikana tehtyjen datan syöttöjen, valintojen ja siirtymien yhteenlaskettu määrä. Muistikuorma Niiden asioiden määrä, joita työnkulkua suorittava henkilö joutuu referoimaan muistista (työmuistissa tai muistiinpanovälineissä) useammin kuin kerran työnkulun aikana. Näiden kahden suureen avulla määritän käyttöliittymille tehokkuusjärjestyksen. Olkoon • KT käyttötilanne • KÄLI1 ja KÄLI2 käyttöliittymiä • Mech(KT, KÄLI) käyttötilanteen KT työnkulun mekaaninen kuorma käyttöliittymällä KÄLI • Mem(KT, KÄLI) käyttötilanteen KT työnkulun muistikuorma käyttöliittymällä KÄLI. 24 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää Tehokkuusjärjestys KÄLI1 on tehokkaampi kuin KÄLI2, jos ja vain jos Mech(KT, KÄLI1) ≤ Mech(KT, KÄLI2) ja Mech(KT, KÄLI1) ≤ Mech(KT, KÄLI2) mutta ei kuitenkaan Mech(KT, KÄLI1) = Mech(KT, KÄLI2) ja Mech(KT, KÄLI1) = Mech(KT, KÄLI2). KÄLI1 on yhtä tehokas kuin KÄLI2, jos ja vain jos Mech(KT, KÄLI1) = Mech(KT, KÄLI2) ja Mech(KT, KÄLI1) = Mech(KT, KÄLI2). Esitetyn järjestyksen puitteissa käyttöliittymät voidaan järjestää seuraavissa tilanteissa: • Jos käyttötilanteen KT työnkulun mekaaninen ja muistikuorma ovat molemmat pienempiä KÄLI1:ssä kuin KÄLI2:ssa, KÄLI1 on tehokkaampi. • Jos käyttötilanteen KT työnkulun mekaaninen kuorma on pienempi KÄLI1:ssä kuin KÄLI2:ssa, mutta muistikuormat ovat samat, KÄLI1 on tehokkaampi. • Jos käyttötilanteen KT työnkulun muistikuorma on pienempi KÄLI1:ssä kuin KÄLI2:ssa, mutta mekaaniset kuormat ovat samat, KÄLI1 on tehokkaampi. • Jos käyttötilanteen KT työnkulun mekaaninen ja muistikuorma ovat yhtä suuret KÄLI1:ssä ja KÄLI2:ssa, KÄLI1 ja KÄLI2 ovat yhtä tehokkaita. Jos käyttötilanteen KT työnkulun mekaaninen kuorma on pienempi KÄLI1:ssä ja muistikuorma pienempi KÄLI2:ssa, käyttöliittymien tehokkuutta ei voi tämän järjestyksen puitteissa määrittää. Oletetaan, että käyttötilanteessa KT KÄLI1 on tehokkaampi kuin KÄLI2. Oletetaan myös, että KÄLI1:n mekaaninen kuorma käyttötilanteen KT työnkulussa on M1 ≠ 0 ja KÄLI2:n M2. Tällöin on mielekästä verrata käyttöliittymien mekaanista tehokkuutta määrällisesti: Mekaaninen tehoero KÄLI1 on mekaanisesti M2/M1 kertaa tehokkaampi kuin KÄLI1 käyttötilanteessa KT. 25 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää Jos esimerkiksi KÄLI1:n mekaaninen kuorma on 20 ja KÄLI2:n 100 käyttötilanteessa KT, KÄLI1 on mekaanisesti 100/20 = 5 kertaa tehokkaampi kuin KÄLI1 käyttötilanteessa KT. Vastaava määrittely tehdään muistikuormalle. 3.2. Esimerkkejä käyttöliittymien tehokkuuseroista 3.2.1. Toisu Toisu on Reaktorilla toteutettu ammattikorkeakoulujen toiminnansuunnittelujärjestelmä. Järjestelmällä suunnitellaan ammattikorkeakoulujen opetusta ja hallinnoidaan käytettävissä olevia henkilöja taloudellisia resursseja. Toisu on osittain tehty kahteen kertaan. Ensimmäinen versio (Toisu1) tehtiin menetelmällä, jossa suunnittelutyötä ei tehdä simuloimalla käyttäjien oikeita käyttötilanteita. Määrittelyprojektin tuloksena syntyi sanallinen vaatimusmäärittely, käyttötapaukset ja rautalankamallit. Toteutuksessa käytettiin Scrum-prosessia. Ne Toisu1:n osuudet, joilla suunnitellaan opetusta, hylättiin käyttökelvottomina ja korvattiin Toisu2:lla. Toinen versio (Toisu2) tehtiin GUIDe-prosessin mukaan Reaktorin toiminnallisten määrittelijöiden Karri-Pekka Laakson ja Vesa-Matti Mäkisen toimesta. Määrittelyvaiheessa tehtiin kaksi käyttäjätarkkailua ja neljä läpikäyntiä käyttäjien kanssa. Toteutuksessa käytettiin Scrum-prosessia. Tehokkuuseroa perinteisen määrittelyn ja GUIDe-määrittelyn pohjalta tehdyissä työkaluissa voidaan valaista suorittamalla samankaltaisia käyttötilanteita Toisu1:ssä ja Toisu2:ssa. Käyttötilanteet Toisu2:n Rakennusfysiikan perusteet -käyttötilanne on käyttäjätarkkailussa havaittu ja täten täysin realistinen. Kyseinen käyttötilanne ei mene läpi Toisu1:ssä, joten Toisu1:ä simuloidaan yksinkertaisemmalla mutta mahdollisimman realistisella Matriisi- ja differentiaalilaskenta käyttötilanteella. 26 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää Koulutussuunnittelija Matriisi- ja differentiaalilaskenta Toisu1:ssä Tavoite Koulutussuunnittelija Anssi Virtasen tulee suunnitella sähkötekniikan vuosikurssin 2005–2009 peruskurssit lukuvuodelle 2005–2006. Kursseja on yhteensä 14. Matriisi- ja differentiaalilaskenta S -kurssin suunnitelma on seuraava: • Vastuuhenkilö on Juha Takkula. • Kurssi järjestetään ensimmäisellä periodilla. • Kurssilla on 20 h luentoja. Koulutussuunnittelija Rakennusfysiikan perusteet Toisu2:ssa Tavoite Koulutussuunnittelija Sanna Heikkisen tulee suunnitella lukuvuoden 2006– 2007 rakennustekniikan kurssit toisen vuosikurssin opiskelijoille. Kursseja on yhteensä 15. Rakennusfysiikan perusteet -kurssin suunnitelma on seuraava: • Kurssin vastuuhenkilö on Mikko Pekkarinen. • Kurssi järjestetään kolmannella ja neljännellä periodilla. • Luennot on tarkoitettu koko ryhmälle. Lähiopetustunteja on 92 h ja suunnittelutunteja 20 h. • Harjoitukset pidetään kolmessa osaryhmässä. Lähiopetustunteja on 32 h ja suunnittelutunteja 6 h per ryhmä. • Kurssin harjoitukset alkavat vasta luentojen jälkeen. • Kurssin suunnittelu on kesken, koska Mikko Pekkariselta ei ole varmistettu, että hän pystyy pitämään luennot. 27 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää Toisu1:n ja Toisu2:n tehokkuuden vertailu yksittäisten kurssien suunnittelulla Rakennusfysiikan perusteet -käyttötilanteen työnkulku on havainnollistettu kuvassa 5, “Rakennusfysiikan perusteet -kurssin suunnittelu Toisu2:lla”. Matriisi- ja differentiaalilaskenta -käyttötilanteen työnkulku on havainnollistettu kuvassa 6, “Matriisi- ja differentiaalilaskenta -kurssin suunnittelu Toisu1:lla”. Em. kuvissa on esitetty työnkulkujen suoritukset kuvasarjoina. Kuvasarjojen pituudet kuvaavat karkealla tasolla työnkulkujen suoritusten mekaanista kuormaa. Työnkulkujen suoritus kuvissa etenee ylhäältä alas, vasemmalta oikealle. Kuva 5. Rakennusfysiikan perusteet -kurssin suunnittelu Toisu2:lla. 28 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää 29 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää Kuva 6. Matriisi- ja differentiaalilaskenta -kurssin suunnittelu Toisu1:lla. 30 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää Toisu1:ssä suoritetun työnkulun mekaaninen kuorma on 83 toimenpidettä ja muistikuorma 5 referoitavaa asiaa: kurssin vastaavan nimi, luennot-tehtävän tunnus, periodin alkupäivämäärä, periodin loppupäivämäärä ja luentojen tuntimäärä. Toisu2:ssa suoritetun työnkulun mekaaninen kuorma on 19 toimenpidettä ja muistikuorma 0 referoitavaa asiaa. Kyseisessä käyttötilanteessa Toisu2 on mekaanisesti yli neljä kertaa tehokkaampi kuin Toisu1. Toisu1:ssä on viisi referoitavaa asiaa enemmän. Ks. kuvat 7 ja 8. Mekaaninen kuorma yksittäisen kurssin suunnittelussa Toisu1 Toisu2 0 23 45 68 90 Kuva 7. Toisujen mekaaniset kuormat yksittäisen kurssin suunnittelussa. 31 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää Muistikuorma yksittäisen kurssin suunnittelussa Toisu1 Toisu2 0 1 3 4 5 Kuva 8. Toisujen muistikuormat yksittäisen kurssin suunnittelussa. Toisu1:n tehottomuuden syitä Toisu1 kärsii hyvin monista tehottomuuden lähteistä, joista esitän kaksi: • Toisu1 ei muista periodien alku- ja loppupäivämäärää. • Toisu1:ssä päivämäärän syöttö on mekaanisesti tehotonta. Kuvassa 6a on esitetty yksityiskohta kurssin ajankohdan määrittelystä. Käytännössä kaikki kurssit pidetään periodien määrääminä ajanjaksoina; on hyvin harvinaista, että kursseilla on periodeista eroava aikataulu. Silti Toisu1 pakottaa käyttäjän määrittämään kurssin ajankohdan päivän tarkkuudella ikään kuin periodeja ei olisi olemassakaan. Lisäksi yksittäisen päivämäärän syöttäminen on hyvin tehotonta: käyttäjä joutuu avaamaan päivämäärän valitsimen ja valitsemaan kuukauden, vuoden ja päivän. Sama toimitus tehdään sekä kurssin aloitus- että lopetuspäivälle. Vastaavat toimenpiteet useaan kertaan toistettuna selittävät suuren osan Toisu1:n tehottomuudesta. Toisu1 sisältää myös paljon vältettävissä olevaa navigointia näkymästä toiseen. 32 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää Kuva 6a. Matriisi- ja differentiaalilaskenta -kurssin ajankohdan määrittely Toisu1:lla. Toisu1:n ja Toisu2:n tehokkuuden vertailu yksittäisten koulutusohjelmien vuosikurssin kurssitarjonnan suunnittelulla Oletetaan, että Toisu1:lla ja Toisu2:lla suunnitellaan saman koulutusohjelman tietyn vuosikurssin kurssitarjonta. Oletetaan myös, että kurssitarjonta on 19 kurssia ja kurssien suunnittelu on työmäärältään keskimäärin samanlainen kuin yllä kuvatuissa käyttötilanteissa. Oletetaan myös, että molemmilla järjestelmillä suunnitellaan lukuvuotta ensimmäistä kertaa; vanhoja lukukausia, joita voisi käyttää hyödyksi, ei ole. Tälloin tehokkuusero mekaanisen kuorman suhteen pysyy samana (Toisu1: 1577, Toisu2: 361), mutta muistikuorma kasvaa Toisu1:ssä 59 asiaan. Toisu1 on tässä käyttötilanteessa muistikuormaltaan vielä tehottomampi suhteessa Toisu2:een. 33 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää Toisu1:n ja Toisu2:n tehokkuuden vertailu yksittäisten koulutusohjelmien vuosikurssin kurssitarjonnan suunnittelulla historiatiedon avulla Oletetaan, että Toisu1:lla ja Toisu2:lla suunnitellaan edelleen koulutusohjelman tietyn vuosikurssin kurssitarjonta, mutta erona edelliseen tilanteseen oletetaan, että molemmilla järjestelmillä on suunniteltu jo ennestään edellinen lukuvuosi. Yksinkertaisuuden vuoksi oletetaan myös, että lukuvuoden suunnitelma on sama kuin viime vuonna, mutta periodit ovat luonnollisesti eri ajanjaksoilla kuin edellisenä lukuvuotena. On huomattava, että kyseinen käyttötilanne on hieman spekulatiivinen, koska käytännössä lukuvuosi ei ikinä ole edellisen kopio. On kuitenkin hyödyllistä simuloida tämä käyttötilanne, koska simuloiden saamme suuntaa-antavan arvion tämänkaltaisen realistisen käyttötilanteen vaativuudesta. Kun lukuvuosi on määritelty ja edellinen lukuvuosi on pohjana, Toisu1:ssä kurssitarjonnan suunnittelu on yhtä vaativaa kuin ilman edellistä lukuvuotta, koska käyttäjä ei pysty käyttämään edellistä lukuvuotta pohjana. Mekaanisten operaatioiden määrä on siis edelleen 1577. Toisu2:ssa edellisen lukuvuoden pohjalta suunnittelu on otettu huomioon. Siinä on toiminto, jolla voi kopioida yhdellä mekaanisella operaatiolla koko koulutusohjelman opettajat ja tunnit edellisvuoden vastineryhmiltä (kuva 8). 34 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää Kuva 8. Kopiointi edellisvuodelta Toisu2:ssa. 35 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää Tässä käyttötilanteessa Toisu2 on mekaanisesti tyrmäävät 1577 kertaa tehokkaampi kuin Toisu. Erään Toisu1:n käyttäjän kommentti onkin varsin kuvaava: “[Toisu1] ole suunnittelujärjestelmä, koska sillä ei voi suunnitella.” 3.2.2. Lakipalvelut Alla oleva käyttötilanne on havaittu Suomenlaki.com-palvelun uudistushankkeen käyttäjätarkkailuissa Jakub Järvenpään ja Eero Anttilan toimesta keväällä 2009. Opiskelija #2 Lakiviite Tavoite Kim Parviainen on valmistautumassa Kauppaoikeuden tenttiin. Hän on lukemassa teosta Haarmann et al.: Immateriaalioikeuden perusteet (2007), jossa viitataan tavaramerkkilain 4 §:ään. Kim uskoo, että tavaramerkkilaissa on jotain tentistä suoriutumisen kannalta relevanttia informaatiota, joten hänen tulee selvittää, mitä ko. pykälässä säädetään. Tilatietoja Kim on kotisohvallaan. Kimillä on internet-yhteydellä varustettu tietokone. Toteuma Käyttäjä avaa selaimeen Finlexin, seuraa linkkejä “Lainsäädäntö”, "Ajantasainen lainsäädäntö", “2009” , siirtää fokuksen hakukenttään, kirjoittaa hakukenttään "tavara*", painaa Hae-nappia, vierittää ensimmäistä hakutulossivua kolme kertaa, siirtyy seuraavalle hakutulossivulle, vierittää toista hakutulossivua kerran, klikkaa tavaramerkkilakilinkkiä “10.1.1964” ja haki selaimella "4 §":ää ja vieritti sivua nähdäkseen pykälän. Vertaan Finlexin (http://www.finlex.fi) ja Suomenlaki.comin (http:// www.suomenlaki.com) tehokkuutta Lakiviite-käyttötilanteella. Finlex Käyttötilanteen työnkulku Finlexissä on sama kuin käyttötilanteen toteuma, koska käyttötilanteessa käyttäjä käytti Finlexiä. 36 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää Mekaaninen kuorma on 15. Muistikuorma on 0. Suomenlaki.com Käyttötilanteen työnkulku on seuraava: Käyttäjä avaa selaimeen Suomenlaki.comin, kirjoittaa hakukenttään “tavara”, valitsee toisen osuman ja klikkaa sisällysluettelosta kohtaa “4 §”. Mekaaninen kuorma on 4. Muistikuorma on 0. 3.2.3. Johtopäätöksiä Sekä Toisun että lakipalveluiden tapauksessa on ilmiselvää, että määritellyn tehokkuusjärjestyksen puitteissa GUIDella määritetyt sovellukset ovat merkittävästi tehokkaampia kuin muilla tavoilla määritellyt sovellukset. 37 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää 4. Guided-flow Ohjelmistoyritys Reaktorilla on viimeisen viiden vuoden aikana (vuosina 2005– 2010) toteutettu sisäisissä ja asiakashankkeissa noin 30 sovellusta GUIDemäärittelyn pohjalta. Toteutustyötä GUIDe-määrittelyjen pohjalta on tehty kahdella eri tavalla, Guide-Scrumilla ja Guided-flow’lla. Guide-Scrum on näistä kahdesta pidempään harjoitettu tapa. Guided-flow on Reaktorilla hiljalleen saamassa jalansijaa Guide-Scrumilta: viimeisimmät viisi hanketta, joissa on ihmiselle tarkoitettu käyttöliittymä, on toteutettu käyttäen Guided-flow’ta. Yhtään uutta Guide-Scrum-hanketta ei ole aloitettu vuonna 2010. Määrittely- ja toteutusmenetelmien historia Reaktorilla vuodesta 2004 eteenpäin on karkeasti seuraava: • Hankkeen toteutusprosessi on Scrum ja määrittelyt on tehty perinteisillä tavoilla, esim. käyttäjätarinoina, sanallisina kuvauksina, rautalankamalleina jne. • Vuonna 2005 preferoiduksi määrittelymenetelmäksi valitaan GUIDe. Hankkeiden toteutusprosessi on pääasiassa Scrum. Tätä yhdistelmää kutsutaan Guide-Scrumiksi. Tämä on pitkään vallitseva metodi Reaktorin hankkeissa. • Vuonna 2008 eräässä asiakashankkeessa kokeillaan työskentelyä ilman sprinttejä. Ko. hankkeen määrittelyt on tehty GUIDella. Sprinteistä luopumisesta saadaan hyviä kokemuksia, ja Reaktorin toiminnallisten määrittelijöiden toimesta alkaa uusien hankkeiden puitteissa yrityksen ja erehdyksen kautta Scrumin käytäntöjen validiuden tutkiminen. • Tutkimuksen avuksi otetaan syksyllä 2008 lean-ajattelun käsitteitä, minkä myötä käytettävien menetelmien validiuden tutkiminen on aiempaa systemaattisempaa. Lean-käsitteiden käyttöönottoa voidaan pitää Guidedflow’n systemaattisen kehityksen alkupisteenä. Guided-flow on adoptoinut monia Scrumin käytäntöjä ja käsitteitä, mutta myös hylännyt Scrumin olennaisia osia. Hyviä kokemuksia Guided-flow'sta on yhden tiimin ja yhden työlistan hankkeista, mutta sen toimivuudesta tai toimimattomuudesta useiden tiimien hankkeissa ei ole merkittävää kokemusta. Tässä kappaleessa analysoin molempia tapoja ja etsin syitä, miksi Guidedflow’ta nykytietämyksellä preferoidaan toteutusvaiheen menetelmänä. 38 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää 4.1. Guide-Scrum ja sen ongelmat Scrumin suosittama tapa jäsentää ja kommunikoida kehitettävän sovelluksen toiminnallisuuksia perustuu käyttäjätarinoihin (Schwaber et Sutherland 2009). Guide-Scrum on käytännössä Scrum, jossa käyttäjätarinat on korvattu työlistalla, joka muodostetaan purkamalla GUIDe-prosessilla tuotettu käyttöliittymän kuvaus toiminnallisuuksiksi. GUIDen ja Scrumin yhdiste on todettu Reaktorin hankkeissa monella tavalla ongelmalliseksi. Esitän alla havaitut ongelmat ja esitän niihin löydetyt ratkaisut seuravassa aliluvussa. • Tuotteen työlistan omistajuus on hajanainen: vaikka alkuperäinen työlista sisältää vain käyttöliittymän kuvauksesta peräisin olevia toiminnallisuuksia, myös toteuttajat ja tuoteomistaja lisäävät työlistaan omasta näkökulmastaan relevantteja toiminnallisuuksia. Työlistassa on toiminnallisia, teknisiä ja liiketoiminnallisia käsitteitä, jotka ovat keskenään erilaatuisia ja usein (priorisointimielessä) vertailukelvottomia. • Sprintin suunnittelut ovat osallistujien kokemuksen mukaan uuvuttavia ja usein ohkaisia anniltaan: suunnittelut venyvät usein kokonaisen päivän pituisiksi eivätkä ne tarjoa juurikaan uutta relevanttia informaatiota tehtävistä toiminnallisuuksista. • Sprinttiin otetut toiminnallisuudet pyritään toteuttamaan, koska niiden toteuttamista on pidetty realistisena tavoitteena sprintin suunnittelussa. Tämä aiheuttaa tyypillisesti sprintin loppuvaiheissa ylitöiden tekemistä tai laadusta lipsumista. Kiireessä toiminnallisilta määrittelijöiltä kysytään “Kelpaako tämä?”, tai joskus ei edes kysytä ja toteuttajat toteavat itse toiminnallisuuden valmiiksi. Valmiin määritelmä on hyvin hutera. • Kun sprintin suunnittelussa otetaan sprintin työlistaan tuotteen työlistan viisi ylimpänä olevaa toiminnallisuutta, saatetaan sprintin aikana tehdä ensimmäiseksi viidenneksi tärkein ja jättää ensimmäinen tekemättä. Sprintin sisällä hukataan alkuperäinen (tuotteen työlistan mukainen) järjestys. • Asiat eivät tule sprintin puitteissa valmiiksi, vaan ne valuvat seuraaviin sprintteihin. Seuraavan sprintin sisältö on tyypillisesti kasa edellisen sprintin keskeneräisiä toiminnallisuuksia ja muutama uusia. Etenemistä on vaikea seurata ja hallita. 39 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää • Kun toiminnallisuus valmistuu, sitä ei tyypillisesti julkaista ennen kuin sprintti loppuu. 4.2. Guide-Scrumin ongelmien korjaaminen leankäsitteiden avulla Edellä kuvatun konfiguraation puutteiden korjaaminen lean-ajattelun näkökulmasta aloitti Guided-flow-menetelmän muodostumisen. 4.2.1. Työlistan sisältö vastaamaan käyttäjien tarpeita Työlistan sisältö ja prioriteetti pitää saada pull-periaatteen mukaiseksi. Toiminnallinen määrittely tuottaa luotettavaa tietoa siitä, mitä käyttäjät tarvitsevat. Toteuttamalla vain sitä, mitä käyttäjät tarvitsevat, tehdyt investoinnit ovat mahdollisimman hyviä. Tuoteomistajana (ja täten työlistan omistajana) tulee olla asiakkaan edustaja, jolla on toiminnallisen määrittelijän tietämys käyttäjien tarpeista mahdollisimman hyvin sisäistettynä. Nimenomaan toiminnallisen määrittelijän tietämyksen huomioon ottaminen priorisointipäätöksissä on erilaista suhteessa aiempiin toimintatapoihin. Priorisointipäätösten tekeminen huomioimatta toiminnallisen määrittelyn aikana tehtyjä havaintoja on Wardin tietämyshukkamallin (Ward, 2007) mukaan toiveajattelua. On huomattava, että yksin toiminnallisella määrittelijällä ei voi olla priorisointivastuuta, koska hänellä tyypillisesti ei ole riittävää tietämystä liiketoiminnallisista prioriteeteista. 4.2.2. Sprintin suunnittelu pois Scrumiin liittyvä sprintin suunnittelu on lean-periaatteiden vastainen: Suunnittelussa jaetaan tietämystä toiminnallisuuksista, jotka • tulevat työn alle mahdollisesti sprintin loppupuolella, mikä voi olla viikkojen päässä, jolloin ihmiset ehtivät unohtaa asioita tai hankittu tietämys saattaa olla vanhentua • eivät tule työn alle ollenkaan, jos liiketoiminnalliset prioriteetit muuttuvat tai sprintti loppuu kesken. Sprintin suunnittelulla luodaan lean-ajattelun näkökulmasta tarpeetonta varastoa. Johtopäätös on poistaa sprintin suunnittelu ja käydä läpi vain seuraavaksi työn alle tuleva toiminnallisuus pull-periaatteella. 40 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää 4.2.3. Toiminnallinen katsaus valmiin määritelmäksi Muri-hukkakäsitteen näkökulmasta epäselvä valmiin määritelmä tarkoittaa työn tuloksen standardiehdon puuttumista. Tämän hukan saa eliminoitua määrittelemällä valmiin määritelmäksi toiminnallisen katsauksen läpäisemisen: työn tulos vastaa hyödylliseksi todettua käyttöliittymäratkaisua. Tämä valmiin määritelmä voisi hyvinkin olla käytössä myös Guide-Scrumissa, mutta sen noudattamista vaikeuttaa mm. vakiomittainen kehityssykli. 4.2.4. Sprintin käsite pois Sprintin käsitteen poistamiseen on useita syitä. • Sprintin lopun lähestyessä tavoitteet halutaan saavuttaa, jolloin on taipumusta tehdä ylitöitä tai tinkiä laadusta (kuvat 9 ja 10). Ylitöiden tekeminen ja laadusta tinkiminen ovat mura-hukkaa. Taipumus tempoiluun ja kompromissien tekoon saadaan poistettua luopumalla keinotekoisesta aikarajasta: työtä voidaan tehdä aina standardimäärä päivässä ja toiminnallisuus on valmis kun se on valmis standardiehdon mukaan (kuva 11). Keskeneräistä ei siirretä valmiiksi, koska sprintin loppumisen painetta ei ole. Työn siirtäminen sprintistä toiseen myös lisää muri-hukkaa: työn tekemisessä on enemmän poikkeustilanteita, jolloin työn standardi on heikompi. • Kun sprintin käsite poistetaan, tuotteen työlistan prioriteettia kunnioitetaan: työn alle otetaan aina työlistan ylin ominaisuus. • Etenemistä on hyvin helppo seurata, koska oikein tehdyn toiminnallisen katsauksen jälkeen asiat ovat todella valmiita. • Sprintissä valmistuneet toiminnallisuudet, jotka julkaistaan sprintin lopuksi, muodostavat tarpeettoman varaston. Kun luovutaan sprintin käsitteestä ja vahvistetaan valmiin määritelmää lisäämällä ehdoksi tuotantoonsiirto, (leanajattelusta tuttua) tarpeetonta varastoa käyttöönottoa vaille valmiille toiminnallisuuksille ei tarvitse ylläpitää. 41 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää Kuva 9. Työtahdin tyypillinen vaihtelu sprintin Kuva 10. Sprintissä valmistuvien toiminnallisuuksien laadun tyypillinen vaihtelu sprintin sisällä. Kuva 11. Toiminnallisuuksien valmistuminen standardiehdon mukaan, kun sprintin käsite poistetaan. Guided-flow’n ensimmäisenä muotona voidaan pitää sellaista Guide-Scrumia, josta on poistettu lean-näkökulmasta haitallisista aikarajatuista kehitysjaksoista (eli sprinteistä) ja tulevaisuuden ennustamisesta ja ja reaalioptioiden rajaamisesta (eli sprinttien suunnittelusta). 4.3. Guided-flow tiivistetysti Guided-flow on kokoelma käytäntöjä, jotka on todettu hyödyllisiksi erityisesti lean-näkökulmasta ja luotetun neuvonantajan mallin näkökulmasta katsottuna. Guided-flow jatkaa siitä, mihin haitallisista käsitteistä riisuttu Guide-Scrum jää. 42 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää Esitän Guided-flow’n käytännöt ensin pääpiirteissään, sitten analysoin kutakin käytäntöä puoltavia syitä. • Toiminnalliset määrittelijät osallistuvat aktiivisesti ja hyvin aikaisessa vaiheessa uuden asiakkuuden luomiseen tähtäävään myyntityöhön. • Hankkeen aluksi tehdään GUIDe-menetelmällä toiminnallinen määrittely, mikä takaa tehokkaan tavan tutustua asiakkaan alaan ja liiketoiminnallisiin prioriteetteihin. • Toiminnallisen määrittelyn tuloksena syntyy käyttöliittymän määrittely, joka on erinomainen keskustelun väline. • Laadukas keskustelu asiakkaan ongelmista luo hyvin nopeasti luottamusta. • Käyttöliittymän läpikäynneillä asiakkaan kanssa saamme sitoutettua asiakasta yhteiseen tavoitteeseen. • Laadukas keskustelu, luottamus ja yhteiseen tavoitteeseen sitoutuminen helpottavat huomattavasti tavoitteeseen pääsyä. • Ennen varsinaista toteutustyötä toiminnallinen määrittelijä purkaa toteuttavan tiimin avustuksella käyttöliittymän kuvauksen tuotteen työlistaksi. • Kun tuotteen työlista on muodostettu, jokainen listan toiminnallisuus on sellainen, jonka kaikki hankkeen osapuolet ymmärtävät. • Kun työlista on asiakkaan ja toiminnallisen määrittelijän yhdistetyn tietämyksen valossa priorisoitu, toteutustyö voi alkaa. • Kun työt aloitetaan, toteuttajat ottavat parhaan näkemyksensä mukaan pienimmän määrän toiminnallisuuksia työn alle. Ennen toiminnallisuuden toteuttamisen aloittamista, toteuttajat käyvät toiminnallisuuden läpi toiminnallisen määrittelijän kanssa, jotta on selvää, mitä ollaan tekemässä. • Kun toiminnallisuus on tiimin mielestä valmis, se toimitetaan toiminnalliseen katsaukseen. Toiminnalliselle määrittelijälle toimitetaan tuotantoversio tai sitä riittävällä tarkkuudella vastaava versio ohjelmasta ja hän tutkii, onko toiminnallisuus toteutettu kuten oli määritelty. • Toiminnallisuuksia toteutetaan, kunnes saavutetaan ensimmäinen julkaisuraja. 43 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää • Tämän jälkeen ohjelma julkaistaan jokaisen toiminnallisuuden valmistuttua, ellei ole erityisiä syitä olla julkaisematta. • Näin jatketaan, kunnes asiakas ilmoittaa, että ohjelman kehitys voidaan lopettaa. 4.4. Guided-flow yksityiskohtaisesti Toiminnalliset määrittelijät osallistuvat aktiivisesti ja hyvin aikaisessa vaiheessa uuden asiakkuuden luomiseen tähtäävään myyntityöhön. Tyypillisesti asiakas haluaa aloittaa asiakassuhteen tilaamalla täsmäratkaisun itse tunnistamaansa tai kokemaansa ongelmaan. Tällöin työskennellään luotetun neuvonantajan mallin ensimmäisellä tasolla, palvelun tarjoamiseen perustuvan asioinnin tasolla (Maister 1988). Tämä on luonnollista, kun luottamusta ei ole vielä kerääntynyt ihmisten välillä. Usein asiakkailla on kiire, minkä myötä asiantuntijalla voi olla kova paine toteuttaa asiakkaan idea tai tarjota pikaisesti hahmoteltu vaihtoehtoinen ratkaisu. Tässä kohtaa hedelmällisempi lähtökohta on noudattaa luotetun neuvonantajan mallin ohjeita: asiantuntijat kuuntelevat asiakkaan näkemyksiä ongelmasta ja sen ratkaisusta, kysyvät avoimia kysymyksiä ja selvitettävät, mikä tässä tapauksessa on asiantuntijan näkökulmasta erilaista verrattuna heidän aikaisempiin asiakkuuksiinsa. Tyypillisesti jo näitä neuvoja noudattamalla asiakas on valmis antamaan asiantuntijoille mahdollisuuden esittää vaihtoehtoinen lähestymistapa, Guidedflow, tietysti sillä varauksella, että se soveltuu asiakkaan ongelmaan. Jos Guided-flow on asiakkaan mielestä alustavasti järkevä tapa lähestyä ongelmaa, keskusteluja asiantuntijoiden ja asiakkaan välillä jatketaan. Jos keskusteluiden myötä päädytään ratkaisemaan asiakkaan ongelmaa Guided-flow’lla, jatketaan seuraavaan vaiheeseen. Guided-flow’n alkupäässä on GUIDe-mallin mukainen käyttäjätarkkailu. Usein asiakas on tehnyt heikkolaatuisia käyttäjähaastatteluja, joissa käyttäjien todelliset tavoitteet ovat tyypillisesti selvittämättä. Tyypillisesti asiakas pitää näiden käyttäjähaastatteluiden tietosisältöä validina ja täten arvokkaana. Asiakas on sortunut Wardin tietämyshukkamallin mukaiseen toiveajatteluun: tehtyjen käyttäjähaastattelujen pohjalta ollaan valmiita etenemään seuraavaan vaiheeseen, vaikka edellytyksiä siihen ei GUIDe-määrittelijöiden mielestä ole. Alustavan luottamuksen puitteissa asiakkaalta pyydetään lupa suorittaa käyttäjätarkkailut uudestaan. Jos lupa saadaan, alkaa GUIDe-prosessin ensimmäinen vaihe. 44 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää Hankkeen aluksi tehdään toiminnallinen määrittely, jonka myötä toiminnalliset määrittelijät saavat tietystä näkökulmasta erittäin syvällisen näkemyksen asiakkaan ongelmiin. Tyypillisesti toiminnalliset määrittelijät ymmärtävät asiakastaan paremmin, mikä ongelma tarvitsee ratkaisun, ja lähes aina (ellei aina) toiminnalliset määrittelijät tietävät paremmin, miten ongelma kannattaa ratkaista. Toiminnallinen määrittely menetelmänä tarjoaa erittäin tehokkaan tavan tutustua asiakkaan erikoisalaan syvällisesti. Käyttäjätarkkailuissa keskitytään yleisen työnkulun lisäksi systemaattisesti ja hyvin tarkasti työnkulkujen yksityiskohtiin, jolloin toiminnallisille määrittelijöille kertyy usein sellaista detaljitason tietämystä käyttäjien ongelmista, josta asiakas ei tyypillisesti ole edes tietoinen. Asiakas arvostaa suuresti sitä, että asiantuntijat ovat tutustuneet aiheeseen perinpohjaisesti ja osaavat tuoda aiemmin pimentoon jääneitä asioita esiin. Tyypillisesti asiakkaalla on huterahko tietämys omien asiakkaidensa (eli käyttäjien) todellisista tarpeista. Tässä on hyvä erottaa, mitä käyttäjä haluaa (tai on ilmoittanut haluavansa) ja mitä käyttäjä tarvitsee. Uuden informaation tarjoaminen käyttäjistä lisää toiminnallisten määrittelijöiden ja asiakkaan välistä luottamusta. Käyttäjätarkkailuissa kerääntyy myös tietämystä liiketoiminnallisista prioriteeteista: mihin ongelmiin on arvokkainta löytää ratkaisu? Kun riittävän monta tarkkailua on suoritettu, toiminnalliselle määrittelijälle syntyy alustava tietämys siitä, mitkä asiat ovat kriittisimpiä tai toistuvat usein. Tyypillisesti asiakkaalla ei ole tällaista tietämystä, joten he ovat varsin kiinnostuneita keskustelemaan aiheesta toiminnallisen määrittelijän kanssa. Jälleen toiminnalliset määrittelijät tarjoavat uutta informaatiota, tällä kertaa siitä, mitä asiakkaan asiakkaat kokevat arvokkaaksi. Laadukas keskustelu asiakkaan ongelmista luo hyvin nopeasti luottamusta ja sitoutumista yhteiseen tavoitteeseen. Mitään ei tarvitse vielä ratkaista. Toiminnallisen määrittelyn tuloksena syntyy käyttöliittymän kuvaus, joka on erinomainen keskustelun väline. Kyseessä on konkreettinen kuvaus tehtävästä tietokoneohjelmasta, jota on helppo kommentoida ja josta on helppo löytää mahdolliset puutteet. Luotetun neuvonantajan mallin mukaan luottamuksen rakentamisen kannalta on oleellista, että asiantuntijat eivät esiinny kaikkitietävinä, vaan pyytävät apua, kun eivät tiedä tai eivät ole varmoja (Maister 1988). Toiminnallisen määrittelyn hyödyllisyysläpikäynnit antavat toiminnallisille määrittelijöille mahdollisuuden 45 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää pyytää apua asiakkaalta ja varmistaa, että he ovat ymmärtäneet asiakkaan ongelman oikein detaljitasolla. Myös tämä osaltaan lisää luottamusta ja läpinäkyvyyttä prosessiin. Ennen varsinaista toteutustyötä toiminnallinen määrittelijä purkaa toteuttajien avustuksella käyttöliittymän kuvauksen tuotteen työlistaksi. Työlistan käsite on lainattu suoraan Scrumista. On erityisen tärkeää, että nimenomaan toiminnallinen määrittelijä johtaa tätä purkutyötä. Toiminnallisen määrittelijän johdolla syntynyt työlista sisältää vain käyttäjän kannalta relevantteja toiminnallisuuksia eli toiminnallisuus saadaan valmiiksi, sovellus on jollain tavalla hyödyllisempi käyttäjälle käyttöliittymäratkaisun suunnittelutyön pohjana olleiden käyttötilanteiden valossa. Kun työlista on muodostettu, jokainen toiminnallisuus on sellainen, jonka kaikki hankkeen osapuolet ymmärtävät. Osapuolia ovat • asiakas, • toiminnallinen määrittelijä ja • toteuttajat. Kun toiminnallinen määrittelijä on johtanut työlistan muodostusta ja tarkkaillee työlistalle lisättäviä toiminnallisuuksia, refaktorointi- ja tekniset toiminnallisuudet pysyvät pääasiassa pois työlistalta. Tämä on hyvä asia, koska tällöin toiminnallisuudet ovat sellaisia, joille asiakkaan on suhteellisen helppo muodostaa prioriteetteja. Asiakkaalle on tyypillisesti mahdotonta muodostaa valistuneita näkemyksiä esim. teknisen velan maksun ja toiminnallisuuksien toteuttamisen suhteesta. Lähes yksinomaan huonoja kokemuksia on siitä, että asiakas priorisoi teknisen työn ja toiminnallisuuksien toteuttamisen välillä. Kun työlista on asiakkaan ja toiminnallisen määrittelijän yhdistetyn tietämyksen valossa priorisoitu, toteutustyö voi alkaa. Työlistan priorisointi on jatkuva prosessi, ja tietyn ajan kuluttua priorisointia auttavat myös toteuttajat, koska he osaavat toteutettujen itemien valossa antaa arvioita tulevien itemien vaativuudesta. Hyvin harvoin asiakkaat vaativat työmääräarvioita toiminnallisuuksille työlistan muodostuksen yhteydessä. Myös tuoteomistajan käsite on lainattu Scrumista. Tuoteomistaja on asiakkaan edustaja, jota toiminnallinen määrittelijä avustaa merkittävästi. 46 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää Priorisoinnin jälkeen vedetään asiakkaan ja toiminnallisen määrittelijän tietämyksen pohjalta ensimmäisen julkaisun raja. Ensimmäisen julkaisun raja pyritään vetämään siihen kohtaan, jossa ohjelma on käyttäjilleen hyödyllinen tai parempi suhteessa kilpailijoihin. Perustuen käyttöliittymän kuvaukseen, alustaviin työmääräarvioihin ja aikatauluvaatimuksiin muodostetaan toteutustiimi. Kriittistä on lähinnä taitoportfolio ja koko. Tekniikat valitaan alustavasti kokeneimpien ohjelmoijien suositusten perusteella. Muun muassa tekniikkavaatimusten pohjalta valitaan toteuttajat. Aikataulujen ja työmääräarvioiden pohjalta päätetään tiimin koko. Toki tiimin kokoonpanoa muutetaan hankkeen edetessä ja liiketoimintaympäristön muuttuessa. Kun työt aloitetaan, tiimi ottaa parhaan näkemyksensä mukaan pienimmän määrän toiminnallisuuksia työn alle. Tämä on linjassa lean-ajattelun tarpeettomien varastojen minimoinnin kanssa. Ottamalla pienin mahdollinen määrä toiminnallisuuksia työn alle WIP (work in progress, keskeneräinen työ) on minimissään. Kun toiminnallisuus tulee työn alle, se käydään toiminnallisen määrittelijän kanssa läpi, jotta on selvää, mitä ollaan tekemässä. Myös tässä lean-ajattelu on läsnä: ei kannata käydä läpi muita kuin työn alle tulevia toiminnallisuuksia, muutoin luodaan tarpeetonta varastoa. Lisäksi ko. varasto mätänee nopeasti: ihmiset unohtavat asioita. Scrumista on lainattu myös vaatimus valmiin määritelmästä. Myös Guidedflow’ssa jokainen toiminnallisuus on joko valmis tai ei-valmis. Ei-valmiilla toiminnallisuuksilla on kolme erilaista tilaa: • ei aloitettu, • työn alla ja • toiminnallisessa katsauksessa. Ei aloitettu tarkoittaa sitä, että tiimi ei ole tällä hetkellä ole toteuttamassa tätä toiminnallisuutta. Työn alla tarkoittaa sitä, että tiimi toteuttaa tällä hetkellä tätä ominaisuutta. 47 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää Toiminnallisessa katsauksessa oleva toiminnallisuus on tiimin näkemyksen mukaan valmis. Jos toiminnallinen määrittelijä toteaa toiminnallisuuden oikein toteutetuksi, toiminnallisuudesta tulee valmis. Kun toiminnallisuus tulee toiminnalliseen katsaukseen, toiminnalliselle määrittelijälle toimitetaan tuotantoa vastaava versio ohjelmasta ja hän katsoo, onko toiminnallisuus toteutettu kuten oli määritelty. Jos mitään huomioita ei tule, toiminnallinen määrittelijä merkitsee toiminnallisuuden valmiiksi. Jos toteutuksessa on jotain huomautettavaa, ko. huomio kommunikoidaan toteuttajille ja toiminnallisuus siirretään takaisin työn alla -tilaan. Näin toimitaan, kunnes toiminnallisuus on toteutettu kuten oli määritelty toiminnallisen määrittelijän näkemyksen mukaan. Lean-ajattelun mukaisesti kaikella työllä on toteuttajien näkökulmasta selkeä standardiehto, toiminnallinen katsaus. Jotta arvoketju ei katkea, toiminnallinen katsaus pyritään tekemään mahdollisimman nopeasti. Kuvassa 12 on pieni siivu Product Backlog Tool -nimisen sovelluksen työlistasta. Toiminnalliselle määrittelijälle on kerääntynyt joukko toiminnallisuuksia katsaukseen, mikä on epäoptimaalista: arvoketju on katkennut. Toteuttajat ovat tehneet kaikki työn alla olevat toiminnallisuudet näkemyksensä mukaan valmiiksi eivätkä ole aloittaneet seuraavien toiminnallisuuksien toteuttamista. Näkyvissä olevista 20 toiminnallisuudesta vain kaksi on teknisiä: toiminnallisuudet 608 ja 614: vaihtoehtoisen toteutustekniikan evaluaatio (608) ja viestintäprotokollien muuttaminen (614). Ideaalitilanteessa tällaisia toiminnallisuuksia ei ole työlistassa, mutta käytännössä niitä on silloin tällöin. Tärkeää on kuitenkin pitää ne minimissä, koska tekninen toiminnallisuus on hyvin harvoin tuoteomistajan näkökulmasta verrattavissa käyttäjän kannalta relevantteihin toiminnallisuuksiin. Jos teknisiä toiminnallisuuksia on liikaa, työlistan priorisointi muodostuu hyvin vaikeaksi tuoteomistajalle. 48 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää Kuva 12. Työlista, jossa on Guided-flow’n määrittelemät tilat. Teknisten toiminnallisuuksien poissa pitäminen työlistasta auttaa myös siinä, että toiminnallisen katsauksen prosessi on toimiva ja tehokas. Toiminnallisella määrittelijällä ei ole tyypillisesti motiivia tai halua ottaa kantaa toteutuksen yksityiskohtiin (esimerkiksi viestintäprotokolliin). Tarkasta vastuurajasta pyritään pitämään kiinni, koska joskus, esimerkiksi vaikeiden toiminnallisuuksien kohdalla, toteuttajilla on taipumusta luistaa käyttöliittymäratkaisun mukaan toteuttamisesta perustuen implementaatiovaikeuksiin: “Tämä on liian vaikea ja kallis toteuttaa, koska 49 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää käyttämämme tekninen framework ei tue tällaista ratkaisua luontevasti”. Kun toiminnallisen määrittelijän kanssa teknisistä detaljeista keskustelu ei ole tavanomaista, käyttöliittymäratkaisun paikallisista toteutusvaikeuksista valitetaan vähemmän. Tällöin myös teknisesti vaikeimmat toiminnallisuudet saadaan toteutettua käyttöliittymäratkaisun mukaisesti. Tyypillisesti asiantuntevat toteuttajat osaavat itse balansoida tarvittavan määrän refaktorointia ja teknista tekemistä toiminnallisuuksien toteutuksen lomaan. Tähän ei tarvita asiakkaan tai toiminnallisen määrittelijän mielipidettä, eikä heillä myös ole kompetenssia ottaa kantaa tällaisiin asioihin. Toiminnallisuuksia toteutetaan, kunnes saavutetaan ensimmäinen julkaisuraja. Jos mitään erityistä syytä ei ole, ohjelma julkaistaan käyttäjille. Tämän jälkeen ohjelma julkaistaan jokaisen toiminnallisuuden valmistuttua, ellei ole erityisiä syitä olla julkaisematta. Julkaisematta jättäminen on periaatteessa leanajattelun vastaista, koska julkaisemattomat toiminnallisuudet muodostavat tarpeettoman varaston. Täten on tarkkaan analysoitava syitä, miksi toiminnallisuuksia ei julkaista heti niiden valmistuttua. Näin jatketaan, kunnes tuoteomistaja ilmoittaa, että ohjelman kehitys voidaan lopettaa. Tämä on myös lean-ajattelun mukaista. Toiminnallisuuksia toteutetaan pull-, ei push-periaatteen mukaan. Guided-flow'n peruskäytäntöjen lisäksi toteuttajat soveltavat muita hyväksi todettuja käytäntöjä, esimerkiksi • daily, • retrospektiivi, • toteuttajien aloitteesta tehtävän työlistan läpikäynti, • pariohjelmointi jne. 4.5. Syitä Guided-flowʼn suosiolle Guided-flow'n mukaan työtä tehdessä asiakkaan kanssa kommunikointi ja oikeiden asioiden tekeminen on sekä toiminnallisten määrittelijöiden ja toteuttajien mielestä vaivattomampaa ja varmempaa kuin Scrum-pohjaisilla käytännöillä. Tärkeimmät asiat menestyksekkään ohjelmistokehityshankkeen läpiviemiseksi ovat Guided-flow-hankkeisiin osallistuneiden (Reaktor 2010a) mielestä 50 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää 1. riittävän laadukkaan keskusteluyhteyden muodostaminen asiakkaaseen, 2. relevantin asian tunnistaminen: simulaatiopohjainen toiminnallinen määrittely, 3. selkeä ja riittävä valmiin määritelmä: toiminnallinen katsaus ja tuotantoon vienti ja 4. inkrementaalinen, ei iteratiivinen, toteutustapa: pieniä paloja yksi kerrallaan valmiiksi bisnesinformaation sanelemassa järjestyksessä. Scrum ei itsessään millään tavalla ota huomioon luottamuksen merkitystä hankkeiden onnistumisessa. Luottamuksen rakentaminen riippuu puhtaasti siitä, miten hankkeen asiantuntijat suhtautuvat luottamuksen rakentamiseen. Guided-flow’ssa luottamuksen rakentaminen on osa prosessia, koska ilman sitä tärkeää tietoa jää vaihtamatta ja puitteet riittävän esiselvitystyön eli GUIDemäärittelyn tekemiselle eivät ole kunnossa. Hankkeen alussa hankittu luottamus on hyödyllinen koko hankkeen elinkaaren ajan. Toteuttajat arvostavat sitä, että sovelluksen toiminnallisuuksien oikeellisuuden vastuu ei ole heillä, vaan käyttöliittymäasiantuntijoilla. Tämä vastuunjako vapauttaa toteuttajat keskittymään omaan erikoisalaansa eli toteuttamiseen. Systemaattinen hukan eliminointi kaikesta toteutusvaiheen työstä tekee Guided-flow’sta toteuttajien ja asiakkaan näkökulmasta tehokkaamman, luotettavamman ja ennustettavamman tavan toteuttaa määrittelyjen pohjalta tietokonesovelluksia. Modernissa ohjelmistokehityksessä nimenomaan tehokkuus (ajan ja kulujen suhteen), luotettavuus (tasainen eteneminen) ja ennustettavuus (etenkin kulujen suhteen) ovat arvostettuja piirteitä. Selkeää standardiehtoa toteuttajien työlle arvostetaan paljon. Ei ole tavatonta, että Scrum-vetoisissa hankkeissa valmiin määritelmä on hutera. Guided-flow tarjoa erittäin jämerän työn standardiehdon toteuttajan näkökulmasta: valmiin määritelmä ei tyypillisesti muutu hankeen aikana eikä hankkeiden välistäkään variaatiota standardiehdossa esinny kovin paljon; erot tulevat lähinnä tuotaantoonvientiin liittyvissä yksityiskohdissa. 4.6. Havaittuja puutteita Guided-flowʼssa Lean-ajattelun myötä monia asioita on saatu tehostettua GUIDe-määrittelyn toteutuksessa toimivaksi sovellukseksi. Paras tietämys tällä hetkellä on edellä esitetty Guided-flow, mutta tälläkin hetkellä menetelmässä on lean-ajattelun 51 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää näkökulmasta monia käytännön puutteita ja tehottomuuksia, joita ei ole saatu vielä ratkaistua. Dokumentoin alla tämän työn puitteissa havaitsemani puutteet. 4.6.1. Riippuvuus toiminnallisesta määrittelijästä Product backlog toolin (PBT:n) (kuva 13) kehityshistoria on hyvä esimerkki siitä, kuinka riippuvainen Guided-flow on toiminnallisesta määrittelijästä. PBT on Reaktorin sisäinen hanke, jossa kehitetään työkalua ohjelmistohankkeiden työlistojen hallintaan. PBT:n määrittely on tehty GUIDella ja sen toteutus on ollut lähes alusta asti Guided-flow’n periaatteiden mukaista. Kuva 13. Product backlog tool. PBT:n kehitys aloitettiin alkuvuodesta 2008 ja ensimmäinen julkaisu tuli loppuvuodesta 2008. Tämän jälkeen Guided-flow’n mukaan sovelluksesta pitäisi tulla tiheään uusia julkaisuja, periaatteessa jokaisen valmistuvan toiminnallisuuden myötä. Näin ei kuitenkaan käynyt; ensimmäisen julkaisun jälkeen tuli vain neljä julkaisua 50 viikossa. Tämän jälkeen seuraavan 30 viikon sisällä tuli 15 julkaisua. Julkaisutahdissa tapahtui siis dramaattinen muutos, aluksi yksi julkaisu keskimäärin 13 viikossa, lopuksi yksi julkaisu keskimäärin kahdessa viikossa. 52 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää Kuvassa 14 on PBT-hankkeeseen käytetyt työtunnit ja julkaisut aikajanalla. Työtunnit on jaoteltu toiminnalliseen määrittelyyn ja toteutustyöhön. Julkaisut on merkitty harmailla pystyviivoilla. Kuva 14. PBT:n työtunnit ja julkaisut. Tulkitsen graafia seuraavasti: Toteutus alkaa viikolla 12/2008 ja toiminnallinen määrittelijä hyväksyy toiminnallisuuksia sitä mukaa kun toteuttajat saavat toiminnallisuuksia mielestään valmiiksi. Ensimmäinen julkaisu tehdään viikolla 48/2008. Tälloin toiminnallinen määrittelijä joutuu jättämään hankkeen muiden kiireiden vuoksi. Toteuttava tiimi saa tehtyä toiminnallisen määrittelijän poissaolon aikana vain yhden julkaisun 14 viikon aikana. Viikoilla 12–22/2009 toiminnallinen määrittelijä on hankkeen käytettävissä, jolloin saadaan kolme julkaisua tehtyä. Tämän jälkeen toiminnallinen määrittelijä on jälleen muiden kiireiden takia yhdeksän viikkoa poissa hankkeesta; tänä aikana ei saada yhtään julkaisua tehtyä. Tämän jälkeen toiminnallinen määrittelijä on jälleen hankkeen käytettävissä, jolloin saadaan tehtyä 15 julkaisua 30 viikossa. Toiminnallisen määrittelijän läsnäolo ja työpanos näyttävät vaikuttavan siis oleellisesti siihen, kuinka paljon hankkeessa saadaan toimitettua loppukäyttäjälle hyödyllisiä inkrementtejä. Käytännössä toiminnallisen määrittelijän olisi sitouduttava koko hankkeen elinkaaren ajaksi, jotta hyödyllisiä inkrementtejä saataisiin tasaisena virtana 53 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää käyttäjille. Tilanne tällä hetkellä ongelmallinen Reaktorilla, koska toiminnallisia määrittelijöitä on vain muutama. Ongelmaan ei ole vielä keksitty kestävää ratkaisua. Ward esittää seuraavanlaisen ajatuksen: tietämystä, vastuuta, toimintaa ja palautetta ei kannata erottaa toisistaan, koska silloin esiintyy tietämyshukasta johtuvia ongelmia (Ward, 2007). Guided-flow'n kontekstissa tämä tuntuu ilmenevän seuraavasti: • Tietämys toiminnallisen määrittelyn tuloksista (mm. käyttötilanteet, käyttöliittymäratkaisun logiikka) on pitkälti vain toiminnallisella määrittelijällä. • Vastuu (hankkeen onnistumisesta) on jaettu toiminnalliselle määrittelijälle ja toteuttajille. • Toiminnan (eli toteuttamisen) vastuu on pitkälti toteuttajilla. • Palaute kohdistetaan koko tiimille. Wardin termein Guided-flow’ssa on sisäänrakennettu tietämyshukkaa luova mekanismi. Seuraavia toimenpiteitä on ehdotettu tietämyshukan vähentämiseksi (Reaktor 2010b): • käyttötilanteiden tarkka läpikäynti kehittäjille, • kehittäjien ottaminen mukaan tarkkailuihin ja • simulointityö kehittäjien kanssa. Näillä toimenpiteillä toiminnallisen määrittelijän tiedossa olevia asioita saataisiin jaettua ainakin yhdelle kehittäjälle, jolloin toiminnalliseen määrittelijään liittyvä tietämyshukkariski pienenisi huomattavasti. On otettava huomioon, että kehittäjien ottaminen mukaan tarkkailuihin ja simulointityön tekeminen vaativat toiminnallisen määrittelyn perustekniikoiden hyvää hallintaa. Näitä toimenpiteitä ei ole vielä kokeiltu käytännössä. 4.6.2. Tutkivan testauksen käynnistyskulut Toiminnallisen määrittelijän tekemä toiminnallinen katsaus on käytännössä kriteeri sille, todetaanko toiminnallisuus valmiiksi. Toiminnallisessa katsauksessa toiminnallisuus todetaan toimivaksi tai toimimattomaksi 54 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää tyypillisiä työnkulkuja läpikäymällä. Vaikka kyseessä on huomattava parannus aiempiin työn standardiehtoihin, se ei edelleenkään ole riittävä. On tyypillistä, että valmiiksi todetussa toiminnallisuudessa huomataan virheitä epätavallisissa tilanteissa. Toiminnallisuuden oikeellisuus poikkeustilanteissa saadaan varsin hyvin varmistettua suorittamalla tutkivaa testausta. Tutkiva testauskaan ei aukottomasti todista toiminnallisuutta oikeaksi, mutta se vähentää dramaattisesti käyttäjien havaitsemia virheitä. (Wikipedia: Exploratory testing, Bach 2003) Guided-flow’n tämänhetkisestä työn standardiehdosta puuttuu uusille toiminnallisuuksille tehtävä tutkiva testaus. Tämä johtuu tutkivien testaajien saatavuuden ja tarpeen epäjatkuvuudesta: tutkivia testaajia on vaikea saada paikalle silloin, kun heitä tarvitaan, ja tarve on huonosti ennustettava. Tämä ongelma on yleisemmin tunnettu puute just-in-timetuotantojärjestelmissä (Wikipedia: Mura). Koska just-in-time-järjestelmissä pyritään rakentamaan myös kaikki järjestelmän aliprosessit pull-ajattelun mukaiseksi, ongelmia tulee sellaisten komponenttien kohdalla, joissa toimitusaika, engl. lead time (Wikipedia: Lead time), on välttämättä pitkä tai komponentin valmistuksen aloittaminen on kallista. Tällöin ainoa asia, mitä voidaan tehdä, on yrittää ennustaa vaikeasti tai hitaasti valmistettavan komponentin tarvetta. Käytännössä tutkiva testaus suoritetaan Guided-flow’ssa prosessin ulkopuolella eli epäsäännöllisin väliajoin koko sovellukselle painottaen uusimpia valmiita toiminnallisuuksia. Tämä lähestymistapa on tietysti lean-ajattelun vastainen, koska se sekoittaa työn standardiehtoa: valmiiksi saatu toiminnallisuus saattaakin osoittautua keskeneräiseksi huomattavasti “valmistumista” myöhemmin. 4.6.3. Retrospektion ajoitus Scrumin eräs hyvä puoli on se, että siinä on hyvin luonteva paikka retrospektiolle: sprintin loppuminen. Kuten aiemmin on mainittu, Scrum nojaa empiirisen prosessikontrolliteoriaan, jolloin siihen on sisäänrakennettu mekanismi toiminnan parantamiseen. Guided-flow’ssa ei ole mitään vakiintunutta hetkeä, jona tiimin tulisi pitää retrospektiivi. Guided-flow’lla ei ole sisäänrakennettua tasaista rytmiä kuten 55 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää Scrumin sprintit. Käytännössä Guide-flow’ta käyttävät tiimit ovat pitäneet retrospektiivejä siinä pisteessä, kun kun tiimin jäsenistä tuntuu siltä, että on liian monta asiaa, joihin pitäisi puuttua. Tyypillisesti tämä on liian myöhäistä, sillä tällaisessa tilanteessa korjattavia asioita on niin paljon, että retrospektiivitilaisuuksissa käsiteltävien asioiden määrä on jo liian suuri, jotta edes tärkeimmiksi koettuja asioita ehdittäisiin fasilitoida hyödyllisiksi toimenpiteiksi. Yksi kehitysmahdollisuus on kokeilla retrospektiivien pitämistä jokaisen valmistuneen toiminnallisuuden yhteydessä, jolloin retrospektiivejä tulisi hyvin usein. Tätä ei ole vielä kokeiltu. Olisi tutkimisen arvoista, miten esimerkiksi Toyota-tavassa retrospektiot on järjestetty ja yrittää soveltaa sieltä hyväksi todettuja käytäntöjä ohjelmistokehitykseen Guided-flow’n puitteissa. 56 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää 5. Johtopäätökset Olen asettanut työssäni kaksi kysymystä: Ovatko GUIDe-määrittelyyn perustuvat sovellukset tehokkaampia kuin muilla tavoilla määritellyt sovellukset? Määritellyn tehokkuusjärjestyksen puitteissa GUIDella määritetyt sovellukset ovat huomattavasti tehokkaampia kuin muilla menetelmillä samaan ongelmaan määritellyt sovellukset. Seuraavat seikat kannattaa ottaa huomioon: • Tehokkuusvertailu on tehty vain kahdelle sovellusparille. Näin pienestä joukosta ei luotettavasti voi vetää vedenpitäviä johtopäätöksiä. • Vertailupareiksi on saatu “patologisia” tapauksia eli GUIDella määritellyn ja toimivaksi todetun sovelluksen vertailupariksi on saatu käytössä erittäin tehottomaksi todettuja sovelluksia. Tällöin tehokkuuserot ovat todella räikeitä. Mielenkiintoista olisi vertailla kahta käytössä todella hyväksi todettua sovellusta, joista toinen on määritelty GUIDella. • Määritetty tehokkuusjärjestys on johdettu GUIDen suunnitteluperiaatteista: mitä tehokkaampi ja suoraviivaisempi käyttöliittymä, sitä parempi se on. Menetelmä tuottaa suoraviivaisia ja tehokkaita käyttöliittymiä, mutta minkälainen yhteys suoraviivaisuudella ja tehokkuudella on käyttäjien kokemukseen? Jos yhteys on vahva, määritetty tehokkuusjärjestys ennustaa hyvin myös käyttäjien kokemuksen. Jos yhteys on heikko, tehokkuusjärjestyksen käsite ei välttämättä ole hyvä tapa mitata käyttöliittymien soveltuvuutta annettuihin tavoitteisiin. • GUIDe-määritettyjä hankkeita ei ole Reaktorin hankehistoriassa kertaakaan jouduttu uudelleenmäärittämään: sovelluksen alkuperäisen määrittelyn pohjalta on saatu aikaan sovellus, jonka käyttäjät ovat todenneet poikkeuksetta hyödylliseksi. Toteutusvaiheen aikana kertyvän lisäinformaation ja käyttäjäpalautteen pohjalta on jouduttu tekemään vain pieniä ja paikallisia muutoksia alkuperäiseen määrittelyyn. Muiden määrittelymenetelmien kanssa hyvinkin dramaattisia muutoksia on jouduttu tekemään, äärimmäisenä esimerkkinä Toisu. Tämä osaltaan tukee Reaktorin toiminnallisten määrittelijöiden kokemukseen perustuvaa näkemystä: GUIDemäärittely on systemaattinen tapa tuottaa hyviä käyttöliittymiä. 57 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää Mitkä syyt puoltavat Guided-flow’n mukaisia käytäntöjä hankkeissa, joissa toteutetaan GUIDe-määrittelyn pohjalta tietokonesovellus? • Prosessien täysin luotettava vertailu vaatisi käytännössä identtisten hankkeiden toteuttamista vertailtavien prosessien avulla. Tällöin variaatiot hankkeiden lähtökohdissa eivät voisi olla syynä erilaisille lopputuloksille. Tällaisia tilanteita on käytännössä hyvin vaikea järjestää. • Paremmin arvoa tuottava prosessi on taloudellisista syistä parempi, koska sijoitetulle pääomalle saadaan parempi tuotto. Jos luotetaan siihen, että leanajattelun mukaisesti toimiminen tuottaa prosesseja, jotka tuottavat enemmän arvoa kuin ei-leanit verrokit, systemaattisesti lean-periaatteiden mukaan parannettu eli leanattu prosessi on tuottaa enemmän arvoa kuin sellainen prosessi, jota ei ole systemaattisesti parannettu lean-periaatteiden mukaan. Koska Guided-flow on leanattu versio Guide-Scrumista, on hyvä syy luottaa siihen, että Scrum-flow tuottaa enemmän arvoa asiakkaille kuin Guide-Scrum. Tällöin taloudelliset syyt puoltavat Guided-flow’n käyttöä. • Myös toteuttajien preferenssiä voidaan pitää luotettavana indikaatiota prosessin tehokkuudesta: ne menetelmät ja prosessit, joissa toteuttajat kokevat olevansa tehokkaampia, ovat usein tehokkaampia arvon tuottamisessa. Tästä hyviä esimerkkejä ovat esimerkiksi Extreme programming (XP) ja Agile-liike, jotka ovat saaneet merkittävää jalansijaa ohjelmistotuotannon alalla. Kahden tutkimuskysymyksen lisäksi olen raportoinut Guided-flow’hun liittyviä ongelmia. • Riippuvuus toiminnallisesta määrittelijästä saattaa hyvinkin johtua vain siitä, että Reaktorilla on noin sataa kehittäjää, mutta vain kuusi toiminnallistä määrittelijää. Voi olla, että koko ongelmaa ei ole, jos riittävän usea reaktorilainen hallitsee riittävän hyvin toiminnallisen määrittelyn erikoistaidot. Sama saattaa päteä tutkivan testauksen käynnistyskuluihin: Reaktorilla on kolme tutkivan testauksen asiantuntijaa. Tämäkin ongelma saattaa poistua, jos riittävän moni reaktorilainen hallitsee tutkivan testauksen erikoistaidot. • Retrospektion ajoitus tuntuu olevan aidosti Guided-flow’hun sisäänrakennettu ongelma, jonka ratkaisu mitä luultavimmin vaatii erilaista lähestymistä. Kyseessä on vakava ongelma, koska sekä lean-ajattelussa että 58 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää Scrumissa korostetaan käytäntöjen jatkuvaa parantamista perustuen havaintoihin omasta toiminnasta. 59 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää 6. Yhteenveto GUIDe on vakiintunut hankkeiden määrittelymenetemäksi Reaktorilla, koska GUIDella määritellyt sovellukset eivät ole vaatineet merkittäviä muutoksia määritelmiin toteutusvaiheessa ja sovellukset ovat toimineet hyvin käyttäjien työn tukena julkaisun jälkeen. GUIDen paremmuutta suhteessa muihin menetelmiin on kuitenkin vaikea todistaa, koska se vaatisi tilastollisesti identtisiä hankkeita, joissa erona olisi vain määrittely- ja toteutusmenetelmät. Muutamien tapausten pohjalta ei voi aukottomasti vetää johtopäätöksiä paremmuudesta, koska ohjelmistokehityshankkeissa on myös monia muita asioita, jotka vaikuttavat lopputuloksen hyödyllisyyteen. Tehtyjen tehokkuusvertailujen pohjalta voi varovasti sanoa, että GUIDe tuottaa parempia käyttöliittymiä kuin sellaiset menetelmät, jotka eivät sisällä simulointiin perustuvaa suunnittelua ja testausta käyttäjien oikeiden käyttötilanteiden avulla. Tulos on vain alustava, koska vertailujen otos on hyvin pieni. Guided-flow’n jalansijan kasvaminen perustuu pitkälti määrittely- ja toteutustyötä tekevien reaktorilaisten hyviin kokemuksiin menetelmän käytöstä ja sijoitetun pääoman parempaan tuottoon tehokkaammassa prosessissa. Myös Guided-flow’n paremmutta on systemaattisesti vaikea todistaa. Syyt ovat samat kuin GUIDen paremmuuden argumentoinnissa. Kokemusten perusteella molemmat menetelmät tuntuvat olevan huomattavasti parempia kuin aiemmin käytetyt. Guided-flow eliminoi monta Guide-Scrumissa esiintyvää ongelmaa, mutta erityisesti retrospektion ajoituksen ongelma Guided-flow’ssa on merkittävä ratkaisematon ongelma, jota ei esiinny Guide-Scrumissa. 60 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää Viitteet Bach, 2003. Exploratory Testing Explained. www.satisfice.com/articles/etarticle.pdf. Viitattu 8.6.2010. Cohn, 2004. User Stories Applied: For Agile Software Development. Addison Wesley. ISBN 9780321205681. Deemer et al, 2009. The scrum primer. http://scrumtraininginstitute.com/ home/stream_download/scrumprimer. Viitattu 6.6.2010. Interacta, 2010. Interactan etusivu. http://interacta.fi/. Viitattu 7.6.2010. Järvenpää, 2006. Test-Driven Development. http://www.reaktor.fi/web/fi/ teknologia-ja-tutkimus/tdd. Viitattu 14.5.2010. Laakso et Laakso 2004. Hyvän käyttöliittymän varmistaminen GUIDeprosessimallilla. http://www.cs.helsinki.fi/u/salaakso/papers/GUIDesuomeksi.pdf. Viitattu 5.6.2010. Laakso et Latva-Koivisto, 2006. Käyttöliittymät. http://www.cs.helsinki.fi/u/ salaakso/papers/Kayttoliittymat-opetusmoniste-2006.pdf. Viitattu 5.6.2010. Lindström, 2006. Scrum. http://www.reaktor.fi/web/fi/teknologia-jatutkimus/scrum. Viitattu 14.5.2010. Maister, 2001. The Trusted Advisor. Free Press. ISBN 0743212347. Poppendieck et Poppendieck, 2003. Lean Software Development: An Agile Toolkit. Addison Wesley. ISBN 9780321150783. Reaktor, 2010a. Keskustelu aiheesta “Miksi preferoitte Guided-flow’ta?”. Keskusteluun osallistuivat Reaktorilta Jakub Järvenpää, Vesa-Matti Mäkinen, Karri-Pekka Laakso, Mikko Koponen, Miki Leskinen, Eero Anttila ja Joni Freeman. Keskustelu on käyty 3.5.2010. Reaktor, 2010b. Keskustelu aiheesta “Karpo-123-flow'n hand-offeihin liittyvät ongelmat”. Keskusteluun osallistuivat Reaktorilta Jakub Järvenpää, Samuli Karjula, Antti Mattila, Karri-Pekka Laakso ja Jari Mäkelä. Keskustelu on käyty 27.5.2010. Robinson et al., 2003. Requirements interaction management. http:// portal.acm.org/citation.cfm?id=857079. Viitattu 14.4.2010. 61 Diplomityö Tietokoneohjelman toteuttaminen GUIDe-määrittelyn pohjalta Jakub Järvenpää Rosenthal, 2008. Mura, muri (and muda) in heathcare. http:// theleanthinker.com/2008/01/29/mura-muri-and-muda-in-health-care/. Viitattu 7.6.2010. Schwaber et Sutherland, 2009. Scrum guide.http://www.scrum.org/ scrumguides. Viitattu 6.6.2010. Sutherland et Schwaber, 2007. The scrum papers: Nuts bolts, and origins of an agile process. http://scrumtraininginstitute.com/home/stream_download/ scrumpapers. Viitattu 6.6.2010. Takeuchi et Nonaka, 1986. The new new product development game. Harvard Business Review, 64(1):137–146, 1986. ISSN 00178012. VersionOne, 2008. The State of Agile Development. http:// www.versionone.com/pdf/3rdAnnualStateofAgile_FullDataReport.pdf. Viitattu 6.6.2010. Ward, 2007. Lean Product and Process Development. Lean Enterprises Inst Inc. ISBN 9781934109137. Wikipedia: Exploratory testing. http://en.wikipedia.org/wiki/ Exploratory_testing. Viitattu 6.6.2010. Wikipedia: Lead time. http://en.wikipedia.org/wiki/Lead_time. Viitattu 6.6.2010. Wikipedia: Lean software development. http://en.wikipedia.org/wiki/ Lean_software_development. Viitattu 6.6.2010. Wikipedia: Muda. http://en.wikipedia.org/wiki/Muda_%28Japanese_term %29. Viitattu 6.6.2010. Wikipedia: Mura. http://en.wikipedia.org/wiki/Mura_%28Japanese_term%29. Viitattu 6.6.2010. Wikipedia: Muri. http://en.wikipedia.org/wiki/Muri_%28Japanese_term%29. Viitattu 6.6.2010. Wikipedia: Toyota production system. http://en.wikipedia.org/wiki/ Toyota_Production_System. Viitattu 6.6.2010. 62
© Copyright 2024