Laatupäälliköillä on kaikenlaisia haasteita. Osaatko antaa joitain esimerkkejä?
Ei auktoriteettia? Ei tiimiä? Ei laatua?

Monissa organisaatioissa projektipäälliköillä on ainakin muodollista auktoriteettia projektinsa ihmisiin. Laatupäällikkönä haluaisit myös vaikuttaa kehittäjiin, mutta mahdollisuutesi ovat hyvin rajalliset. Joskus tuntuu siltä, ettei laadukkaan ohjelmiston tuottaminen ole lainkaan mahdollista ilman muodollista auktoriteettia ja omaa tiimiä.

On syytä muistaa, että kehittäjät haluavat tehdä hyvää työtä myös laadun näkökulmasta. Joskus vain olosuhteet ovat heitä vastaan. Heillä ei ole aikaa tehdä raskaita laatutoimenpiteitä tai noudattaa liian yksityiskohtaisia prosesseja pilkuntarkasti. Sinun tarvitsee antaa ohjelmistokehittäjille käytännöllisiä tapoja parantaa laatua lyhyessä ajassa. He tarvitsevat menetelmiä, joita on helppo suorittaa ja jotka eivät vaadi paljoa byrokratiaa. Yksinkertaisilla, käytännöllisillä ja tehokkailla menetelmillä voit värvätä ohjelmistosuunnittelijat omaan virtuaaliseen laatutiimiisi.

JATKUVASTI KRIISEJÄ?

Onko sinusta vaikea löytää aikaa kaiken tarpeellisen tekemiseen? Juoksetko kriisistä toiseen? Tuntuuko siltä, että sammuttelet jatkuvasti tulipaloja, eikä sinulla ole koskaan aikaa keskittyä oikeisiin asioihin? Ihan kuin olisit koko ajan askeleen jäljessä?

Kiireellisten ja tärkeiden asioiden tasapainottaminen ei ole helppoa. Laatu on yksi niistä asioista, jotka eivät tunnu kiireellisiltä, ennenkuin on liian myöhäistä tehdä sille mitään. Vähän niinkuin tappava sydänkohtaus, jonka aiheuttaa vähitellen kertynyt ylipaino ja kolesterolin tukkimat verisuonet. Sinun tehtäväsi on toimia (ja saada muut toimimaan) ennenkuin projektisi kärsii vääjäämättömän viimeisen sydänpysähdyksen tekemättömien laatuparannusten vuoksi. On aivan liian helppoa keskittyä kiireellisiin asioihin ja olla tekemättä mitään asioille, jotka ovat vain tärkeitä, eivät kiireellisiä. Tottakai sinun pitää hoitaa asiat, jotka ovat SEKÄ tärkeitä ETTÄ kiireellisiä. Niistä pitää huolehtia heti. On olemassa paljon asioita, jotka EIVÄT ole tärkeitä, vain kiireellisiä. Sinun tulee tunnistaa ne kokoukset, puhelut, keskustelut ja sähköpostit, jotka vaativat läsnäoloasi tai huomiotasi, mutta osoittautuvatkin lopulta vähäpätöisiksi. Kitke sellaiset aikataulustasi ja alat löytää aikaa tärkeille muttei kiireellisille asioillekin.

Auta myös kehittäjiä tekemään tällaista analyysiä. Siten voit auttaa heitä toimimaan laadun puolesta. Sinun tulee kaivaa kehittäjien kalentereista aikaa laatua varten. Osoita heille, kuinka jotkut kokoukset, tehtävät, puhelut ja sähköpostit eivät vie organisaatiota lainkaan kohti sille asetettuja tavoitteita vaan syövät itse asiassa heidän kallista aikaansa. Tässä oletetaan, että tunnet organisaatiosi tavoitteet. Toivottavasti laatu on yksi tärkeimmistä. Älä myöskään itse pidä turhia kokouksia.

