Sovelluskehitystä voi toteuttaa monella eri menetelmällä, mutta viime vuosina ketterien menetelmien käyttö on yleistynyt sekä konsultoinnissa että omassa tekemisessä. Myös CGI:ssä työtä tehdään ketterästi ja Agile Community vie paremman tekemisen ja ketterän ajatusmaailman sanomaa eteenpäin myös sisäisesti. CGI Suomen Agile Community -päivä pidettiin jälleen 27.11.2014 ja aiheina olivat Scaled Agile Framework (SAFe), ketterä testaus ja jatkuva toimitus. Iltapäivän Open Spacessa keskusteltiin muun muassa kokemuksista, työvälineistä, esteistä ja ketteryyden viemisestä eteenpäin omassa organisaatiossa. Tässä lyhyt yhteenveto aiheista.

Scaled Agile Framework, eli SAFe

Scaled Agile Framework on viitekehys miten isompikin organisaatio voi toimia ketterästi ja miten lean ja agile käytäntöjä sovelletaan enterprise-skaalassa. Virpi Rowe piti aiheesta hyvän esityksen, jossa selvisi kehyksen pääpiirteet ja perusarvot. SAFe lupaa paljon, kuten että saavutetaan bisnesarvoa ja että läpimenoaika markkinoille on 30-75% nopeampi. Kehyksen ydinarvot ovat hyviä kaikissa projekteissa, eli hankkeen läpivienti, tavoitteen kohdistaminen, koodin laatu ja läpinäkyvyys. CGI järjestää koulutuksia SAFesta sekä ulkoisesti että sisäisesti.

SAFessa, kuten agilessa tekemisessä yleisestikin, tekeminen koostuu ketterästä tiimistä, joka on osaamiseltaan laaja-alainen, itseorganisoituva ja itsemanageroituva. Arvoa tehdään käyttäjätarinoiden kautta. Hanketasolla SAFe koostuu ketterien tiimien tiimeistä ja arvoa tuotetaan ominaisuuksien ja hyötyjen kautta. Portfolio-tasolla SAFe näkyy siten, että strategia on keskitetty ja tekeminen on hajautettu. Arvo kuvataan bisnes ja arkkitehtuuri epicien kautta.

Sovelluskehityksen näkökulmasta SAFe on vain useampi Scrum-tiimi, jonka tuloksia integroidaan. Kehitystä tehdään aikataulussa, mutta julkaisut tehdään tarpeen mukaan. Sprintin pituudeksi on suositeltu 2 viikkoa, sillä 3 viikkoa jakaantuu helposti blokkeihin, eli muuttuu vesiputoukseksi. 4 viikossa vastaavasti asiakas muuttaa mielensä. Kuten hyvässä tekemisessä yleisestikin, koodin laatu pohjaa ketterään arkkitehtuuriin, jatkuvaan integrointiin, testit ensin lähestymiseen, refaktorointiin, parityöskentelyyn ja yhteiseen omistamiseen.

Ketterä testaus

Testausta tarvitaan myös ketterissä projekteissa, joista Jari Koivukoski kertoi muutaman case esimerkin voimin. Lyhyesti tiivistettynä testaus ketterästi on aivan samaa kuin normaalissakin projektissa, mutta sitä tehdään jatkuvasti, osana ketterää kehitysprosessia. Ei vain erillisenä vaiheena.

Case-esimerkeissä testisuunnittelu tehtiin backlogin tai käyttäjätarinoiden pohjalta ja testaus oli osana ”definition of done”, eli valmiin määritelmää. Ketterä kehitys ei rajoittanut testausmenetelmiä, vaan kysymys oli kuinka soveltaa tekemistä ketterään projektiin. Hyvänä esimerkkinä kattava testisuunnittelu jätettiin luonnosasteelle ja suoritettiin testausta alusta alkaen osana kehitystä. Näin saavutettiin enemmän arvoa sopeutumalla tilanteeseen ja tekemällä testausta ennemmin kuin suunnitelmia, jotka olisi pitänyt kuitenkin heittää pois.

