Scrum-menetelmän käyttö Pirkanmaalaisissa ohjelmistoyrityksissä
•
0 j'aime•829 vues
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
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (9)
En vedette
Similaire à Scrum-menetelmän käyttö Pirkanmaalaisissa ohjelmistoyrityksissä
Similaire à Scrum-menetelmän käyttö Pirkanmaalaisissa ohjelmistoyrityksissä (19)
Scrum-menetelmän käyttö Pirkanmaalaisissa ohjelmistoyrityksissä
- 1. Scrum-menetelmän käyttö Pirkanmaalaisissa ohjelmistoyrityksissä Diplomityö, Jyri Vuorinen
- 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Nokia-testi • Testissä 9 kysymystä Scrumin eri osa-alueilta. • Jokainen kysymys pisteytetään asteikolla 0-10. • Vastausten keskiarvona saadaan arvo kuvaamaan yrityksen ketteryyttä Scrumissa.
- 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Tuoteomistaja (Product Owner) • Ongelmia aiheutti tuoteomistaja-roolin sovittaminen muuhun organisaatioon. • Kommunikaatioketju oli joko liian lyhyt tai liian pitkä.
- 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Scrum-suosituksia • Käytä omaa harkintaa Scrumin soveltamisessa. • Luo Scrumiin oma sisäinen koulutuspaketti. • Järjestä kuukausittaisia tietoiskuja ketterästä kehityksestä.
- 39. Scrum-suosituksia • Aseta tiimien kooksi 5-9 henkeä. • Mahdollista tiimien itseorganisoituminen. • Osaavat ja noviisit tasapainottavat toisiaan Scrum- tiimeissä.
- 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. Scrum-suosituksia • Mahdollista kommunikaatio dokumentaation avulla. • Älä unohda arkkitehtuurisuunnittelua tai määrittelyjä ketterässä kehityksessä. • Järjestä ammattilaisten vetämiä retrospektiivejä.
- 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. Scrum-suosituksia • Älä hajauta sovelluskehitystä. • Jos kuitenkin hajautat, käytä etänä työskenteleviä henkilöitä säännöllisesti paikan päällä.
- 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. Lisätietoja: Jyri Vuorinen jyri.vuorinen@gmail.com +358 400 77 63 57 fi.linkedin.com/in/jyrivuorinen