Auta kehittäjiä keskittymään laatuun ja anna heille selkeitä tavoitteita. Tick-the-Code-säännö (oikeastaan koodausohjeistus) ovat selkeitä, tavoitettavissa ja mielekkäitä. Niistä saat erinomaisia laatutavoitteita.

Säännöllisesti tehdyt laatuparannukset vähentävät yllättävien kriisien määrää. Koodissa on vähemmän korjattavia virheitä, ja koodin selkeytyessä väärinymmärrysten määrä pienenee. Kehitystyöstä tulee luotettavampaa ja kiireen syöksykierre voidaan kääntää jatkuvaksi parantuvan laadun ja ajansäästöjen putkeksi.

LIIAN PALJON VIRHEITÄ?

Suuren perityn (legacy) järjestelmän ylläpito on usein ongelmallista. Järjestelmä on riittävän tärkeä pidettäväksi hengissä, muttei tarpeeksi tärkeä uudistettavaksi. Järjestelmää muokataan vain, jos muuta vaihtoehtoa ei ole. Ongelmista päästään eroon kiertämällä ne mahdollisimman pienin muutoksin ja uusia ominaisuuksia lisätään ajattelemattakaan arkkitehtuuria kokonaisuutena. Tuloksena syntyvä järjestelmä on korjausten, laajennosten ja toiveajattelun muodostama tilkkutäkki.

Tähän aivan liian tuttuun tilanteeseen joutumisen syy on monimutkaisuus. Suuret ohjelmistojärjestelmät ovat aina monimutkaisia, ja suuret TUNTEMATTOMAT ohjelmistojärjestelmät ovat lähes ylläpitokelvottoman monimutkaisia. Vuosien kuluessa järjestelmän alkuperäiset kehittäjät ovat kadonneet. Jäljellä on enää itse järjestelmä sekä mahdollisesti mystisiä dokumentteja, jotka näyttävät olleen vanhentuneita jo julkaisunsa aikoihin.

Kuvatunlaiset perityt järjestelmät ovat usein hauraita. Koodin muuttaminen yhtäällä aiheuttaa odottamattomia vaikutuksia toisaalla. Virheen korjaaminen johtaa toiseen. Tuotekehitysvelka on liian suuri. Kauan unohduksissa ollut laatu on hankala lisätä seokseen jälkikäteen. Mutta se ei ole mahdotonta. Jos omaksut pitkän aikavälin ajattelun ja suunnittelet, että järjestelmä tulee olemaan vähemmän hauras esimerkiksi kahden vuoden kuluttua, voit hyökätä monimutkaisuuden kimppuun moduuli kerrallaan.

Tick-the-Code on mahdollisuutesi muuttaa valtavan monimutkainen, henkitoreissaan oleva ohjelmistojärjestelmähirviö hyödylliseksi, kesytetyksi hyvälaatuiseksi järjestelmäksi, jolla on vielä monta terveen kehityksen vuotta edessään. Tyhjästä aloittaminen ei aina ole edes mahdollista. Ja vaikka aloittaisitkin tyhjästä, on paras pitää laatutaso mahdollisimman korkealla koko ajan. Laatutarkistuksia tulisi siis pitää säännöllisesti ja riittävän usein. Tick-the-Code auttaa pitämään lähdekoodin laadun korkealla. Jos laatu lipeää, tilanteen korjaaminen jälkikäteen on hankalampaa.

Asiakkaiden tai testauksen löytämät suuret virhemäärät ovat merkki koodin monimutkaisuudesta. Monimutkaisuutta aiheuttavat hoppuilevat tai taitamattomat kehittäjät, huonot suunnitteluratkaisut tai yleinen yksinkertaisuuden arvostuksen puute. Käytä Tick-the-Code-sääntöjä korostamaan yksinkertaisuutta ja selkeyttä. Jos kärsit liian monista virheistä, älä vain korjaa niitä, hyökkää niiden syiden kimppuun. Monimutkaisuus, taidon, ajan tai motivaation puute ovat mahdollisia kohteitasi. Älä kuluta kaikkea aikaasi oireiden hoidossa, kun sinun pitäisi parantaa sairaus.

