Osa 1

Ensimmäisessä osassa käydään aluksi katsaus ohjelmistotuotantoon, sen historiaan ja osa-alueisiin. Tämän jälkeen tutustutaan ensin ns. vesiputousmalliin, eli aiemmin suosittuun tapaan hallita ohjelmistoprojekteja ja sen jälkeen ketteriin menetelmiin, eli nykyään vallalla olevaan ohjelmistoprojektien kehitys- ja hallintatapaan.

Tämän osan jälkipuolisko keskittyy suosituimpaan ketterään menetelmään Scrumiin, joka antaa erään konkreettisen ohjeiston sille miten ketteriä ohjelmistoprojekteja voi hallita.

Olethan jo lukenut osan 0, missä käydään tarkemmin läpi kurssin järjestelyt ja arvosteluperiaatteet?

Typoja materiaalissa

Tee korjausehdotus editoimalla tätä tiedostoa GitHubissa.

Kurssipalaute

Kurssilla on käytössä normaalin lopussa kerättävän palautteen lisäksi ns. jatkuva palaute: voit antaa milloin vain kurssihenkilökunnalle anonyymiä palautetta osoitteessa https://norppa.helsinki.fi/targets/112400522/feedback

Ohjelmistotuotanto ja sen osa-alueet

IEEE (Institute of Electrical and Electronics Engineers), yksi alamme keskeisistä vaikuttajajärjestöistä, määrittelee ohjelmistotuotannon (engl. software engineering) seuraavasti:

The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software

IEEE:n mukaan ohjelmistotuotannolla tarkoitetaan systemaattista, kurinalaista, mitattavissa olevaa tapaa ohjelmistojen kehittämiseen, operointiin ja ylläpitoon. Määritelmän loppukaneetti sanoo, että kyseessä on “insinöörimäinen” tapa ohjelmistojen kehittämiseen.

Määritelmä on peräisin IEEE:n terminologiastandardista (alun perin IEEE Std 610.12-1990, nykyään ISO/IEC/IEEE 24765), ja sitä käyttää myös SWEBOK, eli Software Engineering Body of Knowledge, missä IEEE on komiteavetoisesti määritellyt sen, mitä se tarkoittaa ohjelmistotuotannolla ja mitä osa-alueita se katsoo ohjelmistotuotantoon kuuluvan.

Sivuhuomio: termi ohjelmistotuotanto on englanniksi software engineering. Suomenkielinen vastine ohjelmistotuotanto onkin terminä aika huono. Jos suomenkielinen termi käännettäisiin takaisin englantiin, olisi tuloksena software production, eli ohjelmien valmistaminen. Termiä production käytetään yleensä suoraviivaisesta tuotteiden rakentamisesta, esim. jos tehdas valmistaa tuoleja, voidaan sanoa että sen ala on chair production. Ohjelmistojen tekeminen on aktiviteettina hyvin erilainen kuin esimerkiksi tuolin valmistaminen. Ohjelmistojen “rakentamisesta” käytetään englanninkielistä termiä development, eli voidaan sanoa että company develops software for accounting, joka taas suomeksi kuuluisi yritys kehittää ohjelmistoja laskutukseen. Kehittäminen (development) on aktiviteetti, joka sisältää muutakin kuin pelkkää suoraviivaista valmistamista (production), kehittäminen sisältää mm. suunnittelun ja kysymyksenasettelun sen suhteen mitä ja miksi ylipäätään on tarve jonkinlaiselle tuotteelle. Ohjelmistotuotanto eli software engineering tarkoittaakin “insinöörimäisen” lähestymistavan soveltamista ohjelmistokehitykseen.

Ohjelmistotuotannon osa-alueet

Vuonna 2024 julkaistun SWEBOK:in version 4 mukaan ohjelmistotuotanto jakautuu seuraaviin osa-alueisiin:

• Software requirements
• Software architecture
• Software design
• Software construction
• Software testing
• Software maintenance
• Software engineering operations
• Software configuration management
• Software engineering management
• Software engineering process
• Software engineering models and methods
• Software engineering economics
• Software security
• Software quality

Listasta puuttuvat vielä ammattikäytäntöjä ja -etiikkaa käsittelevä Software engineering professional practice sekä kolme perustaitoja kuvaavaa osa-aluetta (computing, mathematical ja engineering foundations).

Software requirements tarkoittaa ohjelmistolle asetettuja vaatimuksia, eli sitä miten rakennettavan ohjelmiston tulisi loppukäyttäjän tai tilaajan mielestä toimia.

Software design taas tarkoittaa halutun kaltaisen toiminnallisuuden omaavan ohjelmiston sisäisen rakenteen suunnittelua. Suunnittelun keskeinen osa on Software architecture, eli ohjelman korkean tason rakenne.

Software construction viittaa aktiviteetteihin, joiden avulla suunniteltu ohjelmisto saadaan toimivaksi tuotteeksi eli käytännössä ohjelmointia ja debuggausta.

Kuten arvata saattaa, software testing tarkoittaa niitä menetelmiä, joilla varmistutaan siitä, että ohjelmisto toimii kuten halutaan ja että se on riittävän virheetön käytettäväksi.

Suurin osa ohjelmistoista ei valmistu lopullisesti koskaan. Kun ensimmäinen versio otetaan käyttöön, alkaa ylläpito, software maintenance eli bugeja korjaillaan ja ohjelmistoa laajennetaan uusilla toiminnoilla.

Ylläpitoon liittyy läheisesti SWEBOK:issa omaksi osa-alueekseen nostettu Software engineering operations, eli kaikki ne toimet, millä varmistetaan että ohjelmisto ja sen uudet versiot saadaan loppukäyttäjän käytettäväksi.

Software configuration management viittaa ohjelmiston käyttöönsaattamiseen liittyviin kirjastojen, laitteistojen ja käännösprosessin konfigurointiin sekä ohjelmiston versiointiin.

Ohjelmistojen tekemiseen liittyy paljon suunnittelua, koordinointia, hallinnointia ja raportointia eli “managementtia”, tähän viittaa software engineering management.

Software engineering process eli ohjelmistotuotantoprosessi kuvaa tapoja tai menetelmiä miten ohjelmistoa kehittävien ihmisten tulisi hoitaa ja ajoittaa eri aktiviteettejä (requirements, design, construction, testing), joita ohjelmiston kehittäminen edellyttää. Palaamme aiheeseen tarkemmin myöhemmin tässä osassa.

Software engineering models and methods kuvaa yksityiskohtaisempia menetelmiä, joita ohjelmistokehityksessä käytetään, kuten mallinnusta ja erilaisia suunnittelumenetelmiä.

Ohjelmistojen laatu eli software quality on vielä testaustakin laajempi näkökulma siihen, onko ohjelmisto riittävän hyvä. Bugittomuutta ja oikein toimimista keskeisempi kysymys onkin se, sopiiko ohjelmisto ylipäätään käyttäjien tarpeeseen, eli onko se sopiva käyttötarkoitukseensa. Eräs laadun keskeinen elementti on ohjelmistojen tietoturva, eli Software security.

Ohjelmistot elävät harvoin tyhjiössä, useimmiten niiden avulla halutaan automatisoida ja tehostaa jotain toimintaa, eli niillä on kaupallinen motivaatio, toisaalta ohjelmistojen kehittäminen on kallista, eli ohjelmistojen kehittämisen ja ylläpitämisen hintalappu on iso. Ohjelmistoihin liittyvien taloudellisten vaikuttimien ja realiteettien tarkastelua kuvaa Software engineering economics.

Ohjelmistotuotanto pitää siis sisällään suuren määrän hyvin erilaisiakin asioita. Tällä kurssilla käsitellään ainakin jossain määrin näitä kaikkia osa-alueita. Koska aihepiirien määrä on todella suuri ja aikaa rajallisesti, jää asioiden läpikäynti osin valitettavan pintapuoliseksi. Useasta aihepiiristä on kuitenkin tarjolla syventäviä kursseja maisteriopinnoissa.

Aloittelevalle ohjelmistoalan opiskelijalle on tässä vaiheessa olennaisinta saada kokonaiskuva koko ohjelmistotuotannon kentästä ja sen jälkeen soveltaa sekä reflektoida oppimaansa teoriaa käytännön ohjelmistotyössä, esim. Tietojenkäsittelytieteen osaston opintojaksolla Ohjelmistoprojekti tai oikeassa työelämässä. Aihepiiriä syventävät kurssit ovat todennäköisesti huomattavasti antoisampia kokemuksia siinä vaiheessa kun opiskelija omaa jo jonkin verran käytännön työkokemusta alalta.

Ohjelmiston vaiheet ja elinkaari

Edellisessä luvussa mainittii ohjelmistotuotannon osa-alueeet

• Software requirements, vaatimusten määrittely
• Software design, suunnittelu
• Software construction, ohjelmiston toteutus
• Software testing, testaus
• Software maintenance, ylläpito

Näiden voidaan ajatella muodostavan vaiheet (engl. phases) joiden kautta ohjelmisto kehityksensä aikana etenee. Joskus näistä vaiheista käytetään nimitystä ohjelmiston elinkaari (engl. software lifecycle). Aikojen saatossa on ollut erilaisia tapoja jäsentää ohjelmistojen kehittäminen elinkaaren suhteen, eli se miten ja kenen toimesta vaiheet on suoritettu, on vaihdellut.

Code’n’fix

Tietokoneiden historian alkuaikoina laitteet maksoivat paljon, ohjelmistot olivat laitteistoihin nähden “triviaaleja”. Ohjelmointi tapahtui alussa kaapeleita yhdistelemällä ja hieman myöhemmin konekielellä. Sovellusten käyttäjät, kuten ammusten lentoratoja laskeneet fyysikot, yleensä ohjelmoivat itse tarvitsemansa sovellukset.

Sovelluskehitys tapahtui pitkälti code and fix -mentaliteetilla, eli koodattiin ja katsottiin toimiko softa. Ohjelmistojen yksinkertaisuuden ja suhteellisen halpuuden takia se ei muodostanut minkäänlaista pullonkaulaa työskentelylle vaan päinvastoin helpotti työskentelyä, kun laskutoimitukset voitiin tehdä tietokoneella käsin laskemisen sijaan.

Vähitellen ohjelmistot alkoivat kasvaa. Kehitettiin korkeamman tason ohjelmointikieliä kuten Fortran, Cobol, Algol ja ohjelmistojen käyttöalue alkoi laajeta muuallekin kuin puolustusteollisuuteen. Ohjelmistoja alettiin tekemään loppukäyttäjille, jotka eivät enää olleet ohjelmistoalan ammattilaisia, eli kuilu ohjelmiston tekijöiden ja loppukäyttäjien välillä alkoi kasvaa.

Ohjelmistoala alkoi joutua ongelmiin, wikipedian mukaan ongelmaksi alkoivat muodostua mm. seuraavat seikat

• budjetit ylittyivät ja projektit myöhästyivät aikatauluista
• ohjelmistot olivat tehottomia, niiden laatu oli huono ja ne eivät toimineet käyttäjien tarpeiden mukaan
• koodin ylläpito ja laajentaminen oli vaikeaa
• ja jopa usein kävi niin, että ohjelmistoja ei hyvistä aikeista huolimatta saatu ollenkaan toimitettua

Ohjelmistokriisi

Lokakuussa 1968 Saksan Garmisch-Partenkirchenissä NATO:n järjestämässä konferenssissa todettiinkin, että maailmassa on software crisis, eli ohjelmistokriisi. Konferenssista termi levisi yleiseen käyttöön.

