Kallispalkkainen konsultti numeroa liian suuressa pikkutakissa julistaa Leanin olevan ratkaisu kaikkiin ohjelmistoalan ongelmiin. Esittelykalvoissa vilahtavat tasaisin väliajoin erilaiset nelikentät ja prosessikuvat. Välillä konsultti toistelee mystisiä japanilaisia termejä. Kuulijat pälyilevät kelloa hermostuneesti ja miettivät mitä naposteltavaa seuraavalla tauolla olisi tarjolla. Tilanne on valitettavan tuttu monelle Lean-seminaarissa olleelle. Mutta Lean-ajattelua on myös mahdollista hyödyntää konkreettisesti. Seuraavissa kappaleissa annan muutamia vinkkejä, joita on helppo soveltaa sekä Kanban että Scrum -pohjaisissa ohjelmistoprojekteissa. Varasta vapaasti.
Just In Time
Just In Time (JIT) -menetelmä on suunniteltu alun perin kaupan ja teollisuuden varastonhallinta- ja tuotannonohjausstrategiaksi. JIT-ajattelun lähtökohta on toimittaa vain ja ainoastaan tarvittavat raaka-aineet asiakkaalle vasta silloin kun niitä tarvitaan ja vain sen verran kuin niitä tarvitaan. JIT-ajattelun avulla välivarastojen arvo ja tuotteiden läpäisyaika minimoituu. Ohjelmistokehityksen raaka-aineita ovat luonnollisesti kaikki vaatimusmäärittelyt ja keskeneräiset ominaisuudet.
Näin hyödynnät:
- Kirjoita käyttäjätarina ja siihen liittyvät määrittelyt vasta juuri ennen tehtävän toteuttamista.
- Rajoita backlogin koko esimerkiksi vain kahden viikon työtä vastaavaksi.
- Korjaa löydetyt bugit heti.
- Vältä projektivaiheistuksia, jossa lopputuloksena on vain suuri määrä dokumentaatiota.
- Hallitse tuotteen vaatimuksia karkealla ominaisuustasolla, älä yksittäisillä käyttäjätarinoilla.
Kaikki työ näkyville
Työtehtävien tuominen kaikkien näkyviin on hyvä tapa soveltaa Lean-ajattelun läpinäkyvyysperiaatetta. Tilannetietojen varmistamisen tarve vähentyy, koska tiimi ja sidosryhmät tietävät jatkuvasti projektin tilanteen. Projektin ennustettavuus myös parantuu, koska töiden edistyminen on jatkuvasti seurattavissa. Töiden tuominen näkyviin nostaa esille lisäksi prosessin pullonkaulat ja paikalliset tukokset. Kaikkien töiden ollessa näkyvissä asiakas ymmärtää usein myös monen yhtäaikaisen työn vaaran.
Näin hyödynnät:
- Tee tuotteelle arvoketjuanalyysi (value stream mapping) ja luo tähän pohjautuva Kanban-taulu.
- Vakioi projektissa käytettävät tehtävätyypit (esimerkiksi käyttäjätarinat, tekniset tarinat ja bugit).
- Varmista, että uusien tehtävien luominen on riittävän helppoa ja nopeata.
- Luo loogiset säännöt tehtävien etenemiselle taululla.
- Tarkista aika ajoin, että kaikki projektissa tehtävä työ on näkyvissä taululla.
Läpimenoaika ja teho
Jatkuva parantaminen on ehkä Lean-ajattelun tärkein yksittäisen teesi. Usein jatkuva parantaminen jää projektissa pelkiksi post-it -lapuiksi projektitilan seinälle. Oppimista on kuitenkin helppo seurata läpimenoajan (lead time) ja tehon (throughput) avulla. Läpimenoaika mittaa tehtävän ajallista kestoa prosessin läpi. Teho taas mittaa valmistuneiden tehtävien lukumäärää haluttua aikayksikköä kohti. Projektissa tapahtuva oppiminen näkyy väistämättä läpimenoaikojen keskimääräisenä laskuna ja tiimin kasvavana tehona. Mittarit helpottavat myös projektin ennustamista ja esimerkiksi tulevien julkaisujen suunnittelua.
Näin hyödynnät:
- Käytä tehon seurantaan tehtävien lukumäärää, älä tarinapisteitä.
- Ilman sähköistä työkalua läpimenoaikojen seuranta on työlästä.
- Pyri ajan myötä yhtenäistämään tehtävien koot, jolloin ennustaminen tarkentuu.
- Tuo kiertonopeuden ja tehon tarkastelu osaksi esimerkiksi retrospektiiviä.
- Älä johda mittareilla projektia.
Yhteenveto
Lean-ajattelu ei tule ratkaisemaan ohjelmistoprojektien suuria aikataulu- ja laatuongelmia, mutta tarjoaa työkaluja helpottamaan ohjelmistotyöläisen arkea. Tärkeää on muistaa, että itse Lean ei suunnittele, toteuta tai testaa yhtään palvelun ominaisuutta – If you meet the lean-buddha on the road kill him.
Termien selitykset
- Value Stream mapping= Visuaalinen kuvaus kaikista niistä aktiviteeteista, joita tarvitaan tuotteen tai palvelun toimittamiseksi asiakkaalle. Ohjelmistoprojekteissa tyypillisiä aktiviteetteja ovat esimerkiksi määrittely, toteutus ja testaus.
- Pullonkaula = Prosessin hitain vaihe, joka hidastaa koko prosessin etenemistä.
- Paikallinen tukos = Yksittäinen tehtävä, joka ei edisty syystä tai toisesta
- Tekniset tarinat = Teknisillä tarinoilla osaltaan varmistetaan tuotteen ylläpidettävyys, käytettävyys ja skaalautuvuus. Teknisiä tarinoita ovat mm. erilaiset selvitys-, refaktorointi- ja migraatiotehtävät. Teknisten tarinoiden tarkoitus on minimoida järjestelmän tekninen velka.
Lähteet / luettavaa
Kniberg – Lean from the Trenches: Managing Large-Scale Projects with Kanban (http://www.amazon.com/Lean-Trenches-Managing-Large-Scale-Projects/dp/1934356859)
http://www.netobjectives.com/blogs/why-kanban-board-value-stream-map-scrum-board-isnt-and-what-tells-us
http://en.wikipedia.org/wiki/Just_in_time_(business)
http://softwaredevelopmenttoday.blogspot.pt/2012/01/story-points-considered-harmful-or-why.html
