Scrumjatkuvan palvelun DWprojektissa-case OP-Pohjola Niina Mäkiranta & OP-scrum-tiimi Aureolis Oy
Agenda Scrum lyhyesti Jatkuvan palvelun DW-projekti- Case OP-Pohjola Lähtötilanne ennen Scrumia Scrumin aloitus Scrum projektissa Kehitystä tapahtuu Kokemuksia reilun vuoden jälkeen Onko välineellä vaikutusta scrumin käyttöönottoon? Mikä toimii, mikä on haasteellista? Kysymyksiä & kommentteja
Scrum-prosessi Sprintin suunnittelupalaveri Toiminnallisuuslista (PBL) > Sprintin työlista (SBL) Sprintin palautepalaveri (Retrospective) Sprintin työlista (SBL) Päivittäinen tilannevartti (Daily Scrum) Sprintin katselmointipalaveri (Review) Julkaisu/tuotantoonsiirto
Scrum-roolit Product Owner Vastuussa Product Backlogintekemisestä ja töiden priorisoinnista Scrum Master Tiimin valmentaja ja fasilitoija( mahdollistaja ) Kehitystiimi Koodaajat, määrittelijät, testaajat Kaikki voivat tehdä kaikkea, mutta yleensä toki tehdään enemmän omaa osaamista liippaavaa
Scruminkäyttöönotto Prosessi on kevyt ja helppo ottaa käyttöön maalaisjärkinen prosessi Prosessin ja menetelmän sisäistäminen vie oman aikansa Esim. tulkintaeroavaisuudet mitä valmis tarkoittaa Kahden päivän koulutuksella sertifioituu Scrum Masteriksi, jonka jälkeen menetelmän ja prosessin omaksuminen vasta alkaa Otettava huomioon projektiriippuvuudet, kaikissa ei käytetä Scrumia
Jatkuvan palvelun DW-projekti OP-Pohjola Jatkuva ylläpito- ja pienkehitysprojekti Päivätason asiakas ja sopimus tietovarasto ja sen datamart Jatkunut useita vuosia Toteutustekniikkana SAS Projektitiimi: Toteuttajia 5 + projektipäällikkö Liiketoiminnasta 2 ICT sovelluspäällikkö
Lähtötilanne ennen Scrumia Menetelmänä perinteisempi vesiputousmalli Kahta kiinteästi toisiinsa kytkeytyvää sovellusta (DW ja sen Datamart) ylläpidettiin ja kehitettiin omina kokonaisuuksina pääosin samojen tekijöiden toimesta Tuotantoonsiirrotkerran kuukaudessa tai tarvittaessa, testiinsiirrot tarvittaessa
Lähtötilanne ennen Scrumia Työlista päivittyi sharepointissa, vaikea hahmottaa työn kokonaismäärää Kehittäjillä ja projektipäälliköillä erilliset viikkopalaverit Kehittäjien työtilassa paljon sermejä Kehittäjät istuvat samassa tilassa Sovelluspäällikkö ja liiketoiminta erillään
Scruminaloitus
Scruminaloitus asiakkaan näkökulma Koettiin että väärinymmärtämisen riski oli suuri, hallintoa runsaasti ja aito vuorovaikutus tekijöiden ja sovellusvastaavien välillä puuttui Haluttiin että kahden sovelluksen tekeminen yhdistetään kiinteämmin toisiinsa ja tekeminen saadaan tehokkaammaksi
Scruminaloitus asiakkaan näkökulma OP-Pohjolaryhmässä oli ensimmäiset ketterät kehitysprojektit tehty ja niistä kuultu positiivisia asioita Käyttöönottoa edisti myös Aureoliksen kyvykkyys tarjota valmis Scrum Master käyttöömme, joka tunsi jo ympäristömme
Scruminaloitus asiakkaan näkökulma Tiedostimme heti alkuun kunnossapidon tärkeyden ja varasimme siihen jokaisessa sprintissä keskimääräisen työmäärän Käyttöönotto vaati koulutukset soveltuvin osin. Meillä koulutukset olivat aika järeät (Scrum Master ja Product Owner)
Scruminaloitus asiakkaan näkökulma Lisäksi käyttöönotto vaatii oikeasti aikaa käydä päivittäin dailyissaja muissa prosessiin liittyvissä palavereissa
Scrumprojektissa Tuotantoonsiirto* Sprint 1 Sprint 2 Sprint 3 Suunnittelu 2 viikkoa 2 viikkoa 2 viikkoa Suunnittelu Testiinsiirto Katselmointi Testiinsiirto Suunnittelu Testiinsiirto Katselmointi Palaute Testiinsiirto Tuotantoonsiirto* Testiinsiirto aika Suunn. Katselmointi Testiinsiirto
Scrumprojektissa Toivelista: Product backlog Pakollinen ------------------------------- ------------------------------- ------------------------------- ------------------------------- Päivittäiset Daily Scrumit Pakollinen Ratkaisun määrittely Toivottava ------------------------------- ------------------------------- ------------------------------- ------------------------------- Sprint Backlog 24 tuntia Sprintit Mahdollinen 2 viikkoa Testiin/tuotantoon Vaatimukset
Lähtötilanne
Kehitystä tapahtuu SBL siirtyy Sharepointissaolevaan exceliin, joka heijastetaan dailyssa seinälle Suunnittelupalaverin valmistelua tehostetaan Demot jaetaan koodikatselmointeihin ja tuotantoonmenevien ominaisuuksien läpikäynteihin Product ownerit eivät ota enää puheenvuoroa Daily Scrumissa Määrittelyt siirtyvät keskitettyyn paikkaan Dokumentoidaan yhteisiä toimintatapoja > yhteiset toimintatavat täsmentyvät > mutu vähenee Avotila avartuu
Kokemuksia reilun vuoden jälkeen Työlista eli SBL toimii hyvin sekä ohjaa ja rajaa tekemistä Kehitysajatuksia saa hyvin esille ja niitä myös toteutetaan Kommunikaatio toimii hyvin päivittäin > siirrytty enemmän face to face kommunikaatioon Osaaminen leviää ja tieto kulkee tiimissä paremmin Tiimihenki on hyvä On johtanut suurempaan järjestelmällisyyteen Kaaoksen hallinta Hyvin suunniteltu nopeammin toteutettu
Kokemuksia reilun vuoden jälkeen Tiimiin on helppo tulla uutena Liiketoiminnan ja ICT:n tiivis mukana olo tärkeää Scrumja ketterä toimii ylläpito-& pienkehitysprojektissa! Scrummasterinrooli keventyy => tiimi kehittyy itseohjautuvampaan suuntaan Scrum masterilla osittain kaksoisrooli => SM&PP
Onko välineellä vaikutusta käyttöönottoon? Scrumon välineriippumaton eikä myöskään määrittele, miten ja missä esim. työlistoja pidetään yllä Soveltuu yhtä hyvin niin SAS kuin muihinkin projekteihin
Mikä toimii, mikä on haasteellista? Hyvä kommunikaatio ja tiimihenki parasta antia Osaamista siirtyy väkisinkin tiimin sisällä Perinteistä projektipäällikköroolia ei oikeasti tarvita Menetelmää pystyy soveltamaan Läpinäkyvyys Onko työtä liikaa/liian vähän Keskittyykö osaaminen/tekeminen Pullonkaulat tulevat esille
Mikä toimii, mikä on haasteellista? Lähentää toimittajaa ja asiakasta (esim. dailyt) Koko tiimi ei pysty olla samassa tilassa Kaikki eivät ole 100% tälle projektille varattuja Ylläpidossa paljon adhoc-työtä, jonka määrän arviointi hankalaa Retrojen hyötysuhde ei aina selkeä
Mikä toimii, mikä on haasteellista? Määrittelyissä, testauksessa ja dokumentoinnissa riittää edelleen haastetta Vaatii kaikilta sitoutumista sovittuihin toimintatapoihin (määrittelyt oikeassa paikassa jne.) -> Menetelmä ruokkii prosessin kehittämistä Tehtävien jako helpottuu SBL:nja palavereiden kautta, tiimille tulee käsitys siitä, miten työt kannattaa jakaa => autonomista toimintaa
Mikä toimii, mikä on haasteellista? "Ketterät menetelmät eivät ratkaise yhtään ongelmaa, ne vain tekevät ongelmat niin kivuliaan näkyviksi, että ongelmia ei voi enää vältellä" -- Ken Schwaber, eräs Scrummenetelmän kehittäjistä
Mikä toimii, mikä on haasteellista? Menetelmä on hyvä apu, mutta edelleenkin tiimin ja projektin onnistuminen on kiinni siitä, miten ihmiset toimivat yksilöinä ja miten hyvää yhteistyötä ihmiset saavat keskenään aikaiseksi
Kysymyksiä & kommentteja
Kiitos!
Seuraavaksi Kahvitarjoilu Jatketaan workshopilla n. klo 15
www.aureolis.com Aureolis Oy Hevosenkenkä 3 - FI-02600 Espoo office +358 20 741 2790 contact@aureolis.com