Ketterien menetelmien hyödyntäminen sovelluskehityksessä on nykyään arkipäivää, mutta ketteryyttä voi harjoittaa monella eri tapaa. Erilaisia menetelmiä on useita ja harvoin ne aivan suoraan soveltuvat käytettäväksi ketterissä projekteissa, joten oli hyvä kuulla CGI:n Agile Community -päivässä, miten SAFe oli otettu käyttöön asiakkaalla, miten DSDM:ää hyödynnetään Iso-Britanniassa ja mikä on LeSS. Hyvää jatkumoa viime syksynä Agile Community -päivälle. Tässä lyhyt yhteenveto tilaisuudesta.
Käytännön kokemuksia SAFen käyttöönotosta
SAFe eli Scaled Agile Framework on yksi menetelmä ketterän kehityksen, tai tässä tapauksessa, Scrumin skaalaamiseen isompia projekteja ajatellen, josta Anna Ferguson kertoi käytännön kokemuksia. Vuoden aikana on vesiputous-mallia käyttävästä kehityksestä siirrytty SAFen soveltamiseen, joka ei ole ollut aivan yksinkertaista, sillä muutos ei tapahdu hetkessä, jos kehitystä on tehty vesiputous-mallilla 20 vuotta. Tärkeänä osana muutosta on ketterän kehityksen perusperiaatteiden ja ketterien julkaisujunien valmentaminen. Käytännönläheistä tekemistä. Ei ole yhtä oikeaa tapaa toteuttaa SAFea, vaan se vaatii soveltamista.
Tavoitteena oli saavuuttaa niitä etuja, joita ketterä kehitys mahdollistaa, eli aikaista arvontuottoa, nopeuttaa läpimenoaikaa pienentämällä eräkokoa, saada parempi palautesykli asiakkailta ja rajoittaa yhtä aikaa käynnissä olevan työn määrää. Lean-periaatteita. Asiaa lähdettiin edistämään kahdella pilotilla ja SAFen julkaisujunien valmennuksella. Tavoitetilassa ylläpitotiimeissä käytettäisiin Kanbania ja kehityksessä SAFea palveluiden tuottamiseen ketterien julkaisujunien kautta. Tärkeänä osana muutosta oli myös koulutus SAFeen ja henkilökohtaisten kehityssuunnitelmien tekeminen.
Työvälineinä käytössä olivat muun muassa JIRA ja siihen saatava Structure-lisäosa, joskin Portfolio-lisäosa olisi parempi. Testiautomaatiossa oli hyödynnetty CA Service Virtualisointia ja Silk Testiä.
Poimintoina kokemuksista mainittakoon, että muutos ketteryyteen vaatii valmennusta. Aikaa menee keskusteluun käyttäjätarinoiden ja määrittelyiden suhteesta ja edelleen tehdään helposti liian tarkkoja määrittelyitä jo alkuvaiheessa. Pienien eräkokojen, ketteryyden minimikriteerien määrittely ja testiautomaation tärkeyttä ei voi myöskään sivuuttaa. Ongelmana voi olla myös henkilöiden allokaatio. Testauksen kannalta oleellista on, miten ominaisuudet ovat jaettu, että ne ovat järkevästi testattavissa.
Uuden työtavan käyttöönotto ei koskaan suju ilman muutosvastarintaa, mutta asioihin tottuu. Omissa huoneissa -tekemisestä on vaikea siirtyä yhdessä tekemiseen, sopiiko menetelmä juuri meidän liiketoimintaan, jos ei tehdä määrityksiä ennalta, miten tiedetään mitä tehdään ja koska tarinat ovat pieniä, miten nähdään kokonaiskuva. Tekemistä ei kannatakaan verrata suoraan SAFe-malliin, vaan siihen, missä vuosi sitten oltiin ja kuinka pitkälle ollaan päästy. Vaikka tekemissä ei ollut erikoisia metriikoita, on vuoden julkaisuaikataulusta päästy kolmeen kuukauteen.
Dynamic Systems Development Method, eli DSDM
Päivän toinen aihe käsitteli DSDM:ää, eli Dynamic Systems Development Methodia. Tämä oli itselle uusi tuttavuus ketterien menetelmien osalta ja hieman avoimeksi se kyllä esityksenkin jälkeen jäi. DSDM:stä kuultiin videon välityksellä, joka nopeaan puhumiseen yhdistettynä ei ollut se tehokkain media esittää asia.
Ketteryys on jo vakiinnuttanut asemansa ja erilaisia metodeita on kehitetty erilaisiin lähestymistapoihin ja konteksteihin. Valinnanvaraa oikean työkalun valinnassa tehtävään riittää: Scrum, Kanban, SAFe, Xp ja DSDM. DSDM:n voi kiteyttää olevan iteratiivinen ja inkrementaalinen ketterämalli, joka on saanut alkunsa sovellusten kehityksestä, mutta kattaa nykyään näkymän tietojärjestelmään (bisnes, projekti, teknologia). Vuonna 1994 julkaistiin ensimmäinen versio mallista, 2007 toinen Atern -nimellä ja 2014 APF.
DSDM:n Atern -versiota voi kuvata lyhyesti seuraavien kuvien avulla, jotka esittävät projektin muuttujia ja elinkaarta.
DSDM:stä ei oikein selkeää kuvaa tullut, mitä se käytännössä tarkoittaa ketterän kehityksen kannalta, mutta jos asia kiinnostaa, niin siitä voi lukea lisää vaikka Wikipediasta.
LeSS is more
Vähemmän on enemmän? Kysymys pitää paikkansa, mutta tällä kertaa ei ole kyse sananmukaisesti vähemmästä tai tarkoiteta CSS-tyylien kirjoittamiseen tarkoitettua kieltä, vaan ketterän teeman hengessä puhe on Large-scale Scrumista. Tiina Jääheimo kertoi suhteellisen uudesta menetelmästä skaalata Scrum isompaan kontekstiin, joka tekee asian kevyemmällä ja enemmän Scrum-tyylisellä otteella kuin SAFe. LeSS:n säännöt vakiinnutettiin 2013 ja SAFen tapaan se on lähtöisin Nokiasta. Suomessa on vain yksi sertifioitu LeSS-kouluttuja, Ran Nyman Goseilta.
LeSS on tuotekehitys-kehys, joka laajentaa Scrumia skaalautumiseen liittyvillä säännöillä ja ohjelinjoilla tarjoten Basic LeSS -mallin 2-8 tiimille ja Huge LeSS -mallin yli 8 tiimille. SAFeen verrattuna LeSS säilyttää monet Scrumin käytännöt ja ideat, kuten sen että tiimit työskentelevät samassa sprintissä.
Scrumiin verrattuna eroina on muun muassa Sprint planningit, joita on kaksi kappaletta. Yksi suunnittelutilaisuus kaikille tiimeille ja yksi jokaiselle tiimille erikseen. Retroja on myös jokaiselle tiimille erikseen ja yksi yhteinen. Skaalautuvuus näkyy Open Space -keskusteluissa, Town hall -tilaisuuksissa ja Scrum of Scrumeissa, joita pidetään useamman kerran viikossa informaation jakamiseksi ja koordinointia varten. Scrumiin tapaan tiimeillä on omat Sprint backlogit ja päivittäiset Scrum-tilaisuudet. Samoin tuotteen backlogin tarkennus tehdään tiimikohtaisesti asioille, joita tiimi todennäköisesti aikoo toteuttaa. Sprint Review pidetään kaikille tiimeille yhteisenä.
LeSSin periaatteet ovat käytännöllisiä kaikkeen tekemiseen sovelluskehityksessä.
LeSSissä myös ScrumMasterin ja tuoteomistajan roolit muuttuvat. ScrumMaster ei ole osa tiimiä, eikä tee työtä tiimissä, vaan keskittyy asiaan kokonaisuutena ja palvelee yhdestä kolmeen tiimiä. Tuotteella on yksi tuoteomistaja ja tuotebacklogi, jota useat tiimit tukevat. Tiimit työskentelevät suoraan asiakkaan ja sidosryhmien kanssa. Definition of Done on yhteinen koko tuotteelle ja sen pitäisi olla laaja ja käyttäjäkeskeinen. Tähän tarvitaan organisaatiorakenteen, roolien ja käytäntöjen muutoksia, joka ei välttämättä ole helppoa.
Scrumin tapaan kaikki tekeminen on tiimien sisällä, sisältäen muun muassa jatkuvan palvelun, laadunhallinnan, testauksen ja arkkitehtuurin, vaikka helposti nämä jäävät niin sanotun Undone-osaston vastuulle, joka tekee viimeiset silaukset tuotteelle. Tiimit ovat 7+-2 hengen moniosaaja-tiimejä, jotka tekevät käyttäjälähtöisen ominaisuuden kokonaisuudessa. Projektipäälliköiden on hyvä pysyä poissa tiimien läheltä.
LeSS vaikutti esityksen perusteella käytännönläisemmältä ja selkesti yksinkertaisemmalta lähestymiseltä skaalatuvaan ketterään kehitykseen.