2. Bugit

"Kun meillä on nyt kuulkaas täällä ihan karmea bugi."
Niin. Kovasti olisi hienoa, jos kaikki järjestelmät toimisivat aina pilkulleen oikein. Sekä testeissä että tuotannossa. Sitten jos ja kun kuitenkin joku bugipaholainen sinne tuotantoon asti pääsee, ei ole mitään syytä pysäyttää kaikkia rattaita. Prosessi rullaa edelleen, bugeihin on varauduttu ennalta miettimällä, millä resursseilla niitä korjaillaan. Havainnollistetaan tätä yksinkertaisella esimerkillä:

4 ohjelmistoalan ammattilaista tekee järjestelmää X. Uuden ominaisuuden Y kehityksen on arvioitu kestävän 10 työpäivää. Juuri kun ammattilaiset ovat intoa puhkuen pääsemässä kehittämään uutta ominaisuutta, tuotannosta löytyy karmea bugi. Ohjelmistoprosessin vetäjän tulisi:


a) pistää jäihin uuden ominaisuuden kehittäminen järjestelmään ja laittaa ne 4 ammattilaista korjaamaan bugi, jolloin bugikorjaus ja uusi ominaisuus on valmiina 10 päivän päästä
b) pistää jäihin uuden ominaisuuden kehittäminen järjestelmään ja kulkea ympäri toimistoa voivotellen ne 4 ammattilaista vanavedessään. Voivotteluun varataan päivä, jolloin uusi ominaisuus ja bugikorjaus ovat valmiina 11 päivän päästä.
c) jatkaa uuden ominaisuuden kehittämistä ihan pokkana. Uusi ominaisuus on valmis 10 päivän kuluttua.
d) jatkaa uuden ominaisuuden kehittämistä 2:lla kehittäjällä, jolloin uuden ominaisuuden kehittäminen kestää 20 päivää. Bugikorjaukseen allokoidaan 2 kehittäjää. Bugikorjaus valmistuu sitten kun bugin syy ja laajuus on saatu selville.


Oikea toimintatapa esimerkin tapauksessa olisi c. Bugien olemassaoloon on toivottavasti varauduttu ennalta, ja niiden vaatima aika ja korjaamiseen tarvittavat resurssit ovat olemassa. Myös d on täysin pätevä vaihtoehto, kunhan muistetaan, että sen uuden ominaisuuden luominen puolilla alkuperäisistä resursseista todellakin vie kaksinkertaisen ajan! Tämä tuntuu jostain syystä olevan käsittämättömän vaikea asia joillekin prosessivastaaville ymmärrettäväksi. Jos yhtälö ei muuten aukea, niin kannattaa vaikka leikkiä hieman Excelillä.

Showstopper-tasoiset bugit ovat sitten asia erikseen, mutta niiden kriteerien on syytä olla aika perusteellisen hyvin mietittyjä etukäteen.