Termillä viitataan siihen että on vaikeaa toteuttaa käyttökelpoisia, oikein toimivia, tehokkaita ja laajennettavissa olevia ohjelmistoja käytössä olevien resurssien puitteissa.

Eräs tietojenkäsittelyn pioneereista, Turing-palkittu Edsger Dijkstra ilmaisi asian seuraavasti vuonna 1972 pitämässään esitelmässä

The major cause of the software crisis is that the machines have become several orders of magnitude more powerful! To put it quite bluntly: as long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming has become an equally gigantic problem.

Eli kun tietokoneita ei ollut, ohjelmointi ei muodostanut ongelmaa. Ensimmäiset tietokoneet olivat laskentateholtaan pieniä, ja ne aiheuttivat ainoastaan pieniä ongelmia ohjelmointiin. Massiivisen tehokkaiden tietokoneiden myötä myös ohjelmoinnista on tullut massiivinen ongelma…

Ohjelmistokehitys insinööritieteenä: software engineering

Termiä software engineering eli ohjelmistotuotanto oli käytetty satunnaisesti jo aiemmin, mm. Apollo-ohjelman ohjelmistoja johtanut Margaret Hamilton käytti sitä 1960-luvulla. Laajaan tietoisuuteen termi nousi vuoden 1968 NATO:n konferenssissa, jonka nimeksi se valittiin tarkoituksella provosoivasti. Eräs termin varhainen määritelmä, saksalaisen Fritz Bauerin muotoilema, kuuluu seuraavasti

The establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines

Syntyi idea siitä, että code’n’fix -mentaliteetin sijaan ohjelmistojen kehittämisen tulisi olla kuin mikä tahansa muu insinöörityö, eli kuten esim. siltojen rakentamisessa, tulee rakennettava artefakti ensin määritellä (requirements) tarkasti ja suunnitella (design) aukottomasti ja tämän jälkeen rakentaminen (construction) on melko suoraviivainen vaihe.

Vesiputous- eli lineaarinen malli

Winston Roycen vuonna 1970 julkaisema artikkeli Managing the development of Large Software Systems pohdiskelee isojen ohjelmistojen kehittämiseen liittyvää problematiikkaa. Artikkelin sivulla 2 Royce esittelee yksinkertaisen prosessimallin (eli ohjeiston työvaiheiden jaksottamiseen), jossa ohjelmiston elinkaaren vaiheet suoritetaan lineaarisesti peräkkäin:

Roycen versio kuvasta näyttää seuraavalta:

Suoraviivainen lineaarinen malli, jota ruvettiin kutsumaan vesiputousmalliksi, saavutti nopeasti suosiota. Malli on monella tapaa järkeenkäypä; ensin kannattaa selvittää mitä ollaan tekemässä ja suunnittelu hoitaa vasta tämän jälkeen. Kun suunnitelma on valmis, voidaan tuote valmistaa ja sen jälkeen testata että se toimii kuten haluttiin, näinhän toimitaan monella muullakin tuotannon alalla.

Vesiputousmallin suosion taustalla oli osittain se, että Yhdysvaltojen puolustusministeriö (Department of Defense, DoD) joka oli tuohon aikaan eräs maailman suurimmista ohjelmistojen tilaajista, rupesi vaatimaan kaikilta alihankkijoiltaan prosessin noudattamista (standardit DOD-STD-2167 vuodelta 1985 ja DOD-STD-2167A vuodelta 1988). Muutkin ohjelmistoja tuottaneet tahot ajattelivat, että koska DoD vaatii vesiputousmallia, on se hyvä asia ja tapa kannattaa omaksua itselleen.

Vesiputousmalli perustuu vahvasti siihen, että eri vaiheet ovat erillisten tuotantotiimien tekemiä. Joukko analyytikkoja miettii asiakkaan kanssa sovellukselle asetetut vaatimukset, ohjelmistoarkkitehdit saavat vaatimusmäärittelyn tulokset ja suunnittelevat ohjelman sen perusteella. Ohjelmoijat toteuttavat sovelluksen arkkitehtien suunnitelman mukaan ja antavat sen testaajille laadunhallintaa varten. Tämä tuntuu luonnolliselta työnjaolta, kutakin erilaista vaihetta tekee kyseessä olevan vaiheen työskentelymenetelmiin erikoistunut ihmisjoukko.

Jotta tieto kulkee ohjelmistokehityksen eri vaiheiden välillä, tulee kunkin vaiheen tulokset dokumentoida huolellisesti. Erityisesti asiakkaan kanssa tehtävän vaatimusmäärittelyn on oltava huolellisesti tehty ja hyvin dokumentoitu, sillä kaikki myöhemmät vaiheet olettavat että vaatimukset on kattavasti ja virheettömästi kirjattu.

Vesiputousmallin mukaisesta toiminnasta käytetään joskus luonnehdintaa Big Design Up Front lyhenteenä BDUF, kuvaamaan sitä faktaa, että koko ohjelmisto määritellään ja suunnitellaan tyhjentävästi ennen ohjelmointivaiheen aloittamista. Termiä BDUF käytetään yleensä negatiivisessa merkityksessä kuvaamaan vesiputousmallin raskautta.

Vesiputousmallin mukainen ohjelmistoprosessi on yleensä tarkkaan etukäteen suunniteltu, resursoitu ja aikataulutettu, tästä johtuu joskus siitä käytetty nimike plan based process, eli suunnitelmavetoinen prosessi.

Vesiputousmallin ongelmat

Vesiputousmallin mukainen ohjelmistotuotanto ei ole osoittautunut erityisen onnistuneeksi.

Vesiputousmalli olettaa, että ohjelmistotuotannon vaiheet tapahtuvat peräkkäin ja jokainen vaihe ainakin isoissa projekteissa eri ihmisten toimesta. Tästä koituu useita ongelmia.

Ongelmista keskeisin on se, että tehtiin vaatimusmäärittely miten huolellisesti tahansa, tulevat vaatimukset kuitenkin melkein varmasti muuttumaan matkan varrella. On osoittautunut, että asiakkaat eivät ohjelmistoja tilatessaan tiedä tai osaa sanoa mitä haluavat tai tarvitsevat. Asiakkaan tarpeet nimittäin saattavat muuttua projektin kuluessa. Bisnesympäristö saattaa vaihtua, tulee uusia lainsäädäntöjä, firmat fuusioituvat, maailman taloussuhdanteet vaihtuvat, tulee globaali pandemia… Mitä pidempi ohjelmiston kehitysprosessi on, sitä varmempaa on, että vaatimukset elävät.

On myös kerta toisensa jälkeen nähty, että asiakas alkaa haluta muutoksia heti, kun näkee valmiin lopputuloksen. Koska ohjelmistot ovat abstrakteja tuotteita, joilla ei välttämättä ole aiempia esikuvia, on asiakkaiden hyvin vaikea pystyä etukäteen miettimään kaikkea toiminnallisuutta sillä tasolla, että se voitaisiin lyödä täysin lukkoon, kuten vesiputousmalli olettaa.

Oma riskinsä on myös se, että suunnittelijat tai ohjelmoijat tulkitsevat dokumentoituja asiakkaan vaatimuksia väärin, tai että asiakas ei ole tullut täysin ymmärretyksi vaatimusten kirjaushetkellä, eli vaatimukset on jo lähtökohtaisesti dokumentoitu väärin. Oikeastaan kyseessä ei edes ole riski, vaan on jopa varmaa että ymmärrys- ja tulkintaepäselvyyksiä tapahtuu, oli dokumentaatio miten tarkkaa tahansa.

Vesiputousmallin mukaisen vaatimusmäärittelyn, suunnittelun ja toteutuksen erottaminen on käytännössä järjetöntä tai jopa mahdotonta. Valittu ohjelmiston arkkitehtuuri eli “korkean tason rakenne” ja käytössä olevat toteutusteknologiat vaikuttavat suuresti määriteltyjen ominaisuuksien hintaan, määritellessä kannattaa siis miettiä myös suunnittelua ja toteutusta, ja sitä missä muodossa asiakkaan vaatimukset on ylipäätään mahdollista toteuttaa järkevin resurssein.

Suunnittelun ja toteutuksen eriyttäminenkään ei ole osoittautunut toimivaksi ideaksi. Ohjelmistoja on mahdotonta suunnitella siten, että toteutus on suoraviivainen mekaaninen toimenpide, osa suunnittelusta tapahtuu pakosti vasta ohjelmointivaiheessa.

Vesiputousmalliin perustuvan ohjelmistotuotannon takana on siis pitkälti analogia muihin insinööritieteisiin: rakennettava artefakti tulee ensin määritellä ja suunnitella (design) aukottomasti, tämän jälkeen rakentaminen (construction) on triviaali vaihe.

Perinteisesti ohjelmointi on rinnastettu triviaalina pidettyyn “rakentamisvaiheeseen” ja kaiken haasteen on ajateltu olevan määrittelyssä ja suunnittelussa. Tätä rinnastusta on kuitenkin ruvettu kritisoimaan, sillä ohjelmistojen suunnittelu sillä tarkkuudella, että suunnitelma voidaan muuttaa suoraviivaisesti koodiksi on osoittautunut mahdottomaksi.

Jack Reeves onkin vuonna 1992 kirjoituksessaan What is Software Design? esittänyt, että perinteisen insinööritiedeanalogian triviaali rakennusvaihe ei ohjelmistoprosessissa olekaan ohjelmointi, vaan ohjelmakoodin kääntäminen. Siispä ohjelmakoodi on itseasiassa ohjelmiston lopullinen suunnitelma siinä mielessä kuin insinööritieteet käsittävät suunnittelun (design).

Vesiputousmallin mukaisessa ohjelmistokehityksessä testaus suoritetaan kun ohjelmisto on valmiina. Vasta lopussa tapahtuva laadunhallinta paljastaa ongelmat kuitenkin aivan liian myöhään. Vikojen korjaaminen saattaa tulla hyvinkin kalliiksi, sillä testaus voi tuoda esiin ongelmia, jotka pakottavat muuttamaan radikaalilla tavalla ohjelmiston rakennetta tai jopa sen vaatimuksia.

Jos haluat lukea lisää vesiputousmallin ongelmista, kannattaa tutustua Martin Fowlerin artikkeliin The New Methodology.

Royce ja vesiputousmalli

Paradoksaalista kyllä vesiputousmallin isänä pidetty Royce ei suosittele artikkelissaan suoraviivaisen lineaarisen mallin käyttöä. Royce kyllä esittelee lineaarisen vesiputousmallin artikkelin sivulla 2, mutta toteaa että se ei sovellu monimutkaisten ohjelmistoprojektien tekotavaksi.

Roycen suosituksen mukaan sovelluksesta tulee ensin tehdä prototyyppi ja vasta siitä saatujen kokemusten valossa kannattaa suunnitella ja toteuttaa lopullinen ohjelmisto. Royce esitteleekin artikkelin loppupuolella mallin, jossa ohjelmisto tehdään kahdessa iteraatiossa, kuva Roycen artikkelista:

Vesiputousmalli, tai ainakin Roycen nimeäminen vesiputousmallin isäksi, on siis suuri väärinymmärrys. Onneksi Roycen artikkeli on nykyään saatavilla internetissä (enää tosin ainoastaan web.archive.org:ssa) ja kaikki voivat käydä itse tarkistamassa mitä Royce on vesiputousmallista sanonut.

Iteratiivinen ja inkrementaalinen ohjelmistokehitys

