Agile Eastern Europe 2010

null

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.

Kanban – ďalší nástroj agilných projektov

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.

Kanban schéma

(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:

  1. vizualizuj svoj pracovný tok
  2. limituj svoj WIP

Ešte spomeniem stručné podobnosti Kanbanu so Scrumom:

  • sú Lean a Agile
  • používajú plánovanie vyberaním úloh
  • obmedzujú WIP
  • používajú prehľadnosť na riadenie procesu zlepšovania
  • sústreďujú sa na vytvorenie potencionálne dodateľného produktu rýcho a často
  • stavajú na samoriadenie sa tímu
  • požadujú rozdelenie práce na menšie časti
  • release plán je priebežne upravovaný na základe empirických dát (velocity/lead time)

Odlišnosti Kanbanu od Scrumu:

  • časovo obmedzené iterácie (Sprint) sú voliteľné, nie povinné
  • záväzok tímu je voliteľný, nie povinný
  • používa Lead Time ako metriku na plánovanie a vylepšenie procesu, nie Velocity
  • všestranný tím je voliteľný, špecializované tímy/jednotlivci su povolené
  • roly nie sú preddefinované
  • veľkosť úloh môže byť ľubovolný
  • burndown grafy nie sú povinné
  • WIP obmedzuje priamo, Scrum nepriamo
  • odhady sú voliteľné
  • nové úlohy sa môžu pridávať do zoznamu hocikedy, ak to dovoľuje WIP limit
  • Kanban tabuľa nie je špecifická pre jeden tím, môže ju zdieľať viacero tímov alebo jednotlivcov
  • Kanban tabuľa pretrváva a neruší sa po každej iterácii
  • prioritizácia nie je povinná ale voliteľná

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.

Soft – Skills v SCRUM (Inšpirácie ScrumImpulz 2010)

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ú:

  • spoluúčasť na stanovovaní cieľov a rozhodovaní a riešení problémov (daily meetings, výber taskov,..)
  • spoločne dohodnuté pravidlá a kritéria posudzovania (odmeny, benefity resp. tresty za výkon)
  • spolupráca členov tímu od samého začiatku projektu (krátke šprinty to vynútia na rozdiel od tradičných postupov)
  • preberanie zodpovednosti za svoj podiel práce i za celý tím (šprint musí byť ukončený, merateľný výsledok, user story)
  • časté odovzdávanie medzivýsledkov – čiastočné úspechy povzbudzujú (odovzdaný funkčný blok, release)
  • okamžitá spätná väzba a podpora od ostatných členov tímu i od klienta (daily meetings)
  • intenzívna komunikácia a tímová spolupráca – tímový duch (spoločné sedenie, časté i neformálne stretnutia…)

 Prvky, ktoré podporujú osobný rozvoj každého člena tímu a rozvoj tímu ako celku:

  • zdieľanie know-how počas celého projektu – napr. práca v pároch, tímové stretnutia, spoločná databáza metód, techník
  • informovanosť o celkovom dianí na projekte – problémy a ich riešenia na každodennej báze
  • cielené vzdelávanie a koučovanie ostatnými členmi tímu – semináre, telekonferencie, zaúčanie nových členov tímu
  • učenie sa z chýb po každom cykle – chyby sú povolené, je priestor na to, aby sa napravili
  • možnosť individuálneho výberu takých úloh, ktoré sú „výzva“ – nové veci zo zoznamu taskov
  • zohľadnenie individuálnych preferencií – podpora zvoleného spôsobu učenia, priestor pre kreativitu a zmeny
  • zvyšovanie sebadisciplíny jednotlivcov – prácu je potrebné ukončovať v krátkych intervaloch (na ilustráciu tohto vieme nakresliť pekný obrázok)
  • príležitosť na rozvoj zručností vedenia ľudí, projektu – napr. striedanie v roli scrummastera
  • tím sa rozvíja spoločne, rastie úroveň spolupráce – napr. prostredníctvom retrospektívnych stretnutí

Spolupráca s klientom v agilných metódach umožňuje lepšie napĺňať potreby klienta:

  • rola product ownera zaručuje priebežné sledovanie priorít – potreby klienta sú jasne komunikované a rozsah práce je predmetom vyjednávania
  • jednotlivci i tím má istotu, že nerobí zbytočné veci a smeruje k cieľu, ktorý naplní ich potreby

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ú:

  • Základné manažérske zručnosti pre všetkých ( rozhodovanie, plánovanie…)
  • Partnerstvo od začiatku projektu (vízia, misia, hodnoty, ciele, stotožnenie)
  • Budovanie tímu a špeciálne zručnosti koordinátora a vyzývateľa pre scrum mastra
  • Dávať a prijímať spätnú väzbu priebežne i po skončení projektu
  • Všímať si a oslavovať úspech (hodnotenie, oceňovanie, motivácia)
  • Práca s chybami (motivácia, risk taking, rozdiely medzi ľuďmi)
  • Metódy riešenia problémov, skupinové kreatívne techniky
  • Learning lessons (rozprávať o problémoch, ktoré sme vyriešili)
  • Zručnosti kouča (každý koučuje každého, skupinový koučing)
  • Zručnosti Project ownera (vyjadrovanie sa, priority, motivácia, počúvanie,…).

 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.

Rola: ScrumMaster

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:

  • ochraňuje Tím pred vonkajšími vplyvmi, ktoré by mohli jeho prácu narúšať
  • odstraňuje každodenné prekážky, ktoré by mohli znížiť efektivitu práce Tímu
  • koučuje Tím, Product Ownera a celkovo organizáciu, aby dodržiavali pravidlá Scrumu a integrovali agilné praktiky, sledujúc pritom cieľ – úspešné a efektívne nasadenie Scrumu
  • koučuje Tím, aby správne nasadil a používal vhodné XP praktiky
  • koučuje Product Ownera, aby pracoval efektívne s Product Backlogom, s požiadavkami na produkt, aby maximalizoval návratnosť investícií
  • podporuje dosiahnutie zhody medzi očakávaniami Product Ownera a prísľubom Tímu – mediátor v ich komunikácii
  • organizuje a pomáha viesť porady predpísané Scrumom

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.

Rola: Product Owner

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í.

image

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:

  • Obchodné ciele a stratégiu produktu – produktový vlastník definuje, kto sú cieľoví užívatelia produktu a definuje priestor, v ktorom je možné urobiť produkt úspešným
  • Obchodné prípady – mal by mať prehľad o všetkých zákazníkoch a zároveň by mal s nimi udržiavať komunikáciu tak, aby ich názory a požiadavky boli zachytené, prioritizované a nakoniec aj realizované.

Produktový vlastník definuje architektúru produktu. Nie architektúru v zmysle architektúry komponent, vzťahov medzi nimi, ale:

  • čo bude v produkte implementované – požiadavky. Požiadavky musí produktový vlastník prioritizovať tak, aby dosiahol čo najlepšiu predajnosť. Pravidelne udržiavané požiadavky umožňujú tímu pokračovať ďalej ak dokončil plánovanú činnosť a má momentálne čas.
  • Mal by definovať ako systém bude vyzerať, kde bude používaný, kým a v akom vzťahu bude k okolitým systémom
  • mal by byť zodpovedný za zdroje potrebné pre vývoj systému, či už finančné, materiálne alebo aj za tvorbu a stavbu tímov.
  • sledovanie progresu projektu mu zjednoduší plánovanie releasov, komunikáciu so zákazníkmi a umožní mu pripraviť zákazníkov na novú verziu dopredu – či už organizačne alebo udržaním “napätia”. Sledovanie priebehu projektu zároveň umožňuje priebežne meniť priority podľa možností tímov, potrieb zákazníkov a aktuálneho stavu produktu.

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.

tímy v Scrume

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…

Prezentácie zo ScrumImpulz 2010

Alexey Krivitsky     – Things to unlearn in software development

View more presentations from krivitsky.

Dušan Kocúrek – Efektívny tím

Michal Vallo – Zavádzanie Agilného riadenia

Eva Kišoňová – Agilné postupy Siemens Softwarehouse

View more documents from Dusan Kocurek.

Peter Špireng     – Scrum v slovenskej spoločnosti

Poznáte Scrum?

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

Hodnota

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

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

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.

Priorita a vôľa zákazníka

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í.