Toimivan ja vakaan ohjelmiston toimittaminen ei ole yksinkertaista tyypillisessä ohjelmistoprojektissa. Ymmärtääksemme miksi, meidän on katsottava isompaa kuvaa.
Ohjelmistokehitys koostu lukuisista erilaisista paradigmoista, malleista, kehyksistä, metodologioista, käytännöistä yms. Kaikki tämä heijastuu ohjelmiston elinkaaren yli.
Se mitä missäkin tilanteessa voi soveltaa tehokkaasti vaatii valtavasti asiantuntemusta ja kokemusta.
Ohjelmiston elinkaaren aikana tapahtuu paljon ja se vaihtelee valtavasti ohjelmistosta toiseen.
Emily Freemanin DevOps-malli on yksi hyvä tapa kuvata tyypillistä modernia ohjelmistoprojektia. Mallissa on roolit ja poikkileikkaavat laatuominaisuudet.
Kun ohjelmistokehitystä katsoo kokonaisuutena ja kaikkea mitä siihen sisältyy, voi ymmärtää kuinka haastavaa se on.
Meillä kehittäjillä on ratkaiseva rooli jokaisessa vaiheessa ja tulokulmassa. Oli se sitten tiimin käytännöt, käytetyt teknologiat, testattavuuden varmistaminen kaikilla tasoilla jne. Jokaisella valinnalla on vaikutusta joko omaan tai muiden työhön. Jotta tiimi menestyy, on ymmärrettävä jokaisen valinnan seuraukset.
Ohjelmistokehitys on vaativa laji ja onnistuneiden ohjelmistoprojektien toimittaminen vaatii laaja-alaista osaamista.Olemme tunnistaneet kolme kategoriaa taitoja, jotka ovat oleellisia ohjelmistokäsityöläisyydessä: inhimillisyys, strategiset taidot ja taktiset taidot.
Tuotannossa olevat ohjelmistot ovat arvokkaita jos ne säästävät rahaa, tuottavat rahaa tai suojaavat tuottoja.
Jos taas ohjelmistoja katsotaan niiden kehittämisen näkökulmasta, niin ne ovat arvokkaita jos ne ovat helposti muokattavissa. Tästä johtuen kehityksen aikana yksi arvokkaimmista asioista mitä voidaan tehdä, on ylläpitää tai parantaa ohjelmiston muokattavuutta.
Päivittäisessä työssä on hyvä keskittyä siihen, mikä on siinä hetkessä eniten arvoa tuottavaa ja jättää vähemmän arvoa tuottavat asiat myöhemmäksi, koska haluamme maksimoida arvontuoton.
Myös prosessilla on arvoa. Esimerkiksi jos vaatimukset ovat epämääräisiä tai niiden arvo on epäselvää, on syytä pysähtyä. Tämä pätee myös tiimityöhön jossa hukka pitäisi minimoida ja arvo maksimoida. Esimerkiksi ylimääräisistä palavereista voi luopua tai pitää niitä pienemmällä joukolla.
Arvon lisäämiseksi ohjelmistoa pitää yleensä muokata jollain tapaa.
Jos ohjelmisto on helposti muokattavissa, niin se kertoo laadusta, koska muutokset on helppo tehdä jolloin ne eivät myöskään aiheuta vikoja tai regressioita. Helpot muokkaukset tarkoittavat myös nopeaa palautetta esim. testeistä tai suoraan tuotannosta koska eihän muutokset muuten olleet helppoja.
Tämä voisi tiivistää seuraavaan:
Helppo muokattavuus ⇒ Nopea palaute ⇒ Laatu ⇒ Arvo
On myös hyvä huomata että ohjelmiston tulee olla helpohkosti muokattavissa myös uusille aloitteleville kehittäjille. Jos muokattavuus vaatii seniori tason osaamista ja pitkää kokemusta projektista niin sovellus ei ole helposti muokattavissa.
Nopea palaute parantaa tuottavuutta ja tämä pätee monella tasolla. Esimerkiksi koodikatselmoinnit tai onko tuoteomistaja käytettävissä kun häntä tarvitaan. Myös asiakas tarvitsee nopeasti palautetta jotta kykenee ohjaamaan tuotekehitystä, tekemään kokeiluja sekä innovoimaan.
On tärkeää että palautteen saaminen säilyy nopeana vielä useiden intensiivisten kehitysvuosien jälkeen. Esimerkiksi voisi ottaa vaikka testien ajoajan.
Erilaisista palaute sykleistä on hyödyllistä kerätä statistiikkaa ja seurata kuinka syklit kehittyvät ajan saatossa.
Koko arvo kysymyksen voi tiivistää seuraavasti: uuden ominaisuuden arvolla ei ole väliä, vaan sillä kuinka nopeasti se saadaan tuotantoon.
Me olemme joukko ohjelmistokäsityöläisiä (Software Crafter). Termi viittaa Software Craftsman -liikkeeseen.