7. Iteratiivinen ohjelmistokehitys - cs.helsinki.fi · Ketterä projektinhallinta Ketterät prosessit korostavat tiimityöskentelyä. Tiimi toimii yhtenä tasa-arvoisena yksikkönä

Ohjelmistoprosessit ja ohjelmistojen laatu kevät 2009

1

kevät 2009 Ohjelmistoprosessit ja ohjelmistojenlaatu

163

7. Iteratiivinen ohjelmistokehitys

Iteratiivinen (ja evoluutio-)ohjelmistokehitys (iterativeand evolutionary software development) onprosessimallien perhe, missä ohjelmiston elinkaarimuodostuu useasta peräkkäisestä iteraatiosta.Jokainen iteraatio on pieni projekti, jossa ovatmukana ohjelmistotuotannon perustehtävätvaatimusmäärittely, suunnittelu, toteutus ja validointi.Toisin kuin luulisi, iteratiivinen ohjelmistokehitys onlähes yhtä vanha ajatus kuin lineaarinenohjelmistokehitys. Ensimmäiset iteratiiviset prosessitotettiin käyttöön 1960-luvulla.


164

Julkaisu

Jokaisen iteraation tuloksena saadaan julkaisu (iterationrelease).

Julkaisu on lopullisen järjestelmän toimiva osajoukko. Prototyyppiei kelpaa julkaisuksi.

Käytännössä projekteissa on myös iteraatioita, joista ei synny uuttajulkaisua. Näin käy silloin, kun koodia täytyy refaktoroida (eli siistiä) taikun ohjelmistoa ei ole saatu testattua tarpeeksi aiemmissa iteraatioissa.

Kaikki julkaisut eivät ole julkisia eli loppukäyttäjälle tarkoitettuja.Sisäiset julkaisut ovat kehitystiimin ja asiakkaan käytössä.Julkiset julkaisut ovat loppukäyttäjälle tarkoitettuja versioitatuotteesta. Joskus viimeinen julkaisu on lopullinen tuote, muttanykyisin kehitystyö jatkuu yleensä tuotteen elinkaaren ajan.Tuotteesta tehdään useita julkisia julkaisuja.Jos projektissa on monta kehitystiimiä, niin julkaisuun integroidaankaikkien kehitystiimien tuotokset.


2


165

Iteratiivinen ja lisäävä kehitystyö

Ohjelmistotyötä, jossa tuotteeseen lisätään sykleittäinuusia ominaisuuksia, kutsutaan lisääväksiohjelmistokehitykseksi (incremental development).Jos lisäykset liittyvät iteraatioihin, saadaaniteratiivinen ja lisäävä ohjelmistokehitys (Iterative andIncremental Development, IID).Lähes kaikki modernit ohjelmistoprosessit ovat IID-variantteja.Erityisesti kaikki nykyiset ketterät prosessit ovat IID-variantteja.


166

Iteraation pituus

IID ei määrittele iteraation pituutta, muttamoderneissa iteratiivisissa prosessimalleissaiteraation suositeltava pituus on yhdestä kuuteenviikkoa.

Vertailun vuoksi vanhemmissa prosessimalleissa syklin(cycle) pituus on 3-6kk, joskus jopa enemmän.

Sykli on hiukan eri asia kuin iteraatio. Sykli tarkoittaa aikaa,missä käydään läpi kaikki työvaiheet vaatimusmäärittelystätestaukseen. Tuloksena ei välttämättä saada julkaisua vaanesimerkiksi prototyyppi. Iteraation tuloksena saadaan ainajulkaisu.

Lyhyt sykli tarkoittaa nopeaa reagointia muutokseen.Toisaalta se myös tarkoittaa, että tehtävä ohjelmisto onositettava hyvin pieniin toteutettaviin osiin.


3


167

Iteraation työvaiheet

Iteraatiossa perustehtävien painotukset vaihtelevatsen mukaan, missä kohdassa tuotteen elinkaartaollaan.

Ensimmäisillä iteraatioilla painotetaan vaatimusmäärittelyä javaatimusten validointia.Myöhemmillä sykleillä vaatimusmäärittelyn paino vähenee jasuunnittelun lisääntyy.Vielä myöhemmillä sykleillä vaatimusmäärittelyn jasuunnittelun paino vähenee ja toteutuksen jajärjestelmätestauksen paino lisääntyyYlläpitovaiheessa toteutuksen (plus refaktoroinnin) jaregressiotestauksen paino lisääntyy.


