Määrittely kommunikoinnin välineenä
Perinteisesti ohjelmiston suunnitteluvaihe alkaa vaatimusmäärittelyllä, joka sisältää toteutettavan ohjelmiston yksityiskohtaisen toiminnallisuuden määrittelyn. Yksi määrittelyyn suuntautunut henkilö tekee ensin koko järjestelmän speksit ja kun toteutus alkaa, erillinen toteutustiimi (mitä todennäköisimmin) tulkitsee tämän määrittelyn eri tavalla kuin miten määrittelijä sen alun perin ajatteli. Tämä ei selvästikään ole se tehokkain, nopein ja paras tapa saada asiakkaalle ohjelmistolla haettavaa hyötyä ja vastinetta tehdylle työlle.
Parempi lopputulos saavutetaan jos toiminnallisuudet kuvataan kevyemmin. On hyvä, että ne muuttuvat mahdollisimman vähän ja että niitä on toteutusvaiheessa helppo muuttaa. Tähän yksi hyvä suunnitteluperiaate on käyttäjäkeskeinen suunnittelu.
Toiminnallisuuksien tarkennus tehdään toteutuksen aikana ja se alkaa siitä hetkestä kun kehittäjä ottaa toiminnallisuuden työn alle.
Toteutuksen aikana kehittäjä kommunikoi aktiivisesti aihealueen asiantuntijan kanssa. Tällä tavalla kehittäjällä on tarvittavat tiedot tehtävän suorittamiseen ja ne ovat tuoreessa muistissa, mikä antaa kehittäjälle paremmat mahdollisuudet onnistua työssään. Tehtävien seuranta ja päivittäinen tuoteomistajan katselmointi takaavat sen, että asiakkaalle on selvää mitä ollaan tekemässä.
Kokeilukulttuuri ja ketterä projektitoimitus
Joskus tilanne vaatii kokeilua, sillä voi olla, että toiminnallisuuden yksityiskohtia on vaikea hahmottaa.
Silloin kannattaa tehdä kokeiluversio yhdessä tuoteomistajan tai aihealueen asiantuntijan kanssa ja iteroida tarvittaessa. Tehokkaimmin tämä onnistuu silloin kun asiantuntija on kehittäjän vieressä ja kun muutokset on heti esitettävissä kehittäjän lokaalissa kehitysympäristössä.
Sen jälkeen kun koodi on testattu, katselmoitu ja toiminnallisuus on viety versionhallinnan developiin, annetaan asiakkaan sidosryhmille eri tilaisuuksissa (päivittäinen tuoteomistajan katselmointi, demot) mahdollisuus kommentoida. Heiltä kysytään, onko toiminnallisuus tehty niin kuin oli tarkoitettu. Muutoksia voidaan vielä tehdä jos jotain on mennyt pieleen.
Minimitoteutus
Ketterän ajatusmaailman päätavoite on saada asiakkaalle mahdollisimman nopeasti vastinetta tehdystä työstä.
Tämän takia teemme projektit ketterästi ja pyrimme saamaan minimitoiminnallisuuden asiakkaan käyttöön mahdollisimman nopeasti. Toisin sanoen, toteutamme asiakkaan valitsemat ohjelmiston tärkeimmät toiminnallisuudet ensin. Tätä kutsutaan Minimum Viable Product (MVP) tai kuten Solitassa on tapana sanoa: Minimum Loveable Product. Sen lisäksi että ohjelmiston käyttö on mielekästä ja helppoa niin käyttäjä voi myös suorittaa käyttäjätarinoissa kuvatut tilanteet tehokkaasti.
Rakkaudesta lajiin – pallo peliin
Jalkapalloa kutsutaan kauniiksi peliksi (The Beautiful Game). Koska ketterissä tiimeissä tehdään paljon pelillisyysharjoituksia, ajattelin että jalkapallo toimii tässä hyvin analogiana, joskin optimaalinen kehitystiimin koko on 4-6 henkeä ja jalkapallojoukkueessa on 11 pelaajaa. Jalkapallo on säännöillä ja kentällä rajattu aihealue. Pelaajille tulee pelissä jatkuvasti muttuvien ulkoisten tekijöiden asettamia ongelmia (esteitä), jotka täytyy ratkaista päästäkseen lähemmäs maalintekoa.
Nykyvalmennuksessa kannustetaan laittamaan pallo nopeasti peliin ja havainnoimaan mitä sen jälkeen tapahtuu. Havainnoinnin jälkeen valmentaja reagoi tekemällä muutoksia. Painotus on siinä, että valmentaja antaa pelin aikana pelaajille mahdollisimman vähän suoria ohjeita. Sen sijaan kysymyksiä asetetaan pelin tauottua siitä mitä tilanteessa tapahtui, mitä ratkaisuvaihtoehtoja oli ja mikä ratkaisuvaihtoehto olisi siinä tilanteessa paras. Pelaajat saavat siis itse tehdä päätöksiä ongelmanratkaisua vaativissa tilanteissa. Tällä tavoin pelaaja pystyy kehittymään parhaiten ja oppii ajattelemaan itse.
Voidaan ajatella, että ketteryys ilmenee siten, että pallo laitetaan peliin siinä vaiheessa kun lisäohjeistus (vertaa määrittely) ei tuo tavoitteen savuttamiseksi lisäarvoa.
Kokeiluista ja tekemisestä joukkue oppii ja kehitykseen johtavaa oppimista tapahtuu usein.
Oppiminen – käyttäjän tie on arvaamaton
Ketterässä käyttöpalvelumallissa laitetaan deployment pipeline kuntoon heti projektin alussa niin, että ohjelmisto saadaan asennettua vaivattomasti eri ympäristöihin. Kun ohjelmisto otetaan käyttöön, niin sitten vasta voidaan oikeastaan sanoa miten se palvelee käyttötarkoitustaan, mitä toimintoja käytetään eniten ja miten sitä kannattaa jatkokehittää.
Ohjelmiston käyttöä monitoroidaan eri mittarein ja käytöstä saadaan päätöksenteon tueksi reaaliaikaista tietoa, jolloin ei tarvitse toimia sokkona arvailujen varassa. Näiden seikkojen takia on tärkeää saada minimitoteutus mahdollisimman nopeasti tuotantoon.
Kiinnostuitko? Lue lisää asiakastöistämme ja palveluistamme verkkosivuiltamme tai ajankohtaisista blogeistamme. Kurkkaa lisäksi avoimet työpaikkamme, sillä etsimme jatkuvasti uusia solitalaisia joukkoomme.Jesper työskentelee Helsingissä ohjelmistosuunnittelijana ja full-stack Java-kehittäjänä. Hän on toiminut eri rooleissa useissa ketterissä projekteissa. Vapaa-ajallaan Jesper pyöräilee, juoksee ja pelaa jalkapalloa. Kaksi hänen kolmesta lapsestaan pelaa jalkapalloa, joten iso osa vapaa-ajasta menee kentän laidalla valmentajan roolissa.
