Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Scrum-menetelmän käyttö Pirkanmaalaisissa ohjelmistoyrityksissä

1,672 views

Published on

Yhteenveto diplomityöstäni "Scrum-menetelmän käyttö Pirkanmaalaisissa ohjelmistoyrityksissä"

In english:
http://www.slideshare.net/jvuorinen/the-use-of-the-scrum-method-in-it-companies-in-pirkanmaa-area

  • Be the first to comment

  • Be the first to like this

Scrum-menetelmän käyttö Pirkanmaalaisissa ohjelmistoyrityksissä

  1. 1. Scrum-menetelmän käyttö Pirkanmaalaisissa ohjelmistoyrityksissä Diplomityö, Jyri Vuorinen
  2. 2. Haastattelututkimuksen valikoituja kommentteja "Usein projektimallimme muistuttaa 1800-lukulaista höyryjunamallia, jossa on yhdet suorat raiteet käytössä, joita pitkin mennään." Sovelluskehittäjän kommentti yrityksen projektimallista. "Scrum lähti alun perin yhden miehen ristiretkestä, ja muutos on kestänyt kauan." Kehityspäällikkö Scrumiin siirtymisestä.
  3. 3. Haastattelututkimuksen valikoituja kommentteja "Ei kiinnosta kunhan tulee valmista. Älkää kertoko softakehityksestä vaan valmiista tuotteesta." Asiakkaan kommentti kun esiteltiin Scrum-menetelmää. "Älkää häiritkö meitä ennen kuin on valmista." Asiakkaan kommentti palaveripyyntöihin.
  4. 4. Haastattelututkimuksen valikoituja kommentteja "Meillä on Scrumiin hiljainen johdon hyväksyntä, johto ei haittaa meitä – ainakaan merkittävästi." ScrumMaster toteaa johdon suhtautumisesta Scrumiin. "Tietokonenörtit eivät aina puhu edes vieruskaverinsa kanssa.” Sovelluskehittäjä kertoo kommunikaatiovaikeuksista palavereissa
  5. 5. Diplomityönä haastattelututkimus • 11 haastateltua yritystä • Pieniä ja keskisuuria yrityksiä Pirkanmaalta • Haastateltiin 18 henkilöä: projekti-, kehitys-, ja laatupäällikköjä sekä sovelluskehittäjiä. • 46 haastattelukysymystä
  6. 6. Tutkimuksen tavoitteet • Selvittää millaisia ketteriä käytäntöjä yritykset käyttävät. • Selvittää miten paljon Scrumin käytäntöjä oli omaksuttu ja kuinka tarkasti sen menettelytapoja noudatetaan. • Etsiä ja tunnistaa Scrum-menetelmällä saavutettuja hyötyjä. • Etsiä ja tunnistaa ongelmia ja haasteita ketterissä menetelmissä sekä löytää niihin vastauksia. • Etsiä, tunnistaa ja levittää hyviä ketteriä käytäntöjä.
  7. 7. Haastattelukysymysten aihealueet • Yrityksen taustatiedot • Scrum-menetelmän noudattaminen, eli Nokia-testi • Yksittäiset Scrumin käytännöt ja niiden noudattaminen • Saavutetut hyödyt sekä ongelmat ja haasteet
  8. 8. Tietoa osallistuneista yrityksistä • 5 yritystä erikoistunut sulautettuihin ohjelmistoihin • 2 yritystä mobiilisovelluksiin • Muut tekivät kaikkea mahdollista • Yritysten IT-henkilöstön määrä oli 15-175. • 10 yritystä käytti Scrumia, yhdessä itse kehittetty ketterä menetelmä. • Suurimmalla osalla Scrum-kokemusta oli 1,5-3 vuotta.
  9. 9. Scrum-menetelmän hyötyjä • Tiimi kokee työskentelyn mielekkäämmäksi ja on motivoitunut. • Sprintit tarjoavat mahdollisuuden nähdä kehitystä säännöllisesti. • Scrum tarjoaa selkeän ja riittävän yksinkertaisen toimintamallin.
  10. 10. Scrum-menetelmän hyötyjä • Scrum tehostaa avointa kommuni- kaatiota tiimin sisällä sekä asiakkaan kanssa. • Scrum lisää avoimuutta, koska tiedetään miten projekti sujuu ja riskit ovat näkyvissä. • Työlistojen priorisointien avulla tekeminen kohdistuu oikeisiin asioihin.
  11. 11. Scrum-menetelmän ongelmia ja haasteita • Asiakkaat eivät ymmärrä Scrum- menetelmää tai osaa sitoutua sen toimintatapoihin. • Scrumia on haastava sovittaa yrityksen jähmeään organisaatiokulttuuriin. • Johto ei ole sitoutunut Scrumiin tai pitää sitä epämääräisenä.
  12. 12. Scrum-menetelmän ongelmia ja haasteita • Scrumin käyttöönotto on haastavaa, ja siihen täytyy varata paljon aikaa. • Tuoteomistajan rooli on haastava. Hän ei ehdi panostamaan projektiin tai sekaantuu liikaa tiimin tekemiseen. • Sprinttien rauhoittaminen on hankalaa, koska ylimääräiset ylläpitotehtävät ja virhekorjaukset häiritsevät.
  13. 13. Nokia-testi • Testissä 9 kysymystä Scrumin eri osa-alueilta. • Jokainen kysymys pisteytetään asteikolla 0-10. • Vastausten keskiarvona saadaan arvo kuvaamaan yrityksen ketteryyttä Scrumissa.
  14. 14. Nokia-testin tulokset
  15. 15. Nokia-testin tulokset • Tutkituissa yrityksissä Nokia-testin keskiarvoksi muodostui 4,5. • Joukosta erottui muutama yritys, joka kertoi itse noudattavansa Scrum-prosessia, mutta testin tulosten perusteella he eivät juuri käyttäneet Scrumia. • Kaksi yritystä pärjäsi keskivertoa paremmin, saaden kuusi pistettä tai enemmän.
  16. 16. Nokia-testin tulokset • Yrityksen koolla tai Scrum-kokemuksella ei ollut yhteyttä testissä pärjäämisen kanssa. • Kansainväliseen aineistoon vertailtaessa parannettavaa olisi: – ketterässä määrittelyssä, tuoteomistajan käyttäytymisessä ja hyödyntämisessä sekä häiriötekijöiden ehkäisyssä • Kansainvälistä aineistoa paremmin pärjättiin kuitenkin työlistojen käytössä.
  17. 17. Scrum-koulutukset • Tietoisuus ja hyvät käytännöt lisääntyivät Scrum-koulutuksissa. • Joissain yrityksissä kaikki työntekijät oli lähetetty ScrumMaster-koulutuksiin, toisissa ainoastaan tiiminvetäjät. • Monet olivat panostaneet omaan koulutusmateriaaliin tai kirjastoon.
  18. 18. Asiakkaiden suhtautuminen • Asiakkaita kiinnosti lopputulos. • Eivät välttämättä haluakaan ymmärtää käytettyä menetelmää. • Asiakkaat kiittelivät avoimempaa ja säännöllistä kommunikaatiota sekä joustavuutta. • Kiinteähintaisia projekteja raskaine muutoksenhallintaprosesseineen hankala sovittaa Scrumiin.
  19. 19. Organisaatiokulttuuri • Puolet yrityksistä kertoi että Scrum sopii yhteen heidän organisaatiokulttuurinsa kanssa. • Johdon tuki Scrumille vaihteli, mutta monesti johto oli innoissaan tuloksista. • Muutosvastarintaa Scrumiin siirtyessä esiintyi. • Kahdessa yrityksessä koko toiminta perustui Scrumin periaatteisiin.
  20. 20. Scrum-tiimit • Suurimmalla osalla yrityksistä oli tavoitteena 4-6 hengen tiimit. • Tiimit olivat pääsääntöisesti itseohjautuvia, joissa jäsenten päällekkäinen osaaminen oli kasvanut.
  21. 21. Iteraatiot • Muutamassa yrityksessä ei sprinttejä käytössä, vaan ylhäältä määrätty isompi suunnitelma. • Kesto vaihteli kahdesta viikosta neljään. Kahden viikon mittainen sprintti todettiin useimmiten tehokkaimmaksi. • Pitkät sprintit eivät toimineet, koska kauas tulevaisuuteen ei pystytä ennustamaan ja työmääräarvioit alkavat heittämään.
  22. 22. Testaus • Testausautomaatiossa koettiin olevan paljon parannettavaa. • Jatkuva automaattinen yksikkötestaus oli käytössä vain muutamassa yrityksessä. • Yksikkötestausta kuitenkin käytettiin kaikkialla. • Erillisiä hyväksymiskriteerejä tai hyväksymistestausta käytettiin neljässä yrityksessä.
  23. 23. Määrittely • Jotkut tekivät kaikki määrittelyt ennen ensimmäistäkään iteraatiota. • Kovin monella ei ollut käytössä formaaleja määrittelyjä, sen sijaan käytettiin käyttäjätarinoita ja käyttötapauksia. • Moni myös korosti, että ketteryys ei tarkoita määrittelyistä luopumista.
  24. 24. Tuoteomistaja (Product Owner) • Tuoteomistajan rooli koettiin usein haastavana, koska täytyy hallita niin paljon eri asioita. • Kahdessa haastatellusta yrityksistä ei projekteissa käytetty tuoteomistajia lainkaan. • Seitsemässä yrityksessä tuoteomistaja tuli oman yrityksen sisältä. • Kahdessa yrityksessä tuoteomistaja oli asiakkaan puolella.
  25. 25. Tuoteomistaja (Product Owner) • Ongelmia aiheutti tuoteomistaja-roolin sovittaminen muuhun organisaatioon. • Kommunikaatioketju oli joko liian lyhyt tai liian pitkä.
  26. 26. Tuotteen työlista • Tuotteen työlista oli käytössä kaikissa yrityksissä, mutta työlistan priorisointia tehtiin hyvin erilaisten periaatteiden mukaan. • Osalla yrityksistä työlista tuli suoraan isommasta julkaisusuunnitelmasta, mutta useimmilla yrityksillä tuoteomistaja hallinnoi työlistaa. • Työlistan käyttäminen ja hallinnointi vaati paneutumista sekä ammattitaitoa, sillä on otettava huomioon monimutkaisia riippuvuuksia.
  27. 27. Työmääräarviointi • Työmääräarviointi usein annettu tiimin tehtäväksi. • Projektipäällikön yksin tekemät työmääräarviot olivat enemmän pielessä. • Arvioiden tekeminen itsessään opettaa kaikille, mitä työtä valmiiseen ominaisuuteen oikeasti sisältyy. • Pokerisuunnittelua käytettiin viidessä yrityksessä ja sitä kuvattiin usein hauskaksi käytännöksi.
  28. 28. Burndown-kaaviot • Käytössä suurimmassa osassa yrityksiä, vain kolmessa yrityksessä sitä ei nähty hyödylliseksi. • Burndown-kaavion avulla tiimin nopeutta seurattiin. Nopeus oli tiedossa neljässä yrityksessä. • Nopeuden käsite todettiin melko ongelmalliseksi. • Edistyneimmissä yrityksissä Burndown-kaavio generoitiin automaattisesti sprintin työlistasta, tiimi tiesi oman nopeutensa ja historiadataa käytettiin suunnittelussa apuna.
  29. 29. Tiimin häiriötekijät • Häiriöitä ja keskeytyksiä tiimin työhön näytti tulevan useista eri lähteistä. • Ylläpitotehtävät muista projekteista, tukipyynnöt, asiakkaan pyynnöt ja omat projektipäälliköt häiritsivät. • Ylimääräiset tehtävät eivät usein näy tuotteen työlistassa.
  30. 30. Retrospektiivit • Lisäsivät avoimuutta ja kommunikointia projekteissa. • Saatiin paljon kehitysideoita, jotka sitten toteutuivat vaihtelevalla menestyksellä. • Parannukset jalkautuivat nopeasti, mutta niiden levittäminen muihin tiimeihin oli vaikeaa. • Palautteenantosyklin lyhentäminen nähtiin tärkeänä tavoitteena.
  31. 31. Tiimin työympäristö • Lähes kaikissa yrityksissä oli pyrkimys järjestää tiimi istumaan lähekkäin samaan huoneeseen. • Eräässä yrityksessä oli jopa kaadettu seiniä, jotta saatiin tiimi istumaan lähemmäs toisiaan. • Avokonttoriympäristö oli myös suosittu, siinä kuitenkin jouduttiin usein huutelemaan sermien yli. • Tiimin hajautuksen eri tiloihin todettiin olevan suuri epäkohta.
  32. 32. Hajautus • Hajautusta oli monella eri tasolla: yksittäisiä tiimin jäseniä saattoi olla eri paikkakunnilla tai eri paikkakunnilla sijaitsevat tiimit toimivat yhdessä. • Hajautuksesta tuntui olevan monenlaista päänvaivaa, esim. kommunikaatio- ja kulttuuriongelmia. • Työkalut eivät korvaa kasvotusten kommunikointia. • Ainoastaan yksi yritys oli tyytyväinen hajautettuun toimintaansa.
  33. 33. Alihankinta • Alihankinta oli mukana monessa projektissa tavalla tai toisella, osa yrityksistä oli itse alihankittuina, toiset ostivat alihankintana. • Alihankitut työntekijät usein samoissa tiloissa yrityksen muiden työntekijöiden kanssa. • Työntekijöiden vaihtuvuus, tiukka työtuntiseuranta, kommunikaatio ja sopimustekniset asiat monesti haastavia.
  34. 34. Dokumentointi • Usein asiakkaan kanssa mietittiin, mitä dokumentaatiota tarvitaan, eikä ylimääräisiä ja turhia dokumentteja tarvinnut prosessissa tuottaa. • Käytettiin paljon wikipohjaista dokumentointia. Wiki sai myös moitteita sekavuudesta. • Yleisimmin oli dokumentoitu arkkitehtuuritaso sekä rajapinnat, muuta dokumentaatiota tehtiin asiakkaan toiveen mukaisesti.
  35. 35. Scrum ja laatujärjestelmät • Kuudessa yrityksessä oli käytössä ISO 9001- laatujärjestelmä. • Kahdessa yrityksessä käytettiin CMMI:tä, taso 3. • Osa tyytyväisiä, osa kertoi ettei vaikuta Scrumiin, osa ei halunnutkaan käyttöön koska kokivat hankaliksi. • Todettiin myös Scrumin keventävän laatujärjestelmää. • Laatustandardeista on etua julkisissa kilpailutuksissa.
  36. 36. Milloin tehtävä on valmis? • Kriteereinä mm. hyväksymistestaus, koodin ja dokumentoinnin valmistuminen, yksikkötestien läpimeno, läpi mennyt koodin katselmointi, lokalisointien valmistuminen sekä testikattavuus. • Kriteereitä ei oltu kuitenkaan määritelty selkeästi asiakkaan kanssa tai niin, että ne olisivat kaikkien tiedossa.
  37. 37. Käytetyt työkalut • Haluttiin yhtä kevyitä työkaluja kuin Post-it - laput, mutta jotka mahdollistaisivat paremmin hajautetun työskentelyn ja varmuuskopioinnin. • Suurin osa käytti Scrum-työkaluinaan kuitenkin Post-it- lappuja, tussitauluja ja Excel-taulukoita. • Jotkut käyttivät myös erityisiä Scrum-ohjelmistoja, tai itse tehtyjä ohjelmistoja.
  38. 38. Scrum-suosituksia • Käytä omaa harkintaa Scrumin soveltamisessa. • Luo Scrumiin oma sisäinen koulutuspaketti. • Järjestä kuukausittaisia tietoiskuja ketterästä kehityksestä.
  39. 39. Scrum-suosituksia • Aseta tiimien kooksi 5-9 henkeä. • Mahdollista tiimien itseorganisoituminen. • Osaavat ja noviisit tasapainottavat toisiaan Scrum- tiimeissä.
  40. 40. Scrum-suosituksia • Linjaesimiestä ei kannata asettaa ScrumMasteriksi. • Käytä tiimin omaa sprinttiä, jossa he välillä itse päättävät työlistan. • Lyhennä palautteenantosykliä kahden viikon sprinteillä.
  41. 41. Scrum-suosituksia • Mahdollista kommunikaatio dokumentaation avulla. • Älä unohda arkkitehtuurisuunnittelua tai määrittelyjä ketterässä kehityksessä. • Järjestä ammattilaisten vetämiä retrospektiivejä.
  42. 42. Scrum-suosituksia • Automatisoi testausta ja buildien tekemistä. • Pidä yläosa tuotteen työlistasta aina valmiiksi analysoituna. • Pokerisuunnittelu on hauska tapa hoitaa työmääräarviointi.
  43. 43. Scrum-suosituksia • Älä hajauta sovelluskehitystä. • Jos kuitenkin hajautat, käytä etänä työskenteleviä henkilöitä säännöllisesti paikan päällä.
  44. 44. Scrum-suosituksia • Kerää henkilöstöltä säännöllisesti palautetta ja havainnoi trendiä. • Mittaa asiakastyytyväisyyttä säännöllisesti. • Opasta sidosryhmiäsi Scrumin toiminnasta.
  45. 45. Lisätietoja: Jyri Vuorinen jyri.vuorinen@gmail.com +358 400 77 63 57 fi.linkedin.com/in/jyrivuorinen

×