# Agile-kehityksestä, designista ja laadusta

_2016-03-28 · Pekka Hartikainen_

> 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

_viikko 1_

**Viikko 1 – kaikki näyttää olevan kunnossa**

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

_viikko 2_

**Viikko 2 – bugit alkavat kasautua**

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

_viikko 3_

**Viikko 3 – bugien korjaaminen alkaa viedä menetelmältä 1 enemmän aikaa**

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.

_bugit luovat hälyä_

**Kolme ihmistä käyttää työaikaansa bugiin, jonka yksi ihminen olisi voinut ratkaista hetkessä.**

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.

https://pekkahartikainen.fi/fi/blog/on-agile-development-design-and-quality