Tehokkuuden optimointi ja kustannusten minimointi ovat kaksi tärkeää osa-aluetta Lean-lähestymistavassa ohjelmistokehityksessä, jota monet tietotekniikkayritykset ovat jo testanneet käytännössä.

Tämän lähestymistavan juuret juontavat juurensa tunnetun autonvalmistajan Toyotan historiaan, ja ne perustuvat sen ongelmanratkaisukeinoihin. Lopputuloksena on, että tehdään vain sellaisia muutoksia, joista on hyötyä ja jotka samalla vaativat mahdollisimman vähän kustannuksia ja joiden toteuttaminen ei vie liikaa aikaa.

Ohjelmistokehitykseen liittyen Lean-menetelmää käsittelivät ensimmäisen kerran Mary Poppendieck ja Tom Poppendieck, jotka julkaisivat kirjan “Lean Software Development” vuonna 2003. Siinä kuvataan lean-tuotannon perinteiset periaatteet ohjelmistokehitykseen liittyen sekä joukko 22 työkalua (käytäntöä) ja niiden vertailu ketterään kehitysmetodologiaan.

Lean Software Development – ei ole projektikehityksen hallinnan metodologia, kuten se saattaa ensi näkemältä vaikuttaa. Kyseessä on joukko periaatteita, joita käytetään erilaisissa projekteissa kehitysprosessin parantamiseksi ja sen tehokkuuden lisäämiseksi.

Lean ohjelmistokehityksen 7 periaatetta

Lean-kehityksen ytimessä on joukko tärkeitä periaatteita, jotka ovat pysyneet lähes muuttumattomina viime vuosina. Yritetään selittää ne lyhyesti ja yksinkertaisesti.

1. Hukan poistaminen. Sovelluskehityksessä hukkaa on kaikki se, mikä ei tuota asiakkaalle mitään liiketoiminnallista arvoa eikä paranna kehitettävän tuotteen laatua tai nopeuta projektin julkaisuaikaa.

Muilla sanoilla, tämä on sitä, mihin käytämme rahaa emmekä saa siitä mitään hyötyä. Esimerkiksi käyttämätön koodi ja tarpeettomat toiminnot, jotka eivät tuo lisäarvoa sekä käyttäjälle että liiketoiminnalle, mutta vaativat aikaa keskusteluun, kehittämiseen, testaukseen ja dokumentointiin.

2. Amplify Learning. Jotta tiimi voi kehittää järjestelmän, joka tuo liiketoiminta-arvoa asiakkaalle, sillä on oltava monenlaisia taitoja. Tiimin on kerättävä tietoa ja jaettava sitä esimerkiksi iteraation lopussa pidettävän katselmuksen muodossa.

Ja osa uudesta oppimisesta on teknistä, osa taas luokitellaan ei-toiminnallisiksi vaatimuksiksi. Esimerkiksi ymmärrys siitä, mitä liiketoimintakäyttäjä todella haluaa, eikä sitä, mitä kehittäjät kuvittelevat. Siksi tiimin on jatkuvasti kehitettävä, opittava ja kerättävä tietoa. Näin tiimi voi välttää ongelmat tulevaisuudessa.

3. Päätä mahdollisimman myöhään. Tärkein ajatus tässä on odottaa viimeiseen hetkeen ennen kuin tekee mitään päätöksiä, erityisesti peruuttamattomia päätöksiä. Tämä pätee erityisesti silloin, kun puhutaan päätöksistä, joilla voi olla merkittävä vaikutus kehityksen onnistumiseen.

Kaikkien päätösten tueksi tarvitaan analyyttistä dataa ja prosessinseurantatuloksia, muutoin tiimi on vaarassa uppoutua liian moniin muutoksiin ja saattaa unohtaa projektin päätarkoituksen.

Mitä myöhemmin teet päätöksen, sitä enemmän osaamista ja ymmärrystä sinulla on ja sitä vähemmän joudut myöhemmin tekemään uudelleen.

4. Toimita niin nopeasti kuin mahdollista. Tämä on iteratiivisen kehityksen perusta. Mitä nopeammin näytät pohjatyösi asiakkaalle, sitä nopeammin saat häneltä palautetta, jolloin hän saa tuotteen tarvittavine parannuksineen paljon nopeammin.

Yleenkiintoinen liiketoimintatoiminto, joka meni tuotantoon muutamassa kuukaudessa, voi lopulta osoittautua täysin hyödyttömäksi. Mutta jos se julkaistaisiin kahden viikon kuluessa, se voisi osoittautua asiakkaalle hyödylliseksi.

5. Voimaannuta tiimi. Ohjelmistokehitys on henkistä työtä, joten kohtele ihmisiä pätevinä ja motivoituneina ammattilaisina eikä niinkään ammattilaisina, joilla on kapea-alaiset taidot koodin kirjoittamisessa tai kaavioiden piirtämisessä.

Jotta ihmiset ottaisivat vastuuta, olisivat motivoituneita ja työskentelisivät vankkana tiiminä, heidän pitäisi olla tietoisia omasta panoksestaan kehitettävään tuotteeseen. On luotava olosuhteet, joissa kukin voi keskittyä työskentelemään kulloisenkin liiketoimintatehtävän parissa.

Luota tiimiisi ja kunnioita sitä. Inhimillinen tekijä on yksi tärkeimmistä tekijöistä onnistuneessa ohjelmistokehityksessä.

6. Rakenna rehellisyys sisään. Lean-kehityksen periaatteiden mukaan ongelma voidaan joko löytää sen ilmaantumisen jälkeen tai poistaa ongelmaan johtavat syyt etukäteen.

Lean Software Development -kirjan kirjoittajat ehdottavat, että laatuongelma ratkaistaan suoraan silloin, kun se alkaa ilmaantua – aluksi panostamalla laatuun tuotteessa eikä jättämällä virheiden tunnistamista ja korjaamista testaukseen tai tuotantoon. Tätä varten kannattaa edetä pienin askelin ja tarkistaa laatu jokaisen askeleen jälkeen.

7. Katso kokonaisuutta.

Tärkein tapa ratkaista ongelmia on pilkkoa ne pienempiin ongelmiin ja poistaa johdonmukaisesti niiden esiintymisen syyt. Nähdäksesi ongelman juurisyyn tiimillä tulisi kuitenkin olla hyvä kokonaiskäsitys nykyisestä kehitysprosessista sekä kehitettävän tuotteen konseptista ja strategiasta.

Yhteenveto

Tässä artikkelissa tutustut Lean-ohjelmistokehityksen periaatteisiin, joita voit soveltaa työskennellessäsi projekteissa tiimissäsi. Voi hyvinkin olla, että voit näin parantaa tehokkuutta ja optimoida prosesseja.

On välttämätöntä ymmärtää, että puhumme periaatteista, emmekä tiukoista säännöistä. Siksi on nähtävä hieman vaivaa, jotta niitä voidaan tehokkaasti mukauttaa projektisi erityispiirteisiin.