Scrumjatkuvan palvelun DWprojektissa-case. Niina Mäkiranta & OP-scrum-tiimi Aureolis Oy

Transkriptio

1 Scrumjatkuvan palvelun DWprojektissa-case OP-Pohjola Niina Mäkiranta & OP-scrum-tiimi Aureolis Oy

2 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

3 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

4 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

5 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

6 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ö

7 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

8 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

9

10 Scruminaloitus

11 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

12 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

13 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)

14 Scruminaloitus asiakkaan näkökulma Lisäksi käyttöönotto vaatii oikeasti aikaa käydä päivittäin dailyissaja muissa prosessiin liittyvissä palavereissa

15 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

16 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

17 Lähtötilanne

18

19 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

20

21

22 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

23 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

24 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

25 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

26 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ä

27 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

28 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ä

29 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

30 Kysymyksiä & kommentteja

31 Kiitos!

32 Seuraavaksi Kahvitarjoilu Jatketaan workshopilla n. klo 15

33 Aureolis Oy Hevosenkenkä 3 - FI Espoo office contact@aureolis.com