168

Riskilähtöinen ja asiakaslähtöineniteraatiosuunnittelu

Iteraatiossa toteutettavat ominaisuudet voidaan valitariskilähtöisesti (risk-driven) tai asiakaslähtöisesti(client-driven).

Riskilähtöisessä kehitystyössä iteraatioon valitaan netehtävät, jotka ovat vaikeimmat ja riskialtteimmat toteuttaa.Asiakaslähtöisessä kehitystyössä iteraatioon valitaan netehtävät, jotka asiakas asettaa korkeimmalle prioriteetille.

Riskilähtöinen kehitystyö helpottaa projektia, muttaasiakas ei välttämättä pidä lähestymistavasta. Useinsyvällä olevat vaikeat ratkaisut eivät suoraan näyparantuneena toiminnallisuutena.Asiakaslähtöinen kehitystyö pitää asiakkaantyytyväisenä, mutta voi johtaa raskaaseenrefaktorointiin tai jopa väärään arkkitehtuuriin.


4


169

Timeboxing

IID:ssa iteraation kesto kiinnitetäänetukäteen. Tätä kutsutaan timeboxing-tekniikaksi (termille ei ole hyvää käännöstä:ehdotuksia otetaan vastaan).Timeboxing-tekniikassa iteraation kestoaikaei jousta. Jos sykliin allokoituja tehtäviä onjäljellä enemmän kuin iteraatioon mahtuu,tehtävien määrää karsitaan.Iteraation tuloksena saadaan aina sovittunaajankohtana lopullisen tuotteen osajoukko.


170

Timeboxing 2

Timeboxing ei tarkoita, että tiimiläisten täytyy tehdäylitöitä saavuttaakseen iteraation takarajan.

Joskus ylityöt ovat ok, kunhan sekä tiimi että projektin johtohyväksyvät ne.Pääsääntöisesti pitäisi kuitenkin seurata normaaliatyöviikkoa ja ylitöiden sijaan karsia ominaisuuksista.

Timeboxing ei tarkoita, että kaikkien syklien on oltavasaman mittaisia. Projektin syklien pituus voi vaihdellakeskenään, mutta yhden syklin pituus ei muutu syklinaloituksen jälkeen.Kaikki yleisimmät ketterät prosessimallit vähintäänsuosittelevat vahvasti tai jopa vaativat timeboxing-tekniikan käyttöä.


5


171

Iteraation käynnistymisen jälkeen

IID:ssa varaudutaan muuttuviin vaatimuksiin, mutta eikoska tahansa. Muutoksiin varaudutaan iteraatioidenvälillä, ei niiden sisällä.Iteraation käynnistymisen jälkeen ulkoisetsidosryhmät eivät vaikuta sen sisältöön.

Toisin sanoen, kun tiimi on aloittanut sovitun iteraationtoteutuksen, asiakas, projektin vastuuhenkilö, presidentti ym.ei voi pyytää tai käskeä tiimiä tekemään ylimääräistä.Tiimi itse voi vähentää iteraatiossa tehtäviä tehtäviä, jostimeboxing ei muuten toteudu.Jos iteraatio on menossa todella pahasti metsään, niin sevoidaan keskeyttää ja aloittaa uusi iteraatio etuajassa.


172

IID ja vaatimusmäärittely

IID:ssa iteraatiossa toteutetaan sovitut tehtävät,mutta mistä tehtävät saadaan?Tehtävät saadaan vaatimusmäärittelystä aivan kutensuunnitelmakeskeisissä prosesseissa.Vaatimusmäärittelyä tehdään rinnanohjelmistokehityksen kanssa. Se voi olla osanaiteraatiota, mutta se voi myös olla iteraatioistaerillään.IID:n kannalta riittää, että kussakin iteraatiossatiedetään, mitä tehtäviä siihen kuuluu.


6


173

IID ja vaatimusmäärittely 2

IID sopii projekteihin, joissa vaatimukset muuttuvat. Muttamiten paljon vaatimukset muuttuvat?mitkä vaatimukset saavat muuttua?

