Pitkä viesti, mutta pliis jelppikää vähän osaavat?
Eli, koodarifirma käyttää Scrum -menetelmää meidän erittäin haastavassa projektissamme. Miten siihen asiakkaana voisi osallistua. Nyt minut pyydetään käymään lyhyissä tsekeissä pari kertaa viikossa... mutta jos minulla on jotain korjauspyyntöjä (joita AINA on), miten ne pitäisi prosessin mukaan käsitellä. Minuun suhtaudutaan erittäin nihkeästi ja ei oikein osata sanoa juuta ei jaata.
Miten scrumissa toimii esim. tämä - jos haluan, että leiskassa muutetaan 5 asiaa... meneekö se seuraavaan sprinttiin ja odotan sitten taas pari viikkoa. Entä jos se onkin sitten laitettu taas väärin... taas kaksi viikkoa??? Puhumattakaan isommista muutoksista määrittelyihin. Enkä edes tiedä, missä muodossa ja miten ja mihin minun pitää muutostoiveet toimittaa...
Pahoittelen sekavaa viestiä ja asia on minulle vieras, joten tyhmiä kysymyksiä varmaan... Mutta - miten scrumissa käsitellään ylipäätään asiakkaan osallistumista ja ns. ad hocina tapahtuvaa määrittelyä. Luulin, että näissä agile-menetelmissä asiakas olisi voinut jatkuvasti kommentoida edistymistä, tai minulta kysyttäisiin ihan päivittäin, että 'onko ok, jos teemme tämän palikan näin' ja ohjelmointi olisi ollut läpinäkyvämpää, mutta se ei taida ollakaan näin?
Käytännön esimerkki vielä - softafirma tekee esim. meille lomaketta sivuille joiden on tarkoitus avautua muutaman viikon päästä. No, lomake on alustavasti määritelty ja ne pykäävät sitä sen pari viikkoa. Sitten tulee katselmus ja siellä on vaikka mitä omia ratkaisuja (jotka olisin voinut korjata jos niitä olisi kysytty tai olisin nähnyt, mitä tehdään), esim. lomakkeeseen pitää pystyä lisäämään kolme kuvaa, no se menee seuraavaan sprinttiin... sitten katsotaan loppukäyttäjien kanssa ja sieltä puuttuu joku kriittinen kenttä, joka hoksataan vasta nyt, ja taas kaksi viikkoa yhteen htin lomakkeeseen.... Luulin, että scrumi olisi nimenomaan ollut vastaus tällaiseen kehitykseen asiakkaan kanssa - puhumattakaan mitä sitten, kun käytettävyyttä aletaan testaamaan iteratiivisesti...
Juu, sekavaa tekstiä, mutta osaisiko joku selventää minulle tätä prosessia. Alan olla ihan epätoivoinen tämän kanssa, kun mitään ei kesken sprintin oteta enää huomioon :(
Eli, koodarifirma käyttää Scrum -menetelmää meidän erittäin haastavassa projektissamme. Miten siihen asiakkaana voisi osallistua. Nyt minut pyydetään käymään lyhyissä tsekeissä pari kertaa viikossa... mutta jos minulla on jotain korjauspyyntöjä (joita AINA on), miten ne pitäisi prosessin mukaan käsitellä. Minuun suhtaudutaan erittäin nihkeästi ja ei oikein osata sanoa juuta ei jaata.
Miten scrumissa toimii esim. tämä - jos haluan, että leiskassa muutetaan 5 asiaa... meneekö se seuraavaan sprinttiin ja odotan sitten taas pari viikkoa. Entä jos se onkin sitten laitettu taas väärin... taas kaksi viikkoa??? Puhumattakaan isommista muutoksista määrittelyihin. Enkä edes tiedä, missä muodossa ja miten ja mihin minun pitää muutostoiveet toimittaa...
Pahoittelen sekavaa viestiä ja asia on minulle vieras, joten tyhmiä kysymyksiä varmaan... Mutta - miten scrumissa käsitellään ylipäätään asiakkaan osallistumista ja ns. ad hocina tapahtuvaa määrittelyä. Luulin, että näissä agile-menetelmissä asiakas olisi voinut jatkuvasti kommentoida edistymistä, tai minulta kysyttäisiin ihan päivittäin, että 'onko ok, jos teemme tämän palikan näin' ja ohjelmointi olisi ollut läpinäkyvämpää, mutta se ei taida ollakaan näin?
Käytännön esimerkki vielä - softafirma tekee esim. meille lomaketta sivuille joiden on tarkoitus avautua muutaman viikon päästä. No, lomake on alustavasti määritelty ja ne pykäävät sitä sen pari viikkoa. Sitten tulee katselmus ja siellä on vaikka mitä omia ratkaisuja (jotka olisin voinut korjata jos niitä olisi kysytty tai olisin nähnyt, mitä tehdään), esim. lomakkeeseen pitää pystyä lisäämään kolme kuvaa, no se menee seuraavaan sprinttiin... sitten katsotaan loppukäyttäjien kanssa ja sieltä puuttuu joku kriittinen kenttä, joka hoksataan vasta nyt, ja taas kaksi viikkoa yhteen htin lomakkeeseen.... Luulin, että scrumi olisi nimenomaan ollut vastaus tällaiseen kehitykseen asiakkaan kanssa - puhumattakaan mitä sitten, kun käytettävyyttä aletaan testaamaan iteratiivisesti...
Juu, sekavaa tekstiä, mutta osaisiko joku selventää minulle tätä prosessia. Alan olla ihan epätoivoinen tämän kanssa, kun mitään ei kesken sprintin oteta enää huomioon :(
Vastaukset 7
Vanhimmat
Itsellä ei scrumista paljoa kokemusta ole, mutta idea on juurikin siinä tehtävien priorisoinnissa niiden viikottaisten tapaamisten aikana. Eli sprintissä toteutetaan jotkin tietyt asiat. Piste. Ennen seuraavaa sprinttiä tarkistetaan tilanne ja seuraavan sprintti suunnitellaan sen mukaan.
Toki scrumia voi soveltaa, eli ei ole kiveen kirjoitettuja sääntöjä mitkä on pakko toteuttaa, mutta nämä pelisäännöt pitää toki erikseen sopia.
Jos softafirma tekee omia ratkaisujaan mutu-tuntumalta, tekevät he väärin. Mikäli he koodaavat hyväksytysti katselmoitujen määrittelyjen mukaisesti, on vika määrittelyssa ja siinä tahossa joka on katselmoinnin hyväksynyt.
SCRUM ei oli ohjelmitotuotantomenetelmä vaan se on USKONTO ja kaikki jotka eivät toteuta Kenin (SCRUMin Luojan) sanaa juuri pilkulleen ovat KERETTILÄISIÄ.
Noin, se angstista ja nyt asiaan.
SCRUM on ketterä management-kehys, jonka tarkoituksena on luoda ohjaus ja ajankäyttömalli ohjelmistoprojektille. SCRUMin perusajatus on luoda kehittäjille työrauha sprintin ajaksi, jolloin uusia vaatimuksia ei oteta sprintin backlogiin. Tämä on ihan hyvä ajatus, koska sillä estetään mm. feature creeping ja projekti tempoilu joka suuntaan. SCRUM ei kuitenkaan kerro kuinka vaatimukset ilmestyvät product backlogiin eli entiseen vaamusmäärittelyyn eikä se kerro yhtään mitään siitä, mitä tapahtuu silloin kun kehittäjä ottaa sprint backlogista asian työn alle (sillä on kaksi tilaa NOT-DONE ja 100% DONE-DONE-DONE eli tehty-testattu-dokumentoitu). SCRUMissa on hemmo nimeltä Product Owner (PO). Hänen tehtävänä on tuottaa vaatimuksia. Tässä kohtaa oikeastaan teillä menee homma puihin.
Miksi? Koska, jotta joku asia voidaan laittaa Product Backlogiin, se pitäisi olla riittävän stabiili ja hyvin ymmärretty, jotta sitä kannattaa tehdä. Käyttöliittymät ovat usein haastavimpia juttuja, koska usein ei tiedetä mitä halutaan näytöllä näytää ja erittäin usein näyttöjä ja vaatimuksia ei suunnittele niiden alojen ammattilainen vaan usein peruskoodari. Eli scrumissa kaikki pitää olla valmiina backlogissa, jotta sprintit voidaan viedä läpi suunnitellusti.
Periaatteessa SCRUMissa sprintin aikana ilmenneet muutostoiveet laitetaan Product Backlogiin, joka voi olla vaikka Excel taulukko. SCRUM ei määrittele Backlog itemin sisältöä/muotoa formaalisti, mutta se pitäisi olla toteuttamiskelpoinen (mitä silläkin sitten kukin tarkoittaa). PB:ssä itemit ovat aina priorisoitu tarkein ensin järjestykseen. Jokaisen Sprintin jälkeen PB:stä kaivetaan niin paljon itemeitä (PBI) kuin arvioidaan ehdittävän Sprintin aikana toteuttaa. Jos joku PBI on toteuttajille epäselvä tai sitä on vaikea jakaa tunien tai muutaman päivän työmäärään, tekijä tenttaa PO:ta niin kauan, että PBI on toteuttamiskelpoinen, jonka jälkeen PBI siirretään Sprintin Backlogiin (SB). Kun tämä päivän kestävä Sprintin valmistelu on tehty aloitetaan itse sprint. Eli uusi ominaisuus toteutetaan vasta seuraavassa sprintissä.
Mihin sinun pitää muutostoiveet toimittaa? Kysymys kuuluukin, että mistä tuotantoryhmä ne hakee. Periaatteessa toteuttavassa yrityksessä voi olla PO, jonka tehtävänä on kaivaa sinusta vaatimukset ja ottaa vastaan sinun muutospyyntöjäsi. Asiakas osallistuu aina PO:n takaa. Ja Scrum odottaa kypsiä vaatimuksia, joihin voi tulla muutoksia ajan kuluessa. SCRUM ei ota kantaa määrittelyprosessiin millään tavalla.
Ketterissä menetelmissä asiakas voi "jatkuvasti" havainnoida tuotoksen kehittymistä. "Jatkuvasti" tarkoittaa sprinttien välissä tapahtuvaa ohjausta. Scrum toisaalta ei määrittele sprintin pituutta absoluuttisesti mitenkään, vaan sen on oltava lyhyt (ohje taitaa olla viikosta muutamaan viikkoon). Esimerkiksi inkrementti, jonka aikana tuotokseen tulee uusi ominaisuus, kestää 3 kuukautta, jonka aina tehdään neljä kolmen viikon sprinttiä. Toistaalta, jos tarve niin vaatii, sprintin pituus voi olla tietyn ominaisuuden osalta vaikka vain viikko.
SCRUMissa on sellainen käsite kuin Sprint Abort, jolloin vedetään narusta ja nautitaan kesästä. Tällöin Sprintin tekeminen keskeytetään ja uusin Sprintti suunnitellaan alusta. Tämä on sellainen iso juttu, jota ei missään nimessä kannata käyttää ihan pieniin juttuihin, koska se syö suunnittelijaa rotan lailla. Jos haluat demotivoida tiimisi ja saada vähän kiertoa henkilöstöön, niin viikon välein tehty Sprint Abort on sinun juttusi.
Ei SCRUM, eikä ketteryys yleensä, kuulu samaan lauseeseen koskaan ad hocin kanssa. Ketterä tavat toimia ovat kurinalaisia mutta kevennettyjä menetelmiä. Nyt kuulostaa siltä, että sinun kannattaa kälin osalta neuvotella lyhyempi sykli kuin mitä teillä nyt on esim. viikon sykli (ma-to sprintti ja pe tarkastus ja muutosten kirjaus). Ennen ketterää jeesustelua oli olemassa sellainen käsite kuin nopea protoilu, joka käsitteenä voisi sopia teille.
Kuten ehkä olet viestistäni huomannut, niin Sprintti on todellakin pyhä. Kesken Sprintin asiakas ei saa muutella toiveitaan, koska se on todella pahasta toteuttajien ja koko projektin kannalta. Nyt vaan herää kysymys onko Sprintti oikean mittainen ja toimiiko SCRUM hyvin vaatimusten keräilyyn. Koska SCRUM ei määrittele Sprintin sisältöä, koska se on toteutusta, niin voisitte hyvinkin tehdä Sprintin, joka tarkoituksena on protoilla ja tuottaa BPI:tä. Tällöin sinun tehtävänäsi on vaikkapa joka viikko tutkia käli-tuotos ja antaa ohjausta. Elikä tuo katselmustilaisuus, jonka mainitisit, pitäisi olla Sprintin lopussa ja siitä alkaa uusi Sprintti uusilla/muutetuilla vaatimuksilla.
SCRUM ei ole hauki, joka hoetaan kalaksi. SCRUM on ketterä menetelmä, jonka tarkoituksena on tuottaa tyytyväisyyttä asiakkaalle ja toimittaa usein asiakkaalle arvokasta softaa. SCRUM on kehys, jonka tehtävä on mukautua asiakkaan tarpeisiin kehyksen antamissa raameissa. SCRUM ei ole vain menetelmä vaan se on organisaatiomuutos. Kaikki muuttuu ja monet asiat tehdään eri tavalla ja monien henkilöiden roolit muuttuvat tai poistuvat. Nyt teidän kannattaa keskustella, miten te saatte homman toimimaan niin, että se tuottaa SINULLE eniten lisäarvoa (esim. kälin osalta viikon sprintti tms.). Muista, että ketteryys ei tuo sinulle ad hoc-maista käsien heiluttelua vaan turvan lisäarvosta. Tosin noviisi menetelmän käyttäjä usein käyttää menetelmää väärin ja vanhat vesiputouksen tavat istuvat tiukassa.
Suosittelen vilkaisemaan ketteriä periaatteita (http://agilemanifesto.org/principles.html) ja Agile Manifestoa (http://agilemanifesto.org/). Sorry vähän ylipitkästä vastauksesta pitkään kysymykseen :-)
Aluksi: minulla on vain vähän kokemusta SCRUMista, eli vastuu siirtyy lukijalle:)
Kuten tuossa aikaisemmassa vastauksessa sanottiin, teillä on ongelma vaatimusten kanssa. Jäi itselle hieman epäselväksi kuka teillä on tuotteen omistaja (product owner)? Tuotteen omistajan tehtävä on vastata SCRUM-ryhmän kysymyksiin ominaisuuksista ja omistaja myös priorisoi ohjelman vaatimukset sprintin suunnittelukokouksessa. Tuolta löytyy lisätietoa suomeksi http://www.ketteratkaytannot.fi/fi-FI/Menetelmat/Scrum/
Ketterien menetelmien ongelma on se, että ne lupaa paljon, mutta ne rajaavat lähes järjestäin yhden kaikista tärkeimmän asian määritystensä ulkopuolelle: vaatimusten keräilyn. Kaikki keskittyvät siihen, kun meillä on jo valmiita vaatimuksia muodossa tai toisessa (vaatimuksina, käyttäjän tarinoina, käyttötapauksina tms.). Kehittäjän, projektiohjaajan ja testaajan toimet on pääsääntöisesti kerrottu tarkkaan, mutta käyttäjän harteille on jätetty se kaikista vaikein homma. Ja tämä tulee usein ketterän projektin asiakkaalle vähän kuin yllätyksenä. Kuten tässäkin tapauksessa on käynyt.
Ketterät menetelmät eivät sovellu hyvin sellaisinaan muuttuvien vaatimusten vaiheeseen ohjelmiston synnyssä, vaan se vaatii vähän sopeutumista. Ketterässä yhteisössä on havaittu tiettyjä tilanteita, jolloin sprintin pituutta tulisi lyhentää (http://www.scrumalliance.org/resource_download/20), ja tämä näyttäisi olevan sellainen. Viikon sprintti näyttäisi olevan minimi, koska lyhyemmässä ajassa ei välttämättä ehdi hallitusti käymään läpi sprintin vaatimia asioita ja tekemään tuottavaa työtä. Eli ehdotan seuraavaa:
1) torstaina sprintin aloitus
2) pe, ma, ti armotonta puserrusta
3) ke demo ja retro
4) to if (work != DONE_DONE_DONE) goto 1
Periaatteessa voisi olla lyhyempikin, mutta viikon päivien lukumäärä aiheuttaa helposti sen, että aloituspalaveri on perjantaina ja sitten viikonloppuna menetetään aloituspalaverissa saatu vauhti.
Vaatimuksien keräilyyn niin perinteisesti kuin ketterästi on jonkun kirjallisuutta, mutta sehän ei auta tässä tilanteessa. Ongelma on palautteen saamisessa, jonka pitäisi tulla nopeammin kuin 2 viikon päästä.
Kiitos hienoista vastauksista, etenkin viimeisestä. Tässä on paljon ongelmia - yritys oli aikatauluista noin vuoden myöhässä, palkkasi lopulta uusia työntekijöitä ja otti meiltä tietysti kysymättä scrumin käyttöön. Joten meillä ei ollut/olla sitouduttu ko malliin, eikä suoranaisia esim. tuoteomistajia meidän puoleltamme ole.
Määritykset ovat meillä myös sekavia, johtuen tuosta vuoden viivästymisestä ja monesta muusta toimittajan sotkusta ja sopimuksesta.
Yllä olevat ovat johtaneet siihen, että aikataulu on niin kriittinen, että välillä tuo kaksi viikkoa on yksinkertaisesti liikaa. Toinen on se, että vaatimuksia ennen tätä prosessia ei käyty lävitse tarpeeksi tarkasti, se otettiin käyttöön ja mentiin mutulla.... ja sitten toimittaja suuttui, kun sprinteissä kysymättä tehtiin asioita, jotka piti muuttaa kokonaan.
Lisäksi, noin yleisesti sivulanseerauksiin tämä prosessi on kovin hankala. Kun joku menee liveksi on todella raskasta ja turhauttavaa asiakkaan odottaa muutoksia 2-4 viikkoa.
Onko joku käyttänyt scrumia nopeatempoisissa webbiprojekteissa ja miten olette hanskanneet sen, kun kuluttajasivu on livenä ja sinne halutaan muutoksia, jotka eivät voi odottaa paria viikkoa (enkä tarkoita suoranaisia bugeja)? Toimittajamme kieltäytyy tekemästä mitään ilman, että testaa - mielestäni ihan liiallisesti - jokaista pientä pop-upia ja vie muutokset parin viikon välein tuotantoon.
Teidän ongelma on se, että SCRUM vaatii valmiita ja toteutuskelpoisia vaatimuksia. Scrum ei sovellu sinänsään vaatimusten kalasteluun. Tuoteomistajan (Product Owner, PO; siis periaatteessa sinun) vastuisiin kuuluu kerätä ja analysoida vaatimuksia siten, että ne toteutuskelpoisia. Tämä osuus ei ole osa Scrumia, vaan se on ulkoistettu palomuurin taakse eli PO:n taakse.
Mitä tässä voidaan sitten tehdä? Vaatimukset pitää saada kuntoon ja selkeästi sinun pitää siirtyä protoiluun. Eli sinun pitää lainata tuotekehitysresurssia sprinttien ulkopuolelle siten, että sprinttiä tekevän ryhmän työrytmi ei mene rikki. Tämän sprinttien ulkopuolisen resurssin kanssa sitten teette protoja ja kokeilette asioita, ja kun olette saanut vaatimuksen riittävän stabiiliksi, niin iskette sen tuotteet backlogiin. Se, että meneekö proton koodi tuotantoon onkin sitten eri ongelma. Jos proton tekemisessä on oiottu paljon, niin tekninen/laadullinen velka saattaa kasvaa niin suureksi, että on turvallisempaa nakata koodi bittien kaatopaikalle ja odottaa uutta toteutusta. Vaikka kuulostaa heittää ns. rahaa kaivoon, niin loppuviivalle ei kustannuksia otetusta laatuvelasta.
Toimittajasi tekee oikein scrumin mukaan, eikä keskeytä sprinttiä tai muuta skooppia kesken sprintin. Toisaalta sprintin skoopin muuttaminen kuuluu scrumin hätätilatoimiin ja silloinkin vain jos tiimi niin sallii. Toisaalta voidaan kysyä toteuttaako toimittaja Scrumia ketterien periaatteiden mukaisesti? Mielestäni ei.
Muuten sprintin pituus 2-4 viikkoa ei ole kuin suositus. Tietääkseni minimissään voidaan pitää 2 sprinttiä viikossa. Ei tehokas välttämättä, mutta saattaa sopia johonkin tilanteeseen. Tärkeintä on toimivan softan toimittaminen asiakkaalle, joka saa softasta lisäarvoa.