Lineaarisen mallin ongelmiin reagoinut iteratiivinen tapa tehdä ohjelmistoja alkoi yleistyä 80- ja 90-luvuilla (mm. Barry Boehmin spiraalimalli, prototyyppimalli, Rational Unified Process).

Iteratiivisessa mallissa kehitystyö jaetaan lyhyisiin, yleensä muutaman viikon mittaisiin jaksoihin eli iteraatioihin. Jokaisessa iteraatiossa käydään läpi kaikki ohjelmistoprosessin vaiheet: osa ohjelmistosta määritellään, suunnitellaan, toteutetaan ja testataan. Toisin kuin vesiputousmallissa, kattavaa määrittelyä ja suunnittelua ei siis tehdä heti alussa, vaan ne tarkentuvat sitä mukaa kun kehitys etenee.

Malli on samalla inkrementaalinen: jokainen iteraatio tuottaa toimivan lisäyksen (inkrementin) aiempaan, eli ohjelmisto kasvaa pala palalta. Termit kuvaavat kahta eri asiaa. Iteratiivisuus tarkoittaa saman työskentelysyklin toistamista ja tuotoksen parantamista palautteen perusteella, inkrementaalisuus taas ohjelmiston kasvamista vähitellen. Käytännössä nykyiset menetelmät ovat molempia.

Asiakasta tavataan jokaisen iteraation välissä, asiakas näkee sen hetkisen version ohjelmasta ja pystyy vaikuttamaan seuraavien iteraatioiden kulkuun. Ohjelmiston inkrementaalisen kasvamisen takia sen perusversio on mahdollista saada loppukäyttäjien käyttöönkin vielä kehitystyön ollessa käynnissä.

Seuraava kuva havainnollistaa mallia. Määrittelyllä ja suunnittelulla on alussa suurempi painoarvo, mutta toteutus ja testaus alkavat jo ensimmäisessä iteraatiossa, ja ohjelmisto kasvaa jokaisen iteraation myötä.

Vesiputousmallin “isä” Royce suositteli siis jo vuonna 1970 juurikin iteratiivista tapaa (kahden iteraation versiota) monimutkaisten ohjelmistojen kehitysmalliksi. Roycen ehdottama menetelmä ei kuitenkaan ollut inkrementaalinen yllä kuvatussa mielessä, sillä ensimmäisen iteraation aikana rakennettiin ainoastaan prototyyppi, jonka pohjalta varsinainen sovellus määriteltiin, suunniteltiin ja toteutettiin.

Myös Yhdysvaltojen puolustusministeriö muutti kantaansa. Vuonna 1994 vesiputousta suosineen standardin korvasi MIL-STD-498, joka salli myös iteratiivisen kehityksen, ja vuonna 2000 julkaistu hankintaohje DoD 5000.2 alkoi suorastaan suosittelemaan iteratiivista ohjelmistoprosessia:

There are two approaches, evolutionary (iterative) and single step (waterfall), to full capability. An evolutionary approach is preferred. … In this approach, the ultimate capability delivered to the user is divided into two or more blocks, with increasing increments of capability…software development shall follow an iterative spiral development process in which continually expanding software versions are based on learning from earlier development. It can also be done in phases

Itseasiassa iteratiivinen ohjelmistokehitys on paljon vanhempi idea kuin vesiputousmalli. Esimerkiksi NASA:n ensimmäisen amerikkalaisen avaruuteen vieneen Project Mercuryn ohjelmisto kehitettiin 50- ja 60-lukujen taitteessa iteratiivisesti, jopa puolen päivän mittaisissa iteraatioissa. Avaruussukkuloiden ohjelmisto tehtiin vesiputousmallin valtakaudella 70-luvun lopussa, mutta sekin kehitettiin lopulta iteratiivista prosessia käyttäen 8 viikon iteraatioissa, 31 kuukauden aikana. Lisää aiheesta Larmanin ja Basilin erinomaisessa artikkelissa incremental and iterative development, a brief history.

Ketterä ohjelmistokehitys

1980- ja 1990-luvun prosessimalleissa korostettiin huolellista projektisuunnittelua, formaalia laadunvalvontaa, yksityiskohtaisia analyysi- ja suunnittelumenetelmiä ja täsmällistä, tarkasti ohjattua ohjelmistoprosessia. Prosessimallit tukivat erityisesti laajojen, pitkäikäisten ohjelmistojen kehitystyötä, mutta pienten ja keskisuurten ohjelmistojen tekoon ne osoittautuivat usein turhan jäykiksi.

Perinteisissä prosessimalleissa (myös iteratiivisissa) on pyritty työtä tekevän yksilön merkityksen minimoimiseen. Ajatuksena on ollut että yksilö on “tehdastyöläinen”, joka voidaan helposti korvata toisella ja tällä ei ole ohjelmistoprosessin etenemiselle mitään vaikutusta.

Ristiriidan seurauksena syntyi joukko ketteriä menetelmiä (engl. agile methods), jotka korostivat itse ohjelmistoa sekä ohjelmiston asiakkaan ja toteuttajien merkitystä yksityiskohtaisen suunnittelun ja dokumentaation sijaan.

Ketterä manifesti

17 ketterien menetelmien pioneeria kerääntyi helmikuussa 2001 kokoukseen, jonka tuloksena oli ketterä manifesti, eli näkemys siitä, mitä ketterällä ohjelmistokehityksellä tarkoitetaan:

Manifesti on käännetty monelle kielelle, myös suomeksi. Suomeksi manifesti kuuluu seuraavasti:

Etsimme 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.

Manifesti siis koostuu neljästä vastakkainasettelun sisältävästä kohdasta, jotka ilmaisevat mikä on ketterien menetelmien näkemyksen mukaan oleellisinta ohjelmistokehityksessä. Ensimmäinen kohta sanoo, että erilaiset työkalut ja prosessit voivat olla tärkeää, mutta vielä tärkeämpää ovat ohjelmiston kehittäjät, käyttäjät, tilaajat ja heidän välinen interaktio. Toinen kohta taas ei kiellä dokumentaation tärkeyttä, mutta sanoo että lopulta tärkeintä on toimiva ohjelmisto. Ketterä manifesti ei siis kiellä tai pidä arvottomana “vanhan maailman” tärkeänä pitämiä asioita kuten suunnitelman noudattamista, mutta osoittaa, että niitäkin oleellisimpia seikkoja on, kuten muutokseen reagoiminen.

Manifestin laatijoiden joukko koostuu monesta tutusta ja vaikutusvaltaisesta nimestä, kuten Kent Beck, Robert Martin, Ken Schwaber, Martin Fowler ja Alistair Cockburn, jotka ovat vaikuttaneet merkittävästi nykyiseen vallitsevaan ohjelmistokehityksen tapaan.

Ketterät periaatteet

Manifesti sisältää yllä olevan lisäksi 12 hieman konkreettisempaa toiminnan ohjeistusta antavaa ketterää periaatetta. Käydään periaatteet nyt läpi ja pohditaan myös niiden taustalla olevia ajatuksia.

Aloitetaan kolmesta periaatteesta.

Tärkeimpänä tavoitteenamme on täyttää asiakkaan toiveet toimittamalla arvokasta ohjelmistoa jo varhaisessa vaiheessa ja jatkuvasti.

Toimitamme toimivaa ohjelmistoa säännöllisesti, parin viikon tai kuukauden välein, mieluummin lyhyemmällä aikavälillä.

Toimiva ohjelmisto on ensisijainen edistymisen mittari.

Oleellisinta kaikesta ja mittarina projektin edistymiselle on toimintakelpoisen, arvoa tuottavan ohjelmiston toimittaminen asiakkaalle. Toisin kuin vesiputousmallissa, aloitetaan valmiin toiminnallisuuden toimittaminen jo aikaisessa vaiheessa ja sitä tehdään toistuvasti tiheähkösti iteroiden. Manifesti puhuu parin viikon tai kuukauden välein tapahtuvasta toimittamisesta, nykyään ideaali on vieläkin tiheämpi toimitusväli, jopa joka päivä tapahtuva useiden sovelluksen versioiden julkaisu. Tämä on mahdollista jatkuvan toimittamisen ja DevOpsin käytänteiden avulla. Ohjelmistotiimien toimituskykyä mitataankin nykyään usein ns. DORA-metriikoilla, joista keskeisiä ovat mm. julkaisutiheys sekä aika, joka kuluu muutoksen tekemisestä sen päätymiseen tuotantoon.

Liiketoiminnan edustajien ja kehittäjien tulee työskennellä yhdessä päivittäin koko projektin ajan.

Tehokkain ja toimivin tapa välittää tietoa kehitystiimille ja tiimin sisällä on kasvokkain käytävä keskustelu.

Otamme muuttuvat vaatimukset vastaan myös kehityksen loppuvaiheessa. Ketterät menetelmät valjastavat muutoksen asiakkaan kilpailueduksi.

Vesiputousmallissa fundamentaalina periaatteena oli se, että ohjelmiston valmistaminen alkaa kattavalla vaatimusmäärittelyllä, jonka aikana asiakkaan vaatimukset selvitetään, dokumentoidaan huolellisesti ja “jäädytetään”, eli vaatimuksiin ei sen koommin edes sallita muutoksia. Asiakas on seuraavan kerran mukana kehitystyössä ehkä vasta lopussa tekemässä hyväksymistestausta.

Ketterän manifestin periaatteet ovat täysin päinvastaiset. Asiakkaiden ja sovelluskehittäjien oletetaan toimivan koko ohjelmiston kehityskaaren tiiviissä, jopa päivittäisessä yhteistyössä. Kommunikointi pyritään hoitamaan raskaan dokumentaation sijaan kevyemmin, jopa keskustellen. Manifestin aikaan keskustelu tarkoitti kasvokkain käytävää keskustelua, mutta etä- ja hybridityön yleistyttyä periaatetta tulkitaan väljemmin: kasvokkaisen keskustelun rinnalle ovat nousseet videopalaverit sekä asynkroninen, kirjallinen viestintä esim. chatissa, issueissa ja pull requesteissa, joka samalla jättää päätöksistä jäljen. Myös suhtautuminen vaatimusmäärittelyyn on mennyt päälaelleen. Asiakas saa vaihtaa vaatimuksiaan kesken ohjelmistokehityksen ja siihen jopa rohkaistaan, jos asiakas pystyy muuttamalla vaatimusmäärittelyä saavuttamaan kilpailuetua.

Rakennamme projektit motivoituneiden yksilöiden ympärille. Annamme heille ympäristön ja tuen, jota he tarvitsevat, ja luotamme siihen, että he saavat työn tehtyä.

Parhaat arkkitehtuurit, vaatimukset ja suunnitelmat syntyvät itseorganisoituvissa tiimeissä.

Ketterät periaatteet luottavat siihen, että kun ohjelmistokehittäjille annetaan sopiva työskentely-ympäristö, he tekevät parhaansa toimittaakseen asiakkaalle arvokkaan sovelluksen ilman tarvetta ulkoiselle kontrolloinnille. Ei ole tarvetta myöskään erillisille vaatimuksia keräävän analyytikon tai suunnittelusta huolehtivan ohjelmistoarkkitehdin rooleille, softatiimit osaavat toimia parhaiten itseorganisoitumalla, eli päättämällä itse toimintamenetelmistään. Tämän voi ajatella myös niin, että jos näitä rooleja omaavia ihmisiä on, he työskentelevät osana tiimejä eikä erillisissä tiimeissä.

Tiimi tarkastelee säännöllisin väliajoin, kuinka toimia tehokkaammin, ja mukauttaa toimintaansa sen mukaisesti.

