Aj tento rok by sme Vás radi pozvali zúčastniť sa skvelej akcie Agile Eastern Europe 2010 o Agile, Scrum, Lean atď.
Skvelý program
35 rečníkov z 18 krajín, 2 dni, 4 pódiá, 40 prezentácií
Master Classes (CSM, CSPO, Lean, Design) vedené hlavnými rečníkmi!
Web: http://agileee.org
Kedy: 8-9 októbra 2010
Kde: Kyjev, Ukrajina
Zaregistrovaním sa získate vstupenky so zľavou,výšku ktorej momentálne dohadujeme s organizátormi Agile Eastern Europe.
Po dlhej dobe sa mi konečne podarilo dokončiť slovenský preklad knihy Henrika Kniberga “Scrum a XP zo zákopov” (pôvodne Scrum and XP from Trenches).
Ďakujem Tiborovi Radačovskému za pomoc s prekladom obrázkov.
Kniha je dostupná na InfoQ.com
Kanban je ďalší nástroj v skupine agilných metód, kde sa nachádza aj Scrum. Je kompatibilný s agilným manifestom a nepopiera agilné princípy. Oproti Scrumu je však menej reštriktívny a je založený na veľmi jednoduchej myšlienke:
Nedokončená práca (Work-in-progress alebo WIP) by mala mať svoje obmedzenie a nová práca sa môže začať len vtedy, keď sa iná práca dokončí (alebo posunie do iného stavu).
Kanban (v japončine “signalizačná tabuľka”) predpokladá, že vznikne vizuálny signál o tom, že sa môže rozpracovať novú úloha, pretože aktuálne množstvo rozrobenej práce ešte nedosiahlo svoj limit.
(c) Henrik Kniberg & Mattias Skarin: Kanban and Scrum – Making the most of both (InfoQ 2010)
Znie to zaujímavo ? Na prvý pohľad možno nie, možno je to malá, nenápadná myšlienka, ale môže zmeniť všetko v doterajšom procese! Kanban totižto nie je proces ani metodika, je to spôsob ako zaviesť zmenové riadenie (change management) do existujúceho životného cyklu softvérového vývoja. Bol vytvorený ako časť Lean iniciatívy s cieľom transformovať firemnú kultúru na nepretržité zlepšovanie (Continuous Improvement).
Princíp Kanbanu – začať s tým, čo robíme teraz. Pochopíme proces zobrazením dôležitých tokov a nastavíme limity na každý stav tohto procesu. Potom začneme pracovať s tokom úloh v systéme tým, že ich vyberáme len vtedy, keď je vygenerovaný Kanban signál. Toto spôsobí, že sa v niektorých stavoch začnú úlohy blokovať a upchávať systém. To je to, čo sme chceli – tím v čo najkratšom čase odstráni problém a obnoví tak tok úloh. Pochopením príčin, upravovaním limitov WIP prípadne zmenou stavov procesov sa celý tok stáva priechodným.
Kanban takto vďaka transparencii zviditeľňuje úzke hrdlá, fronty, nestálosti a zbytočnosti – toto všetko má vplyv na výkonnosť z pohľadu množstva užitočnej práce a doby cyklu (začaté – odovzdané). Prehľadnosť sa dá ľahko zabezpečiť tým, že sa použije tabuľa/stena s lístočkami. Lístoček (Post-it) je ten vizuálny signál, ktorý som spomenul na začiatku.
Pravidlá sú iba dve:
Ešte spomeniem stručné podobnosti Kanbanu so Scrumom:
Odlišnosti Kanbanu od Scrumu:
Myslím, že stojí za to sa nad Kanbanom zamyslieť a zvážiť jeho výhody a prípadné dôsledky. Má menej obmedzení ako Scrum, takže jeho akceptácia v tíme môže byť jednoduchšia, navyše kto má skúsenosti so Scrumom a narazil na niektoré jeho obmedzenia, je možno toto ten správny impulz, že je čas sa posunúť zase o kúsok ďalej.
Autor: Tibor Šipocz, Mária Dobešová
Vo svojej práci sa stretávame s niekoľkými princípmi ako by manažéri mali viesť svojich ľudí v práci, v projektoch. Tréneri mäkkých manažérskych zručností zdôrazňujú a na tréningoch nacvičujú manažérov, aby používali taký prístup k ľuďom, ktorý je motivujúci zvnútra, rozvíja pracovníka a napĺňa potreby jeho i potreby klientov. Veľká väčšina týchto princípov je inherentne obsiahnutá v agilných metódach riadenia projektu, v SCRUM osobitne.
Takže sme sa mi „kauči“ zhodli, že silné motivujúce prvky sú:
Prvky, ktoré podporujú osobný rozvoj každého člena tímu a rozvoj tímu ako celku:
Spolupráca s klientom v agilných metódach umožňuje lepšie napĺňať potreby klienta:
Tieto prednosti agilných metód (SCRUMu) nie sú vždy využité v plnej šírke. Počas konferencie ScrumImpulz 2010 i následnom Bootcampe sme videli ako sú tieto nesporné výhody uvedomene využívané, avšak i nedocenené resp. nevhodne interpretované alebo nepochopené. Je to nevyužitá príležitosť pracovať v projektoch úspešnejšie. Je na to potrebná zručnosť pri vedení ľudí, ktorá sa dá nadobudnúť iba praxou a cieleným tréningom. V tom môžeme projektovým tímom pomôcť my – tréneri, kauči.
Niektoré prvky, ktoré sú motivačné v SCRUM bežne učíme používať napr. v tréningovom module Motivácia a hodnotenie, ktorý sa zaoberá motivovaní ľudí všeobecne. Patria tam teórie motivácie – expectancy theory i teória stanovovania cieľov, dôsledky pravidelnej spätnej väzby a hodnotiacich rozhovorov. Budovanie tímu a tímová práca sa zase detailne venuje tomu ako zostaviť projektový tím a cielene ho viesť k vysokej výkonnosti. Leadership čiže Vedenie ľudí vo všeobecnosti, či Projektový manažment – v zmysle – vedenie ľudí v projektoch cielene rozvíja zručnosti koordinátora. ScrumMaster by určite mal rozvíjať svoje facilitačné zručnosti v tréningu nazvanom Vedenie porád alebo Moderovanie, či Kreatívne techniky riešenia problémov.
Celkove sa dá stimulovať všestranný rozvoj zainteresovaných strán v SCRUM projekte. Najviac by mohol pomôcť výcvik v používaní koučovacích techník v tréningu Koučovanie.
Pri jednaní s Product Ownerom zase môžu pomôcť tréningy z názvom Obchodné vyjednávanie či Ovplyvňovanie a argumentácia. Vzťah tímu a najmä ScrumMastera ku klientovi je v podstate konzultačný – pomohli by Konzultačné zručnosti.
Z nášho pohľadu najdôležitejšie zložky, ktoré treba podporovať sú:
Možno by stálo za to spoločne pripraviť program na rozvoj soft skills v SCRUMe. V tomto ohľade bol pre nás ScrumImpulz 2010 rozhodne inšpirujúci.
ScrumMaster je jeden z najdôležitejšách prvkov Scrumu, ak chceme byť úspešní.
Prvý kľúčový bod a zároveň najčastejšie nepochopenie tejto role – ScrumMaster nie je manažér Tímu, neriadi ho. Vyplýva to už z názvu tejto role – “ten kto ovláda Scrum”. ScrumMaster teda Tím podporuje, slúži mu, ochraňuje ho pred vonkajšími vplyvmi a usmerňuje ho, aby bol Scrum pochopený a správne aplikovaný. Prechod na agilné princípy nie je jednoduchý, od samého začiatku zviditeľňuje skryté prekážky v organizácii – práve počas týchto náročných zmien je potrebná úloha ScrumMastera.
Rola ScrumMastera teda zahŕňa následovné zodpovednosti:
Zo začiatku sa na túto rolu odporúča priradiť osobu na plný úväzok. Členovia Tímu sa ešte len zoznamujú so Scrumom v ich každodennom živote, manažment hľadá možnosti, ako zasahovať do iterácií, vývojové prostredie a testovacie nástroje nie sú pripravené na agilné procesy… toto všetko predpovedá, že ScrumMaster bude mať plné ruky práce. Neskôr, ako sa Scrum a agilné myšlienky stávajú samozrejmosťou, nástroje sú automatizované a XP praktiky sa plnohodnotne využívajú, význam dedikovaného ScrumMastera klesá a jeho kapacita sa môže postupne presúvať na členov Tímu, napríklad rotovaním tejto role.
Koho do role ScrumMastera dosadiť ? V prvom rade takú osobu, ktorá už má skúsenosti s agilnými princípmi a vývojom, je do Scrumu zaškolená a verí v agilné princípy. Tieto predpoklady netreba podceniť, medzi agilnými projektami a chaosom je relatívne tenká línia, takže neskúsený ScrumMaster môže narobiť viac škody ako úžitku. Je to teda ten, kto vie o Scrume najviac a je ochotný a schopný tieto vedomosti šíriť ďalej a presadzovať ich nielen v Tíme ale aj v celej organizácii. Je tiež užitočné, ak má ScrumMaster zároveň praktické znalosti z projektového manažmentu, dizajnu, kódovania a testovania, takže sa ľahko stotožní so vznikajúcimi problémami a vie ich promptne riešiť. Ak však bol ScrumMaster pred prechodom na Scrum vedúcim tímu / projektovým manažérom, jeho zmena myslenia môže byť veľmi ťažká – musí v sebe potlačiť tendenciu prikazovať členom čo a ako robiť, plánovať, rozhodovať za nich o riešeniach alebo prideľovať konkrétne úlohy. Samoriadenie Tímu ako nástroj na zvýšenie efektivity potom nezafunguje.
Ako už bolo spomenuté, časom sa môže rola ScrumMastera obsadiť členom Tímu. Neplatí to však v prípade kombinácie ScrumMaster-Product Owner. Tieto roly sú často vo vzájomnom rozpore a človek na dvoch takýchto stoličkách má ťažké sa rozhodnúť, koho rolu má v ktorej situácii hrať. Napríklad Product Owner je pod tlakom priorít v požiadavkách a ak v sebe potlačí zodpovednosť ScrumMastera, tak môže urobiť takú zasadnú chybu ako meniť Tímu úlohy počas Sprintu. Bez druhej osoby mu chýba jasný protiklad, ktorý by ho upozorňoval na potencionálne chyby a riziká a nasadenie Scrumu by sa minulo účinkom.
Mnoho z ľudí sa ma počas ScrumImpulz-u pýtalo za čo je vlastne zodpovedný v Scrum-e produktový vlastník. Z Vašich odpovedí som zistil, že je pokladaný za synonymum inej riadiacej roly (napr. produktový manažér,…). Táto rola však pokrýva podstatne viac činností.
Produktový vlastník musí mať jasnú víziu o produkte, ktorý tím má dodať. Je to práve on, kto dodáva impulzy do dennodenného rytmu vývoja. Ak chýba špecifikácia toho, čo sa má vyvíjať, tím bude stáť a časom začne byť frustrovaný.
Z hľadiska marketingu produktu by sa mal starať o:
Produktový vlastník definuje architektúru produktu. Nie architektúru v zmysle architektúry komponent, vzťahov medzi nimi, ale:
Zároveň ale má byť v kontakte s vývojovým tímom a má byť k dispozícii tak, by tím mal dostatok informácií pre implementáciu. Produtkový vlastník musí byť k dispozícii počas plánovania produktu (product planning meeting, sprint planning meeting) a počas predvádzania produktu, kedy by mal jednoznačne akceptovať alebo neakceptovať implementáciu dokončenú počas iterácie.
Scrum neprináša do procesu vývoja produktu množstvo rolí ako iné metodiky. Cieľom je vytvoriť prostredie, v ktorom sa rozvíja spolupráca a zdieľanie znalostí.
Člen tímu pracujúceho pomocou Scrumu má oveľa viac príležítostí (samozrejme ak chce) pracovať nielen v oblasti danej metodikou a pracovnou zmluvou. A to nielen zameraním – vývojár, dizajnér alebo architekt, ale aj technológiami a časťami samotného produktu.
Tímy v Scrume by mali byť multidisciplinárne. Teda postavené zo všetkých profesií tak, aby tím bol schopný dodať výsledok bez zbytočného meškania. Táto možnosť absorbovať znalosti v celom tíme je kľúčovou motiváciou ľudí. Rôzne profesie prinášajú iné uhly pohľadu na rovnaký produkt. Tester tak môže poskytnúť cenné informácie ešte pred dokončením produktu. Vývojár môže zas testerovi poskytnúť viac detailov o implementácii produktu a spoluparticipovať tak na príprave testov
V takomto prostredí juniori rýchlo a prirodzene “nasávajú” od seniorov vedomosti. Naopak seniori sa môžu vďaka juniorom, nezaťažených rokmi “osvedčených” postupov, skonfrontovať svoje myslenie a znalosti s často modernejšími technológiami, ktoré práve juniori dokážu priniesť.
A podľa mňa najväčšia výhoda takéhoto tímu je zdieľanie znalostí o produkte, o vzťahoch medzi ľuďmi nehovoriac…
Túto otázku sa často pýtam najmä ľudí pracujúcich v manažmente spoločností. A odpoveď na Slovensku je vo veľkej väčšine nie. Je zvykom používať pre riadenie projektov osvedčené metódy. Len málokedy sú však osvedčené aj výsledkami projektu.
Na druhej strane stoja agilné metódy, ktoré už dnes nie sú novinkou. Jednou z agilných techník je Scrum.
Scrum je agilným frameworkom, ale nie metodikou. Teda sadou postupov, ktoré sa majú prispôsobiť konkrétnej spoločnosti. Je založený na úzkej kooperácii medzi zákazníkom a vývojovým tímom.
Ak by som mal Scrum popísať jednou vetou, znela by asi takto:
Hodnota je vytvorená počas iterácie celým tímom podľa priority a vôle zákazníka
Hodnotu prináša výsledok, ktorý je skutočne dokončený a otestovaný, ktorý sa dá okamžite používať. Nie diagram, nie dokument. Keďže vývoj trvá kratší interval ako je bežné v iných postupoch, takýto skorý výsledok prináša výhodu rýchleho získania spätnej väzby od klienta. Následne sa implementácia môže ľahko prispôsobiť požadovaným zmenám ešte v čase, kedy sa produkt tvorí.
Iterácia určuje obdobie, v ktorom má tím priestor pre svoju prácu. Iterácia v Scrume trvá zvyčajne 2-4 týždne.
Každá začína plánovaním práce, ktorá má byť v rámci iterácie urobená, a končí sa prezentáciou výsledkov. V úvode iterácie by mal zákazník odprezentovať tímu čo potrebuje, ako si predstavuje výsledok a poskytnúť potrebné vysvetlenia. Na konci tím musí urobiť prezentáciu výsledku.
Počas nej by sa zadanie nemalo meniť, čím sa vytvorí priestor pre tím a pre samotnú realizáciu bez vyrušenia. Zároveň tím je oboznámený s progresom implementácie a v prípade problémov okamžite reaguje. Pre iteráciu sa v Scrume používa pojem sprint.
Celý tím v Scrume znamená zákazníka, analytika, dizajnéra, programátora, testera a ďalších. Zameranie vývoja na vlastnosti poskytuje priestor pre spoluprácu všetkých tzpických rolí. Zatiaľčo jedna vlastnosť môže byť analyzovaná, ďalšia sa už môže testovať. Takéto kolektívne spracovanie vlastností vedie k všeobecnej znalosti implementácie produktu v rovnakom čase.
Tím je v tom istom čase obohatený intenzívnou komunikáciou a spoluprácou, ktorá je jednoznačným prínosom z dlhodobého hľadiska.
Zákazník je v Scrume kľúčový element riadiaci postupnosť vývoja vlastností a akceptujúci výsledky. Rozhoduje aj o tom, či sa bude vo vývoji pokračovať nasledujúcou iteráciou.
Takéto zahrnutie zákazníka do vývoja je inovatívnym prvkom agilných postupov. V praci však často zistíme, že zákazník ani nechce byť integrovaný do vývoja. Pozor, v tomto prípade sa nepriamo vytvára možnosť, že tím nebude realizovať to čo potrebuje. Pre rozpoznanie potrieb je preto dobré ustanoviť rolu produktový vlastník, ktorý zákazníka a užívateľov zastúpi. Bude zodpovedný za stanovenie, popis a priority jednotlivých vlastností.