Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
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.
kevät 2009 Ohjelmistoprosessit ja ohjelmistojenlaatu
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.
Ohjelmistoprosessit ja ohjelmistojen laatu kevät 2009
2
kevät 2009 Ohjelmistoprosessit ja ohjelmistojenlaatu
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.
kevät 2009 Ohjelmistoprosessit ja ohjelmistojenlaatu
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.
Ohjelmistoprosessit ja ohjelmistojen laatu kevät 2009
3
kevät 2009 Ohjelmistoprosessit ja ohjelmistojenlaatu
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.
kevät 2009 Ohjelmistoprosessit ja ohjelmistojenlaatu
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.
Ohjelmistoprosessit ja ohjelmistojen laatu kevät 2009
4
kevät 2009 Ohjelmistoprosessit ja ohjelmistojenlaatu
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.
kevät 2009 Ohjelmistoprosessit ja ohjelmistojenlaatu
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öä.
Ohjelmistoprosessit ja ohjelmistojen laatu kevät 2009
5
kevät 2009 Ohjelmistoprosessit ja ohjelmistojenlaatu
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.
kevät 2009 Ohjelmistoprosessit ja ohjelmistojenlaatu
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.
Ohjelmistoprosessit ja ohjelmistojen laatu kevät 2009
6
kevät 2009 Ohjelmistoprosessit ja ohjelmistojenlaatu
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.
kevät 2009 Ohjelmistoprosessit ja ohjelmistojenlaatu
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.
Ohjelmistoprosessit ja ohjelmistojen laatu kevät 2009
7
kevät 2009 Ohjelmistoprosessit ja ohjelmistojenlaatu
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ä.
kevät 2009 Ohjelmistoprosessit ja ohjelmistojenlaatu
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.
Ohjelmistoprosessit ja ohjelmistojen laatu kevät 2009
8
kevät 2009 Ohjelmistoprosessit ja ohjelmistojenlaatu
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.
kevät 2009 Ohjelmistoprosessit ja ohjelmistojenlaatu
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.
Ohjelmistoprosessit ja ohjelmistojen laatu kevät 2009
9
kevät 2009 Ohjelmistoprosessit ja ohjelmistojenlaatu
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.
kevät 2009 Ohjelmistoprosessit ja ohjelmistojenlaatu
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.
Ohjelmistoprosessit ja ohjelmistojen laatu kevät 2009
10
kevät 2009 Ohjelmistoprosessit ja ohjelmistojenlaatu
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)
kevät 2009 Ohjelmistoprosessit ja ohjelmistojenlaatu
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ä.
Ohjelmistoprosessit ja ohjelmistojen laatu kevät 2009
11
kevät 2009 Ohjelmistoprosessit ja ohjelmistojenlaatu
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.
kevät 2009 Ohjelmistoprosessit ja ohjelmistojenlaatu
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.
Ohjelmistoprosessit ja ohjelmistojen laatu kevät 2009
12
kevät 2009 Ohjelmistoprosessit ja ohjelmistojenlaatu
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.
kevät 2009 Ohjelmistoprosessit ja ohjelmistojenlaatu
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.
Ohjelmistoprosessit ja ohjelmistojen laatu kevät 2009
13
kevät 2009 Ohjelmistoprosessit ja ohjelmistojenlaatu
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.
kevät 2009 Ohjelmistoprosessit ja ohjelmistojenlaatu
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.
Ohjelmistoprosessit ja ohjelmistojen laatu kevät 2009
14
kevät 2009 Ohjelmistoprosessit ja ohjelmistojenlaatu
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.
kevät 2009 Ohjelmistoprosessit ja ohjelmistojenlaatu
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.
Ohjelmistoprosessit ja ohjelmistojen laatu kevät 2009
15
kevät 2009 Ohjelmistoprosessit ja ohjelmistojenlaatu
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
kevät 2009 Ohjelmistoprosessit ja ohjelmistojenlaatu
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.
Ohjelmistoprosessit ja ohjelmistojen laatu kevät 2009
16
kevät 2009 Ohjelmistoprosessit ja ohjelmistojenlaatu
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.
kevät 2009 Ohjelmistoprosessit ja ohjelmistojenlaatu
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.
Ohjelmistoprosessit ja ohjelmistojen laatu kevät 2009
17
kevät 2009 Ohjelmistoprosessit ja ohjelmistojenlaatu
195
Scrum-prosessimallin kaaviokuva
Kuvalla on lähteestä wikimedia.orgKuva on julkaistu GFDL-lisenssillä
(GNU Free Documentation License)
kevät 2009 Ohjelmistoprosessit ja ohjelmistojenlaatu
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.
Ohjelmistoprosessit ja ohjelmistojen laatu kevät 2009
18
kevät 2009 Ohjelmistoprosessit ja ohjelmistojenlaatu
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).
kevät 2009 Ohjelmistoprosessit ja ohjelmistojenlaatu
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.
Ohjelmistoprosessit ja ohjelmistojen laatu kevät 2009
19
kevät 2009 Ohjelmistoprosessit ja ohjelmistojenlaatu
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ä.
kevät 2009 Ohjelmistoprosessit ja ohjelmistojenlaatu
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ä.
Ohjelmistoprosessit ja ohjelmistojen laatu kevät 2009
20
kevät 2009 Ohjelmistoprosessit ja ohjelmistojenlaatu
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.
kevät 2009 Ohjelmistoprosessit ja ohjelmistojenlaatu
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.
Ohjelmistoprosessit ja ohjelmistojen laatu kevät 2009
21
kevät 2009 Ohjelmistoprosessit ja ohjelmistojenlaatu
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ä.
kevät 2009 Ohjelmistoprosessit ja ohjelmistojenlaatu
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.