Aiemmin mainittu periaate Otamme muuttuvat vaatimukset vastaan… siis kuvailee, että ketterä mahdollistaa ja suorastaan kannustaa tuotteen kehityssuunnan muuttamisen uusien tarpeiden ilmetessä. Vastaavasti kehitystiimin odotetaan tarkastelevan omaa toimintaansa ja muokkaavan sitä jatkuvasti parempaan suuntaan.

Yksinkertaisuus – tekemättä jätettävän työn maksimointi – on olennaista.

Vesiputousmalli ja muut vanhemmat kehitysmenetelmät antoivat suuren painoarvon dokumentaatiolle ja erilaisille “prosessin määräämille” raporteille, joihin käytettiin paljon aikaa ja vaivaa, ilman että ne olisivat kuitenkaan kovin paljoa edistäneet itse tuotteen valmistumista. Ketterissä menetelmissä ideana on eliminoida mahdollisimman pitkälle kaikki mikä ei ole primääristen tavoitteiden kannalta oleellista (Toimiva ohjelmisto on ensisijainen edistymisen mittari). Myös ohjelmistokehittäjillä on pyrkimys rakentaa ohjelmistoon tulevaisuuden varalta kaikenlaista ekstraa, myös tällaiseen tulisi ketterässä hengessä suhtautua kriittisesti.

Viimeiset kaksi periaatetta ovat ne, jotka tahtovat useimmiten unohtua:

Jatkuva huomio tekniseen laatuun ja hyvään suunnitteluun edistää ketteryyttä.

Ketterät menetelmät edistävät kestävää kehitystä. Tilaajien, kehittäjien ja käyttäjien tulisi pystyä ylläpitämään tasainen työtahti loputtomiin.

Ketteryys edellyttää että tiimi pystyy muuttamaan tarvittaessa sovelluskehityksen suuntaa uusien tarpeiden noustessa esiin. Tämä taas edellyttää, että tiimin on ylläpidettävä ohjelmiston laatua riittävällä tasolla. Jos sovellus on sisäiseltä rakenteeltaan huono purkkaviritys, on siitä koko ajan vaikeampi laajentaa uusilla toiminnallisuuksilla, erityisesti sellaisilla, joiden tarvetta ei aiemmin osattu ennakoida. Eli jos laatuun ei kiinnitetä riittävää huomiota, ketteryys menetetään, ja sovelluksen kehitys muuttuu erittäin hitaaksi. Tämä myös tarkoittaa sitä, että ohjelmistoa on suunniteltava riittävissä määrin. Ketterässä kehityksessä suunnittelu ei kuitenkaan tapahdu kerralla etukäteen, vaan jatkuvasti koko kehityksen ajan: rakennetta parannetaan refaktoroimalla sitä mukaa kun uusia tarpeita ilmenee. Ilman jatkuvaa huolenpitoa sovelluksen rakenteesta sovellukseen kertyy teknistä velkaa, eikä se pysy rakenteeltaan laadukkaana.

Tyypillisesti ohjelmistoprojekteihin saatetaan suhtautua deadlinevetoisesti, eli lähellä deadlinea siirrytään paniikinomaiseen ylityömoodiin, jotta toimiva tuote saadaan puristettua kasaan. Tämän jälkeen hengähdetään, mutta pian edessä on taas seuraava tärkeä deadline ja kun vuodet kuluvat loppuunpalamisenkin riski alkaa kasvaa. Kaikesta tästä on usein seurauksena myös huonolaatuista koodia, joka on päivä päivältä hankalammin muokattavaa.

Manifesti kuitenkin muistuttaa, että tällainen oravanpyörä ei ole välttämätön, ja suosittelee että sovellusta kehitettäisiin sellaisella nopeudella, joka on mahdollista ylläpitää vaikkapa ikuisesti.

Ketterät menetelmät ja Lean

Ketterät menetelmät on sateenvarjotermi useille eri menetelmille. 2000-luvun alkupuolella Extreme programming eli XP oli ketteristä menetelmistä suosituin. Nykyään hyvin harva soveltaa “oppikirjamaista” XP:tä, mutta sen käytänteistä monet ovat jääneet elämään ja ne on omaksuttu monien ohjelmistotiimien työkalupakkiin. Tutustumme moniin XP:n käytänteisiin kurssin aikana.

XP:ltä valta-aseman on ottanut pikkuhiljaa Scrum, joka lienee tällä hetkellä maailman eniten käytetty ohjelmistokehitysmenetelmä. Esimerkiksi vuosittain julkaistavan State of Agile -kyselyn mukaan Scrum on selvästi yleisin ketterien tiimien käyttämä menetelmä. Tutustumme Scrumiin tarkemmin seuraavassa luvussa.

Ketterä ohjelmistotuotanto on ottanut runsaasti vaikutteita Toyota production systemin taustalla olevasta lean-ajattelusta. Termi lean näkyykin usein termin agile rinnalla tai tilalla ohjelmistokehityksestä puhuttaessa. Leanista peräisin olevaa kanbania on ruvettu soveltamaan runsaasti ohjelmistokehitykseen. Usein se täydentää jotain ketterää menetelmää kuten Scrumia. Kanbanin ja Scrumin yhdistelmä kulkeekin nimellä Scrumban (termin lanseerasi Corey Ladas vuonna 2008). Monet tiimit käyttävät nykyään myös pelkkää kanbania, jolloin työ ei etene sprinteissä, vaan tasaisena virtana (The Kanban Guide). Palaamme Leaniin ja kanbaniin tarkemmin kurssin osassa 5.

Ketterät menetelmät on alun perin kehitetty yksittäisten, pienehköjen ohjelmistotiimien hallintaan. Ketterille menetelmille on 2000-luvun lopulta alkaen hahmoteltu useitakin laajennuksia mm. SAFe ja LeSS, joiden avulla on mahdollista hallinnoida useista ohjelmistotiimeistä koostuvia kokonaisuuksia. Ketterien periaatteiden lisäksi nämä laajemman skaalan kehitysmenetelmät nojaavat voimakkaasti leanin tarjoamiin periaatteisiin. Palaamme asiaan kurssin viidennessä osassa.

Ketterien menetelmien hyödyistä on myös tutkimusnäyttöä, joskin se on kirjavampaa kuin menetelmien markkinointi antaisi ymmärtää. Esimerkiksi Dybån ja Dingsøyrin systemaattinen kirjallisuuskatsaus (2008) löysi ketteryydestä useita hyötyjä mm. asiakasyhteistyöhön ja työtyytyväisyyteen liittyen, mutta totesi tutkimusten laadun olevan vaihtelevaa. Hodan, Sallehin ja Grundyn katsaus (2018) kuvaa, miten ketteryyden tutkimus on siirtynyt yksittäisten tiimien käytänteistä laajan skaalan ketteryyteen, DevOpsiin ja ketteryyden vaikutuksiin koko organisaatiossa.

Scrum

Tutustumme nyt ketteristä menetelmistä eniten käytettyyn, eli Scrumiin. Tarkastellaan ensin muutamaa perustavanlaatuista Scrumin ja muidenkin ketterien menetelmien taustalla olevaa perusolettamusta.

Suunnitelmavetoisista malleista ketteryyteen

Kuten aiemmin todettiin, vesiputousmallin perusongelma on, ettei vaatimuksia voi määritellä eikä ohjelmistoa suunnitella tyhjentävästi etukäteen, ja lopussa tapahtuva testaus paljastaa ongelmat liian myöhään.

80- ja 90-luvuilla kehitellyt iteratiiviset prosessimallit korjaavat monia näistä epäkohdista, mutta ne ovat kuitenkin vielä vahvasti suunnitelmavetoisia (engl. plan-based) ja olettavat, että ohjelmistotuotanto on jossain määrin kontrolloitavissa oleva prosessi.

Keskiössä oli siis tarkka projektisuunnitelma (joka toki iteratiivisissa malleissa saattoi elää) ja sen noudattaminen sekä selkeä roolijako: projektipäälliköt, analyytikot, arkkitehdit, ohjelmoijat, testaajat muodostavat kukin omiin vastuualueisiinsa liittyvät tiiminsä.

Ketterien menetelmien perusolettamuksia

Useimmat ohjelmistoprojektit ovat laadultaan uniikkeja. Vaatimukset ovat erilaiset kuin millään jo tehdyllä ohjelmistolla. Tekijät vaihtuvat usein, kukin tiimi on omanlaisilla kompetensseilla ja persoonallisuuksilla varustettu. Myös toteutusteknologiat kehittyvät koko ajan, joten uusia projekteja tehdään todennäköisesti tavalla, joka ei ole kaikille ohjelmistokehittäjille ennestään tuttu.

Näiden seikkojen takia ketterien menetelmien mukaan järkevää onkin lähteä oletuksesta, että kyseessä ei ole kontrolloitu prosessi, jonka eteneminen on mahdollista suunnitella etukäteen tarkasti. Parempi onkin ajatella ohjelmiston kehittäminen tuotekehitysprojektina, joka sisältää runsaasti epävarmuutta ja tuntemattomia seikkoja. Tällaisten projektien hallinnointiin sopii tarkkaan etukäteissuunnitelmaan perustuvan lähestymistavan sijaan empiirinen prosessi.

Empiirisessä prosessissa taustalla olevina periaatteina ovat läpinäkyvyys (transparency), tarkkailu (inspection) ja mukauttaminen (adaptation). On oleellista, että koko tiimi on mahdollisimman hyvin selvillä siitä, mitä tapahtuu ja mistä puhutaan, esim. mitä tarkoitetaan, kun jonkin asian sanotaan olevan valmiina. Projektiin liittyvien asioiden suhteen tulee siis vallita suuri läpinäkyvyys (transparency), joka taas mahdollistaa asioiden tilan jatkuvan tarkkailun (inspection), eli onko tuotteen kehitys menossa sinne suuntaan, mikä on asiakkaan nykyisen näkemyksen mukainen ja tukevatko tiimin käytänteet optimaalisella tavalla sovelluksen kehitystä. Jos ja kun asioissa havaitaan parannuksen varaa, mukautetaan (adaptation) tuotteen kehityssuuntaa tai tiimin toimintaperiaatteita.

Ketterien menetelmien oletuksena on myös, että perinteinen command-and-control-tyylinen ylhäältäpäin tapahtuva johtaminen ja ihmisten sekä tiimien jakaminen eri vastuualueisiin (suunnittelija, ohjelmoija, testaaja, frontend, backend) ei tuota optimaalista tulosta.

Sen sijaan oletetaan että ihmiset toimivat parhaiten itseorganisoituvissa (engl. self-organizing) tiimeissä, jossa tiimille annetaan työskentelyrauha ja uskotaan tiimin omaan kykyyn ottaa vastuu toiminnastaan. Itseorganisoituva tiimi toimii kollektiivina, kantaen yhteisen vastuun tekemisistään, eli tiimi onnistuu ja epäonnistuu yhdessä. Yhteinen vastuu edellyttää, että virheistä voi puhua ilman syyllistämistä, ks. psykologinen turvallisuus.

Scrumin taustaa

Tutustutaan nyt Scrumiin, joka on tällä hetkellä selvästi suosituin ketterä menetelmä/prosessimalli.

Termi Scrum ja osa sen taustalla olevista periaatteista löytyvät ensimmäistä kertaa 1986 julkaistusta artikkelista The new new product development game, missä japanilaiset professorit Takeuchi ja Nonaka kuvailevat mitä yhteisiä toimintaperiaatteita joukolla menestyneitä yrityksiä (mm. Fuji-Xerox, Canon, Honda, NEC, Epson, Brother, 3M, Xerox, Hewlett-Packard) on.

