# Agile-kehityksest, tissainist ja laadust

_2016-03-28 · Pekka Hartikainen_

> 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

_viikko 1_

**Viikko 1 – kaik näyttää olevan kunnos**

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

_viikko 2_

**Viikko 2 – bugit alkaa kasautuu**

Toisel viikol **menetelmä 1** tuottaa yhä enemmä ominaisuuksii ja enemmä bugei. Bugeist huolimatta ominaisuuksii julkastaa enemmä. Kaik on viel ok, eiks nii?

### Viikko 3

_viikko 3_

**Viikko 3 – bugien korjaamine alkaa viejä menetelmält 1 enemmä aikaa**

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.

_bugit luo hälyy_

**Kolme ihmist käyttää työaikaas bugii, minkä yks ihmine ois voint ratkasta hetkes.**

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.

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