Parauga kontrollapa ScrumMasteriem
Autors:Tulkotājs:
Avots:

Michael James (mj4scrum@gmail.com)
Kārlis Cinis (karlis.cinis@gmail.com)
Balstīts uz angļu valodas oriģināla 2016. gada 2. februāra redakciju

Pilna laika fasilitators?
Adekvāts ScrumMasters var darboties ar divām vai trim komandām vienlaicīgi. Ja Teviapmierina savas lomas ierobežošana līdz sapulču organizēšanai, sapulču laika ierobežojumunoturēšanu un darbībām ar šķēršļiem, uz kuriem komandas tieši norāda, tad varēsi šo lomu
darīt papildus citām lomām vai pienākumiem. Komanda droši vien tāpat darbosies
veiksmīgāk, salīdzinot ar pirms-Scrum periodu Tavā organizācijā, un droši vien nekādas
katastrofas nenotiks.
Bet, ja Tu spēj iztēloties komandu, kura izmainītajā organizācijā kopā jūtas lieliski,
paveicot lietas, kuras iepriekš šķita neiespējamas, tad apsver būt par lielisku ScrumMasteru.
Mēs iesakām vienu pilna laika ScrumMasteru uz vienu aptuveni septiņu cilvēku
komandu sākuma posmā.
Ja Tu neesi atklājis visus darbus, kas būtu darāmi, tad paskaties vērīgi uz ProduktaĪpašnieku (eng. – Product Owner), Tavu komandu, Tavas komandas tehniskajām praksēm unorganizāciju aiz Tavas komandas robežām. Lai gan nepastāv viena recepte, kas derētu visiem,
esmu piefiksējis tipiskākās lietas, kuras ScrumMasteri mēdz nepamanīt. Lūdzu, veic atzīmi
katrā kvadrātā atbilstoši norādēm pēdējā lapaspusē.

I daļa – Kā iet manam Produkta Īpašniekam?
ScrumMasteri uzlabo Produktu Īpašnieku efektivitāti, palīdzot viņiem atrast veidus kāuzturēt Produkta Darbu Sarakstu (eng. – Product Backlog) un relīzes plānu. Atceries, kaProdukta Īpašnieks ir tas, kurš ir atbildīgs par svarīguma ziņā sakārtotu Produkta DarbuSarakstu).



Vai Produkta Darbu Saraksts ir sakārtots pēc svarīguma atbilstoši viņa/viņas
jaunākajiem uzskatiem?

 Vai Produkta Darbu Sarakstā ir ietvertas prasības un vēlmes no visām ieinteresētajām
pusēm? Atceries, ka Produkta Darbu Saraksts pastāvīgi mainās – darbi tajā maina savu
svarīgumu, tiek pievienoti un arī dzēsti.

 Vai Produkta Darbu Saraksts ir pārvaldāmā izmērā. Lai tajā saglabātu darbu skaitu, kas irpārvaldāms, tā augšgalā esošajiem darbiem jābūt sadalītiem mazākos gabalos, bet
nedetalizēti darbi un lielāki darbu nodomi jāpatur saraksta apakšā. Detalizēti analizēt
darbus, kas ir pārāk tālu no Produkta Darbu Saraksta augšgala, ir neproduktīvi. Prasības
mainīsies pastāvīgajā evolucionējošā produkta komunikācijā ar iesaistītajām pusēm unklientiem.

Autortiesības © 2007-2016 Michael James. Visas tiesības aizsargātas.

 Vai kāda no prasībām (īpaši tām, kas atrodas Produkta Darbu Saraksta augšgalā) varētu
tikt labāk noformulēta kā neatkarīgs, pārrunājams, vērtīgs, novērtējams, mazs un
notestējams Lietotāja Stāsts (eng. – user story)1?

 Vai Tu esi izglītojis Produkta Īpašnieku par tehniskajiem parādiem un kā no tiem
