Ketterä ohjelmistokehitys tarkoittaa lyhyesti sitä, että projekti tehdään iteroiden yhdessä asiakkaan kanssa. Ohjelmistokehityksen menetelmänä ketteryyteen kuuluu, että toteutus jaetaan pienempiin osiin eli sprintteihin. Kuhunkin sprinttiin sisältyy tavoitteiden asettaminen, toteutus ja katselmoinnit.
Ketterä ohjelmistokehitys on ikään kuin filosofia, jota voidaan soveltaa ohjelmistokehityksessä. Tässä blogitekstissä kerromme, mitä ketterä ohjelmistokehitys tarkoittaa meillä Hurjalla ja mitä asiakkaamme hyötyy ohjelmistoprojektin ketteryydestä.
Ohjelmistokehityksen menetelmät voidaan yleisesti jakaa kolmeen kategoriaan: vesiputousmalli (waterfall), nopean kehittämisen malli (RAD), ja ketterät ohjelmistokehityksen menetelmät (agile).
Perinteisessä vesiputousmallissa prosessi etenee alaspäin vaihe vaiheelta, kuten vesiputouksessa. Vesiputousmallissa määrittelyvaihe on pidempi ja vaatimukset lukitaan tässä vaiheessa. Vesiputousmalli voi monissa tapauksissa olla liian kankea monimutkaisen projektin läpivientiin, jos ohjelmiston vaatimukset ja tavoitteet eivät ole täysin selvät jo projektin alussa. Nopean kehittämisen mallissa pyritään prosessin mahdollisimman nopeaan läpivientiin, mutta malli sopii lähinnä hyvin yksinkertaisien ohjelmistojen kehittämiseen.
Tämän blogitekstin aiheena olevassa ketterässä ohjelmistokehityksessä (agile) taas pyritään toteuttamaan projekti iteroiden asiakkaan kanssa, tuottamaan juuri asiakkaan tarvitsema ratkaisu ja jakamaan toteutusprosessi pienempiin osiin. Tällä tavalla projektiin saadaan joustavuutta ja minimoidaan myös riskejä, samalla pitäen asiakas jatkuvasti mukana kehittämisessä.
Varmaan huomasitkin jo selvät yhtäläisyydet kaikkien tuntemaan ja Toyotan kehittämään lean-filosofiaan, jossa riskit ja hukka minimoidaan, ja tärkeintä on aina tuottaa asiakkaalle arvoa. Ketterän kehittämisen tunnetuimpia työkaluja ovat scrum ja kanban, jotka noudattavat sekä leanin että ketterän kehittämisen periaatteita.
Hurjalla ketterä ohjelmistokehitys merkitsee tiivistä asiakasyhteistyötä, nopeaa muutoksiin reagointia, riskien minimoimista ja yleistä Just-In-Time -filosofiaa. Ketterässä mallissa asiakkaan ja tiimin välille saadaan syvempi yhteisymmärrys, sillä keskinäinen yhteydenpito on tiiviimpää. Nopea muutoksiin reagointi pienentää riskiä liian aikaisin lukituista toiminnallisuuksista, jotka eivät edistä tavoitteita. Tavoitteena on siis tuottaa arvoa tuotteellesi tai palvelullesi, joka saadaan aikaan luotettavalla ja aikaa kestävällä koodilla.
Ketterä ohjelmistokehitys on nykyaikaista, tehokasta, asiakkaan tarpeet huomioivaa ja ammattitaitoista ohjelmistokehitystä. Joustavassa ja ketterässä mallissa räätälöimme sinulle juuri sopivan ratkaisun huomioiden tarpeet ja budjetin. Otamme tarpeet huomioon heti aloituspalaverista lähtien ja tarkennamme niitä projektin edetessä. Ketterässä mallissa ei yleensä myöskään kannata käyttää kiinteää hinnoittelua, koska vaatimuksia voidaan tarkentaa joustavasti projektin edetessä. Muuttuvat vaatimukset vaikuttavat usein myös toteutuksen työmäärään suuntaan tai toiseen.
Ketterän mallin ansiosta pääset lisäksi myös osallistumaan kehitettävän järjestelmän testaamiseen varhaisessa vaiheessa, jolla varmistetaan, että ratkaisu varmasti palvelee liiketoiminnallisia tavoitteitasi. Aktiivinen viestintä, avoin keskustelu sekä kyky mukautua projektin aikana tapahtuviin muutoksiin ovat kehittämisen peruspilareita. Ohjelmistoprojektin aikana meillä on yleensä käytössä dailyt, eli lyhyet päiväpalaverit sekä sprinttipalaverit asiakkaan kanssa.
Ohjelmistoprojekti pilkotaan ketterässä mallissa sprintteihin, eli pienempiin kehitysjaksoihin ja projekti etenee sprintti kerrallaan. Ketterä ohjelmistokehitys mahdollistaa ongelmakohtien tunnistamisen sekä muutostarpeet aikaisessa vaiheessa. Kun ominaisuuksia toteutetaan sykleissä, joiden lopuksi lopputulos arvioidaan, saadaan palautetta myös nopeammin kuin perinteisessä vesiputousmallissa.
Lue myös: Testivetoinen kehittäminen tuo laatua ja vakautta
Ketterä projekti etenee sprinteissä. Suppea projekti voi olla vain yhden sprintin mittainen, kun taas laaja ohjelmisto koostuu useista eritasoisista sprinteistä. Yhden sprintin pituus on yleensä 1-4 viikkoa
Sprintit kulkevat eteenpäin ketterästi iteroiden, joten projektitiimin aktiivinen ja luottamuksellinen vuorovaikutus on ensisijaisen tärkeää projektin kaikissa vaiheissa! Asiakkaamme osallistumista tarvitaan erityisesti tavoitteiden asettamisessa ja katselmoinnin aikana. Projektin alussa sovitaan yhteisistä käytännöistä: ketkä viestivät, missä ja kuinka usein.
Määrittelyvaiheessa selvitämme ohjelmiston käyttäjätarinat yhdessä asiakkaan kanssa. Käyttäjätarina on kuvaus siitä, missä tilanteissa ja millä tavalla erilaiset käyttäjät ohjelmistoa käyttävät. Kartoitamme myös muut ohjelmistolle asetettavat vaatimukset ja sen, miltä käyttöliittymä voisi näyttää. On myös tärkeää tietää, miten ohjelmiston omistaja ja loppukäyttäjät hyötyvät palvelusta. Tavoitteiden määrittelyn apuna voidaan käyttää myös palvelumuotoilussa ja tuotekehityksessä suosittua työpajamenetelmää Design Sprintiä. Design Sprintin avulla varmistetaan, että kaikilla projektin osapuolilla on yhteinen käsitys lähtötilanteesta, suunniteltava ratkaisu on varmasti käyttäjälle toimiva ja että se tukee liiketoiminnallisia tavoitteita.
Määrittelyn esimerkkejä:
Ketterässä mallissa suunnittelun aikana vaatimukset konkretisoidaan muun muassa käyttöliittymän, ohjelmiston rakenteen ja teknisen toteutuksen osalta. Käyttöliittymä- ja toiminnallisen suunnittelun apuna voidaan myös hyödyntää sovitun tasoisia prototyyppejä. Nopeastikin tehty demo konkretisoi suunnitelmia sekä nopeuttaa ja helpottaa toteutusvaiheen työnkulkua.
Rautalankamalli, mockup ja prototyyppi auttavat ohjelmistohankkeen pilotoinnissa ja tekevät ideoista konkretiaa. Niitä voidaan hyödyntää myös sprinttien sisällä ja apuna katselmoinnissa. Demojen ja prototyyppien avulla on helppo saada kokonaiskuva toteutuksesta! Esim. muutamalla toiminnallisuudella varustettu prototyyppi valmistetaan usein ennen lopullisen tuotteen rakentamista, koska prototyypin avulla voidaan esitellä ideaa, kerätä palautetta ja tutustua toteutusvaihtoehtoihin.
Varsinainen koodaustyö etenee myös ketterästi vaiheittain. Vaiheittain etenevä työnkulku antaa tilaa nopealle reagoinnille ja muutostoiveille. Tätä varten tiimi pitää päivittäin myös lyhyitä sisäisiä palavereita (dailyja). Vaikka määrittely on tehty alussa huolellisesti, tapahtuu yksityiskohtaisempi määrittely projektin edetessä. Toteutuksen aikana tulee myös lähes poikkeuksetta esille uusia ideoita ja vaatimuksia. Vuorovaikutus asiakkaan kanssa on siis tärkeää myös toteutusvaiheessa! Sopivien viestintäkanavien hyödyntämisestä nopeita ja joustavia keskusteluja varten sovitaan yhdessä.
Toteutukseen kuuluu aina ratkaisujen testausta sovitulla laajuudella ja projektin luonteeseen ja vaatimuksiin sopivilla menetelmillä.
Katselmoinnissa projektitiimi kokoontuu tarkastelemaan sprintissä aikaansaatuja tuloksia. Katselmoinnin päätyttyä pidetään retrospektiivi, jonka jälkeen aloitetaan uusi sprintti siihen valittujen tehtävien, esimerkiksi ohjelmiston uusien toiminnallisuuksien toteuttamisen parissa. Haluamme, että tiedät, miten työ etenee ja missä vaiheessa kehittäminen on, joten säännölliset katselmoinnit pidetään koko projektitiimin kesken. Katselmointirytmistä sovitaan tapauskohtaisesti kunkin asiakkaan kanssa. Katselmoinnit pidetään aina sprintin päätteeksi, tyypillisesti esim. 1-2 viikon välein.
Katselmoinnin ohessa kehittäjät pitävät sisäisen retrospektiivin eli retron. Retrospektiivissä sprinttiä tarkastellaan erityisesti tiimin toiminnan näkökulmasta. Retron tarkoituksena on analysoida sprintin onnistumista, jotta virheistä voidaan oppia ja saadaan aikaan aina parempia tuloksia. Kehittäjät käyvät tällöin sisäisesti läpi, mikä onnistui, mitä voidaan tehdä ensi kerralla paremmin sekä mitä toimenpiteitä tehdään virheiden korjaamiseksi ja toiminnan kehittämiseksi seuraavassa sprintissä.
Kun sprintin aikaansaannokset on hyväksytty katselmoinnissa tai hyväksyntätestauksessa, on ohjelmiston osa valmis julkaistavaksi (integroiminen). Iteratiivisessa ja ketterässä kehityksessä julkaisuja tapahtuu usein myös sprintin aikana ja jokaisen sprintin tavoitteena tuottaa uusi ohjelmiston osa kehitettävään tuotteeseen tai palveluun.
Ohjelmistokehittäjien ja asiakkaan tehtävät ja vastuualueet ovat sprinteissä erilaiset. Jos koodia kirjoittaa useampi henkilö, sovitaan työnjaosta sprintin tavoitteiden mukaan.
Kehittäjillä on sprinttien sisällä päivittäisiä palavereja, joissa tarkastellaan työn edistymistä ja mahdollisia ongelmakohtia. Määrittelyä ja suunnittelua muokataan tarvittaessa lennosta, jos parhaan tuloksen saavuttaminen sitä edellyttää. Silloin tarvitaan joustavaa reagointia myös asiakkaalta – emme ohita toiveitasi ja tarpeitasi, vaan etsimme parhaat ratkaisut yhdessä!
Sisäisissä katselmoinnissa ja retrossa kehittäjät käyvät yhdessä läpi toteutunutta sprinttiä ja kehittämiskohteita, kuten miten kehittämistä voisi parantaa seuraavissa sprinteissä ja työvaiheissa.
Nyt tiedät, mitä ketterä ohjelmistokehitys tarkoittaa Hurjalla ja miten me käynnistämme juuri sinun liiketoimintaasi sopivan, lisäarvoa tuovan ohjelmistoprojektin. Kuten huomasit, teemme ohjelmistokehitystä suhteessa asiakkaamme tarpeisiin ja kehitämme laajatkin ohjelmistot ketterästi, sinua kuunnellen.
Kun tarvitset ohjelmiston, joka on suunniteltu vastaamaan tavoitteisiisi, ota yhteyttä!
Lataa ostajan opas