Itse asiassa useimmissa projekteissa suurin osa vaatimuksistaon melko stabiileja. Nämä vaatimukset tunnistetaan (jatoteutetaan) aikaisissa sykelissä.Osa vaatimuksista elää. Asiakas ei osaa kertoa, mitä tarvitaantai ongelmakenttä muuttuu. Nämä tunnistetaan ja toteutetaanprojektin edetessä.Tärkeimpiä tunnistettavia vaatimuksia ovat laatutekijöihin liittyvätvaatimukset. Ne pitää tunnistaa mahdollisimman aikaisin, jottaohjelmiston arkkitehtuuri saadaan räätälöityä niille sopivaksi.Niiden pitää myös olla mahdollisimman stabiileja.

Yleensä laatutekijöiden stabiilius ei ole ongelma. Lähinnätehokkuus-laatutekijä voi tuottaa ongelmia.


174

IID ja aikataulu

Eräs tavallisimmista IID:n kritiikin aiheista liittyy projektinaikataulutukseen. IID:n adaptiivisen luonteen johdosta varsinkinprojektin alussa on vaikea tehdä edes alustavaa aikataulua.Maagiset fraasit edellisessä kohdassa ovat projektin alussa jaalustava aikataulu. Nimittäin

jo muutaman iteraation jälkeen meillä on jo aika hyvä käsitys siitä,kuinka monta iteraatiota työ vaatii jamikä tahansa projektin alussa tehty aikataulu on vain alustava.Suunnitelmakeskeisten projektien projektin alussa tehdyt aikataulutovat ihan yhtä summittaisia.

Ongelman ratkaisu onsiirtää yleisen aikataulun tekoa projektin alusta muutamaniteraation päähän jatehdä yksityiskohtaista aikataulusuunnittelua korkeintaanmuutaman iteraation verran eteenpäin.


7


175

8. Ketterä ohjelmistokehitys

Ketterä ohjelmistokehitys (agile development) taiketterät prosessimallit (agile process models) ovatIID:n osajoukko. Ne sisältävät IID:n periaatteita,kuten timboxing ja viivästetty projektisuunnittelu,mutta niiden lisäksi ne korostavat muutostenhyväksymistä (embrace change).Ketterässä ohjelmistokehityksessä oleellista onohjautuvuus (maneuverability). Se tarkoittaa, ettäketterät projektit valmiita vaihtamaan suuntaa, kuntarve vaatii. Ne ovat – ketteriä.

Aiempi termi kevyet prosessimallit (lightweight processmodels) on auttamatta vanhentunut. Ketterät prosessimalliteivät ole välttämättä kevyitä eivätkä kevyet mallit ketteriä.


176

Ketterien prosessien muodollisuus

Muodollisuus (ceremony) määrittelee, miten paljon prosessissaon dokumentaatiota, matemaattista formalismia, tarkastuksiajne.Ketteriin prosesseihin yhdistetään helposti epämuodollisuus,mutta tämä on myytti. Ketterät prosessit eivät ole senepämuodollisempia kuin suunnitelmakeskeiset prosessit.

Esimerkiksi Scrumissa ei oteta kantaa siihen, miten muodollinenprojektin tulee olla. Muodollisuuden aste jätetään projektinpäätettäväksi.XP:ssa dokumentaatio pidetään minimissä, mutta vastaavasti XPsisältää paljon muodollisia tekniikoita, kuten pariohjelmoinnin jatestauslähtöisen ohjelmistokehityksen.Amblerin kehittämä menetelmäjoukko Agile Modeling(www.agilemodeling.com) lisää mallinnuksen ketteriin prosesseihin.Menetelmät sopivat käytännössä mihin tahansa ketteräänprosessimalliin.

http://www.agilemodeling.com


8


177

Agile Alliance

Ketterille prosessimalleille ei toistaiseksi oleolemassa määritelmää. Parhaiten ketteriäprosessimalleja kuvaa Agile Alliancen 2001esittelemät Ketterien prosessimallien manifesti (Agilemanifesto) ja ketterät periaatteet (agile principles).Agile Alliance voi edelleen hyvin. Organisaatiossa onkehitelty ketterien prosessimallien yleisiä periaatteitaja tehty ketteriä prosesseja tutuksi.