LIIAN VÄHÄN TESTAUSTA?

Kerronpa sinulle salaisuuden: testaus ei ole ratkaisu. Testaus tulee jäljessä ja liian myöhään. Järjestelmään on jo päässyt virhe, kun järjestelmätestaus nappaa sen. Olisi paljon mukavampaa välttää virheet kokonaan kuin löytää niitä testauksessa. Virheiden löytyminen testauksessa on tietenkin parempaa kuin että asiakas löytäisi ne, mutta miksi tyytyä työlään vaivalloiseen loppumattomaan muka-ratkaisuun, kun oikeitakin ratkaisuja on olemassa? Tick-the-Code auttaa kehittäjiä löytämään monimutkaisia kohtia koodistaan. Monesti toiminnallisuus on kunnossa kun kehittäjät tikkaavat koodiaan. 'Tikki' on osoitus alentuneesta paikallisesta laadusta ja tikkien huomioonottamatta jättäminen johtaa ennen pitkää virheisiin, jotka ovat kalliita löytää ja korjata.

Ennaltaehkäisyn avain on oppimisessa. Testaus, jonka tekee joku muu, ei juurikaan opeta kehittäjille mitään. He korjaavat virheensä vähimmällä mahdollisella vaivalla ja unohtavat koko homman. Tick-the-Code -menetelmässä he tutkivat lähdekoodia itse. He oppivat paljon pelkästään näkemällä kuinka muut kehittävät koodiaan. Lisäksi säännöt ovat selkeitä ohjeita, joita hyvät ohjelmistokehittäjät noudattavat kirjoittaessaan koodia. Jos sääntö on tuntematon, on mahdollista oppia, minkä takaa toisto ajan myötä. Parempilaatuinen koodi parantaa tämänhetkisen projektin työskentelyolosuhteita, mutta jatkuvasti oppivat ohjelmistokehittäjät parantavat jokaista tulevaisuudenkin projektia ja tekevät työstä mukavampaa.

Jos minä olisin sinun saappaissasi - ja olen ollut saappaissasi - löisin vetoa ennemminkin virheiden välttämisen puolesta pysyvänä laaturatkaisuna kuin jatkuvasti lisääntyvän testaustarpeen puolesta. Testaus on jo hävinnyt.

OK, eiköhän tuo riitä ohjelmistokehitysorganisaatioiden ongelmista. Tietääkö kukaan, mitä Tick-the-Code voi tarjota?
LAADUN PARANTUMISTA

Oikein. Säännöllisillä Tick-the-Code -istunnoilla laatupäällikkö luo parantamisen ilmapiirin, jossa vikojen löytyminen ei ole paha asia, vaan tilaisuus oppia ja kehittyä.

Laadun parantuminen tarkoittaa käytännössä selkeämpää ja ymmärrettävämpää koodia, yksinkertaisempaa ja luotettavampaa ylläpitoa sekä vähemmän ja lyhyempiä debuggauskertoja. Virheistä tulee poikkeuksia.

OPPIMISTA!

Niin, hyvä. Luulen, että mainitsimme oppimisen jo, mutta se jos mikä kannattaa toistaa. Toistohan on opintojen äiti ja Tick-the-Code tarjoaa kehittäjille useita mahdollisuuksia käyttää selkeitä koodaussääntöjä. Sääntöjen noudattaminen koodia kirjoittaessa auttaa ehkäisemään monia virheitä. Jotkin säännöistä ovat niin yksityiskohtaisia, että voi olla vaikea nähdä ensisilmäyksellä mikä koodausperiaate sen takana on. Kaikki säännöt pohjautuvat nimittäin hyviin koodausperiaatteisiin. Oppimisen avain on ymmärtää periaatteet.