Tänä päivänä tuntemamme Scrum, joka alun perin suunnattiin ohjelmistokehitykseen, kehitettiin Ken Schwaberin ja Jeff Sutherlandin toimesta 1990-luvun puolivälissä. Scrumin perussisällön määrittelee The Scrum guide, 13-sivuinen dokumentti, joka päivittyy aika ajoin. Voimassa oleva versio on vuodelta 2020. Kesällä 2025 Jeff Sutherland julkaisi yhdessä Ralph Jochamin ja John Colemanin kanssa Scrum Guidea täydentävän, huomattavasti laajemman Scrum Guide Expansion Packin, joka käsittelee mm. tuoteajattelua ja tekoälyn roolia Scrum-tiimeissä. Se ei korvaa Scrum Guidea, vaan on vapaaehtoinen lisäosa.

Kehittäjiensä sanoin

Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.

Scrumin kehittäjät mainitsevat, että kyseessä on framework, eli menetelmäkehys, jonka avulla monimutkaisten tuotteiden kehitystä voidaan hallita siten, että asiakkaalle saadaan tuotteista maksimaalinen arvo. Scrumin kehittäjät korostavat, että kyseessä ei ole prosessi (process) tai menetelmä/tekniikka (technique), joka yksistään antaisi riittävän ohjeiston työskentelylle. Vuoden 2020 Scrum Guiden mukaan Scrum on tarkoituksella ei-kattava (engl. purposefully incomplete), eli se määrittelee vain ne osat, jotka ovat välttämättömiä Scrumin toteuttamiseksi. Kyseessä on siis menetelmäkehys, joka antaa kehityksen suuntaviivat mutta mahdollistaa ja oikeastaan edellyttääkin muitakin menetelmiä ja tekniikoita, jotka kukin tulee valita tapauskohtaisesti.

Scrumin tärkein tavoite on tehdä käytettyjen työskentelymenetelmien suorituskyky näkyväksi ja mahdollistaa näin ollen tuotteen sekä työskentely-ympäristön jatkuva parantaminen, eli edellä mainittu kolmikko transparency, inspection ja adaptation, läpinäkyvyys, tarkkailu ja mukautuminen ovat Scrumin keskiössä.

Scrum Guiden aiemmat versiot kuvasivat Scrumin olevan

• Lightweight
• Simple to understand
• Extremely difficult to master

Vaikka luonnehdinta on jätetty vuoden 2020 Scrum Guidesta pois, pitää se edelleen paikkansa. Toisin kuin jotkin muut ohjelmistokehitysmallit (kuten vuosituhannen vaihteessa suosittu Rational Unified Process tai laajan skaalan kehitykseen tarkoitettu SAFe), Scrum sisältää ainoastaan muutaman “säännön”, joiden määritelmän sisältävän Scrum Guiden lukee puolessa tunnissa. Kaikki vaikuttaa selkeältä ja yksinkertaiselta, mutta todellisuus on usein toinen. Toimiakseen tehokkaasti Scrum vaatii syvällistä perehtymistä ja vuosien kokemusta. Pelkkä sääntöjen mekaaninen seuraaminen ei riitä.

Scrum lyhyesti

Scrum on iteratiivinen ja inkrementaalinen menetelmä tai kehittäjiensä mukaan menetelmäkehys (framework), jossa ohjelmistokehitys tapahtuu korkeintaan kuukauden mittaisissa iteraatioissa, joita Scrumissa kutsutaan sprinteiksi.

Kehityksestä vastaa Scrum-tiimi, johon kuuluvat kehittäjät (engl. developers), scrum master ja product owner. Tiimin koko on tyypillisesti korkeintaan kymmenen henkilöä. Scrum master auttaa tiimiä mm. prosessin noudattamisessa ja parantamisessa sekä esteiden poistamisessa. Product owner eli tuotteenomistaja hallinnoi projektin backlogia, joka sisältää priorisoidussa järjestyksessä projektissa toteutettavalle ohjelmistolle asetetut vaatimukset.

Jokaisen sprintin alussa tiimi valitsee projektin backlogista sprintin aikana toteutettavat vaatimukset, eli ne toiminnallisuudet, jotka sprintin aikana on tarkoitus toteuttaa. Sprintin aikana Scrum-tiimi toteuttaa itseohjautuvasti sprinttiin valitut vaatimukset lopputuloksena vaatimusten osalta toimiva ohjelmisto.

Scrum: vastuut, artefaktit ja eventit

Käydään vielä läpi hieman seikkaperäisemmin Scrumin terminologiaa ennen kun mennään tarkempiin yksityiskohtiin.

Scrum määrittelee kolme erilaista vastuuta (engl. accountability): kehittäjät (engl. developers), scrum masterin ja product ownerin. Aiemmin Scrum Guide puhui rooleista, vuoden 2020 versio korvasi termin vastuilla korostaakseen, että kyse ei ole työnimikkeistä vaan siitä, kuka vastaa mistäkin. Product ownerille on kohtuullisen vakiintunut suomennos tuotteenomistaja, käytämme kuitenkin kurssilla pääosin englanninkielistä termiä.

Scrumiin kuuluvat artefaktit eli “konkreettiset asiat” ovat product backlog eli tuotteen kehitysjono, sprint backlog eli sprintin tehtävälista sekä increment eli valmiiksi saatu, käyttökelpoinen lisäys ohjelmistoon. Jokaiseen artefaktiin liittyy sitoumus (engl. commitment), joka antaa artefaktille suunnan ja jota vasten edistymistä voidaan arvioida:

• product backlogiin liittyy tuotteen tavoite (engl. product goal)
• sprint backlogiin liittyy sprintin tavoite (engl. sprint goal)
• incrementiin liittyy valmiin määritelmä (engl. definition of done)

Scrumissa tekeminen rytmittyy sprintteihin eli korkeintaan kuukauden mittaisiin iteraatioihin. Sprintteihin kuuluu muutamia standardipalavereja: sprintin suunnittelupalaveri, daily scrum -palaverit, sprintin katselmointi sekä retrospektiivi. Scrum Guide kutsuu näitä tapahtumiksi (engl. events), ja myös sprintti itse on tapahtuma, joka sisältää kaikki muut. Tapahtumia on siis kaikkiaan viisi.

Product backlog

Product backlog (jonka suomenkielinen, mutta harvoin käytetty käännös on tuotteen kehitysjono) on priorisoitu lista asiakkaan tuotteelle asettamista vaatimuksista eli toivotuista ominaisuuksista ja toiminnoista. Backlog voi sisältää myös esimerkiksi isompia bugikorjauksia.

Backlogin sisältämät asiat tähtäävät tuotteen tavoitteeseen (engl. product goal), joka kuvaa tuotteen tavoiteltua tulevaa tilaa. Tuotteen tavoite on pidemmän aikavälin päämäärä, jota kohti sprintit yksi kerrallaan vievät.

Hyvänä käytänteenä pidetään sitä, että backlogille kirjatut vaatimukset ovat asiakkaan tasolla mielekkäitä, arvoa tuottavia toiminnallisuuksia, esim. verkkokaupassa toiminnallisuus voisi olla ostoksen voi lisätä ostoskorille, tai opintohallintojärjestelmässä opiskelija voi ilmoittautua HOPS:iin lisäämälleen kurssille. Kaikkia ohjelmistokehitykseen liittyviä tehtäviä ei saa ainakaan helposti muotoiltua asiakkaan tasolla mielekkäänä toiminnallisuutena. Esim. ohjelmiston rakenteen muokkaamiseen liittyvä refaktorointi voi olla tällainen. Nämä tulee joka tapauksessa merkata backlogille, muuten läpinäkyvyys vaarantuu.

Backlogin kärjessä eli korkeimmilla prioriteetilla olevat vaatimukset valitaan toteutettavaksi seuraavan sprintin aikana. Tämän takia backlogin kärjessä olevat vaatimukset on yleensä kirjattu tarkemmin kuin backlogin häntäpään vaatimukset.

