Biežāk uzdotie jautājumi - Agile

Esam apkopojuši biežāk uzdotos jautājumus, kurus saņemam Agile lekcijās un ikdienā.

Kā vislabāk uztaisīt Kanban dēli (JIRĀ)?

Vislabākais ir sākt ar visu komandu un iziet caur Kanban darbnīcai, kur komanda izveido savu dēli, kas ir fizisks "veidojums" pie sienas. Tad kādu laiku padzīvot ar fizisko dēli uzlabot / atrast versiju, kas apmierina komandu, produktu un pienes effektivitāti, un tad pārcelt to uz elektronisku rīku (JIRA, Trello vai kādu citu). Šādā veidā komanda labāk un ātrāk sapratīs Kanban metodi un vairāk arī ticēs šai pieejai un pašam dēlim, jo paši to būs radījuši, uzturējuši un pilnveidojuši. Problēma ar JIRA un citiem elektroniskajiem dēļiem ir tāda, ka dēlis nav visu laiku acu priekšā (arī TV šeit nepalīdzēs) un Tu nevari laicīgi pamanīt potenciālās problēmas un veikt pareizās diskusijas. Fizisks dēlis ar fiziskām lapiņām un fiziskām darbībām daudz labāk veicina saprašanu, sastrādāšanos un efektivitāti, kad tas ir izdarīts tad var mēģināt pārcelt uz JIRA vai citu elektronisko rīko.

Lai izveidotu dēli JIRĀ, izmanto jau doto Kanban projekta veidni. Pie board uzstādījumiem nodefinē procesa soļus pa kollonām (ja kollonnu skaits sanāk pārāk daudz, paliec zem tām apakšsoļus ar statusiem). Turpat nodefinē arī sākotnējos WIP limitus. Izvēlies atbilstošu swimlane - t.i. izvēlies parametru, kurš tev ir svarīgs, lai būtu vizuāli redzams, ka komanda un Kanban sistēma atrodas balansā. Piem., ja katrs cilvēks komandā individuāli noved ienākošo biļeti no A-Z, tad var būt labi uzlikt swimlanes pa cilvēkiem, lai redzētu noslodzes balansu; Vai varbūt ir vairāki projekti, kur katram ir cits uzdevumu izpildes laiks, kuram jāseko līdzi. Atceries noteikt atbildīgo, kurš regulāri papildinās dēli ar jauniem uzdevumiem (un līdz ar to prioritizēs ienākošos darbus). Atceries arī par atgriezenisko saiti - kad produkts ir piegādāts klientam, pieprasi atgriezenisko saiti par apmerinātību ar pakalpojumu un produktu. Neļauj DONE kolonai uzblīst pilnai ar veciem uzdevumiem - veic regulāras produkta piegādes.

^ Uz augšu ^

Kādi ir piemēri Agile izmantošanā ārpus IT nozares?

Šādi uzņēmumi izmanto Agile filozofiju savu produktu izstrādē vai pakalpojumu sniegšanā:

Scaled Agile Framework lapā var apskatīt citus piemērus gan IT, gan ārpus IT.

^ Uz augšu ^

Kā JIRĀ uzstādīt Work In Progress (WIP) limitu ar avatāriem?

Ar standarta risinājumu tas nav iespējams, bet var izstrādāt savu pielāgojumu. Protams, to var risināt nedaudz savādāk - var uzstādīt WIP limitu katram solim kopā uz visu komandu un JIRA soļus ar pārsniegto limitu iezīmēs sarkanus.

^ Uz augšu ^

Vai Agile komandu dalībniekiem - darbiniekiem ir speciāli (darba) līgumi?

Darbiniekiem ir parasti darba līgumi. Tomēr Agile komandās ir papildus rīki, kur populārākais ir "darba noteikumi" (working agreements) katrai komandai, kas kļūst par sava veida darba aprakstu un līgumu. Ir vēl tādi rīki kā komandas vīzija un misija, "high performance team tree" un citi. Šos Agile komandu dalībnieki novērtē daudz augstāk nekā klasiskos darba līgumus un aprakstus.

