42 kilometrin pika-aidat
Sydän hakkaa 201 lyöntiä minuutissa. Paita on läpimärkä ja hiki nostaa kyynelet silmille. Päässä jyskyttää, koska korvissa kohisee armoton fyysinen suoritus. Keuhkoissa polttelee ja oksettaakin. Sprintti oli kova. Onneksi myös kunto kesti maksimisuoritusta aiotun matkan.
Ohjelmistokehityksemme on agilea. Sovellamme Scrumia
Näillä sanoilla alkaa suurin osa keskusteluista, joissa käsitellään kehitysprosessia. Kun asiaan syvennytään, niin kehitys paljastuukin kolmivaiheiseksi speksaus-devaus-testaus-rumbaksi. Oikeasti se on siis sarja vesiputouksia.
Yksi agilen tärkeimmistä ajatuksista on, että kehitystä tehdään sopivan kokoisina siivuina. Niin, että kunto riittää sprintin toisensa jälkeen. Siksi minusta on kummallista kuulla kerta toisensa jälkeen kuinka kehityssyklin pituus on 4-8 viikkoinen.
8 viikon sprintti on kuin juoksisi 42km pika-aidat.
Suosittelemme myös:
Mielenterveys on työtäni
Hämmästynyt katse seuraa lähes poikkeuksetta kun vastaan siihen yhteen kysymykseen. Mitäs sinä teet Antti? Tai mitäs tuo teidän yritys...
Oivalluksellakin on hintansa
Jos kysymys ei ole uskomattomasta munkista, mäihästä tai tuurista, niin onnistumisilla on aina hintansa. Hinta on mahdollista maksaa etukäteen ja...
Mun mielestä tuo sprintin pituus riippuu monesta tekijästä ja se mikä sopii toiselle ei vältämättä sovi toiselle. Tärkeintä kai on koko sprintin aikana tuottaa toimivaa koodia, testatusti.
Mun mielestä 8 viikon sprinttikin voidaan tehdä ”hätäilemättä” tai ”juoksematta” niin että kunto riittää vielä seuraavaankin sprinttiin. En siten ymmärrä analogiaa että mitä pidempi sprintti sitä vaativammaksi se tulisi (= kunnon loppuminen). Tietenkään tämä ei tarkoita että 20 viikon sprintti olisi välttämättä hyvä tai toimiva idea.
On kylläkin totta että kehitys pitäisi tehdä sopivan kokoisina siivuina, mutta mun mielestä se on jokaisen tiimin löydettävä itse.
Komppaan edellistä. Kyllä prosessi pitää olla tapauskohtainen ja syklin pituus sitä myöten. (NSNllä mm. 6 vuotta yritetty Scrumia ja kuulemma vieläkään ei oikeen onnistu.)
Pitää ymmärtää että nää Scrummit ja RUPit jne… ovat kuin uskontoja. Keksijät luennoivat, mentoroivat, kirjailevat lisää ja samalla keräävät rahaa hölmöiltä pois.
Reaalielämä on niin kovin yksilöllistä ja ympäristöt vaihtelee. Soveltakaa oppimaanne ja muotoilkaa prosessit tukemaan esim. liiketoimintaa…
Siinä edelliset kommentoijat on kyllä oikeessa, että yksi kehitystapa ei millään sovi kaikille.
Mun mielestä Antti ei tässä ota kantaa siihen, että pitääkö kehityssyklin olla 1 viikkoa vai 3 kuukautta. Vaan siihen, että jos puhutaan nimenomaan ketteristä kehitysmenetelmistä, niin ei siihen oikein sovi pitkät syklit. Vähintään pitäisi olla ”välireleaseja”, jolloin koodia testataan ja korjataan myös varsinaisten tuotantojulkaisuiden välissäkin.
Naulan kantaan Jaakko.
Mielestäni kehityssyklien käydessä pitkiksi, homma kääntyy hirveän helposti klassiseen vesiputoukseen. Niin käy ihan huomaamatta, vahingossa.
Sprinttaaminen tarkoittaa toki eri ihmisille eriä asiaa. Minulle se on nopeita pikamatkoja… Tietysti esim NSN:llä 8 viikkoa voi joskus tuntua pikamatkalta 😉
Itse yhdyn myös tähän linjaan, että yhtä oikeaa tyyliä ei ole. Kahdeksan viikkoa pitkä sykli saadaan sekin ketteräksi siten, että tehdään releaseja ja bildejä päivittäin ja testitiimi testaa niitä ihan koko ajan. Usein näin myös menetellään.
Hyvää on myös selkeästi määrittää, että scrum on yksi ketterämenetelmä muiden joukossa. Itse olen havainnoinut, että liekköhän alkanut scrum jo menemään tuonne old schoolin puolelle.
Yleensä kaikissa projekteissa, pohjautuvat ne sitten mihin vaan malliin, on aina kaksi asiaa, jotka yleensä aiheuttavat ongelmia asiakkaan silmissä:
– toimittajan projektin aikana tekemän testauksen näkyvyys asiakkaalle (onko sitä olemassa, mitä on testattu jne)
– toimittajan tekemä testaus kehityssyksin aikana (kehitetäänkö uutta syklin loppuun asti, onko testaukselle ja virheiden korjaukselle aikaa)
– asiakkaan löytämien virheiden korjaus projektin aikana (koska testattuja korjauspaketteja saa toimittajalta, vai tulevatko ne sovitun toimitusaikataulun puitteissa, jolloin asiakas ei voi testata kaikkea siinä aikataulussa. kun on luultu)
T: Konkari