Agile Alliance löytyy osoitteesta http://www.agilealliance.com– kannattaa tutustua!

Toistaiseksi vahvistamattomien huhujen mukaanketterille prosessimalleille on tulossa piakkoinstandardi.


178

Agile Manifesto

Koska ketterien prosessien manifesti menettää liikaakäännöksessä, laitan sen tähän alkuperäisessämuodossa (Agile Alliance, 2001):

Individuals and interactionsWorking softwareCustomer collaborationResponding to change

over processes and toolsover comprehensive documentationover contract negotiationover following a plan

Agile Manifesto

That is, while there is value in the items on the right,we value the items on the left more.

http://www.agilealliance.com


9


179

Ketterät periaatteet

Myös Agile Alliancen ketterien periaatteiden käännösmenettää osan sisällöstä, joten laitan nämäkin englanniksi(Agile Alliance, 2001):

1. Our highest priority is to satisfy the customer through early andcontinuous delivery of valuable software.

2. Welcome changing requirements, even alte in development. Agileprocesses harness change for the customer’s competitiveadvantage.

3. Deliver working software frequently, from a couple of weeks to acouple of months, with a preference to the shorter time scale.

4. Business people and developers must work together dailythroughout the project.

5. Build projects around motivated individuals. Give them theenvironment and support they need, and trust them to get the jobdone.

6. The most efficient and effective method of conveying informationto and within a development team is face-to-face conversation.


180

Ketterät periaatteet jatkuvat

7. Working software is the primary measure of progress.8. Agile processes promote sustainable development.9. The sponsorts, developers, and users should be able to

maintain a constant pace indefinetely.10.Continuous attention to technical excellence and good

design enhances agility.11.Simplicity – the art of maximizing the amount of work not

done – is essential12. the best architectures, requirements, and designs emerge

from self-organizing teams.13.At regular intervals, the team reflects on how to become

more effective, then tunes and adjusts its behavioraccordingly.


10


181

Ketterien periaatteiden tulkintaa

Ketteristä periaatteista saadaan aika hyväkuva siitä, mitä ketteriin prosesseihin kuuluu:

Projektit ovat joustavia (2, 3, 10, 11)Kommunikointi on erityisen merkittävässä roolissa(4, 6, 12, 13)Asiakastyytyväisyys on tärkein laadun mittari (1, 2,3, 7)Työntekijöiden tyytyväisyys on tärkein laadun tae(4, 5, 6, 9, 10)Kehitystyö on systemaattista (1, 3, 4, 8, 9, 11)


182

Ketterä projektinhallinta

Ketterät prosessit korostavat tiimityöskentelyä. Tiimitoimii yhtenä tasa-arvoisena yksikkönä.

Perinteiset projektipäällikön tehtävät kuuluvat ketterissäprosesseissa koko tiimille. Koko tiimi esimerkiksi vastaaaikataulusta, resurssi- ja kustannusarvioista sekäriskienhallinnasta.

Tiimeillä on toki johtaja, mutta ei perinteisessämielessä.

Projektin johtajan tehtäviin kuuluvattiimiläisten valmennus,työtä hidastavien ongelmien (”töyssyjen”) tasoitus,resurssien tarjoaminen,ketterien periaatteiden ylläpito projektissa jne.

Hyvässä ketterässä projektissa johtajan ei juurikaan tarvitsekäskeä tiimiläisiä.


11


183

Minimalismin periaate

Ketterä periaate 11 yksinkertaisuudesta (”Simplicity isessential”) on helppo ymmärtää väärin. Sitä useintulkitaan niin, että ketterät projektit ovat holtittomia jahallitsemattomia. Tämä on totaalinen väärinkäsitys.Periaate 11 on minimalismin periaate. Se sanoo, ettäasiat pitää tehdä niin yksinkertaisesti kuinmahdollista, mutta ei yhtään yksinkertaisemmin.

Periaate 11 tarkoittaa koko projektia, ei vain koodausta.Mikä on yksinkertaisin toimiva tapa kerätä projektinvaatimuksia? Mikä on yksinkertaisin toimiva tapaus tehdäjatkuvaa testausta? Jos yksinkertaisin tapa on rakentaa sitävarten sovellus, niin sitten sellainen sovellus rakennetaan.