izvairīties? Viens no risinājumiem varētu būt automātisko testu un koda pārstrādāšanas
iekļaušana „izdarīts” definīcijā (eng. – definition of done) katram sarakta darbam.

 Vai Produkta Darbu Saraksts ir informācijas izstarotājs, kas acumirklī ir pieejams visāmieinteresētajām pusēm?

 Ja izmantojat automatizētu rīku Produkta Darbu Saraksta vadībai, vai visi zina kā to ērtilietot? Automatizētajiem vadības rīkiem bez aktīvas informācijas izstarošanas noScrumMaster puses ir risks kļūt par informācijas saldētavām.

 Vai Tu palīdzētu informācijas izstarošanā, ja rādītu visiem izdrukas?
 Vai Tu palīdzētu informācijas izstarošanā, ja izveidotu lielas, redzamas diagrammas?
 Vai esi palīdzējis savam Produkta Īpašniekam sakārtot Produkta Darbu Saraksta vienības
relīzēs vai prioritāšu grupās?

 Vai visi zina vai relīzes plāns joprojām atbilst realitātei? Tu varētu pamēģināt visiem
parādīt Produkta / Relīzes Burndown diagrammas2 pēc tam, kad atbilstošās ProduktaDarbu Saraksta vienības ir atzīmētas kā „izdarīts” Sprinta Pārskatīšanas Sapulcē (eng. –Sprint Review Meeting). Diagrammas, kas atspoguļo gan Produkta Darbu Saraksta
pabeigto vienību apjomu, gan jaunu pievienoto vienību apjomu, ļauj agri pamanīt
novirzes no sākotnējās plānotās funkcionalitātes (eng. – scope/Schedule drift).

 Vai Tavs Produkta Īpašnieks atjaunoja relīzes plānu pēc pēdējās Sprinta Pārskatīšanas
Sapulces? Maza daļa no Produktu Īpašniekiem pārplāno relīzi katru sprintu, bet tiešiviņiem izdodas piegādāt adekvāti notestētus produktus paredzētajā laikā. Tas bieži vien
nozīmē noteiktu darbu atlikšanu uz tālākām relīzēm, jo tiek atklāti būtiskāki, drīzāk
veicami darbi.

II daļa – Kā iet manai komandai?
Lai gan ir atbalstāma komandas vadīšana ar personīgo piemēru, pildīt komandas
darbus, sadarbojoties ar komandas dalībniekiem, pastāv risks nogrimt tehniskos uzdevumos.
Atceries par savām primārajām atbildībām pret komandu: Vai Tava komanda ir plūsmas stāvoklī ? Šim stāvoklim ir raksturīgi:
3





Skaidri mērķi (gaidas un noteikumi ir saprotami, mērķi sasniedzami unpiemēroti personas prasmēm un iemaņām),Koncentrācija un fokuss, spēcīgs fokuss uz šauru darba lauku,
Sevis apzināšanās izzušana, darbības un esības saplūšana,Tieša un acumirklīga atgriezeniskā saite (veiksme un neveiksme darbībā
ir ļoti skaidra, lai darbība varētu tikt pielāgota atbilstoši vajadzībām),1

http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
Mike Cohn, Agile Estimation and Planning. (2005).
3
Mihaly Csikszentmihalyi, Flow: The Psychology of Optimal Experience (1990).
2Autortiesības © 2007-2016 Michael James. Visas tiesības aizsargātas.



Balanss starp spēju līmeni un izaicinājumu (aktivitāte nav ne pārākviegla, ne pārāk grūta),Personīgas kontroles sajūta pār situāciju vai aktivitāti,
Aktivitāte ir iekšēji atalgojoša, radot viegluma sajūtu tās izpildē.

 Vai komandas dalībnieki viens otram patīk, kopīgi joko un svin viens otra panākumus?
 Vai komandas dalībnieki viens pret otru uztur augstus standartus un izaicina viens otru
augstāku mērķu sasniegšanai?

 Vai ir sarežģījumi/ iespējas, kurus komanda neapspriež tāpēc, ka tā būtu pārāk neērtasituācija4?

 Vai Tu esi pamēģinājis dažādus formātus un norises vietas Sprinta Retrospekcijas
Sapulcei5?

 Vai komanda ir noturējusi uzmanību uz Sprinta mērķiem? Iespējams, komandai būtu
