Lukuaika 2 min
Agile-kehityksest, tissainist ja laadust
Laadun unohtamine voi tehä agile-kehityksest hidast.
Vaik agile-kehitys on yleist monis organisaatiois, sen ymmärtää helpost väärin. Ihmiset voi nyökytellä ja sanoo, et ne tietää, mitä agile-kehitys on, mut niil voi olla siit ihan erilaiset käsitykset.
Tosi yleine väärinkäsitys on, et kehittäjät ”voi nyt unohtaa laadun ja vaa heittää jutun ulos”. Toki se riippuu toiminnallisuuest ja tilantehest, mut usee huolimaton laatu kehitykses vaa hidastaa vauhtii.
Sanotaa vaik, et kaks tiimii tekköö ohjelmistokehitystä:
- Ensimmäine tiimi käyttää menetelmää 1 ja toimittaa viikos nii monta ominaisuutta ko mahollist, mut enemmä bugei.
- Toine tiimi käyttää menetelmää 2 ja toimittaa vähä vähemmä ominaisuuksii parempal laadul.
Verrataa nyt lopputulost viikko kerrallaa.
Viikko 1
Tapa 1, viikko 1 – enemmä ominaisuuksii, heikompi laatu
Tapa 2, viikko 1 – vähemmä ominaisuuksii, parempi laatu
Ensimmäisel viikol menetelmä 1 tuottaa enemmä ominaisuuksii mut myös enemmä bugei. Bugeist huolimatta oikeil käyttäjil on enemmä testattavaa. Tää vaikuttaa nopeemmalt tavalt testata, mikä toimii, ko vertaa menetelmää 2.
Viikko 2
Tapa 1, viikko 2 – enemmä ominaisuuksii, heikompi laatu
10 päivee, 10 ominaisuutt 24 bugii
Tapa 2, viikko 2 – vähemmä ominaisuuksii, parempi laatu
10 päivee, 6 ominaisuutt 2 bugii
Toisel viikol menetelmä 1 tuottaa yhä enemmä ominaisuuksii ja enemmä bugei. Bugeist huolimatta ominaisuuksii julkastaa enemmä. Kaik on viel ok, eiks nii?
Viikko 3
Tapa 1, viikko 3 – enemmä ominaisuuksii, heikompi laatu
15 päivee, 11 ominaisuutt 12 bugii
Tapa 2, viikko 3 – vähemmä ominaisuuksii, parempi laatu
15 päivee, 9 ominaisuutt 3 bugii
Kolmannel viikol menetelmäl 1 julkastaa vaa yks uus ominaisuus, ko osa bugeist pitää korjata. Menetelmä 2 taas kirii eroo kiinni, ko kokonaislaatu on parempi ja bugikorjauksii on vähemmä. Lisäks ensimmäine menetelmä on tuottant nii paljo bugei, et niit jää rutkast seuraavallekii viikol.
Luvut on keksittyi, mut ajatus on selvä. Agile ei välttämät tarkota huolimatont kehitystä ja huonoo laatuu. On paljo tärkeemp päättää, mitä minäki viikkon kehitetää, ja tehä se kunnol. Huolimattomal tissainil ja kehityksel sie voit myös saaha aikaa firmakulttuurin, mis huono työ hyväksytää agilen nimis. Sitä on vaikee korjata myöhemmi.
Tietyst osa ominaisuuksist karsitaa, ko niit ei tarvita – siinhä agilen koko idea on. Mut paljo on myös ominaisuuksii, mitä sie tarviit joka tapaukses – vaikka rekisteröitymine tai käyttäjäprofiili.
Huono laatu luo paljo turhaa hälyy
Ko ominaisuus julkastaa eikä se toimi niinko piti, oman organisaatios ihmiset raportoi siit ja ihmettelee, miks se on semmone. Tääst syntyy paljo turhaa viestintää ja raportointii – ja aikaa kuluu asiaa, minkä yks ihmine ois alun perin voint ratkasta helpost.
Asiakkaat, liiketoiminta-analyytikot, tissainerit ja muut kehittäjät sotkeutuu asiaa ja miettii, korjataaks bugi ja millo.
Ehotus: tee fiksust, toimita laatuu
Mie ehotan, et parempi tapa tehä agileeta on keskittyy laatuu, päätöksentekoprosessii ja takarajoihi. Vaik joku ominaisuus ois viikos ”melkei valmis”, oikee valmistumisaika voi bugien takii venyy jopa kuutee viikkoo. Usee ois suoraviivasemp budjetoija sille ominaisuuel vähä enemmä aikaa ja julkasta se ilman bugei.