184

Ketterät prosessit ja systemaattisuus

Ketterät prosessit eivät ole holtittomia taihallitsemattomia. Niissä on paljon rakennetta,ohjausta ja hallintaa. Ne ovat systemaattisia.Ero suunnitelmakeskeisiin prosesseihin on siinä, ettäketterissä prosesseissa lähtökohtana on muutos.Muutokseen varautuminen pakottaa joustaviinratkaisuihin projektinhallinnassa, aikataulutuksessa,resurssien arvioinnissa ja dokumentaatiossa.Joustavuus saavutetaan sillä, että ketterien

menetelmien periaatteet ovat vahvasti julkaisu- jalaatukeskeisiä. Toimiva laadukas tuote on kattavaadokumentaatiota tärkeämpi ketterän projektin tuotos.


12


185

Säännöt vastaan periaatteet

Ehkä tavallisin virhe siirryttäessä ketteräänohjelmistokehitykseen on määritellä hurja määräprosessissa seurattavia sääntöjä.

Tuloksena saadaan jäykkä prosessi, joka ei ole joustavaeikä työntekijäystävällinen.Ajan kanssa kommunikaatio saattaa jäädä sääntöjen tieltävähemmälle.Kommunikoinnin kärsiessä saadut julkaisut eivät vastaaasiakkaan tarpeita, jolloin asiakastyytyväisyys kärsii.Lopulta sääntöjä seurataan epäsäännöllisesti, jolloinkehitystyön systemaattisuus kärsii.

Sääntöjen sijaan ketterissä prosesseissa suositaanperiaatteita. Ne määrittelevät kehykset, joidenpuitteissa projektit voivat toimia. Jos jotkutperiaatteista eivät sovi tiimille, niistä voidaan luopua.


186

Ketterien prosessien vaikutusohjelmistokehitykseen

Ketterät prosessimallit eivät keksineet iteraatioita, lyhyitä syklejätai usean julkaisun esittelyä. Kaikki nämä keksittiin jo 60-luvullaennen vesiputousmallia.Royce ”esitteli” vesiputousmallin 1970, minkä jälkeenlineaarinen suunnitelmakeskeinen ohjelmistokehitys alkoi saadaerityisesti managereiden suosiota.

Royce ei itse asiassa esitellyt lineaarista mallia. Artikkelissaan hänehdotti mallia, jossa kehitystyö tehdään kahdessa iteraatiossa.Ilmeisesti väärinkäsityksen johdosta Roycen artikkelia pidettiintodisteena managerien suosimasta lineaarisesta mallista.

Sen sijaan sellaiset tekniikat, kuten pariohjelmointi,testauslähtöinen ohjelmistokehitys ja jatkuva integrointi ovatmelko tuoreita ja nimenomaan ketterään ohjelmistokehitykseenliittyviä tekniikoita.Tekniikoita tärkeämpää ketterissä prosesseissa on filosofia.Vaikka tekniikat kehitettiin aikaisemmin, vasta ketterissäprosessimalleissa ne yhdistettiin yhteisen filosofian alle.


13


187

9. ScrumScrum on IID-pohjainen prosessimalli, jonkapainopiste on projektinhallinnan arvoissa jatekniikoissa.

Nimi ”Scrum” tulee rugbysta. Se tarkoittaa pelinaloitusryhmitystä.

Scrum on tällä hetkellä yleisinohjelmistoteollisuudessa käytetty ketteräprosessimalli. Sen suosio perustuu senyksinkertaisuuteen ja eleganttiin tapaan suhtautuaprojektinhallintaan.Scrum on joustava prosessimalli, jossa vain joitainprojektinhallintaan liittyviä tekniikoita kiinnitetään.Scrum-projektissa voidaan käyttää hyväksi muidenketterien prosessimallien tekniikoita. Esimerkiksiuseimmat XP:n tekniikat sopivat Scrum-projektiin.


188

Scrumin elinkaari

Scrumin elinkaari rakentuu neljästä vaiheesta:Valmistelu (planning),Järjestäminen (staging),Kehitystyö (development) jaJulkaisu (release).