lietderīgi veikt Sprinta uzdevumu pārskatīšanu Sprinta vidū, lai pārliecinātos, kapaņemto uzdevumu izpildes kritēriji (eng.- acceptance criteria) ir ņemti vērā.

 Vai Sprinta uzdevumu tāfele atspoguļo to, ar ko komanda patiesībā nodarbojas?
Uzmanies no noklusēto uzdevumu un uzdevumu, kas lielāki par vienu dienu, „tumšāsmatērijas”. Uzdevumi, kas neattiecas uz Sprinta mērķiem, ir uzskatāmi par šķēršļiem šomērķu sasniegšanā.

 Vai Tava komanda sastāv no 3-9 cilvēkiem ar pietiekamu prasmju kopumu, lai radītu
potenciāli piegādājumu produkta vienību (eng. – potentially shippable productincrement)?

 Vai komandas uzdevumu tāfele atspoguļo aktuālāko informāciju?
 Vai komandas pašpārvaldības artefakti ir redzami komandai un tai ērti lietojami?
 Vai šie artefakti ir pietiekami pasargāti no cilvēkiem, kuriem varētu rasties vēlmejaukties komandas iekšējās lietās? Pārlieka ikdienas darbību pārraudzīšana nocilvēkiem, kuri atrodas ārpus komandas, var apgrūtināt komandas iekšējo
caurskatāmību un pašpārvaldību.

 Vai komandas dalībnieki paši piesakās uz Sprinta darbiem?
 Vai nepieciešamība atmaksāt tehniskos parādus ir skaidri padarīta „izdarīts” definīcijā,pakāpeniski padarot kodu par jaukāku vietu, kur strādāt?

 Vai komandas dalībnieki atstāj amata nosaukumus aiz durvīm un kopīgi uzņemasatbildību par visiem aspektiem paņemtajos uzdevumos (testēšana, dokumentēšana,utt.)?

4Marshall Rosenberg, Nonviolent Communication: A Language of Life: Life-Changing Tools for Healthy
Relationships (2003). Apsver profesionāla fasilitatora piesaistīšanu, lai neērtās sarunas padarītu
komfortablākas.
5
Derby/Larson Agile Retrospectives: Making Good Teams Great (2006).

Autortiesības © 2007-2016 Michael James. Visas tiesības aizsargātas.

III daļa – Kā mums iet ar tehniskajām praksēm?

 Vai sistēmai, kuru jūs izstrādājat, ir poga „palaist testus”, kas atļauj ikvienam (tajā pašāvai citā komandā) ērti noskaidrot, kad viņi ir radījuši regresijas kļūdu (salauzta iepriekš
strādājoša funkcionalitāte)? Tipiski tas tiek sasniegts ar xUnit rīkiem (Junit, NUnit, etc.).

 Vai pastāv pareizs balanss starp automatizētajiem sistēmas jeb funkcionālajiem testiem
un automatizētajiem vienību testiem?

 Vai komandas raksta sistēmas testus un vienību testus tajā pašā programmēšanas
valodā, kurā tiek rakstīts sistēmas kods? Sadarbību neveicina specifiskas skriptēšanas
valodas vai rīki, kas notver un atkārto darbības, ja tikai daļa komandas zina kā tos lietot
un uzturēt.

 Vai Tava komanda ir atklājusi lietderīgo pelēko zonu starp sistēmas testiem un vienību
testiem6?

 Vai nepārtrauktās integrācijas serveris automātiski paziņo par kļūdu, ja neiziet kāds
7

regresijas tests? Vai šī atgriezeniskā saite var tikt samazināta līdz stundām vaiminūtēm? („Automātiskā ikdienas sistēmas būvēšana ir nīkuļiem” – Kent Beck) Vai visi testi tiek ietverti pastāvīgās integrācijas servera rezultātos?
 Vai komandas dalībnieki ir atklājuši nepārtrauktās dizaina attīstīšanas un pastāvīgās
