Udostępnij za pośrednictwem

TFS 2013 ja Scrum kyvykkyys

  • Artykuł

Hóla, eli terveiset täältä Madridista, jossa olen opiskellut ahkerasti Scrumia ja sen käyttämistä TFS 2013 kanssa. Se, miten tämä liittyy asiaan, on luettavissa täältä: <blog.jessehouwing.nl/2014/02/avanade-partners-with-scrumorg.html>.

Olen ollut erittäin kiireinen juuri näistä ketteristä syistä ja sen takia on pitänyt pitää taukoa blogikirjoituksista.

Chaos Manifeston vuonna 2011 julkaiseman tutkimuksen mukaan karkeasti ottaen 14% Waterfall-projekteista onnistuu kun taas Agile-projekteissa lukema on 42. (Lähde: <www.mountaingoatsoftware.com/blog/agile-succeeds-three-times-more-often-than-waterfall>)

Niistäkin Agile-projekteista joissa on ollut ongelmia, on asiakas ollut tyytyväisempi lopputulokseen vastoin kuin Waterfall – projektissa.

Useampi varmaan tietää tämän, mutta miten tämä liittyy Team Foundation Serveriin?

Versiosta 2010 lähtien Microsoft on toimittanut versio versiolta parempia Scrum-prosessimalleja (Project Template) Team Foundation Serverin päälle. Mainitsinkin näistä viime syksynä kun kirjoitin TFS 2013 uusista ominaisuuksista.

Mitkä ovat Scrumin lähtökohtia?

Suoraan Scrum. Org määrittelyä lainatakseni Scrum on:

  • ketterä

  • helppo ymmärtää

  • vaikea hallittava.

Tuohon viimeiseen kohtaan TFS 2013 tuo isoja helpotuksia.

Scrum projektinhallinta TFS 2013-tuotteessa

 

Scrum-projektilomakkeella näkyy mitä työkortteja voi tallentaa. Tämä on suoraan Scrum-kehitysmallia tukeva prosessimalli. Huomatkaa uutena Feature. Tämän voi käsittää myös Epic-nimikkeenä, mutta kyse on siis toiminnallisesta kokonaisuudesta. Esimerkkinä vaikka: (Palauteportaali, ulkoinen portaali, työkalu x). Näiden alle voidaan sitten linkittää niihin kuuluva backlog – nimikkeet. Tämä portaali on syytä olla koko Scrum - tiimin, tuoteomistajan ja sidosryhmien käytössä. Näin varmistetaan Scrumin läpinäkyvyys periaate. Raapaisen tässä hieman pintaa aiheesta, mutta suosittelen kokeilemaan itse vaikka Visual Studio Online versiolla sitä, miten tämä toimii.

 

 

Tuotteen backlogin hallinta määritellään seuraavalla tavalla Scrumin sääntöjen mukaan:

  • Näyttää tuotteen nimikkeet (Backlog items)

  • Nämä kokonaisuudet tulee olla järjestettävissä

  • Kehitystiimin tehtävän työn arvoa voidaan optimoida

  • Tuotteen backlog pitää olla nähtävissä kaikille, ja se näyttää mitä kehitystiimi tekee seuraavaksi

  • Kehitystiimin pitää ymmärtää backlogissa olevat nimikkeet.

 

 

Uutena konseptina on Feature, josta jotkut käyttävät myös termiä Epic. Tämä on isompi toiminnallisuus kokonaisuus:

 

Featuren merkitys näkyy tässä filteröinnissä paremmin (käytettäessä toimintoa Features to Backlog Items):

 

 

Tämä on toteutettu erikseen näin koska Scrumin mukaan Backlog pitää olla yksirakenteinen lista (eli ei puuhierarkia), jota voidaan helposti priorisoida. Tämä auttaa rakentamaan tuotteen kategorisoinnin paremmin kuitenkin näin. Näin ollen Backlog items -sivulla toteutuu se periaate, että backlog voidaan oikeasti priorisoida ilman rakenteita. Vaikka TFS mahdollistaa backlog to backlog -rakenteen (EPIC) käytön varsinkin aiemmissa versioissa, niin tämän on tarkoitus saada Scrum-prosessia tukevaa toiminnallisuutta paremmin käyttöön.

Joillekin on varmaan tuttu termi KanBan-taulu. Täällä löytyy lisää tietoa siitä mikä on KanBan: <www.kanbanblog.com/explained/>. Sekin on toteutettu TFS:ään. Tässä määritellään eritasoisesti mitkä Backlog nimikkeet ovat uusia, Product Ownerin hyväksymiä, Kehitystiimin Sprinttityöhön sidottuja ja tietenkin niitä mitkä ovat jo valmistuneet.

 

Uudessa versiossa tämä on myös tehty Featureille:

 

 

Sitten on vielä tarkemmin KanBan-taulu tehtäville per Backlog nimike:

 

Kanban-taulu henkilöille:

 

Scrum tiimin kapasiteetti voidaan asettaa täällä ja poissaolopäivät Sprintin aikana:

 

Burndown kaavio: (Huomatkaa että aiemmat tehtävät laitoin juuri tälle sprintille ja Sprintti on alussa.)

 

Tiimin velocity sprinteittäin:

 

Kaavio aikajanalla backlogin tilanteesta: (Cumulative flow)

 

Lisäksi on olemassa työkalu joka löytyy asetusten alta nimeltä ”Iteraatiot”.

Täällä voidaan merkitä Sprinttien suunnittelussa esiin tuleva aikataulutus, joka voidaan jakaa toimituspätkiin. Tämä Ei ole siis puhdasta Scrumia, mutta todellisuutta koska asiakkaat haluavat saada yleensä ottaen jonkinnäköisen RoadMapin kehitettävälle tuotteelle.

Tässä oli perusasioita siitä miten voidaan hyödyntää TFS 2013 peruskyvykkyyksiä tuoteomistajan ja Scrum Masterin sekä kehitystiimin työkaluna.

Täältä löytyy Microsoftin virallinen englanninkielinen artikkeli aiheesta:

msdn.microsoft.com/en-us/library/vstudio/dn306083.aspx

 

Lisäksi uusia uutisia jotka kannattaa lukea:

Team Explorer everywhere:

blogs.msdn.com/b/bharry/archive/2014/02/28/team-explorer-2013-update-1-available.aspx

TFS 2013 CTP2

blogs.msdn.com/b/bharry/archive/2014/03/05/vs-tfs-2013-2-ctp-2-available.aspx

PS: Kannattaa odotella ensi kuun blogikirjoitustani J. Kerron mitä uutta ja hienoa löytyy ALM-rintamalta San Franciscon Build -konferenssista.