Valmistelu ja järjestäminen ovat Scrum-projektinesivaiheita.Kehitystyö tehdään sykleittäin.

Alun perin syklin pituus on ollut tasan 30 päivää, muttanykyisin Scrum suosii 15-30 päivän mittaisia syklejä.

Julkaisussa asiakkaalle toimitetaan ohjelmistontoimiva versio.


14


189

Scrum: Valmistelu

Valmisteluvaihe vastaa lineaaristenprosessien kelpoisuusselvitystä (feasibilitystudy). Siinä selvitetään tehtävän ohjelmistonja projektin taustoja ja varmennetaan, ettäohjelmisto kannattaa toteuttaa.Tarkoitus:

Asetetaan tavoite,selvitetään odotukset javarmistetaan rahoitus.


190

Scrum: Valmistelu 2

Tehtävät:Kirjataan tavoite,kirjataan budjetti,alustetaan työlista (backlog) ja

Työlista sisältää tähän mennessä tehtävälle tuotteellelöydetyt vaatimukset.Työlistaa päivitetään sitä mukaa, kun syntyy uusiavaatimuksia vai vanhat vaatimukset muuttuvat.

tarvittaessa tehdään ongelmakenttää selventäväohjelmistosuunnitelma ja/tai prototyyppi.


15


191

Scrum: Järjestäminen

Järjestäminen vastaa vaatimusten kartoitusta jaanalyysia. Siinä selvitetään alustavat tuotteenvaatimukset ja kuvataan ongelmakenttä.

Sekä vaatimukset että ongelmakenttä päivittyvät projektinaikana. Jokaisen syklin jälkeen tehtävästä tuotteesta onentistä selkeämpi käsitys.

Tarkoitus:Tunnistetaan tuotteen vaatimuksia ja priorisoidaan niitäriittävästi ensimmäistä iteraatiota varten

TehtävätValmisteluAlustava ohjelmistosuunnitelma ja/tai prototyyppi


192

Scrum: Kehitystyö

Kehitystyössä tehtävää ohjelmistoa toteutetaaniteratiivisesti IID:n periaatteiden mukaisesti.Tehtävä:

Toteutetaan julkaisukelpoinen järjestelmä joukossapyrähdyksiä (sprint).

Yksi pyrähdys tarkoittaa yhtä timeboxattua iteraatiota.Tehtävät:

Pyrähdyksen suunnitteluPyrähdyksessä toteutettavien työlistan tehtävien valinta.

Tehtävät kirjataan julkaisun työlistaan (sprint backlog).Jäljellä olevan työmäärän säännöllinen arviointi.Päivittäiset Scrum-kokouksetScrum-katselmointi (Scrum review) pyrähdyksen lopussa

Katsotaan (demotaan), mitä tiimi sai pyrähdyksessä aikaan.


16


193

Scrum: Julkaisu

Julkaisussa loppukäyttäjälle tarkoitettuohjelmisto annetaan tuotantokäyttöön.Projektin aikana voi olla monta julkaisua.Tarkoitus:

Julkaistaan valmis ohjelmisto.Tehtävät:

DokumentointiKoulutusMyyntiJne.


194

Scrum-prosessi lyhyesti

Kunkin pyrähdyksen alussa tehtävälistalta valitaan pyrähdyksenaikana tehtävät tehtävät pyrähdyksen tehtävälistalle.

Pyrähdyksen tehtävälistalle ei lisätä uusia tehtäviä pyrähdyksenaikana.

Jokainen työpäivä aloitetaan Scrum-kokouksella (Scrum-meeting). Kokous pidetään samassa paikassa samaan aikaan.

Kokouksessa jokainen tiimin jäsen vastaa seuraaviin kysymyksiin:Mitä olet tehnyt edellisen Scrum-kokouksen jälkeen?Mitä aiot tehdä seuraavaan Scrum-kokoukseen mennessä?Mitä esteitä olet kohdannut työssäsi?

Lisäksi oppikirjassa (Larman, 2004) suositellaan kahtalisäkysymystä:

Puuttuuko tehtävälistasta tehtäviä? (Ei uusia vaatimuksia vaanvanhojen tarkennuksia.)Oletko oppinut jotain sellaista, josta on hyötyä muille tiimiläisille?