Työvälineiden osalta ei mitään erikoisia valintoja esitelty, kunhan ne tukevat tiedon jakamista ja päivittäistä tekemistä. Tähän käy niin JIRA, Confluence tai kuten tässä tapauksessa testibacklog QC:ssa ja vaatimukset ja käyttötapaukset Jama-sovelluksessa. Perinteistä ketterää Scrum-tekemistä pienissä 3-4 hengen mikrotiimeissä. Testit valmiina juuri oikeaan aikaan, kun sovelluskoodi oli valmiina. Jama-työväline oli itselle uusi ja se näytti monipuoliselta insinöörikäyttöliittymäiseltä Web-sovellukselta ja kätevältä vaatimusten hallintaan yhdessä paikassa, niiden liittämiseen esimerkiksi käyttötapauksiin, muutoksenhallintaan, katselmointeihin ja parempaan näkyvyyteen ja jäljitettävyyteen.

Jatkuva toimitus, continuous delivery

Päivän viimeisenä aiheena oli jatkuva toimitus, eli continuous delivery. Eli miten sovelluksen asennus saadaan automatisoitua ja mahdollisimman kivuttomasti ja helposti asennettua tuotantoon. Ville Hartikainen kertoi oivasti, miten jatkuva toimitus jatkaa siitä, mihin jatkuva integraatio jää ja mitä periaatteita ja käytäntöjä tarvitaan inkrementaalisten muutosten viemiseen asiakkaalle. Tätä myös isot pojat, eli Amazon, Facebook ja Google tekevät. Jopa monta kertaa päivässä.

Mutta miksi? Ideana on vähentää asennusten aiheuttamia pullonkauloja, vähentää asennusprosessin puutteiden aiheuttamia virheitä, saada uusi idea käyttöön nopeammin, nopeampaa palautetta virheistä, onnistumisen tunnetta, vähentää stressiä ja voimaannuttaa tiimia. Kuulostaa hienolta ja sitä se onkin. Miksi tehdä asioita manuaalisesti, kun niitä voi automatisoida.

Case-esimerkkinä esiteltiin tapaus, jossa alkujaan tarvittiin hitaita manuaalisia vaiheita etenkin palveluväylän kanssa, mutta lopulta päästiin alle kymmenessä minuutissa commitista valmiiksi. Osana nopeampaa tekemistä oli palveluväylän päivitys ja rajapintojen ”väärinkäyttö”, jotta asioita saatiin automatisoitua. Tekemisessä ei ollut mitään erikoista, sillä työvälineinä käytettiin Mavenia, SoapUI:ta integraatiotesteihin ja Jenkinsiä build pipeline -lisäosan kanssa.

”If it hurts, do it more frequently, and bring the pain forward”

Open Space

Iltapäivän keskusteluosuudessa aiheita saatiin yhdeksän kattaen käytännön kokemuksia, työvälineitä, miten edistää ketterää tekemistä ja kommunikointia yli yksikkörajojen.

Yksi käsitelty ongelma oli resurssien hajaantuminen ketteressä tekemissä useisiin projekteihin. Scrumissa tekijän pitäisi olla vähintään 50% osuudella ja yksi ratkaisu tähän on sovellusylläpidon ja projektien eriyttäminen. Myös Kanban boardista ja vallan ja vastuun antamisesta tiimille on hyöytyä.

Toinen keskustelua herättänyt aihe oli tiedonsiirto yksiköiden ja tiimien välillä, sillä isossa talossa tieto ei aina liiku. Ratkaisuna esitettiin sisäisiä tilaisuuksia, avointa asennetta, työtiloja, työn kiertoa, sosiaalista mediaa ja eri yksiköissä ja tiimeissä vierailua.

Aiheena käsiteltiin myös ketterän kehityksen viemistä asiakkaalle. Agilen edut ovat kiistattomat vesiputoukseen verrattuna, sillä palauteketju on nopeampi, markkinoille päästään nopeammin, mielen muuttaminen on mahdollista sprinttien välillä ja toiminta on läpinäkyvää.

Keskustelua oli hyvä jatkaa Open Spacen jälkeen yläkerran saunatiloissa, joissa kuuman saunan lisäksi oli tarjolla iltapalaa ja virvokkeita. Kiitoksia CGI:n Agile Communitylle hyvästä tilaisuudesta.