Vältä Pimeä Agile



Ketterästä ohjelmistokehityksestä, agilesta, pidetään niin paljon ääntä, että voisi luulla aivan kaikkien harjoittavan sitä. Ikävä kyllä agile on alkanut kärsiä vapaasti muuttuvien kuvausten ongelmasta, vähän kuin kilpailua syrjivää sääntelyä kutsutaan kapitalismiksi. Maailmalla on paljon esimerkkejä, että itse asiassa monet, jotka sanovat olevansa agileja, eivät sitä oikeasti ole. Nämä tahot harjoittavat Pimeää Agilea, ja näin sinä voit välttää syyllistymästä samaan.

Houkutus on suuri
Houkutus on suuri

Muista, mistä agilessa on kyse

Jotta voi välttää antautumasta agilen pimeälle puolelle, täytyy ensin muistaa mistä agilessa on kyse. Liike alkoi n. 15-20 vuotta sitten eri ideoiden koheesiosta. Ohjelmistokehitys oli hidasta ja kankeaa. Ohjelmoijat saivat olla kiitollisia jos näkivät saman koodin kehittyvän iteraatioissa, muuten kaikki tehtiin kerralla hyvin suunnitellusti. Agilen kenties tärkein vaikuttaja oli Extreme Programming -nimellä kulkeva joukko menetelmiä. Kirjoittamalla yksikkötestejä ja modulaarista koodia, harjoittamalla pariohjelmointia ja muokkaamalla koodia usein pystyy toimittamaan toimivia ratkaisuja hyvinkin nopeasti.

Scrum pähkinänkuoressa

Scrum on menetelmä, joka jakaa muutaman yksinkertaisen roolin kehittäjien ja liiketoiminnan kesken, antaen muutoin vapaat kädet toimia. Liikepuolelta kuullaan mitä tarvitaan. Tuoteomistaja päättää mitä voi ja pitää tehdä, toki pitäen liiketoiminnan mielessä. Kehitystiimi päättää aikataulut.

Päämääränä luottamus osapuolten välille

Liikepuolelle yrityksessä tämä on vaikea pala, koska hehän tuovat rahat sisään elättääkseen ohjelmoijia! Toisaalta, ohjelmoijat mahdollistavat tämän rahan tuomisen. Tällainen menetelmä, jolla laadukasta ohjelmistoa toimitetaan nopeasti, on tarkoitettu parantamaan luottamusta osapuolten välille. Liikemiesten ei tarvitse enää hönkiä ohjelmoijaparan niskaan kuukausikaupalla kun näytettävää tulee nopeammin. Ohjelmistopuoli alkaa luottaa liikemiehiin enemmän, kun palautetta saa nopeammin.

Ketterän ohjelmistokehityksen julistus kuvastaa muutamalla ranskalaisella viivalla ydinperiaatteet.

Tule pimeälle puolelle…

Ei mennyt kovinkaan kauaa, kunnes agilen pimeä puoli alkoi houkutella. Perinteiselle projektijohdolle Scrum Master -koulutus on tietysti yksi natsa CV:ssä muiden joukossa, mutta alunperin Scrummasterin piti olla yksi kehittäjistä. Mieluusti vähän väliä eri kehittäjä. Syyllistämättä tämän enempää projektipäälliköitä on käynyt niin, että ulkopuolinen Scrummaster lähestyy tilannetta usein komentavasti, ei fasilitoivasti.

Sen lisäksi, että Scrummasterin, tiimin fasilitaattorin, pitäisi olla kiinteä osa tiimiä, hänen pitäisi olla tekninen. Ymmärtämättä Extreme Programmingin tärkeyttä saatetaan ajautua tilanteeseen, jossa testit irrotetaan koodista tai kannustetaan ohjelmoijaa kirjoittamaan monoliitti, koska rajapintasuunnitteluun menee pidempi aika. Tai mitä tahansa muuta, johon ohjelmoijat samaistuvat pimeänä puolena. On valitettavaa, ettei Agile Manifesto nosta tätä yhdeksi periaatteeksi.

Toisin sanoen, Scrummasterin, tai minkä tahansa vastaavan, työ on puolustaa Scrumia ja teknistä laatua, eikä mitään muuta. Jos tämä ei pidä paikkaansa, et harjoita Scrumia, etkä luultavasti agilea muutenkaan.

Mistä tiedät siirtyneesi Pimeään Agileen?

On paljon tunnusmerkkejä, joista tietää lipsuvansa:

  • Työskentelyssä väheksytään suunnittelua, koska sehän olisi vanhanaikaista. Tiimin täytyy ymmärtää, että nopea koodin muokattavuus ei ole hyväksyttävä peruste aikaa hukkaavalle uudelleenkirjoittelulle, jos kerran voi suunnitella paremmin etukäteen.
  • Tuoteomistaja on suorittavalla tasolla tekemisissä ohjelmoijien kanssa, vaikuttaen (tai edes yrittäen vaikuttaa) työskentelyyn. Tuoteomistajan rooli on selventää työtehtäviä, ei muuttaa niitä työn aikana tai kertoa ohjelmoijille miten työ kuuluu tehdä.
  • On olemassa projektipäällikkö, joka pääsee häiritsemään esimerkiksi Scrumin sprinttien pituutta.
  • Vähintään viikottaisia isompia tehtävälistan muutoksia. Tekemättömien töiden listaa voi olla järkevää hienosäätää vaikka jatkuvasti, mutta sprintin tavoitteeseen ei saa kajota kun se on lyöty lukkoon.
  • Yksittäiset pienet alitehtävät tai vastaavat yksityiskohdat näkyvät ulospäin. Liiketoiminnan ei pitäisi välittää kuin päätason tehtävistä ja bugikorjauksista.

Pysy agilen valoisalla puolella

Mitä täytyy sitten pitää mielessä, että pysyisimme agilen valoisalla puolella? Ladon tähän listan, joka pätee melko hyvin, oli käytössä Scrum tai jokin täysin itsekeksitty juuri sinun tiimillesi toimiva malli.

  • Valmiin määritelmä, Definition of Done, sisältää aina vähintään yksikkötestit ja mahdollisesti muita laatukriteerejä. Kukaan tiimin ulkopuolelta ei saa vaatia kriteerien poistamista tai heikentämistä. Ketteryys vaatii laadukasta työtä, joten tiimin täytyy aina varata puskuria mahdollisille ongelmille, olivat ne tiukasta laadunvarmistuksesta huolimatta ilmenneitä bugeja tai jotakin muuta. Kukaan tiimin ulkopuolelta ei saa vaikuttaa ajanvarauksiin tai deadlineihin.
  • Tiimin on ansaittava luottamusta kertomalla tiimin jäsenille ongelmista. Scrummasterin on fasilitoitava ongelmat pois tieltä.
  • Tuoteomistajan on luotettava tiimiin. Jos jotain jää tekemättä sprintissä, sille on varmasti syy ja siitä tulee keskustella, mutta ei syyllistää.
  • Liiketoiminnan ei tarvitse myöskään tietää mistään story pointeista tai velocitystä tai muusta tiimin sisäisestä kirjanpidosta. Ihanteellisesti liiketoiminnan, poislukien tuoteomistajan tai muun yhteyshenkilön, ei tarvitse edes tietää harjoittaako tiimi Scrumia vai jotakin muuta.

Loppuun pari havainnollistavaa Youtube-videota:

 

 

***
Ylin kuva: Flickr CC, Holley & Chris Melton

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *