Ketterien periaatteiden merkitys projektityössä Suvi Jentze-Korpi Helsinki 18.10.2012 Kandidaatintutkielma-kurssin aine HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Sisältö i 1 Johdanto 1 2 Lineaarinen malli 2 3 Ketterä ohjelmistotuotanto 3 3.1 Ketterät ohjelmistotuotantoperiaatteet................. 3 3.2 Arkkitehtuurisuunnittelu ketterässä kehityksessä............ 4 4 Yhteenveto 6 Lähteet 7
1 Johdanto 1 Ohjelmistokehityksessä on turvauduttu paljolti tuotettavan ohjelmiston tarkkaan määrittelyyn. Ohjelmistotuotannossa nojattiin 1990-luvulla tarkkaan vaatimusmäärittelyyn ja arkkitehtuurisuunnitteluun joita seurasi toteutus, sekä tarkan suunnitelman mukaiseen testaukseen koodausvaiheen jälkeen [Williams12]. Kantava ajatus toiminnassa oli, että ohjelmisto tulisi tehdä oikein heti ensi yrittämällä. Tästä seurasi, että suunnitteluvaiheen päätyttyä lopullinen toteutustapa oli jo päätetty. Suurten ohjelmistoprojektien yhteydessä tilaajan tarpeet saattoivat muuttua ratkaisevasti tuotannon aikana. Ohjelmistoja jouduttiin suunnittelemaan uudelleen ja turhaa työtä tehtiin paljon. Ohjelmointivaiheessa - joka saattoi kestää vuosia - tapahtuvat muutokset asiakkaan tarpeissa saattoivat olla niin perustavanlaatuisia, että tuotannossa oleva ohjelma oli käynyt tarpeettomaksi sen valmistuessa. Esimerkiksi vesiputousmallin etuna on selkeä siirtyminen vaiheesta toiseen sekä laaja dokumentaatio vaatimusmäärittelyn ja testaussuunnitelman kautta. Selkeä siirtyminen tuotannon vaiheista toiseen helpottaa projektin seurantaa aikataulullisesti. Uuden tuotantovaiheen alkaessa voidaan vielä tarvittaessa palata edelliseen vaiheeseen ja käsitellä asioita uudelleen, mutta lopulta tuotantovaihe on valmis, eikä siihen enää palata. Yksityiskohtainen ja perusteellinen dokumentaatio yksilöi sen, mitä tilaaja ja tuottaja ovat sopineet lopputuotteeksi. Kun tuotannon alussa dokumentaatioon määritellyt asiat löytyvät ohjelmistosta, voidaan todeta että ohjelmiston tuotantoprosessi on lopussa ja tuote sellainen kuin tilattu. Monet tuotantotiimit ryhtyivät kehittämään ratkaisutapoja viivästyneiden projektien loppuun saattamiseksi ja kehittivät suoraviivaista tuotantomallia sellaiseksi, että se paremmin vastaa projektin muuttuviin tarpeisiin. Uusina tuotantomalleina esiteltiin muun muassa extreme Programming (XP), Crystal Methodologies, Feature- Driven Development ja Dynamic Systems Development Method (DSDM) [Mishra11]. Keskinäisen kilpailun sijaan uusien metodien suunnittelijat päättivät yhdistää voimansa vuonna 2001 ja kokoontuivat keskustelemaan menetelmien yhteneväisyyksistä [Williams12]. Kokoukseen osallistui useita uusien metodien luojia ja tukijoita jotka muotoilivat yhdessä ketteryyden julistuksen johon on koottu ketterien ohjelmistotuotantomenetelmien keskeisimmät periaatteet [AgileManifesto].
2 Lineaarinen malli 2 Lineaarinen ohjelmistotuotanto alkaa vaatimusten määrittelystä ja jatkuu suunnittelun, toteutuksen ja testauksen kautta ylläpitovaiheeseen. Lineaarisuutta hyödyntäviä malleja ovat muun muassa vesiputous -malli (waterfall) ja RUP (Rational Unified Process), joka perustuu peräkkäisiin iteraatioihin joista jokainen suunnitellaan vesiputousmallin mukaisesti. Lineaarinen malli vaikuttaa pääsääntöisesti liian raskaalta ja jähmeältä ohjelmistotuotannon käyttöön. Dokumentaation tekeminen voi ajoittain käydä raskaaksi ja se sitoo vahvasti projektia tiettyyn suuntaan. Ohjelmiston tuottajat eivät tarkkaan tiedä mihin tai miten uutta ohjelmistoa tullaan tarkalleen käyttämään: yleisiä vaatimuksia voidaan toki poimia, mutta tilaajan omat käytännöt voivat jäädä huomiotta tai ohjelmiston tuottajat voivat ymmärtää käytäntöjä väärin. Jos yksityiskohtia vahvistetaan ennen ohjelman tuotantoa, voi käydä niin, että lopputulos on jotakin aivan muuta kuin mitä pitäisi. Vahva alkuvaiheen suunnittelu voi myös sitoa ohjelmiston tuottajan sellaisiin ohjelmistoratkaisuihin, jotka myöhemmin osoittautuvat huonoiksi tai jopa haitallisiksi ja niiden korjaamiseen tai ongelmien minimoimiseen kuluu aikaa ja resursseja. Ohjelmasta voi tulla vaikeasti käytettävä ja ylläpidettävä ja sen käyttö voi alkaa vaikeuttamaan tilaajan omaa toimintaa sen helpottamisen sijasta.
3 Ketterä ohjelmistotuotanto 3 3.1 Ketterät ohjelmistotuotantoperiaatteet Ketterässä ohjelmistotuotannossa tähdätään laadukkaan, asiakkaan mahdollisesti tuotannon aikana muuttuneet tarpeet huomioon ottaneen ohjelmiston toimittamiseen aikataulussa. Ketterän ohjelmistokehityksen julistuksessa todetaan seuraavaa: Löydämme parempia tapoja tehdä ohjelmistokehitystä, kun teemme sitä itse ja autamme muita siinä. Kokemuksemme perusteella arvostamme: Yksilöitä ja kanssakäymistä enemmän kuin menetelmiä ja työkaluja Toimivaa ohjelmistoa enemmän kuin kattavaa dokumentaatiota Asiakasyhteistyötä enemmän kuin sopimusneuvotteluja Vastaamista muutokseen enemmän kuin pitäytymistä suunnitelmassa Jälkimmäisilläkin asioilla on arvoa, mutta arvostamme ensiksi mainittuja enemmän [AgileManifesto]. Julistuksen lisäksi laadittiin myös ketterän ohjelmistokehityksen 12 periaatetta [AgileManifesto]: Tärkein tavoitteemme on tyydyttää asiakas toimittamalla tämän tarpeet täyttäviä versioita ohjelmistosta aikaisessa vaiheessa ja säännöllisesti. Otamme vastaan muuttuvat vaatimukset myös kehityksen myöhäisessä vaiheessa. Ketterät menetelmät hyödyntävät muutosta asiakkaan kilpailukyvyn edistämiseksi. Toimitamme versioita toimivasta ohjelmistosta säännöllisesti, parin viikon tai kuukauden välein, ja suosimme lyhyempää aikaväliä. Liiketoiminnan edustajien ja ohjelmistokehittäjien tulee työskennellä yhdessä päivittäin koko projektin ajan. Rakennamme projektit motivoituneiden yksilöiden ympärille. Annamme heille puitteet ja tuen, jonka he tarvitsevat ja luotamme siihen, että he saavat työn tehtyä. Tehokkain ja toimivin tapa tiedon välittämiseksi kehitystiimille ja tiimin jäsenten kesken on kasvokkain käytävä keskustelu. Toimiva ohjelmisto on edistymisen ensisijainen mittari. Ketterät menetelmät kannustavat kestävään toimintatapaan. Hankkeen omistajien, kehittäjien ja ohjelmiston käyttäjien tulisi pystyä ylläpitämään työtahtinsa hamaan tulevaisuuteen.
4 Teknisen laadun ja ohjelmiston hyvän rakenteen jatkuva huomiointi edesauttaa ketteryyttä. Yksinkertaisuus - tekemättä jätettävän työn maksimointi - on oleellista. Parhaat arkkitehtuurit, vaatimukset ja suunnitelmat syntyvät itseorganisoituvissa tiimeissä. Tiimi tarkastelee säännöllisesti, kuinka parantaa tehokkuuttaan, ja mukauttaa toimintaansa sen mukaisesti. Ketterässä ohjelmistokehityksessä käytetään lyhyitä ajanjaksoja joita kutsutaan pyrähdyksiksi (sprint). Yhden pyrähdyksen aikana toteutetaan tietyt, sovitut ominaisuudet ohjelmistoon ja pyrähdyksen lopuksi on tarkoitus, että asiakas saa nähtäväkseen toimivan tuotteen jossa on mukana ne ominaisuudet, jotka pyrähdyksen loppuun mennessä ovat valmistuneet. Ketterään ohjelmistotuotantoon on kehitetty apuvälineitä joiden avulla työtehtävien valintaa pyrähdykseen ja pilkkomista pieniin osiin on helpotettu. Työtehtäviä valitaan pyrähdykseen keskustelemalla asiakkaan kanssa siitä, mikä olisi tärkeää saada ohjelmistossa seuraavaksi toimimaan. Työtehtävien työmääräarvoita voidaan arvottaa keskustelemalla tiimin kesken. 3.2 Arkkitehtuurisuunnittelu ketterässä kehityksessä Ketterässä kehityksessä pääpaino on iteratiivisessa ongelmanratkaisussa, jolloin arkkitehtuuriin liittyviä kysymyksiä pyritään ratkaisemaan sitä mukaa kun niitä nousee projektin edetessä esille [Fontdevila10]. Vastuuta jaetaan koko tiimille, jolloin jokainen tiimin jäsen pääsee ihannetapauksessa vaikuttamaan arkkitehtuuriratkaisuun, sekä ymmärtää miksi tietyt ratkaisut on tehty. Fontdevila ja Salías suosittelevat, että arkkitehtuuriin liittyviä kysymyksiä pidetään esillä koko projektin ajan ja niitä käsiteltäisiin jokaisessa pyrähdyksessä. He suosittelevat myös, että tärkeimmät arkkitehtuuriin liittyvät ratkaisut olisivat jatkuvasti näkyvillä ohjelmistotiimin nähtävillä. Ketterässä kehitysprosessissa otetaan alkuvaiheista lähtien monien eri yhteistyötahojen intressit suunnitteluun mukaan [Fontdevila10] ja arkkitehtuurivaatimuksia on tarkasteltava alkuvaiheista lähtien monesta eri näkökulmasta. Arkkitehtuurin suunnitteluun ja jatkuvaan kehittämiseen ohjelmistotuotannon aikana on kehitetty menetelmiä. Eräs menetelmistä on nimeltään Sashimi ja sitä esitellään Fontdevilan ja Salíaksen artikkelissa. Menetelmän lähtökohtana voidaan pitää sitä, että arkkitehtuuria rakennetaan vain pienin vaadittu määrä jotta järjestelmää voidaan ryhtyä ohjelmoimaan ja sitä laajennetaan tilanteen niin vaatiessa. Arkkitehtuuria pystyttäessä on myös pyrittävä pitämään komponentit yksinkertaisina, jotta niitä on helppo tarvittaessa muokata. Tarkoitus on, että arkkitehtuuria voi tarvittaessa muokata mahdollisimman vähäisellä järjestelmän muutoksella jotta tehtyä työtä (esimerkiksi valmista ohjelmakoodia) ei menisi hukkaan.
Toinen esitelty lähestymistapa on käydä läpi arkkitehtuuritarpeet kerroksittain, alkaen korkean tason toteutuksesta. Toisessa kerroksessa koostetaan moduuleja jossa kuvataan sidosryhmien tarvitsemat palvelut. Kolmannessa kerroksessa kuvaus koostuu tyypillisesti arkkitehtuurikuvauksessa käytetyistä termeistä ja neljännessä kerroksessa kuvataan komponentteja, jotka ovat pakattuja ohjelmiston osia. Viides kerros on kuvaus luokkatasolla. 5
4 Yhteenveto 6 Ketterissä tuotantomalleissa käytetään hyödyksi lineaarisen tuotantomallin vaiheita lyhyiden iteraatioiden aikana. Tämä antaa mahdollisuuden puuttua ongelmiin heti niiden ilmetessä. Yhdessä pyrähdyksessä käydään läpi suunnitelu-, tuotanto- ja testausvaihe ennen ohjelmiston uuden version luovuttamista asiakkaalle. Kun uusia osia liitetään olemassa olevaan ohjelmistoon tulee ohjelmiston toimintaa kokonaisuutena testattua jatkuvasti. Virheiden paikallistaminen on helpompaa kuin lineaarisessa mallissa, sillä ohjelmisto kasvaa pala palalta ja yhteensopivuusongelmat nousevat säännöllisesti esiin. Ketterät menetelmät ovat Mishran mukaan [Mishra11] nousemassa tietotekniikkaalan toimijoiden valtavirran tietoisuuteen ja alan opiskelijoiden työllistymisen kannalta on oleellista käydä ketteriä menetelmiä läpi ennen valmistumista ja työelämään siirtymistä.
Lähteet 7 Abrahamsson10 Abrahamsson P., Babar M.A., Kruchten P. Agility and Architecture: Can They Coexist? IEEE Software, vol. 27, no. 2, 2010, s. 16-22 AgileManifesto AgileManifesto.org http://agilemanifesto.org/iso/fi/ Beck99 Beck K. Extreme Programming Explained Addison-Wesley, Reading, USA, 1999 Boehm03 Boehm B., Turner R. Using Risk to Balance Agile and Plan-driven Methods Computer, vol. 36, no. 6, 2003, s. 57-66 Fontdevila10 Fontdevila D., Salías M. Software Architecture in the Agile Life Cycle Microsoft, The Architecture Journal, vol. 24, 2010 http://msdn.microsoft.com/en-us/architecture/ff476940 Gotterbarn04 Gotterbarn D. UML and agile methods: in support of irresponsible development ACM, SIGCSE Bull., vol. 36, no. 2, 2004, s. 11-13 Grenning02 Grenning J. Planning Poker or How to Avoid Analysis Paralysis while Release Planning 2002, http://www.renaissancesoftware.net/files/articles/planningpokerv1.1.pdf Maurer05 Maurer F., Melnik G. What You Always Wanted to Know About Agile Methods but Did Not Dare to Ask ACM, ICSE 05, s. 731-732 Mishra11 Mishra A., Mishra D. A Curriculum for Agile Software Development Methodologies ACM, SIGSOFT Softw. Eng. Notes, vol. 36, no. 3, 2011, s. 1-2 Williams12 Williams L. What Agile Teams Think of Agile Principles Commun. ACM, vol. 55, no. 4, 2012, s.71-76