Olen töissä pienenpienessä firmassa missä noita "hienouksia" ei oikein tunneta. Sanokaas siis, mitä nuo scrum ja agile käytännössä meinaavat ohjelmistosuunnittelijalle, paitsi kokouksissa kahvin juontia?
Scrum/Agile käytännössä?
isot pojat tietää?
182299
0Äänestä
Muut lukivat myös
Odottaa vastausta
Näihin keskusteluihin ei ole vielä vastattu. Ole ensimmäinen.
Vastaukset 18
Vanhimmat
eipä tuo sen kummempaa ole kuin että projektipäällikkö on nyt hienosti ylipalkattu, tekniikasta mitään tietämätön "scrum master". näin täällä.
Päin vastoin, eihän scrum masterille tarvitse maksaa yhtään extraa koodariin nähden, kun paperilla rooliin ei liity juuri mitään vastuuta.
Scrum/agile tarkoittaa, ettei osata suunnitella, vaan tehdään sitä mukaa kun keksitään. Toimii hyvin jossain, mutta ei kaikessa. Halutaan implementoida nykyisin joka paikkaan, koska projektin metriikka on selvempi, asiakas saa tuotteen osasia näprättäväksi projektin aikana ja voi kesken projektin muuttaa mieltään asioista.
Mahtavia juttuja joista pikkufirmojen nilkit eivät tajua mitään. Koettakaa pärjätä out there.
Isot pojat tietää, että koko akilevouhotus on neitimäistä hippeilyä. Vesiputous on se jolla oikeasti isot projektit tehdään. Tietysti jossain kotisivuprojekteissa voi vähän irrotella ja kokeilla, mutta kun puhutaan Projekteista isolla P:llä, niin vesiputoukselle ei ole vaihoehtoja.
Kiteyttäen: Tehdään hosumalla paskaa.
Tänään hosutaan jotakin ja ensi viikolla jotakin toista.
Lopputulos on sitten jotakin sinne päin.
Varmaan monissa firmoissa käytetään, koska johtotaso kuvittelee saavansa enemmän aikaan jo sinällään liian vähistä resursseista. Ei vain ymmärretä, että menetelmillä ei pidä yrittää korvata pitkäjänteistä suunnittelutyötä.
Kuinkahan moni firma on ajanut tai ajamassa koko tuotekehitystään kiville näiden menetelmien siivittämänä?
Agile on ja tulee olemaan lähes kaikkien it-projektien prosessimalli tulevaisuudessa. Siitä on erityisesti hyötyä asiakkaalle, mutta myös meille koodaajille. Työ on rauhallisempaa, kun ylitöitä ei tarvita ja koodaajalla on enemmän valtaa siihen mitä tehdään ja missä ajassa tehdään.
Projektipäälliköt vanhassa merkityksessä tulevat kuolemaan sukupuuttoon. Heille muutos tulee olemaan vaikein, mutta se onnistuu esim. product owneriksi, mutta se vaatii tahtoa. Olin Soneralla viime vuonna ja siellä yritetään juuri nyt vaihtaa ketteryyteen, mutta sisältä päin nähtynä, siinä tulee kyllä kestämään. Osa vanhoista projektipäälliköistä yrittää kaikin keinoin vääntää ketteräämallia vanhaan tapaan toimia. Lopputulos on koomisen huono. Lopulta se ei enää kuitenkaan onnistu ja sitten on heille myöhäistä. Kannattaisi ennakoida ja ketteröityä jo nyt.
Laajemmassa merkityksessä ketteryys, avoin kommunkointi, prosessien keveys yms. saattaa muuttaa yritysmaailmaa enemmänkin. Kokemuksesta esimerkiksi Nokialla, jos halusi ostaa sisäisesti uuden palvelimen, pari porttia auki tai perustaa uuden projektiimin, niin byrokratia oli aivan käsittämätön. Siellä on lukematon määrä henkilöitä, joiden ainoa tehtävä on pitää kiinni prosesseista ja suunnitella uusia. Yritä tämmöisessä ympäristössä sitten olla ketterä. Tätä kun vertaa esimerkiksi uuden aallon firmoihin, Google, Facebook, ... niin homma toimii juuri päinvastoin. Aluksi prosesseja ei ole tai ne ovat hyvin kevyitä. Kaikilla on pääsy kaikkialle ja jokaisella on paljon valtaa ja sitä myöten vastuuta. Erikoistilanteissa voidaan joitakin asioita muuttaa hankalammaksi. Esimerkki: haluat avata pari porttia palvelimella: et suinkaan tee 'tikettiä' tai jotain muuta naurettavaa, vaan 1) jos on kiire, soitat ihmiselle joka avaa sen heti 2) ei ole kiire, laitat meilin ja se avautuu lähiaikoina.
Näillä asioilla tulee olemaan pitkällä tähtäyksellä todella iso vaikutus, kenties koko yhteiskuntaan. Aiheesta lisätietoa, http://en.wikipedia.org/wiki/Lean_software_development tai vaikkapa Avartamon -tilaisuudet.
t:Viisi vuotta ketterästi koodaillut, enkä vaihtaisi 'suunnitellaan 6kk eteenpäin ja toivotaan parasta' -malliin takaisin
Ja paskat tulee olemaan mutta kun sun housussas, hippi.
Yksi oleellisista asioista on myös jatkuva arvon lisääminen. Kaikella tekemisellä tai vähintään ennalta sovitun määräajan päästä (sprintin päätteeksi) voidaan osoittaa, mitä lisäarvoa maksavalle asiakkaalle tekemisestä on saavutettu.
Tuon kommentin lisäarvo tämän threadin kysymykseen ja keskusteluun jäi ainakin minulle täysin arvoitukseksi. Tuo kommentti edustaa juuri vesiputousajattelua, jossa tärkeintä on suoltaa jotain, vaikkei siitä olisi kenellekään mitään virkaa; lähinnä päinvastoin.
Kaikkein vaikeinta on vanhoille lusmukoodareille jotka puuhailevat laatikoissan viikkokaupalla omiaan. Jos mennään päivittäiseen 15 min palaveriin johon osallistuu kaikki koodarit. Palaverissa käydään seuraavat kysymykset läpi per koodari.
1) Mitä sait aikaan eilen?
2) Mitä saat valmiiksi tänään?
3) Onko mitään mikä estäisi sen toteutumista?
Teknisiä yksityiskohtia ei käydä hieromaan vaan asianosaiset selvittävät palaverin jälkeen.
Palaveri pidetään seisaaltaan projektihuoneessa jossa kaikki koodarit koodaavat samassa tilassa seinällä on tehtävä taulut jossa jokainen koodari on saanut valita minkä lupautuu tekemään jne.
Itse olen enemmän KanBanin kannalla kuin Scrumin yksinkertaisena ja helposti opittavana ohjelmointiprosessin hallintamenetelmänä.
http://blog.crisp.se/henrikkniberg/2009/04/03/1238795520000.html
Unohdit kaikista tärkeimmän yksityiskohdan: noissa kokouksissa tulee ehdottomasti seista asennossa.
Ideaalitilanne ehkä jossakin rinnakkaistodellisuudessa.
Käytännön elämässä asiat menevät aivan toisin:
- Päivittäiset palaverit toistavat itseään, lisäarvoa niistä ei ole kenellekkään.
Päivästä toiseen ihmiset toistavat samoja asioita tekemisistään ja mielellään hieman suurentelevat aikaansannoksiaan.
- Palavereissa samat ihmiset toitottavat ongelmiaan, joihin sitten pähkäillään yksityiskohtaisia ratkaisuja. 90% paikalla olijoista toivovat vain pääsevänsä jo töihin turhasta ja pitkästyttävästä palaverista.
- Lukuisista palavereista on tullut itseisarvo, yksinkertaistakaan asiaa ei osata itsenäisesti ratkaista. Ongelmaa pyörittää 10 ihmistä 2-3 päivää.
"Palaveri pidetään seisaaltaan projektihuoneessa jossa kaikki koodarit koodaavat samassa tilassa seinällä on tehtävä taulut jossa jokainen koodari on saanut valita minkä lupautuu tekemään jne."
- Tilassa, jossa työrauhasta tai mahdollisuudesta keskittyä kunnolla ei ole tietoakaan.
- Mikäli töitä saa itse valita mielensä mukaan, parhaat / helpoimmat työt menevät aina samoille ihmisille.
Voin kertoa vain nyt omasta ASP.NET-projektista. Reilut kolme vuotta on nyt väännetty uutta versiota noin 10 hengen voimin. Kun tulin projektiin 3 vuotta siten vaivihkaa esitin Scrum konseptia. No responce. Ensimmäinen vuosi mentiin prosessi(iso toiminnallinenkokonaisuus) per kehittäjä. Saatiin pilotti Spike aikaiseksi.
Seuraava vuosi: versio 2 asiakkaan yhteishenkilöiden kanssa ohjelman kaikki prosessit taaperisivat eteenpäin Inegraatio oli koodarien käsissä. Asiakkaan mielestä siirrytään tuotantoon. Projetipäällikkö siirtyi uusiin tehtäviin.
Projekti organisoitiin uusiksi. Kerrottiin asiakkaalle missä todellisuudessa mennään. Asiakas pakotettiin määritelmään, mitkä asiat pitää toimia kuukauden kuluttua kun lähdetään julkaisuun.
Nyt on päästy pikkuhiljaa selkeisiin syklelihin, joissa asiakkaan tulee ottaa oikeasti kantaa mitä tehdään.
Jatkossa sovittiin, että kuukausittain tulee uusi versio jossa on asiakkaan tärkeimmäksi määrittelemiä asioita. Ohjelmiston eri prosessien (eri koodareiden tekemiseen) samankaltaisuuksiin panostettiin ja nämä asiat nostettiin prioriteetille 1
Mitä tästä on opittavaa:
1) Koodari ei ole ajatustenlukija.
2) Jokainen koodari tekee niin kuin aiemmin on tehnyt ellei toisin vaadita.
3) Asiakas on yleensä OTO joka ei pysty abstractiin ajattteluun.
4) Asiakas odottaa yleensä ratkaisua, mutta ei osaa sanoa millainen se pitää olla. Usein se voi olla vain yhden henkilön näkemys.
Suomalaisissa ohjelmistoyrityksissä voidaan työntuottavuus tuplata kevyesti, kun pistetään koodarit oikeasti tekemään töitä. Enää perinteinen lääkäriasenne "kello on yks' hyvästi HYKS" ei käy.
Ketteryys tarkoittaa sitä että laitetaan koodarit hyppimään ketterämmin renkaiden läpi ja tekemään enemmän palkatonta ylityötä.
Väärin koodarit saavat itse päättää mitä tekevät ja mihin sitoutuvat. Työ tehdään ammattimaisemmin, niin että kokoajan syntyy valmista ja puututaan heti ongelmakohtiin. Projekti onnistuu tai kuolee, jos product backlogia ei osata rakentaa. eli
1) asiakas ei tiedä mitä haluaa
2) ei osaa priorisoida mitä tehdään
3) ei osata pilkkoa abstrakteja kokonaisuuksia konkreettisiksi tehtäviksi
Scrum on miniatyyri-Neuvostoliitto.
En tunne ketään tässä firmassa kuka pitäisi scrumista. Ainoa kuka tätä on minulle hehkuttanut on scrum kurssien vetäjät....