Lukuaika 2 min
Agile-kehityksestä, designista ja laadusta
Laadun laiminlyönti voi tehdä agile-kehityksestä hidasta.
Vaikka agile-kehitys on yleistä monissa organisaatioissa, se on helppo ymmärtää väärin. Ihmiset saattavat nyökytellä ja sanoa tietävänsä, mitä agile-kehitys on, mutta heillä voi olla siitä hyvin erilaiset käsitykset.
Hyvin yleinen väärinkäsitys on, että kehittäjät ”voivat nyt unohtaa laadun ja vain heittää jutun ulos”. Toki se riippuu toiminnallisuudesta ja tilanteesta, mutta usein huolimaton laatu kehityksessä vain hidastaa vauhtia.
Oletetaan, että kaksi tiimiä tekee ohjelmistokehitystä:
- Ensimmäinen tiimi käyttää menetelmää 1 ja toimittaa viikossa niin monta ominaisuutta kuin mahdollista, mutta enemmän bugeja.
- Toinen tiimi käyttää menetelmää 2 ja toimittaa hieman vähemmän ominaisuuksia paremmalla laadulla.
Verrataan nyt lopputulosta viikko kerrallaan.
Viikko 1
Tapa 1, viikko 1 – enemmän ominaisuuksia, heikompi laatu
Tapa 2, viikko 1 – vähemmän ominaisuuksia, parempi laatu
Ensimmäisellä viikolla menetelmä 1 tuottaa enemmän ominaisuuksia mutta myös enemmän bugeja. Bugeista huolimatta oikeille käyttäjille on enemmän testattavaa. Tämä vaikuttaa nopeammalta tavalta testata, mikä toimii, verrattuna menetelmään 2.
Viikko 2
Tapa 1, viikko 2 – enemmän ominaisuuksia, heikompi laatu
10 päivää, 10 ominaisuutta 24 bugia
Tapa 2, viikko 2 – vähemmän ominaisuuksia, parempi laatu
10 päivää, 6 ominaisuutta 2 bugia
Toisella viikolla menetelmä 1 tuottaa yhä enemmän ominaisuuksia ja enemmän bugeja. Bugeista huolimatta ominaisuuksia julkaistaan enemmän. Kaikki on vielä ok, eikö niin?
Viikko 3
Tapa 1, viikko 3 – enemmän ominaisuuksia, heikompi laatu
15 päivää, 11 ominaisuutta 12 bugia
Tapa 2, viikko 3 – vähemmän ominaisuuksia, parempi laatu
15 päivää, 9 ominaisuutta 3 bugia
Kolmannella viikolla menetelmällä 1 julkaistaan vain yksi uusi ominaisuus, koska osa bugeista on korjattava. Menetelmä 2 taas kirii eroa kiinni, koska kokonaislaatu on parempi ja bugikorjauksia on vähemmän. Lisäksi ensimmäinen menetelmä on tuottanut niin paljon bugeja, että niitä jää runsaasti seuraavallekin viikolle.
Luvut ovat keksittyjä, mutta ajatus on selvä. Agile ei välttämättä tarkoita huolimatonta kehitystä ja heikkoa laatua. On paljon tärkeämpää päättää, mitä kunakin viikkona kehitetään, ja tehdä se laadukkaasti. Huolimattomalla suunnittelulla ja kehityksellä voit myös luoda yrityskulttuurin, jossa heikkolaatuinen työ hyväksytään agilen nimissä. Sitä on vaikea korjata myöhemmin.
Osa ominaisuuksista tietenkin karsitaan, koska niitä ei tarvita – siinähän agilen koko idea on. Paljon on kuitenkin myös ominaisuuksia, joita tarvitset joka tapauksessa – esimerkiksi rekisteröityminen tai käyttäjäprofiili.
Heikko laatu luo paljon turhaa hälyä
Kun ominaisuus julkaistaan eikä se toimi tarkoitetulla tavalla, oman organisaatiosi ihmiset raportoivat siitä ja ihmettelevät, miksi se on sellainen. Tästä syntyy paljon turhaa viestintää ja raportointia – ja aikaa kuluu asiaan, jonka yksi ihminen olisi alun perin voinut ratkaista helposti.
Asiakkaat, liiketoiminta-analyytikot, suunnittelijat ja muut kehittäjät sotkeutuvat asiaan ja miettivät, korjataanko bugi ja milloin.
Ehdotus: työskentele fiksusti, toimita laatua
Ehdotan, että parempi tapa tehdä agilea on keskittyä laatuun, päätöksentekoprosessiin ja aikatauluihin. Vaikka jokin ominaisuus olisi viikossa ”melkein valmis”, todellinen valmistumisaika voi bugien takia venyä jopa kuuteen viikkoon. Usein olisi suoraviivaisempaa budjetoida kyseiselle ominaisuudelle hieman enemmän aikaa ja julkaista se ilman bugeja.