Jostain syystä versionhallinta osoittautuu välillä ihan ylitsepääsemättömän vaikeaksi asiaksi softan tekijöille. Versionhallintaa käytetään jonkinmoisena koristeena serverin syövereissä. Koodaajat hautovat koodiansa omilla koneillaan, kunnes jostain ylhäältä kuulu, käsky että "Nyt saa kommitoida!!!". Sitten kommitoidaan, mergetään, selvitellään konflikteja, itketään, revitään hiuksia, saadaan versionhallinta jonkinmoiseen kuosiin, viedään tavara tuotantoon, itketään, revitään hiuksia, rollbackataan (tai mikä pahinta, ei kyetä tekemään rollbackia, vaan joku näpertää käsin tuotantoa ns. releasea edeltäneeseen kuntoon) ja jännitetään seuraavaa releasea.
Ihan vaan vinkiksi kaikille prosesseja työkseen pohtiville: useimmat, ellei peräti kaikki aataminaikuisetkin versionhallintatyökalut tarjoavat sellaisia ominaisuuksia kuin branchays ja tagays, joita voi käyttää avuksi ihan oman mielikuvituksen mukaan. Ja nykyään on muodissa agile ja commit small and often. Ei tarvii sitten itkeä, jos jonkun koodarin kone hajoaa ja koodimuutokset sen mukana, tai versiot menee solmuun, kun kommitoidaan kerralla paljon muutoksia monen eri kehittäjän koneelta. MOT.
101 Tapaa Mokata Ohjelmistotuotanto
-Ilmaisia vinkkejä mielenterveyden säilyttämiseksi it-alalla
torstai 5. tammikuuta 2012
tiistai 8. marraskuuta 2011
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.
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.
1. Prosessi...
... tai tarkemmin sanottuna sen puute. Prosessilla on, yllätys yllätys, vaikutusta lopputulokseen. Lopputulosta ei määritä se, kuinka monta yliälykästä ohjelmoijaa ja siistiin pikkutakkiin pukeutunutta hankkeen vetäjää sopassa on mukana. Lopputulosta ei voi myöskään ennustaa projektin osallistujien tuntihinnan perusteella. Halvalla ja kalliilla saa ihan yhtä huonoja järjestelmiä.
Prosessin valitsijalla on syytä olla kokemusta erilaisista prosesseista ohjelmistokehityksessä, niiden vahvuuksista ja heikkouksista, sekä kykyä tunnistaa prosessien pullonkaulat. On myös toivottavaa, että kaikille projektiin osallistuville on selvää, mitä prosessia käytetään. Lopputulosta ei ainakaan myöskään heikennä, jos osallistujilla on edes jonkinlainen käsitys siitä, millaista prosessia käytetään ja miten se noin niinkuin suunnilleen toimii.
Prosessin valitsijalla on syytä olla kokemusta erilaisista prosesseista ohjelmistokehityksessä, niiden vahvuuksista ja heikkouksista, sekä kykyä tunnistaa prosessien pullonkaulat. On myös toivottavaa, että kaikille projektiin osallistuville on selvää, mitä prosessia käytetään. Lopputulosta ei ainakaan myöskään heikennä, jos osallistujilla on edes jonkinlainen käsitys siitä, millaista prosessia käytetään ja miten se noin niinkuin suunnilleen toimii.
Tilaa:
Blogitekstit (Atom)