Pyrähdyksen päätteeksi tarkistetaan Scrum-katselmoinnissa,että tuotettu ohjelmistoversio täyttää sille asetetut vaatimukset.


17


195

Scrum-prosessimallin kaaviokuva

Kuvalla on lähteestä wikimedia.orgKuva on julkaistu GFDL-lisenssillä

(GNU Free Documentation License)


196

Scrumin sidosryhmät

Scrum-projektissa on neljä sidosryhmää:Tuotteen omistaja (product owner)

Tuotteen omistaja vastaa projektin asiakasta. Hänvastaa siitä, että projektin työlista on ajan tasalla,valitsee seuraavassa pyrähdyksessä tehtävät tehtävät jayhdessä muiden sidosryhmien kanssa arvioi jokaisen pyrähdyksenpäättyessä tehdyn tuotoksen.

Tuotteella voi olla monta yhteistyössä toimivaa omistajaa.Scrum-tiimi (Scrum team)

Scrum-tiimi vastaa kuhunkin pyrähdykseen valittujen tehtävientoteutuksesta.Tiimiläisille ei ole määritelty tämän tarkempia tehtäviä.Tiimissä ei saisi olla enemmän kuin seitsemän henkeä. Tätä isommissaprojekteissa on monta tiimiä.

Kanat (Chickens)Kaikkia muita projektin sidosryhmiä kutsutaan kanoiksi, myösesimerkiksi projektien johtajia. Kanat saavat tarkkailla projektia muttaeivät voi vaikuttaa pyrähdysten sisältöön.


18


197

Scrumin sidosryhmät 2

Scrum-sidosryhmät jatkuvat:Scrum-mestari (Scrum master)

Scrum-mestari vastaa projektin hallinnasta Hän ei olevarsinainen projektipäällikkö, vaan enemmän projektinvalmentaja.Scrum-mestari on myös Scrum-tiimissä kehittäjänä, eikä sitenprojektissa pelkkänä hallintohenkilönä.Scrum-mestari

varmistaa, että projektin tavoitteet säilyvät projektin ajan,varmentaa, että projektissa seurataan Scrumin periaatteita,toimii Scrum-tiimin ja hallinnon yhteyshenkilönä,toimii Scrum-tiimiläisten valmentajana,tasoittaa esteitä,vastaa Scrum-kokouksista javastaa Scrum-katselmoinneista (demoista).


198

Scrumin käytännöt

Tärkeimmät Scrumin käytännöt ovatPyrähdykset

Aluksi 30pv, nykyisin 2-6 viikkoa. Pyrähdyksen aikana Scrum-tiimillä on vapaus tehdä julkaisun työlistalla olevia tehtäviäilman keskeytyksiä.

Itseorganisoituvat tiimitPyrähdyksen aikana asiakas, Scrum-mestari, managerit jamuut sidosryhmät eivät määrää tiimiä toimimaan kehitystyössätietyllä tavalla. Kaikki päätökset tehdään pyrähdysten välillä.

Scrum-kokouksetJokainen työpäivä alkaa samaan aikaan ja samassa paikassaScrum-kokouksella.

Ei lisäyksiä iteraatioonPyrähdyksen aikana julkaisun työlistalle ei lisätä uusia tehtäviä.Jos jokin tehtävä on aivan pakko lisätä julkaisun työlistalle,samalla jokin toinen tehtävä on poistettava listalta.


19


199

Scrumin käytännöt 2

Scrumin käytännöt jatkuvat:Päätökset tunnissa

Scrum-mestarin päätöstä vaativat kysymykset pyritäänmieluiten ratkaisemaan välittömästi tai vähintään tunnin sisällä.

Esteet pois päivässäScrum-kokouksissa esille tulevat ongelmat pyritään korjaamaanennen seuraavaa Scrum-kokousta.

Yhteinen työtilaScrum-tiimi työskentelee yhteisessä projektihuoneessa.Yksityiset työtilat ovat muita tehtäviä varten.

Päivittäinen integraatioKaikki varmennettu koodi integroidaan ja regressiotestataanainakin kerran päivässä.


200

XP ja Scrum