koda pārstrādāšanas8 prieku kā alternatīvu lielam sākotnējam dizainam? Koda
pārstrādāšanai (eng. – refactoring) ir strikta definīcija: iekšējās struktūras mainīšana,nemainot ārējo uzvedību. Koda pārstrādāšanai vajadzētu notikt vairākas reizes stundā,katru reizi, kad kodā ir dublēšanās, sarežģīta nosacījumu loģika (redzama pēc
apjomīgām atkāpēm no loga kreisās puses vai garām metodēm), slikti nosaukti
identifikatori, pārlieka saistība starp objektiem, utt. Koda pārstrādāšana ir iespējam
tikai tad, ja ir pietiekams automātisko testu pārklājums. Koda pārstrādāšanas trūkums
padara nākotnes izmaiņas produktā daudz sarežģītākas jo īpaši tāpēc, ka ir grūti atrast
labus izstrādātājus, kuri vēlētos strādāt sliktā kodā.

 Vai Tava „izdarīts” definīcija katrai Produkta Darbu Saraksta vienībai ietver pilnu
automātisko testu pārklājumu un koda pārstrādāšanu? Testu virzītas izstrādes metodes(eng. – Test Driven Development) apgūšana palielina iespējamību to paveikt.

 Vai komandas dalībnieki izmanto pāra programmēšanu vairumā gadījumu? Pāra
programmēšana var būtiski uzlabot koda uzturamību un samazināt kļūdu apjomus. Tāizaicina cilvēku robežas un dažkārt šķietami aizņem vairāk laika (ja mēra koda līnijas,
nevis piegādājamu funkcionalitāti). Vadi ar piemēru, iniciējot pāru darba dienas arkomandas dalībniekiem. Daži no viņiem sāks dot priekšroku šādam darba stilam.

6

http://blogs.collab.net/agile/junit-is-not-just-for-unit-testing-anymore
http://www.martinfowler.com/articles/continuousIntegration.html
8
Martin Fowler, Refactoring: Improving the Design of Existing Code (1999)
7Autortiesības © 2007-2016 Michael James. Visas tiesības aizsargātas.

IV daļa – Kā iet organizācijai?

 Vai pietiekamā apjomā notiek starp-komandu komunikācija? „Scrum of Scrums” ir tikaiviens no veidiem kā to panākt. Turklāt tas reti ir labākais veids.9

 Vai komandas spēj neatkarīgi saražot strādājošu funkcionalitāti, kas sniedzas pāriarhitektūras robežām?10 Vai jūsu ScrumMasteri tiekas viens ar otru un strādā ar organizacionālo šķēršļusarakstu?

 Vai piemērotos gadījumos organizacionālo šķēršļu apraksts piestiprināts pie izstrādes
struktūrvienības vadītāja biroja sienas? Vai šo šķēršļu izmaksas var tikt sarēķinātasdolāros, pazaudētā kvalitātē, zaudētās klientu iespējās vai laikā, par kādu paildzinās
produkta izstrādes ilgums līdz tas nonāk pie klienta? Tomēr mācies no Ken Schwaberakļūdām: „Miris ScrumMasters ir nelietderīgs Scrummasters.”11

 Vai Tava organizācija ir viena no retajām, kurā karjeras izaugsmes ceļi saskan arkomandu kolektīvajiem mērķiem? Atbildi ar „Nē”, ja pastāv karjeras ieguvumi12, veicot
programmēšanu vai arhitektūras darbus uz testēšanas, testu automatizācijas vailietotāju dokumentācijas rēķina.

 Vai Tava organizācija ir atzīta par vienu no labākajām darbavietām vai nozares līderi
kādā no nozares medijiem vai citos neatkarīgos avotos?

 Vai Tu veido organizāciju, kas mācās?
Secinājums
Ja vari sekmīgi aizkrāsot kā padarītus vairumu no šiem punktiem un Tev joprojām
darba dienās ir brīvs laiks, es vēlētos uzzināt, kā Tev tas ir izdevies?
Nepastāv neviena gatava formula, ar kuru iespējams iedēstīt radošumu. Šis materiālsuzskaita punktus, kas var (vai arī nevar) palīdzēt Tavā situācijā.
Tiklīdz Tu sāksi aptvert tās lietas, kuras Tu varētu darīt, lai uzlabotu situāciju, Tevvarētu piezagties bailes tās īstenot. Tā ir zīme, ka esi uz pareizā ceļa.

