Cowboy Koodarin päiväkirja

Scrum, viitekehys

Aika usein kun puhutaan ketteristä menetelmistä, niin asiakkaalle kerrotaan menetelmän olevan Scrum. Mutta tämähän on osatotuus siitä kuinka työt tehdään. Pelkkä Scrum ei vielä takaa laadukasta lopputulosta. Vaan se on pelkään viitekehys, joka kertoo kuinka työt organisoidaan.

Kun puhutaan viitekehyksestä, niin se vihjaa siihen että kyseessä on määrämuotoinen tapa toimia. Mutta se ei yksinomaan tuo mukanaan laatua vaan viitekehystä pitää osata käyttää oikealla tavalla. Viitekehyksen käyttö perustuu siihen, että työt etenevät määrämuotoisesti.

Scrummissahan työt pilkotaan sprintteihin, joiden aikana luodaan uusia toiminnallisuuksia. Ja ennen sprinttiä ja sen jälkeen palaveroidaan. Eli pitkällä tarkkailuajalla huomataan, että työt tehdään toistuvasti ja tuote kasvaa inkrementaalisesti. Aina sprintin lopussa pyritään kertomaan tilaajalle mitä saatiin aikaan ja miten sprintti meni.

Eli ulkopuolinen näkee Scrummin sprintistä suunnittelukokouksen jossa suunnitellaan sprintin työjono. Sprintin aikaiset utelut ja lisätietopyynnöt  koordinoidaan tuoteomistajan kautta. Ja lopuksi katselmuksen jossa esitellään tuoteomistajalle sekä mahdollisille sidosryhmille saavutukset.

Tämä on se tapa, jolla mm. scrummia markkinoidaan ulospäin. Eli syklisellä tuotannolla saadaan paremmin pidettyä tuote oikeassa suunnassa. Tämä lieneekin totta. Mutta usein unohdetaan muutama perusasia eli se, että hyvä tuote ei synny vain cowboy koodauksella tai ad hoc-maisesti. Vaan että sen tekeminen vaatii kurinalaisuutta ja järkeviä menetelmiä.

Ja tämä on monelle se vaikeasti ymmärrettä asia. Scrum on hallinnollinen viitekehys, jolla seurataan työlistassa olevien asioiden valmistumista. Burndown chartit yms. muut eivät kerro mitään siitä tekniikasta kuinka lopputulos saadaan aikaiseksi. Vaan kertovat siitä, kuinka kahden viikon sprintissä työt edistyvät.

Eli scrum on vain viitekehys, jolla ohjataan projektia. Samalla kehyksellä voidaan ohjata muitakin kuin softaprojekteja. Vaikkapa festifaalien toteutusta. Taskit on vain hiukan erilaisia.

Softapuolella siihen laatuun vaikuttavat muutkin tekijät kuin tämä viitekehys. Eli se kuinka se itseohjautuva tiimi rakentaa softan. Eli kuinka kurinalaisesti siellä sisällä tehdään töitä ja millä metodeilla. Tyypillisesti siellä sisällä voidaan käyttää esimerkiksi vaikkapa TDD- menetelmää eli test driven development- tapaa. Eli jokainen taski suunnitellaan testivetoisesti.

Eli se Scrum ei ole mikään hopealuoti siihen, että saadaan aikaiseksi laadukasta softaa. Mutta se voi olla hopealuoti siihen, että saadaan muuttuvassa liiketoimintaympäristössä oikeat tarpeet tyydyttävää softaa.

Kannattaa muistaa, että Scrum kertoo mitä tehdään. Mutta sen sisällä pitää olla työtavat, jotka kertovat sen miten tehdään.

Kuhan pohdin, Kari…