eXtreme Programming (XP) aloitti ketterienprosessimallien esiinmarssin 1998. Vaikkamenetelmä ei ole enää samalla tavalla yritystensuosiossa kuin Scrum, sen käytännöt ovat erittäinsuosittuja.XP:n käytännöt keskittyvät pääasiassa kehitystyöhön.Koska Scrumin käytännöt keskittyvät pääasiassaprojektinhallintaan, XP:n tekniikat ovat pitkältiyhteensopivat Scrumin kanssa.Vaikka Scrum-projektissa ei tarvitse seurata muitakuin Scrumin periaatteita, sopivien XP:n periaatteidenlainaaminen varmasti tehostaa projektityöskentelyä.


20


201

Scrumiin sopivia XP:n käytäntöjä

Ainakin seuraavat XP:n käytännöt sopivat hyvinScrum-projektiin:

Automatisoitu testausKaikki testit on voitava suorittaa automaattisesti.Kaikista testistä on saatava yksiselitteinen läpi/kaatui-tulos(pass/fail).Hyväksymistestit kirjoitetaan yhdessä asiakkaan (tuotteenomistajan) kanssa.

Testauslähtöinen kehitystyöYksikkötestauksessa testit kirjoitetaan ennen koodia.Yksikkötestit vastaavat sekä testitapauksen kuvausta ettätestattavan yksikön spesifikaatiota.

PariohjelmointiKaikki koodi kirjoitetaan pariohjelmointina yhden koneenääressä. Pariohjelmoinnissa toinen kirjoittaa koodia ja toinentekee koodille jatkuvaa laadunvarmistusta.


202

Scrumiin sopivia XP:n käytäntöjä 2

Lisää Scrumiin sopivia XP:n käytäntöjä:Jatkuva integrointi

Kaikki hyväksytty koodi integroidaan ja testataan jatkuvastierillisessä integrointijärjestelmässä.Integrointijärjestelmä toimii 24/7-silmukassa, jossa se kääntääkoodin, suorittaa kaikki yksikkötestit ja kaikki/useimmathyväksymistestit.

Yhteinen koodin omistajuusKuka tahansa tiimi jäsen on velvollinen korjaamaan löytämänsäkoodivian.Tiimiläisten on seurattava yhtenäistä koodausstandardia.

Yksinkertainen suunnitteluKoodi suunnitellaan ja toteutetaan nykyistä julkaisua varten.

Säännöllinen refaktorointiKoodia yksinkertaistetaan ja siivotaan säännöllisesti.Tavoitteena on minimaalinen luettava koodikanta.


21


203

Julkaisun työlista

Julkaisun työlista sisältää pyrähdyksen kannalta oleellista tietoatehtävistä töistä. Listalla on ainakin

Tehtävän kuvaus: mitä tehdäänTehtävän esittäjäTehtävästä vastuussa oleva tiimiläinenTehtävän status: aloittamaton, aloitettu, valmisTehtävän vaatima jäljellä olevan työajan arvio.

Jäljellä olevan työajan arvio on mielenkiintoinen. PuhtaassaScrumissa ei arvioida tehtävien kestoja tai tehtävien välisiäriippuvuuksia. Riippuvuusverkkoa ja kriittistä polkua ei tarvita.Kun kaikki julkaisun työlistan jäljellä olevan työajan arviotyhdistetään, saadaan Burn down chart (hyviäkäännösehdotuksia otetaan vastan). Se kertoo, paljonkopyrähdyksen työmäärästä arvioidaan olevan jäljellä.


204

Scrumin luonne

Scrum on selkeästi hallinnollinenprosessimalli.

Sen käytännöissä otetaan kantaa siihen, mitenprojektiryhmä organisoituu ja toimii yhteistyössä.Sen sijaan siinä otetaan hyvin vähän kantaasiihen, mitä tekniikoita projektiryhmä käyttääkehitystyössä.

Koska Scrum ottaa kantaa erityisestihallintoon, se sopii hyvin erilaisten projektienprosessimalliksi. Se sopii myös hyvin yhteenmuiden prosessimallien käytäntöjen kanssa.

Documents

7. Iteratiivinen ohjelmistokehitys - cs.helsinki.fi · Ketterä projektinhallinta Ketterät prosessit korostavat tiimityöskentelyä. Tiimi toimii yhtenä tasa-arvoisena yksikkönä