Backlogia ylläpidetään ja tarkennetaan jatkuvasti, tätä kutsutaan nimellä backlog refinement. Usein on tarkoituksena myös estimoida eli arvioida backlogissa olevien vaatimusten toteuttamisen vaatima työmäärä. Työmääräarviot tekevät kehittäjät. Scrum Guide ei määrää arviointitekniikkaa. Yleisiä tapoja ovat esim. ns. story pointit, mutta osa tiimeistä luopuu arvioinnista kokonaan ja pyrkii sen sijaan pilkkomaan työn tasakokoisiin pieniin osiin (ns. #NoEstimates-liike). Palaamme estimointiin osassa 2.

Scrum ei määrittele, missä muodossa backlog ja siinä olevat vaatimukset esitetään. Vakiintunut käytäntö on esittää vaatimukset ns. user storyinä, joihin tutustumme osassa 2.

Product owner

Product backlogia hallinnoi product owner eli tuotteen omistaja, joka päättää mitä backlogille voidaan lisätä, sekä priorisoi backlogilla olevat vaatimukset.

Product owner on Scrumin mukaan yksittäinen henkilö, ei komitea. Priorisointiin voi toki olla vaikuttamassa useampikin henkilö, mutta product owner tekee lopulliset päätökset prioriteettien suhteen.

Product owner vastaa tuotteen tavoitteen määrittelemisestä ja kommunikoinnista, backlogista ja täten kehityksen suunnasta, eli siitä mitä sovellukseen ollaan tekemässä ja missä järjestyksessä. Product ownerin tehtävänä on priorisoida product backlogilla olevat vaatimukset siten, että sovelluksen tilaaja/asiakas saa tuotteesta maksimaalisen hyödyn. Jotta product owner pystyy tähän, on hänen luonnollisesti kommunikoitava mahdollisimman laajalti kaikkien sovelluksen sidosryhmien kanssa.

Product ownerin vastuulla on myös varmistua siitä, että kehittäjät varmasti ymmärtävät toteutettavaksi valitut vaatimukset.

Product ownerin tehtävää tarkastellaan nykyään usein tuoteajattelun (engl. product thinking) näkökulmasta. Keskeistä on erottaa toisistaan tuotos (engl. output) eli valmistuneet ominaisuudet ja vaikutus (engl. outcome) eli muutos käyttäjien toiminnassa tai liiketoiminnassa, jota ominaisuuksilla tavoitellaan. Toteutettujen ominaisuuksien määrä ei vielä kerro, onko ohjelmistosta ollut hyötyä. Myös Scrumin tuotteen tavoite (product goal) kuvaa tavoiteltua tilaa eikä listaa toteutettavia ominaisuuksia. Palaamme käyttäjien todellisten tarpeiden selvittämiseen osassa 2.

Scrum master

Jokaisella Scrum-tiimillä on scrum master, eli henkilö, joka vastaa siitä että Scrumin pelisääntöjä ja henkeä noudatetaan kehitystyössä. Scrum master vastaa myös Scrum-tiimin tehokkuudesta. Scrum master ei kuitenkaan ole perinteinen projektipäällikkö, vaan pikemminkin ryhmää tukeva valmentaja. Aiemmin scrum masteria luonnehdittiin termillä servant leader, vuoden 2020 Scrum Guide puhuu todellisista johtajista, jotka palvelevat (engl. true leaders who serve) Scrum-tiimiä ja laajempaa organisaatiota.

Scrum masterin tehtävänä on muun muassa opastaa ryhmää hyvien käytänteiden noudattamisessa sekä rohkaista ja auttaa tiimiä itseohjautuvuudessa sekä työskentelytapojen parantamisessa. Scrum master hoitaa myös käytännön asioita, esim. järjestää Scrumiin liittyviä palavereja ja koordinoi kommunikointia sidosryhmiin päin.

Scrum masterin ehkä keskeisin tehtävä on pyrkiä eliminoimaan kehitystyön esteitä. Esteenä on usein jokin tiimistä riippumaton asia, jonka poistamiseksi scrum master joutuu neuvottelemaan yrityksen hallinnon tai muiden ohjelmistotiimien kanssa. Tällaisen esteen voi muodostaa myös esimerkiksi se, että sovelluskehitystiimillä ei ole pääsyä tuotantoympäristöön tai edes vastaaviin palvelinympäristöihin, tai jos kehitettävä sovellus on riippuvainen muiden toimittajien vastuulla olevista rajapinnoista, ja ne eivät valmistu ajoissa tai toimi määritelmien mukaan.

“Este” voi myös liittyä ryhmän työskentelytapoihin, tällöin scrum master opastaa ryhmää muuttamaan toimintaansa siten, että tuottavuutta haittaava este poistuu.

Scrum masterin tehtävänä on myös taata kehittäjille työrauha ja suojata tiimiä esim. ulkopuolisten yrityksiltä puuttua sprintin aikaiseen toimintaan.

Joissain tilanteissa scrum master toimii product ownerin apuna product backlogin ylläpitämisessä, tämä on tärkeää erityisesti silloin jos product owner on kokematon ja ei vielä osaa optimaalisella tavalla muotoilla backlogille lisättäviä käyttäjien sovellukselle asettamia vaatimuksia.

Scrum master siis pyrkii tekemään kaikkensa, jotta tiimillä olisi optimaaliset olosuhteet asiakkaalle arvoa tuottavan sovelluksen kehittämiseen.

Kehittäjät

Kehittäjät (engl. developers) ovat ne Scrum-tiimin jäsenet, jotka tekevät jokaisessa sprintissä käyttökelpoisen lisäyksen ohjelmistoon. Aiemmat Scrum Guiden versiot puhuivat erillisestä kehitystiimistä, jonka kooksi määriteltiin 3-9 henkilöä. Vuoden 2020 versiossa on enää yksi Scrum-tiimi, jonka koko product owner ja scrum master mukaan lukien on tyypillisesti korkeintaan kymmenen henkilöä. Tiimin sisällä ei ole alitiimejä eikä hierarkioita.

Vaikka kaikista käytetään nimikettä developer, voivat jotkut tiimin jäsenistä olla erikoistuneita tiettyyn osa-alueeseensa, esim. testaamiseen, tai backend-ohjelmointiin. Koko tiimi kuitenkin kantaa aina yhteisen vastuun kehitystyöstä.

Scrum-tiimien tulee olla cross-functional, eli tiimin tulisi pitää sisällään kaikki tarvittava osaaminen järjestelmän suunnitteluun, toteuttamiseen, testaamiseen ja jopa tuotantoympäristössä operoimiseen.

Tiimit ovat autonomisia, eli periaatteena on että tiimiä ei johdeta ulkopuolelta vaan kehittäjät päättävät, miten paljon vaatimuksia backlogista valitaan sprintissä toteutettavaksi. Tiimi päättää myös itse kuka tekee mitä, milloin ja miten sprintin tavoite saavutetaan. Vuoden 2020 Scrum Guide kuvaa tiimiä termillä itseohjautuva (engl. self-managing), aiemmin käytössä oli termi itseorganisoituva (engl. self-organizing). Pelkkä autonomia ei kuitenkaan riitä: itseohjautuvuus toimii parhaiten, kun tiimin jäsenet luottavat toisiinsa.

Scrum Guide ei ota kantaa siihen, missä tiimi työskentelee. Pitkään ideaalina pidettiin sitä, että tiimi työskentelee samassa tilassa ja täysipäiväisesti samassa tiimissä. Nykyään yhä useampi tiimi toimii hybridi- tai etämallilla, mikä korostaa sovittujen kommunikaatiokäytäntöjen ja läpinäkyvyyttä tukevien työkalujen merkitystä.

Sprintti

Scrumissa kehitystyö siis jakautuu korkeintaan kuukauden mittaisiin iteraatioihin eli sprintteihin. Sprintin kesto on projektissa tyypillisesti aina sama, nykyään suosituin sprintin pituus lienee 2 viikkoa. Sprintti on “time-boxed”, eli sprinttiä ei missään olosuhteissa pidennetä kesken sprintin. Ainoastaan product owner voi perua sprintin, jos sprintin tavoite käy tarpeettomaksi.

Jokaisen sprintin alussa tiimi valitsee projektin backlogista sprintin aikana toteutettavat vaatimukset. Backlog on product ownerin toimesta priorisoitu ja vaatimukset valitaan aina priorisoidun listan kärjestä. Product owner siis näin ohjaa sen missä järjestyksessä asioita toteutetaan. Kehittäjät kuitenkin valitsevat itse sprinttiin ainoastaan sen verran toteutettavaa, minkä he arvioivat saavansa valmiiksi.

Sprintin aikana Scrum-tiimi toteuttaa itseohjautuvasti sprinttiin valitut ohjelmiston toiminnallisuudet.

Scrumissa periaatteena on, että jokaisen sprintin aikana saadaan aikaan ainakin yksi increment eli käyttökelpoinen, valmis lisäys tuotteeseen. Sprintin aikana on siis tarkoitus saada aikaan käyttöön valmiita ominaisuuksia, ei ainoastaan kasaa melkein toimivaa koodia. Incrementtejä voi syntyä sprintin aikana useita, ja niitä voidaan toimittaa käyttäjille jo ennen sprintin loppua. Sprintin lopun katselmointia ei siis pidä nähdä porttina, jonka jälkeen vasta julkaistaan.

Sprintin aikana ei tehdä muutoksia, jotka vaarantaisivat sprintin tavoitteen, eikä laadusta tingitä. Sprintin sisältöä voidaan kuitenkin tarkentaa ja neuvotella uudelleen product ownerin kanssa, kun toteutettavasta asiasta opitaan lisää. Scrum master suojelee tiimiä, jos joku ulkopuolinen yrittää saada kehittäjät tekemään sprintin aikana muuta kuin sprintin tavoitteen kannalta oleellisia asioita.

Definition of done

Eräs ketterän manifestin periaatteista nostaa ohjelmiston laadun ketteryyttä edistäväksi seikaksi

Jatkuva huomio tekniseen laatuun ja hyvään suunnitteluun edistää ketteryyttä.

Myös Scrum asettaa suuren painoarvon tuotetun ohjelmiston laadulle. Jokaisessa sprintissähän lopputuloksena tulee olla increment, eli valmiiksi tehty, käyttöön valmis osa ohjelmistoa.

Jotta vallitsisi yksimielisyys siitä, minkälaisella laatutasolla ohjelmistoa on toteutettava, määritellään Scrumissa definition of done, suomeksi valmiin määritelmä, eli se mitä tarkoittaa, että jokin vaatimus on toteutettu valmiiksi. Jos organisaatiolla on yhteinen valmiin määritelmä, sitä noudatetaan, muussa tapauksessa Scrum-tiimi laatii sen itse. Jos samaa tuotetta kehittää useampi tiimi, niillä on yhteinen valmiin määritelmä.

Valmiiksi tehty määritellään useimmiten tarkoittamaan sitä, että vaatimus on analysoitu, suunniteltu, ohjelmoitu, testattu, testaus automatisoitu, dokumentoitu, integroitu muuhun ohjelmistoon ja viety tuotantoympäristöön. Valmiin määritelmä siis parhaassa tapauksessa on määritelty niin, että kun asian sanotaan olevan valmis, ei siihen liity enää yhtään ekstratyötä.

Kun sprintin lopussa tavoitteena on olla toimiva ohjelma, tarkoitetaan sillä nimenomaan definition of donen tasolla toimivia ja valmiiksi toteutettuja vaatimuksia. Jos jokin backlogin vaatimus ei täytä definition of donea, sitä ei voi julkaista eikä edes esitellä sprintin katselmoinnissa, vaan se palaa product backlogiin myöhemmin toteutettavaksi.

Jos sprintin aikana osoittautuu että tiimi ei ehdi toteuttamaan kaikkea suunniteltua, ei ole hyväksyttävää tinkiä laadusta, vaan osa vaatimuksista jätetään seuraavaan sprinttiin.

Definition of done on eräs tapa millä Scrum pyrkii läpinäkyvyyteen, koska ketterässä ohjelmistokehityksessä tärkein edistymisen mittari on valmiina oleva ohjelmisto, on erittäin tärkeää, että kaikilla on sama näkemys mitä “valmis” tarkoittaa. Asia ei nimittäin ole ollenkaan itsestäänselvä, jos sitä ei tarkkaan määritellä. On melko yleistä, että kun ohjelmistokehittäjä ilmaisee jonkun ominaisuuden olevan kahden päivän ohjelmoinnin jälkeen “melkein valmis”, kestää lopulta parikin viikkoa ennen kun asia on kokonaan valmis siinä mielessä että sovelluksen asiakkaat pääsevät käyttämään uutta ominaisuutta.

Sprintin suunnittelu

Ennen jokaista sprinttiä järjestetään sprint planning eli sprintin suunnittelukokous.

Vuoden 2020 Scrum Guide määrittelee sprintin suunnittelulle kolme aihetta (engl. topic): miksi sprintti on arvokas, mitä sprintissä voidaan saada valmiiksi ja miten valittu työ tehdään.

Ensimmäisenä aiheena on selvittää, miksi sprintti on arvokas. Product owner ehdottaa, miten sprintti voisi lisätä tuotteen arvoa ja edistää tuotteen tavoitetta, ja koko Scrum-tiimi muotoilee yhdessä sprintin tavoitteen (engl. sprint goal).

Toisena aiheena on selvittää mitä sprintin aikana tehdään. Product owner esittelee tiimille product backlogin kärjessä olevia vaatimuksia. Tiimin tulee päästä selvyyteen vaatimuksista sillä tasolla, että heidän on vähintäänkin summittaisesti mahdollista arvioida kuinka paljon vaatimuksen toteuttaminen vaatisi resursseja, sillä tiimin tulee arvioida kuinka monta backlogin vaatimuksista se kykenee sprintin aikana toteuttamaan definition of donen määrittelemällä laadulla.

Sprintin tavoite on yksittäisiä vaatimuksia geneerisempi ilmaus siitä, mitä tulevassa sprintissä on tarkoitus saada aikaan. Se antaa kehittäjille joustavuutta, sillä sprintin tavoitteen saavuttamiseksi tarvittavaa työtä voidaan tarkentaa sprintin kuluessa.

Suunnittelukokouksen kolmantena aiheena on selvittää miten sprintin tavoite saavutetaan.

Tämä yleensä tarkoittaa, että tiimi suunnittelee toteutettavaksi valitut vaatimukset tarvittavalla tasolla. Tämän vaiheen tuotoksena on usein lista tehtävistä (engl. task), jotka sprintin aikana on toteutettava, jotta sprinttiin valitut vaatimukset saadaan toteutettua. Suunnittelun aikana identifioidut tehtävät kirjataan sprintin backlogiin eli sprintin tehtävälistaan.

Toisin kuin “asiakkaan kielellä” kirjoitettu product backlog, sprintin backlogilla olevat asiat on usein ilmaistu sovelluskehittäjien kielellä, ja sisältävät monia teknisen tason asioita, jotka eivät vielä itsessään ole asiakkaan kannalta kiinnostavia. Sprint backlog onkin ennen kaikkea scrum-tiimin sovelluskehittäjien työnteon organisoinnin väline.

Sprint planningin maksimikesto on 8 tuntia kuukauden mittaisessa sprintissä, lyhyemmissä sprinteissä kokous on yleensä lyhyempi.

Palaamme sprintin suunnitteluun tarkemmin ja konkreettisten esimerkkien kanssa osassa 2.

Daily scrum – päiväpalaveri

Sprintin jokaisena työpäivänä pidetään daily scrum eli korkeintaan 15 minuutin mittainen palaveri. Palaveri on tarkoitettu kehittäjille, ja se pidetään aina samaan aikaan ja samassa paikassa. Usein palaveri pidetään aamulla, mutta Scrum Guide ei tätä edellytä.

Vuoden 2020 Scrum Guide määrittelee daily scrumin tarkoituksen seuraavasti:

• Daily scrumin tarkoituksena on tarkastella edistymistä kohti sprintin tavoitetta ja mukauttaa sprintin backlogia tarvittaessa, eli muokata tulevaa suunniteltua työtä.
• Kehittäjät voivat valita palaverille haluamansa rakenteen ja tekniikat, kunhan daily scrum keskittyy edistymiseen kohti sprintin tavoitetta ja tuottaa konkreettisen suunnitelman seuraavan työpäivän työlle.

Daily scrum ei siis ole pelkkä statuspalaveri, vaan osa Scrumin inspect-and-adapt-sykliä: asioiden tilaa tarkastellaan päivittäin, ja kehitystyötä suunnataan tarvittaessa uudelleen, jotta sprintin tavoite pystytään edelleen saavuttamaan.

Uusin Scrum Guide ei määrää palaverin muotoa, mutta Scrum Guiden aiempien versioiden suosittelema kolmen kysymyksen malli on edelleen yleinen. Siinä jokainen kehittäjä vastaa vuorollaan kysymyksiin

• Mitä sain aikaan edellisen tapaamisen jälkeen?
• Mitä aion saada aikaan ennen seuraavaa tapaamista?
• Mitä esteitä etenemiselläni on?

Mallissa on riskinä, että palaveri muuttuu yksittäisten kehittäjien raportoinniksi. Kysymyksiä kannattaakin tarkastella sprintin tavoitteen näkökulmasta. Esteistä kertominen puolestaan edellyttää, että tiimissä uskalletaan myöntää olevansa jumissa.

Palaverin on tarkoitus olla lyhyt, ja liian rönsyilevä keskustelu ei ole suotavaa. Jos joillakin ilmenee ongelmia tai etenemisen esteitä, niihin palataan tarkemmin daily scrumin jälkeen. Scrum Guiden mukaan kehittäjät kokoontuvatkin usein heti päiväpalaverin perään tarkempiin keskusteluihin.

Jos muuhun palaverointiin, esim. suunnitteluun tai vaatimusten tarkentamiseen on tarvetta, tulee palaverit järjestää daily scrumista erillään. Scrum ei ota kantaa muihin sprintin aikaisiin palavereihin.

Sprintin katselmointi

Sprintin päätteeksi järjestetään sprint review eli katselmointi. Katselmointi on informaali tilaisuus, jonka aikana Scrum-tiimi esittelee sprintin aikaansaannoksia kaikille kehitettävästä tuotteesta kiinnostuneille sidosryhmille.

Katselmoinnissa on tarkoituksena tarkastella, demota ja kokeilla toteutettua, toimivaa ohjelmistoa. Scrum Guiden mukaan katselmointi on työskentelysessio, jota ei pidä rajata pelkäksi esitykseksi. Diaesityksen sijaan katselmoinnissa kannattaa siis näyttää toimivaa ohjelmistoa ja keskustella siitä.

Katselmoinnissa demonstroidaan ainoastaan niitä ominaisuuksia, jotka on toteutettu kokonaan eli definition of donen tasolla. Näin pyritään antamaan mahdollisimman realistinen kuva siitä miten sovelluksen kehitys etenee.

Yleinen käytäntö on, vaikka Scrum Guide ei tätä erikseen mainitse, että product owner varmistaa (joko katselmoinnissa tai ennen sitä), mitkä sprintissä kehitetyistä vaatimuksista on toteutettu hyväksyttävällä tavalla, eli että ne toimivat oletusten ja odotusten mukaan sen lisäksi että ne on toteutettu definition of donen määrittelemällä laatutasolla. Ne vaatimukset, joita ei hyväksytä toteutetuksi, siirretään takaisin product backlogiin viimeisteltäväksi myöhempien sprinttien aikana.

Katselmoinnin aikana sidosryhmät antavat palautetta tuotteesta ja voivat esimerkiksi ehdottaa uusia vaatimuksia lisättäväksi product backlogiin. Samalla arvioidaan edistymistä kohti tuotteen tavoitetta. Katselmointi aiheuttaa usein myös tarpeen product backlogin osittaiseen uudelleenpriorisointiin.

Myös katselmoinnin kesto on rajoitettu: enintään neljä tuntia kuukauden mittaisessa sprintissä, lyhyemmissä sprinteissä yleensä vähemmän.

Retrospektiivi

Eräs ketterän manifestin periaatteista toteaa seuraavasti

Tiimi tarkastelee säännöllisin väliajoin, kuinka toimia tehokkaammin, ja mukauttaa toimintaansa sen mukaisesti.

Scrumissa jokaisen sprintin päätteeksi pidettävä retrospektiivi ilmentää tätä periaatetta. Siinä missä Scrumin muut palaverit on tarkoitettu enimmäkseen tuotteen suunnan tarkasteluun, retrospektiivissä Scrum-tiimi tarkastelee nimenomaan omaa työskentelyprosessiaan. Retrospektiivin maksimikesto on kolme tuntia kuukauden mittaisessa sprintissä.

Tarkoituksena on identifioida mikä meni hyvin ja missä asioissa on parantamisen varaa. Palaverissa mietitään ratkaisuja joihinkin ongelmakohtiin, joita pyritään korjaamaan seuraavan sprintin aikana. Retrospektiivistä on hyötyä vasta, kun ongelmia voi nostaa esiin syyllisiä etsimättä: tarkastelun kohteena on prosessi, ei yksittäiset ihmiset.

Aikojen saatossa on kehitetty lukuisia tekniikoita retrospektiivien pitämiseen, ja esim. Retromat kokoaa satoja valmiita retrospektiiviharjoituksia. Palaamme niihin laskareiden yhteydessä.

Scrumin periaatteet: transparency - inspection - adaptation

Kuten aiemmin mainittiin, on Scrumin takana kolme periaatetta, läpinäkyvyys (transparency), tarkkailu (inspection) ja mukauttaminen (adaptation). Retrospektiivi on nimenomaan kehitysprosessin tarkkailun ja mukauttamisen väline.

Kehitettävän tuotteen tarkkailua ja suunnan mukauttamista tukevat useat Scrumin työkalut. Näitä ovat esimerkiksi lyhyt, sprinteissä etenevä kehityssykli, product backlog, jota voidaan tarvittaessa priorisoida uudelleen, sekä säännölliset palaverit.

Tarkkailun ja mukauttamisen mahdollistaa läpinäkyvyys, eli asioita ei piilotella, vaan sekä tuotteen kehityssuunta, valmiin määritelmä että menossa olevan sprintin status pidetään koko ajan avoimesti kaikkien nähtävillä ja asioista keskustellaan sekä sprintittäisellä että päivittäisellä tasolla.

Toisin sanoen asioiden läpinäkyvyys mahdollistaa niiden jatkuvan tarkkailun ja sen seurauksena sekä toimintatapoja että kehitettävää tuotetta on mahdollista mukauttaa haluttuun suuntaan.

Scrumin arvot

Scrum guide nostaa esiin myös joukon arvoja (engl. values) oleellisena seikkana sen taustalla että oikeanlainen mentaliteetti tehokkaaseen sovelluskehitykseen pääsee syntymään.

When these values are embodied by the Scrum Team and the people they work with, the empirical Scrum pillars of transparency, inspection, and adaptation come to life building trust.

Arvoja on viisi: commitment, focus, openness, respect ja courage.

Tiimin tulee olla sitoutunut (commitment) yhteisen tavoitteen saavuttamiseksi ja fokusoitua oikeiden asioiden tekemiseen. Tulee olla myös rohkeutta tehdä päätöksiä ja kohdata myös vaikeimpia asioita, eli tulee olla avoimia sekä onnistumisten että ongelmien suhteen kuitenkin kunnioittaen koko ajan kaikkia tiimin jäseniä sekä ohjelmiston sidosryhmiä.

Syksyllä 2019 julkaistu A Scrum book toteaa, että arvojen kautta syntyy fertile soil, eli hedelmällinen maaperä, jonka ansiosta sovelluskehityksen on mahdollista kukoistaa.

Scrumin ei siis pidä missään tapauksessa olla Scrum Guiden ohjeiden orjallista noudattamista. Jotta Scrum toimisi, tarvitaan sen soveltamiseen sopivanlainen asenne ja orientaatio. Scrumin tarkkailuun ja mukauttamiseen perustuva luonne jopa ohjaa siihen, että tiimien kannattaa jossain vaiheessa toimia joidenkin Scrumin ohjeiden vastaisesti, jos tiimin optimaalinen toiminta sitä vaatii.

Psykologinen turvallisuus

Scrumin arvoista avoimuus, kunnioitus ja rohkeus ohjaavat rehtiin ja läpinäkyvään kommunikointiin ja vuorovaikutukseen. Jos arvot eivät kuitenkaan toteudu tiimissä, on yhden henkilön raskasta pyrkiä näihin arvoihin. Tätä ilmiötä kuvaa käsite psykologinen turvallisuus (engl. psychological safety), jonka Amy Edmondson vuonna 1999 määritteli tiimin jäsenten yhteiseksi käsitykseksi siitä, että tiimissä on turvallista ottaa ihmissuhteisiin liittyviä riskejä. Tällaisia riskejä ovat esim. kysyminen, oman osaamattomuuden tai virheen myöntäminen, eriävän mielipiteen esittäminen ja ongelmien esiin nostaminen. Psykologinen turvallisuus ei tarkoita, että kaikki ovat aina samaa mieltä, vaan sitä, että erimielisyydestä uskalletaan puhua. Esimerkiksi Googlen omien tiimiensä tehokkuutta selvittäneessä tutkimuksessa psykologinen turvallisuus todettiin tärkeimmäksi tekijäksi tiimien onnistumisessa.

Ketterät käytänteet ja psykologinen turvallisuus vahvistavat toisiaan. Retrospektiivi ja daily scrum edellyttävät, että niissä uskalletaan kertoa ongelmista, ja toisaalta käytänteet itse rakentavat turvallisuutta. Ketterissä ohjelmistotiimeissä psykologista turvallisuutta tukevat erityisesti syyllistämisen välttäminen (engl. no blame), eli virheiden näkeminen prosessin eikä yksilöiden ongelmina, yhteinen päätöksenteko sekä avoimuus palautteelle ja kritiikille. Psykologista turvallisuutta ei voi vaatia tai pakottaa, vaan se rakentuu luottamuksesta tiimin jäseniin.

Psykologisen turvallisuuden kannalta merkittävää on se, miten tiimissä johdetaan. Johtaminen ei ole pelkästään esihenkilön tai scrum masterin tehtävä. Johtamista tapahtuu itseohjautuvassa tiimissä jatkuvasti, esim. silloin kun joku vetää palaveria, ehdottaa ratkaisua tai ottaa vastuun jonkin asian hoitamisesta, ja jokaisen käytös näissä tilanteissa vaikuttaa siihen, uskaltavatko muut puhua. Turvallisuutta tarvitaan myös toiseen suuntaan: aloitteen ottaminen on riski, ja se tuntuu luontevalta lähinnä silloin, kun muut arvostavat sitä. Tiimin jäsenten ei tarvitse olla ystäviä, mutta heidän on kunnioitettava toisiaan voidakseen luottaa toisiinsa.

Scrumin ongelmia

Scrum on osoittautunut monin paikoin paremmaksi tavaksi ohjelmistojen kehittämiseen kuin vesiputousmalli tai muut suunnitelmavetoiset mallit. Scrum ei kuitenkaan ole mikään silver bullet, eli yleispätevä resepti, joka ratkaisisi kaikki sovelluskehityksen ongelmat, ja Scrumin käytön yleistyessä myös epäonnistuneiden Scrum-projektien määrä kasvaa.

Yhtenä syynä ongelmiin sanotaan olevan ScrumBut:

• We use Scrum, but having a Daily Scrum every day is too much overhead, so we only have one per week.
• We use Scrum, but Retrospectives are a waste of time, so we don’t do them.
• We use Scrum, but we can’t build a piece of functionality in two weeks, so our Sprints are 3 months long

ScrumButilla siis viitataan siihen, että noudatetaan jotain Scrumin osa-alueita, mutta tehdään todella suuria kompromisseja joidenkin oleellisten osien suhteen ja näin ollen läpinäkyvyyden, tarkkailun tai mukauttamisen periaatteet vaarantuvat liikaa.

Hajautettu ohjelmistotuotanto, alihankkijoiden käyttö ja massiivista kokoluokkaa olevat projektit aiheuttavat edelleen haasteita Scrumille ja muillekin ketterille menetelmille, vaikkakin asiaan on sittemmin kiinnitetty paljon huomiota. Uncle Bob Martinin Scrum-kritiikki nostaa esiin nämä ja muutamia muitakin oleellisia seikkoja, jotka voi tiivistää neljään kohtaan:

• Tekniset käytänteet puuttuvat: Scrum on projektinhallinnan menetelmäkehys, eikä se anna teknisiä suosituksia, esim. automaattisesta testauksesta.
• Scrum masterin rooli: sertifikaatin suorittanut scrum master voi muuttua mikromanageroivaksi projektipäälliköksi.
• Itseohjautuvuuden ja skaalautumisen rajat: Scrum korostaa tiimien itseohjautuvuutta liikaa, eikä se kerro, miten toimitaan usean tiimin kanssa.
• Product backlogin hallinta: Scrum antaa liian vähän ohjeita product backlogin organisointiin.

Koska Scrum ei ota mitään kantaa ohjelmistokehityksen teknisiin periaatteisiin, on suurena riskinä se, että sovelluksen sisäiseen laatuun ei kiinnitetä riittävää huomiota, ja tämä taas saattaa rapauttaa ketteryyden. Kehitys ehkä etenee aluksi nopeasti, mutta hidastuu ajan myötä sovelluksen teknisen velan tehdessä sen laajentamisen yhä vaikeammaksi. Erityisesti tätä riskiä nostaa se jos projektissa ei ole automatisoituja testejä. Scrum ei ota mitään kantaa sovelluksen testaukseen.

Martin pitää scrum masterin roolia ongelmallisena monellakin tavalla. Ensinnäkin häntä hiertää sertifiointisysteemi, scrum mastereita pikakoulutetaan parin päivän kursseilla ja joskus scrum masterina toimiikin aiemmin projektimanagerin titteliä kantanut henkilö. Vaikka sertifikaatti on suoritettu, ei henkilön toimintatapaan ole välttämättä tullut muita muutoksia kuin uusi terminologia.

Vaikka Martin pelkää, että scrum masterit monesti ovat ainoastaan managereita valekaavussa, hän pitää ongelmallisena myös sitä, että Scrum olettaa tiimien olevan täysin itseorganisoituvia. Itseorganisoituminen toimii monissa konteksteissa ja joillakin tiimeillä, mutta sillä on rajansa, varsinkin jos tuotetta on tekemässä useita Scrum-tiimejä, voidaan ajautua ongelmiin jos luotetaan pelkkään itseorganisoitumiseen.

Monimutkaisen tuotteen hallinnoiminen on kompleksista, Scrum ei kuitenkaan ota millään tavalla kantaa product backlogin organisointiin ja jättää kehittäjät omilleen asian suhteen.

Uncle Bobin kritiikki on vuodelta 2010 mutta pitkälti validi edelleen. Myöhemmin kritiikkiä on esittänyt mm. ketterän manifestin allekirjoittaja Ron Jeffries, joka kuvaa kirjoituksessaan Dark Scrum (2016), miten Scrumista tulee helposti kehittäjiä kontrolloivan johdon väline. 2020-luvulla monet yritykset ovat myös vähentäneet erillisiä scrum master- ja agile coach -rooleja ja siirtäneet niiden tehtäviä tiimeille ja esihenkilöille. Psykologisen turvallisuuden näkökulmasta liiallinen kontrolli myös heikentää tiimin ketteryyttä, sillä ongelmista ja virheistä ei enää uskalleta puhua avoimesti.

Scrumin rinnalle erityisesti Suomessa suosituksi noussut Scaled agile framework eli SAFe itse asiassa tarjoaa monia lääkkeitä Martininkin esiin nostamiin ongelmiin. SAFe on kuitenkin saanut myös voimakasta kritiikkiä ja auktoritatiivisetkin tahot (kuten Scrumin kehittäjä Ken Schwaber kirjoituksessaan unSAFe at any speed) ovat jopa kyseenalaistaneet menetelmän ketteryyden. Tutustumme SAFeen pintapuolisesti osassa 5.

Scrum, kuten muutkin ketterät kehitystavat, ovat syntyneet pitkälti ohjelmistokehittäjien keskuudessa. Melko yleinen raportoitu ongelma ketterään kehitykseen siirryttäessä onkin se, että muu organisaatio jää täysin ennalleen. Tällöin tuloksena on usein nimikkeen waterscrumfall saanut kehitysmalli, missä ainoastaan ohjelman uusien toiminnallisuuksien kehitys tapahtuu Scrumia mukaillen, mutta budjetointi, vaatimusten hallinta sekä tuotantoonvienti etenevät edelleen vanhoja kontrolloituja prosesseja noudattaen.

Päätetään alustava Scrumiin tutustumisemme Scrum Guiden aiempien versioiden osuvaan kiteytykseen Scrum is easy to understand but extremely difficult to master.

Laajat kielimallit ohjelmistokehityksessä

Laajoihin kielimalleihin perustuvat työkalut, kuten ChatGPT, Claude ja GitHub Copilot, ovat muuttaneet ohjelmistokehitystä nopeasti. Alun koodin täydennyksestä ja chat-käyttöliittymistä on siirrytty agentteihin (esim. Copilotin Agent-tila, Claude Code ja Cursor), jotka osaavat itsenäisesti tehdä useisiin tiedostoihin ulottuvia muutoksia, suorittaa koodia ja testejä ja korjata tekemisiään virheilmoitusten perusteella.

Itse käytän koodatessa Claude Codea, mutta koska se on maksullinen, kurssilla käytetään GitHub Copilotia, joka on natiivisti integroitu VS Codeen. Yliopisto-opiskelijat saavat Copilot Student -version käyttöönsä ilmaiseksi GitHub Educationin kautta. Vaihtoehtoisesti tehtävät voi tehdä avoimen lähdekoodin OpenCode-agentilla CurreChatin kielimalleja käyttäen.

Kielimallien ehkä suurin ongelma on hallusinointi: ne generoivat välillä täysin vakuuttavan näköisiä vastauksia, jotka ovat kuitenkin täysin päättömiä. Ohjelmoidessa hallusinoitu koodi jää usein nopeasti kiinni, jos koodi ei toimi. Agentteja käytettäessä hallusinointi onkin ohjelmoinnissa nykyään melko vähäistä, sillä agentti suorittaa koodin ja testit itse ja korjaa virheet niiden perusteella. Ongelmallisempia tilanteita ovat ne, missä tekoälyn generoima koodi näyttää toimivan, mutta sisältää vaikeammin havaittavia bugeja tai tietoturvahaavoittuvuuksia. Jos asiaan ei kiinnitetä huomiota, tekoäly myös usein kirjoittaa uutta koodia sen sijaan, että hyödyntäisi olemassa olevaa, mistä voi seurata koodikannan rapautuminen. Riskejä on koottu tarkemmin tekoälymateriaaliin.

Tekoälyä käytettäessä vastuu jää siis aina ohjelmoijalle.

Tekoälyn vaikutuksesta tuottavuuteen on ristiriitaista tutkimustietoa, ja tulokset vanhenevat nopeasti työkalujen kehittyessä. Googlen DORA-raportin (2025) keskeinen johtopäätös on, että tekoäly toimii vahvistimena: se parantaa hyvin toimivien tiimien suorituskykyä, mutta voimistaa myös heikosti toimivien organisaatioiden ongelmia. Tällä kurssilla käsiteltävät asiat, kuten vaatimusten hallinta, automatisoitu testaus, jatkuva integraatio ja hyvä ohjelmistosuunnittelu, ovat siis tekoälyn aikakaudella entistäkin tärkeämpiä. Aiheesta lisää tekoälymateriaalissa.

Kielimallien nopea kehitys asettaa ohjelmointia opiskelevan haastavaan asemaan: kannattaako ja tarvitseeko enää ylipäätään opetella ohjelmointia, kun agentti kirjoittaa koodin nopeammin kuin ihminen?

Kun koodin kirjoittaminen muuttuu halvaksi, arvokkaammaksi muuttuu se, mitä agentti ei osaa tehdä puolestamme. Tärkein näistä on suunnan näyttäminen. Agentti toteuttaa taitavasti sen, mitä sille kerrotaan, mutta se ei tiedä, mitä kannattaisi tehdä. Ihmistä tarvitaan selvittämään, mitä asiakas oikeasti tarvitsee, priorisoimaan tehtävät asiat ja arvioimaan, tuottaako ohjelmisto asiakkaalle arvoa. Nopeasti koodia tuottava agentti on hyödytön, jos se rakentaa väärää asiaa.

Syvällistä teknistä osaamista tarvitaan edelleen. Agentin tuotosta arvioidaan yhä useammin testien, toimivan sovelluksen ja suunnitteluratkaisujen kautta eikä pelkästään koodia rivi riviltä lukemalla, mutta sekin edellyttää ymmärrystä siitä, miten ohjelmistot rakentuvat ja millainen on hyvä ratkaisu. Ilman tätä ymmärrystä agenttia ei myöskään pysty ohjaamaan oikeaan suuntaan. Ohjelmointia siis kannattaa edelleen opetella, mutta painopiste siirtyy koodirivien tuottamisesta kokonaisuuden hallintaan: ohjelmiston suunnitteluun, ratkaisujen arvioimiseen ja laadun varmistamiseen.

Tekoälyn hyödyntämistä ohjelmistotuotannossa käsitellään tarkemmin erillisessä materiaalissa Tekoäly ohjelmistotuotannossa, joka etenee viikoittain laskareiden [tekoäly]-tehtävien tahdissa.