Raksti tālākai izziņai:

^ Uz augšu ^

Vai un kā Agile var izmantot darbinieka veikstpējas novērtēšanas procesā?

Ja iet runa par augsta līmeņa Agile, tad tur īsti nav tādas lietas kā veiktspējas novērtēšana, vismaz ne individuālā līmenī. Agile mēs skatamies komandas darbu kopumā un tās piegādāto vērtību, kā arī mēģinam izvairīties no tādu individuālu KPI uzlikšanas, kas ir piesaistīti bonusiem un prēmijām. Agile motivēšanas shēma strādā savadāk, sākot ar visas komandas atgriezenisko saiti par visiem darbiniekiem (360 feedback), beidzot ar stratēģisku mērķu sasniegšanu uzņēmuma līmenī. Protams, lai tur nonāktu, ar kaut ko ir jāsāk. Viena no populārākajām lietām Agile ir tā saucamie pašnovērtēšanas (self-assesment) radari ar fokusu uz izaugsmi un kompetences celšanu, nevis papildus bonusu iegūšanu.

Tai pat laikā, Agile dod iespēju veikt biežākas un ātrākas iterācijas atgriezeniskās saites sniegšanā darbiniekiem. To ne tikai var, bet pētījumi liecina, ka tas ir ļoti nepieciešams. Tradiocionālā pieeja, ka reizi gadā vai pusgadā menedžeris "šauj" ārā visu, kas ir sakrājies, ar domu, ka tam būs pievienotā vērtība attiecību būvēšanā ar darbiniekiem un viņu izaugsmē, ir izgāzusies biežāk kā gribētos. Agile pieeja veiktspējas novērtēšanas un atgriezeniskās saites sniegšanas procesam nozīmē sniegt tulītēju atgriezenisko saiti pie katras notikuma, lai šī saite ir maksimāli atbilstoša, aktuāla un saprotama, un darbinieks nekavējoties var veikt nepieciešamās korekcijas. Bez tam, arī regulāras īsas 1-pret-1 tikšanās līderiem ar darbiniekiem ir vēlama prakse, kas ļauj ātrā un cilvēcīgākā gaisotnē ievākt aktuālu un saistošu informāciju.

Raksti tālākai izziņai:

^ Uz augšu ^

Kā Agile palīdz noteikt projektu(-a) prioritāti attiecībā pret citiem?

Agile kā tāds nepalīdz noteikt prioritāti. Tā ir tikai vērtību sistēma, kas saka, ka mēs vēlamies kopīgi saprast, kur slēpjas vislielākā vērtība un tad to fokusēti sastrādājot piegādāt. Kā noteikti vērtību/prioritāti - tas ir jau katras komandas rokās. Ja runa iet par prioritāšu noteikšanu projekta vai produkta ietvaros, tad Agile praktiķiem ir diezgan līdzīgas rīku lādes. Prioritāšu noteikšanai (t.i. kādā secībā izstrādāt pēc tam, kad jau ir noteikts ko vajag izstrādāt) pieminēšanas vērtas metodes ir MoSCoW prioritāšu noteikšana, Kano modelis, relīžu plānošana ar User Story Mapping, pakalpojumu klases (Class of Services) un citas.