Neljä periaateluokkaa ovat 1) Puuttuva tieto, 2) Turha painolasti, 3) Kaaoksen aiheuttajat ja 4) Vaaralliset oletukset. Kaikki säännöt pohjautuvat näihin neljään luokkaan ja ovat siksi järkeviä.

NOPEAMPAA PALAUTETTA

Juuri niin. Tick-the-Code-menetelmällä voit tarkistaa koodia heti kun se valmistuu. Itse asiassa voit tikata koodia milloin hyvänsä, koodin ei tarvitse toimia, samperi, sen ei tarvitse edes kääntyä ja Tick-the-Code voi silti tuottaa mielekästä palautetta.

Testaus, ainakin järjestelmätestaus, on lähes täysin mahdotonta ennenkuin koko toiminnallisuus on olemassa. Sitä paremmin oppii, mitä nopeammin saa palautetta.

TARKKUUTTA!

Aivan oikein. Tick-the-Code saa kehittäjät todella katsomaan lähdekoodia. He näkevät kuinka toiset ovat ratkaisseet ongelmansa ja he huomaavat sekä hyviä että huonoja esimerkkejä. Tarkistajat tietävät tikkauksen jälkeen tarkalleen, mitä kirjoittaja on tehnyt viime aikoina. Tietoa projektista - yksityiskohtaista tietoa - leviää organisaatiossa, jossa tikataan. Erityisesti jos eri projektien henkilöstö tikkaa toistensa koodia ristiin.

Tarkistajat ja erityisesti kirjoittajat oppivat, että mitä tahansa lähdekoodista puuttuukin, puuttuu lopputuotteestakin. Selittelyt eivät auta. Tick-the-Code -menetelmässä ei ole mahdollista selitellä omia unohduksiaan, unohtuneet koodilohkot on vain lisättävä. Se, että lähdekoodi on viimeinen sana ohjelmistotuotannossa, on vahva huomio. Se mitä on vaatimusmäärittelyissä tai se kuinka upea arkkitehtuuri on kuvattu suunnitteludokumentaatiossa, ei merkitse mitään. Ne ovat vasta aikomuksia. Jos niitä ei noudateta koodia kirjoittaessa, niillä ei ole mitään merkitystä. Loppujen lopuksi vain lähdekoodi merkitsee. Lähdekoodi merkitsee aina.

EI BYROKRATIAA!

Oikein. Tick-the-Code tarjoaa ohjelmistokehittäjille käytännöllisen ja hyödyllisen tavan pitää lähdekoodinsa sisäisen laadun kunnossa. Menetelmä on tehokas, sillä tarkistajat löytävät tavallisesti useita kymmeniä parannusehdotuksia, ja se on käytännöllinen, sillä tuhannen koodirivin tarkistaminen Tick-the-Code -menetelmällä vie noin tunnin. Koodi tulostetaan paperille ja tarkistajat merkitsevät sääntörikkomukset eli tikit suoraan koodiin vapaalla kädellä. Sen jälkeen kirjoittaja saa koodin ja tekee tarvittavat muutokset sähköiseen muotoon ja siinäpä se. Paperiversion tikkeineen voi sitten heittää silppuriin ja unohtaa. Ei byrokratiaa, kaikki on äärimmäisen käytännöllistä ja suoraviivaista. Kehittäjät rakastuvat Tick-the-Code -menetelmään.

Tick-the-Code - käytännöllisen ohjelmistolaadun puolesta!
Kiinnostaisiko koeajo?

Tick-the-Code käytännössä:

video

MAGIC-sääntö.

Olet nyt tässä:

sivustokartta

Klikkaamalla sivustokarttaan.

Osanottajien sanomaa:

Todellista koulutuspalautetta

Klikkaamalla kurssitietoihin.