Ketterän kehityksen ideologiassa lähdetään siitä, että myönnetään se, minkä me kaikki olemme usein kalliisti joutuneet toteamaan: kaikkien vaatimusten kirjaaminen etukäteen ei useinkaan onnistu ja vaikka siinä näennäisesti onnistutaankin, projektin aikana törmätään kuitenkin moniin määrittelyn puutteisiin, muutostarpeisiin ja väärinymmärryksin.

Toinen keskeinen teema on se, että kehitystyössä tehdään koko ajan korkeimman prioriteetin ominaisuuksia. Perinteisissä malleissa, missä toimintojen priorisointi jätetään vain ohjelmoijien päätettäväksi, toteutetaan usein ensin helpot toiminnot, jotta voidaan osoittaa projektin edistymistä. Näin projektin loppuvaiheessa on tekemättä vaikeimmat, suuririskisimmät toiminnot. Usein nämä olisivat asiakkaalle juuri niitä kaikkein tärkeimpiä.

Kolmantena teesinä pidetään koko ohjelmiston elinkaaren läpikäyntiä useita kertoja. Monissa projekteissa törmätään käyttöönottovaiheessa moniin yllättäviin ongelmiin. Ketterissä menetelmissä projekti jaetaan pienempiin paloihin siten, että kaikki projektissa tarvittavat vaiheet on käyty läpi moneen kertaan. Näin vältytään ikäviltä yllätyksiltä projektin loppuvaiheessa.

Neljäntenä seikkana on mainittava jatkuva laadunvarmistus ja testaus. Perinteisesti testaus on suoritettu projektin loppuun, hetkeen, jolloin ei enää olisi aikaa tehtä korjauksia. Jakamalla projekti pienempiin paloihin ja käymällä kaikki vaiheet läpi useasti varmistutaan siitä, että deadlinen koittaessa on jotain valmiina, ja kaikki mitä on valmiina, on jo testattua ja hyväksi todettua.

Oleellista on siis toteuttaa toimintoja kokonaisuuksina nopeasti ilman, että työtä tehdään varastoon. Tyypillisesti projektin alussa tehdään kattava vaatimusmäärittely, jonka jälkeen siirrytään seuraavaan vaiheeseen. Mutta miksi määritellä toimintoja, ennenkuin niitä aletaan toteuttamaan? Ketterässä kehityksessä pyritään toistamaan jatkuvasti ja tehokkaasti määrittele-suunnittele-toteuta-testaa-julkaise -sykliä.

"Mikäli vaatimukset muuttuvat koko ajan, olet tarkentanut niitä liian aikaisin. Mikäli projektin lopussa on pitkä "koodaa ja korjaa" -vaihe, olet testannut liian myöhään."

Projektin alussa vaatimusten määrittelyn on hyvä käyttää käyttäjätarinoita.

Kiinteä hinta, kiinteä projektin koko?

Vanha projektikolmio on edelleen voimassa^*). Sen mukaanhan projektissa on kolme kulmaa, koko, hinta ja aikataulu, joista voidaan kiinnittää enintään kaksi, mutta vähintään yhdessä on oltava valmis joustamaan. Valitettavan usein näistä pyritään kuitenkin kiinnittämään kaikki, ja kaikki riski jätetään toimittajan kannettavaksi. Viime kädessä ei kuitenkaan ole asiakkaankaan etu, jos projektissa ei saavuteta yhteisiä tavoitteita.

Mikäli projektilla on selkeä deadline, on koosta usein oltava valmis tinkimään. Tällöin on erittäin tärkeää, että toimintoja toteutetaan alusta saakka prioriteettijärjestyksessä. Näin deadlinen koittaessa tekemättä on vain vähemmän tärkeitä toimintoja. Mikäli taasen tuotteen ominaisuusjoukko on paljon tärkeämpää kuin aikataulu, on oltava valmis joustamaan kustannuksissa.

Lyhyesti sanottuna, valitessanne ketterän projektimallin, asiakkaana saatte:

• jatkuvan, todellisen tiedon projektin tilasta, mikä perustuu todellisiin toiminnallisuuksiin, ei vain raportteihin ja dokumentaatioon
• luvan muuttaa vaatimuksia ilman lisäkustannuksia! Muistaen kuitenkin, että erilaiset sopimukset mahdollistavat eri määrän joustoa
• varmuuden siitä, että kaikkein tärkeimmät toiminnot on toteutettuna ajallaan

*) Itse asiassa projektikolmiossa onkin neljä kulmaa - laatu on myös yksi muuttuja kokonaisuudessa. Mikäli kaikki kolme perinteistä nurkkaa yritetään kiinnittää, tuloksena on väistämättä laadun heikkeneminen. Kehittäjät tinkivät testaamisesta, lopettavat refaktoroinnin, tekevät nopeita purkkavirityksiä jne. Tästä seuraa paitsi huonompi käyttäjäkokemus, myös suuremmat kustannukset ylläpitovaiheessa.