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.

Sysartin palvelun toimitusmalli

166 views

Published on

Sysartin toimintamalli ohjelmistokehityksen palveluissa.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Sysartin palvelun toimitusmalli

  1. 1. PALVELUN TOIMITUSMALLI
  2. 2. Miten se toimii? Sysartilla k�ytet��n ketter�� toimitusmallia, joka pohjautuu pitk�lti Scrumiin *1). Mallin tavoitteena on pyrki� parhaaseen mahdolliseen lopputulokseen, joka on saavutettavissa asetettujen aika- ja budjettirajoitusten puitteissa. Kuten Scrumin, my�s meid�n toimintamallin perusteena ovat monitaitoiset tiimit, jotka ty�skentelev�t 1-3 viikon mittaisissa iteratiivisiss� ty�jaksoissa eli sprinteiss�. T�m�n lis�ksi k�yt�mme Scrumista tuttuja Tuoteomistajan sek� Scrum Masterin rooleja ja tuotteen kehitysjonoa, jolla hallitaan j�ljell� olevan toteutuksen laajuutta. 1) https://fi.wikipedia.org/wiki/Scrum
  3. 3. Hyvin l�hell� Scrumia Scrumista poiketen me pyrimme v�ltt�m��n yksitt�isten kehitysjonon kokonaisuuksien estimoinnin sellaisenaan. T�m�n sijaan me pilkomme vaatimukset pienempiin osiin, jotka ovat ty�m��r�lt��n ja laajuudeltaan karkeasti samansuuruisia ja joita voidaan hallinnoida ilman estimointeja. Sprinttien osalta sitoudumme ennemmin sovittuun kokonaisuuteen kuin yksitt�isiin k�ytt�j�tarinoihin, koska meid�n n�kemyksen mukaan oppiminen ja ymm�rrys karttuvat sovelluskehityksess� jatkuvasti, jolloin sitoutuminen kiinteisiin suunnitelmiin lyhyell�kin aikav�lill� voi heikent�� lopputuloksen laatua.
  4. 4. Iteraatiot ovat palautekierroksia Prosessimme ydin on iteratiivinen suunnittelu yhdistettyn� jatkuvaan priorisointiin, joka perustuu jatkuvaan ymm�rryksen kertymiseen Korkean tason estimointi ja palvelusuunnittel u Vaatimusten hiominen Jakaminen ja priorisointi Suunnittelu Toteutus Testaus Validointi L�pik�ynti K�ytt�j�palaute A/B testaus 1-3 viikon ty�jaksot T�st� se l�htee!
  5. 5. Miten vaatimukset suunnitellaan? Vaatimukset ovat erilaisia ja ratkaisevat ongelmia eri n�kemysten ja l�ht�kohtien pohjalta. Karkeasti ajateltuna ne voidaan jakaa kahteen eri ryhm��n: Tavoite on selke�, suunnitelma ei. Tavoite on selke�. Suunnitelma on selke�.
  6. 6. Ensimm�inen estimointi Paras tapa estimoida ep�m��r�isi� vaatimuksia on verrata niit� aikaisempiin kokemuksiin. Paras tapa estimoida hyvin m��riteltyj� vaatimuksia on pilkkoa ne pienempiin samankokoisiin osiin ja laskea osien lukum��r�. 5 tarinaa 200 tarinaa 150 tarinaa 1200 tarinaa 150 tarinaa
  7. 7. Miten vaatimukset jaetaan osiin? Tyypillisiss� tapauksissa kehitysjono sis�lt�� aluksi useita ep�m��r�isi� vaatimuksia ja toiveita, jotka edellytt�v�t tarkempaa l�pik�ynti�. Pilkkominen on suositeltavaa tehd� mahdollisimman my�h�isess� vaiheessa, koska jokainen iteraatio lis�� ymm�rryst� ja osaamista. L�pik�ynnin aikana k�sitelt�v� kokonaisuus voidaan usein jakaa pienempiin kokonaisuuksiin, joilla voi olla eri prioriteetit. Vaatimus X Arvio 15 k�ytt�j�tarinaa L�pik�ynti (Vaatimuksen ensimm�inen k�ytt�j�tarina)) Kriittinen: 5 tarinaa Valmis: 1 tarina T�rke�: 6 tarinaa Nice to have: 4 tarinaa Kriittinen Valmis T�rke� Nice to have
  8. 8. Kehitysjonon hallinta K�ytt�j�tarinoiden ja estimoidun keskiarvon pohjalta voidaan tehd� pitk�n aikav�lin aikatauluennusteita. Kun ty� etenee, tehtyjen kokonaisuuksien keskiarvon pohjalta voidaan seurata ja parantaa pitk�n aikav�lin ennusteiden ja arvioiden tarkkuutta. Kehitysjonon hallinta perustuu jatkuvaan priorisointiin. Kun tiet�mys ja ymm�rrys jostain toteuttamattomasta osakokonaisuudesta lis��ntyy, k�ytt�j�tarinoiden priorisointi tulisi p�ivitt�� vastaavasti. Critical Important Nice to have Delivery Stories Time
  9. 9. Jatkuva aikatauluennustaminen Stories K�sitys siit�, millainen valmis palvelu tulee olemaan muuttuu l�hes poikkeuksetta kehityskaaren aikana. Kun palvelua toteutetaan, kuva t�rkeist� ja v�hemm�n t�rkeist� ominaisuuksista kehittyy ja selkeytyy. K�ytt�m�ll� mallia, joka perustuu keskiarvoihin, pystymme paremmin arvioimaan aikatauluun ja budjettiin mahtuvaa laajuutta. Ennusteiden tarkkuus paranee ajan kuluessa. Critical Important Nice to have DeliveryNow Time
  10. 10. Kulu- ja aikarajoitteiden hallinta Aikataulu ja budjetti asettavat rajat sille, mit� kaikkea projektin aikana voidaan saavuttaa. Toteutuksen osakokonaisuuksien jatkuva priorisointi takaa sen, ett� aika ja raha k�ytet��n niiden ominaisuuksien toteuttamiseen, jotka ovat t�rkeimpi�. Uuden k�ytt�j�tarinan lis��minen siirt�� kaikkia pienemm�n prioriteetin asioita alasp�in kehitysjonossa sek� pudottaa alhaisimman prioriteetin tarinan pois laajuudesta. Laajuudesta poistettuja k�ytt�j�tarinoita voidaan ottaa uudelleen laajuuteen kulu- ja aikarajoitteiden puitteissa, mik�li muut ominaisuudet on toteutettu. Kriittinen T�rke� Nice to have Laajuus
  11. 11. Scrum Master TIIMI Roolit Account manager ja asiakas ovat vastuussa sopimuksesta. Projektin vet�j� ja Tuoteomistaja ovat vastuussa ty�jonon sis�ll�st� ja priorisoinnista. Scrum Master on vastuussa tiimin toiminnasta. Tiimi voi koostua sek� toimittajan ett� asiakkaan organisaation j�senist�. Yhdell� henkil�ll� voi olla useampi rooli. AsiakasAccount manager TuoteomistajaProjektin vet�j� Asiantuntijat Loppuk�ytt�j�t Asiantuntijat
  12. 12. K�yt�nn�t Me uskomme vahvasti siihen, ett� paras lopputulos saavutetaan soveltamalla parhaita k�yt�nt�j� ja tapoja sen perusteella, mitk� sopivat parhaiten projektin ja tiimin vaatimuksiin ja mieltymyksiin. Me suosimme yhdistelm�� Kanbanin ja Scrumin k�yt�nn�ist� (Yht�aikaisesti ty�stett�vien asioiden rajoitukset, p�ivitt�iset palaverit, s��nn�lliset suunnittelutapaamiset, demot ja retrospektiivit) Me suoritamme koodikatselmointia, jatkuvan integraation periaatteita, automatisoituja testej� sek� parikoodausta aina kun ne tukevat parempaa lopputulosta. Ty�mme pohjautuu vahvasti avoimeen kommunikaatioon kaikkien sidosryhmien v�lill�!
  13. 13. Olemme aina valmiita yhteydenottoosi! Sysart Oy www.sysart.fi @SysartOY

×