9Šeit atrodami citi veidi http://less.works/less/framework/coordination-and-integration.html

10

http://featureteamprimer.org/Ken Schwaber, Agile Project Management with Scrum (2004)
12
Alfie Kohn, Punished By Rewards: The Trouble with Gold Stars, Incentive Plans, A's, Praise, andOther Bribes (1999)
11Autortiesības © 2007-2016 Michael James. Visas tiesības aizsargātas.

Organizacionālo Šķēršļu Veidlapa
Virspusējā problēma:

Pamata cēlonis (izmanto piecreiz „Kāpēc?”):Biznesa ietekme:

Emocionālā ietekme:

Skaidrs, izpildāms pieprasījums:.....................................................................................................................................................

Organizacionālo Šķēršļu Veidlapa
Virspusējā problēma:

Pamata cēlonis (izmanto piecreiz „Kāpēc?”):Biznesa ietekme:

Emocionālā ietekme:

Skaidrs, izpildāms pieprasījums:

Autortiesības © 2007-2016 Michael James. Visas tiesības aizsargātas.

Organizacionālo Šķēršļu Veidlapa
Virspusējā problēma:

Pamata cēlonis (izmanto piecreiz „Kāpēc?”):Biznesa ietekme:

Emocionālā ietekme:

Skaidrs, izpildāms pieprasījums:.....................................................................................................................................................

Organizacionālo Šķēršļu Veidlapa
Virspusējā problēma:

Pamata cēlonis (izmanto piecreiz „Kāpēc?”):Biznesa ietekme:

Emocionālā ietekme:

Skaidrs, izpildāms pieprasījums:

Autortiesības © 2007-2016 Michael James. Visas tiesības aizsargātas.

Organizacionālo Šķēršļu Veidlapa
Virspusējā problēma:

Pamata cēlonis (izmanto piecreiz „Kāpēc?”):Biznesa ietekme:

Emocionālā ietekme:

Skaidrs, izpildāms pieprasījums:.....................................................................................................................................................

Organizacionālo Šķēršļu Veidlapa
Virspusējā problēma:

Pamata cēlonis (izmanto piecreiz „Kāpēc?”):Biznesa ietekme:

Emocionālā ietekme:

Skaidrs, izpildāms pieprasījums:

Autortiesības © 2007-2016 Michael James. Visas tiesības aizsargātas.

Instrukcija
Ja esi saņēmis šo kontrollapu kā mācību uzdevumu un Tavs šī brīža(vai pēdējais) darba devējs mēģina kaut ko, kas atgādina Scrum, lūdzu,izmanto šo kontrollapu, lai novērtētu to, ko esi tur novērojis. Atzīmēkatru punktu ar vienu no zemāk norādītajiem simboliem.
?
NTiek veikts labi.
Var tikt uzlabots un es zinu, kur sākt.
Var tikt uzlabots, bet kā?
Nav attiecināms uz manu situāciju vai nesniegtu nekādu labumu.

Ja Tavs šī brīža (vai pēdējais) darba devējs nemēģina neko, kasatgādina Scrum, atzīmē katru punktu ar vienu no zemāk norādītajiemsimboliem.
?
NTiek veikts labi vai to būtu vienkārši veikt labi.
Tas būtu izaicinājums un es zinu, kur sākt.
Tas būtu izaicinājums un es nezinu, kur sākt.
Nav attiecināms uz manu situāciju vai nesniegtu nekādu labumu.

Kad visi punkti ir atzīmēti ar kādu no simboliem, izmanto
Organizacionālo Šķēršļu Veidlapas, lai aprakstītu divus līdz sešusorganizacionālos šķēršļus neatkarīgi no tā vai tie atpazīti ar šīs
kontrollapas palīdzību vai kā savādāk. Izvēlies tādus šķēršļus, kuru
izmainīšanas iespēja ir vismaz 1%.

Autortiesības © 2007-2016 Michael James. Visas tiesības aizsargātas.