Ja runa iet par projektu prioritāti portfolio līmenī, nevis par prioritāti viena produkta / projekta ietvaros, tad iepriekš minētās metodes šeit īsti nepalīdzēs. Te būtu jāskatās portfolio līmeņa Kanban virzienā, kur visi projekti ir attiecīgi vizualizēti, ir saprotams pie kā jau strādājam, kāds ir atlikums, vai kopējā Kanban sistēma nav pārslogota, un tad jaunam prjektam / produktam tiek piešķirta prioritāte balstoties no lietām, kas jau ir plūsmā un jaunā projekta izdošanas / svarīguma kritērijiem - potenciālais ieguvums, reputācija, izdevumu samazināšana, kvalitātes pacelšana un citiem kritērijiem. Šeit teorētiski var izmantot prioritizāciju pēc pakalpojumu klasēm, bet tas varētu būt diezgan grūti aprēķināms projektu līmenī. Šo parasti organizācijās dara grupa ar cilvēkiem, kas ir ļoti tuvu produkta attīstībai un uzņēmuma stratēģijai. Tas viss kopā saucas - Agile projektu vadība.

Raksti tālākai izziņai:

^ Uz augšu ^

Kā uzrunāt C līmeņa vadītājus, lai izstāstītu par Agile iespējām un ieguvumiem? Caur sāpi, caur skaitļiem?

Vadītājam ir jābūt vajadzībai/vēlmei mainīties. Ja viss ir labi, tad būs grūti ieinteresēt vadītāju par jebkādām pārmaiņām. Ja ir slikti, tad, balstoties uz sāpi (pozīcijas zaudēšana konkurentiem, kvalitātes problēmas, pārāk lēna versiju piegāde tirgū, pārtērēti projektu budžeti un kavēti termiņi, neapmierināti klienti utt.), var vadītājam parādīt piemērus, kā Agile ir risinājis šo sāpi citos uzņēmumos. Ja gadījumā šāda piemēra nav, vai arī trūkst argumentācijas, var piesaistīt speciālistus, kuri pastāstīs iespējas un piemērus no prakses, kā uzlaboties un novērst vai uzlabot esošās problēmas. Šajā brīdī pat nav svarīgi, vai tas ir Agile vai kāda cita pieeja - svarīgi ir piedāvāt citu pieredzi, kur šāda situācija jau ir izlabota. Pašiem bez pieredzes būs grūti pārliecināt vadību. Ja šāda nepieciešamība rodas, sazinieties ar mums.

^ Uz augšu ^

Kādas ir pieejamās Scrum sertifikācijas?

Populārākās organizācijas, kas nodrošina Scrum sertifikāciju ir Scrum.org, ScrumAlliance un ScrumStudy. Visas organizācijas piedāvā sertifikācijas atsevišķi Scrum meistariem, Produkta īpašniekiem un Izstrādes komandas biedriem. 

Scrum.org - Scrum mājvieta, atzītākā un sarežģītākā sertifikācija. Scrum meistariem piedāvā Professional Scrum Master (PSM) trīs līmeņos, Produkta īpašniekiem - PSPO, Izstrādes komandas biedriem – PSD. Šos sertifikātus var kārtot pašmācības ceļā, kā arī apmeklējot jebkuras apmācības, tai skaitā mūsu organizētās

ScrumAlliance - ļoti atzīta organizācija un sertifikācija. Scrum meistariem Certified ScrumMaster trīs līmeņos - CSM, A-CSM un CSP-CSM. Produkta īpašniekiem – CSPO. Izstrādes komandas biedriem - CSD. Sertifikāta iegūšanai ir jāapmeklē speciāli kursi, kurus pasniedz tikai ScrumAlliance sertificēti treneri. 

ScrumStudy – trešā populārākā un vieglākā sertifikācija, kas līdz ar to nav tik atzīta ekspertu vidū kā pirmās divas. Scrum meistariem Scrum Master Certified (SMC), Produkta īpašniekiem – SPOC, Izstrādes komandas biedriem – SDC. Arī priekš šīs sertifikācijas nepieciešams apmeklēt kursus, kurus pasniedz ScrumStudy sertificēts treneris.

^ Uz augšu ^

Kas ir Agile kargo kults?


^ Uz augšu ^

Neatradi atbildi uz savu jautājumu?

Pajautā mums, un mēs pacentīsimies atbildēt!

Gedvillo Consulting
E-pasts:

 .