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.

Agile na Slovensku

Skupina Agile@Slovakia Vás pozýva v septembri 2010 na stretnutie Agile na Slovensku všetkých, ktorí sa zaujímajú o Scrum a Agile.

Predbežný program:

  • krátke predstavenie skupiny Agile@Slovakia
  • Kto som. Čo robím, čo viem. Čo hľadám. (Predstavenie účastníkov)
  • Prednáška
  • Open space + diskusia

Kde: Bratislava, lokalitu upresníme
Kedy:  September 2010
Vstupné: 0 €, strava + nápoje nie sú v cene 🙂

Agilie Brno

V utorok 22.6.2010 sa uskutočnilo stretnutie pod názvom Agilie Brno. Stretnutie ľudí, ktorí implementujú Scrum vo svojom pracovnom prostredí bolo usporiadané s podporou Agilního Konsorcia v Brne po prvýkrát.

Diskusia sa zamerala na praktické problémy zavádzania Scrumu, na používané agilné techniky a aj na story ako prostriedok zápisu požiadaviek.

Malým prekvapením bola aj účasť ďalších Slovákov.

Na koniec len dodajme, že v septembri 2010 chystá Agile@Slovakia podobné stretnutie v Bratislave!

Agile Eastern Europe 2010 is near!

Pridajte sa k skupine Agile@Slovakia a zúčastnite sa skvelej konferencie  Agile Eastern Europe usporiadanej tímom aj u nás známeho Alexeja Krivitského. 

Kyjev, Ukrajina, Október 2010.

Naša skupina získala zľavu na vstupnom. Ak máte záujem kontaktujte founders at agile.sk.

Mimochodom, vo videu sú aj Slováci, ktorí minulý rok cestovali s nami.

Agileee is calling you! from Agile Eastern Europe on Vimeo.

ScrumMaster, alebo prečo to nie je také jednoduché

Na Agileee 2009 som mal tú možnosť sa účastniť diskusie niekoľkých prednášajúcich tejto konferencie. Okrem iných tém sa v jednom momente diskusia viedla o tom, kto to má byť ScrumMaster. Zatiaľ čo niektorí tvrdili, že je to človek, ktorý musí byť zručný pri práci s ľudmi a organizovaní, iní tvrdili, že to môže robiť aj ich 5-ročný syn. Že je to pozícia, ktorá nevyžaduje žiadne špeciálne zručnosti, pretože človek vykonáva len jednoduché veci ako kreslenie grafu alebo varenie kávy pre tím. Verím, že rozlúsknuť tento problém nie je jednoduché, ale aj tak sa pokúsim prispieť k objasneniu.

Máme tu teda dva typy ScrumMastera. Jedného ako silného vodcu, ktorý zvláda prácu s ľuďmi, rozumie agilným metódam a má silné zručnosti v oblasti organizovania práce. Na druhej strane je to niekto, kto vykonáva rutinné práce potrebné na to, aby tím mohol nerušene pracovať. Tieto dva typy predstavujú opačné strany spektra, pričom typy ScrumMasterov v jednotlivých tímoch sa môžu pohybovať v ňom.

Je nutné povedať, že na tím sú kladené požiadavky. Tieto požiadavky môžu byť vnútorné, čo napríklad môže znamenať, že tím musí byť schopný uskutočniť poradu, vyriešiť konflikty alebo navrhnúť riešenie nejakého problému, a tiež vonkajšie, ako napríklad, že musí odovzdávať prehľady o svojej práci alebo musí byť schopný zodpovedať otázky ohľadom plánovania.

Predstavme si teraz na chvíľu absolútne ideálne samoorganizovaný tím. Je to skupina ľudí, ktorá (ako skupina) dokáže tieto požiadavky splniť. Ak treba aby sa uskutočnila porada, tak sa niekto postaví, poradu zvolá a odmoderuje ju. Ak treba vyriešiť problém, tak sa zíde niekoľko ľudí, dajú hlavy dokopy a nájdu najlepšie riešenie. Niekto kreslí graf a niekto pomáha s riešením konfliktov. Takto by mohol vyzerať ideálny svet.

V reálnom svete ale tím nie je schopný splniť všetky tieto požiadavky. Nedokáže napríklad sám zvolať poradu. Dôvody môžu byť rôzne ale faktom je, že v schopnostiach tímu plniť požiadavky môžu byť rôzne medzery. A práve tieto medzery musí zaplniť ScrumMaster. Som presvedčený, že práve preto táto pozícia vznikla. Aby bola schopná zastúpiť tím v akciách, ktorých sám nie je schopný. Je dôležité povedať, že dobrý ScrumMaster by mal vykonávať len veci, ktoré tím nezvláda spraviť sám, čo je jeden z rozdielov medzi vedúcim tímu a ScrumMastrom. K tomu sa ale dostaneme neskôr.

schopnosti.vs.poziadavky

Ak sa teda vrátim k dileme, ktorú som popísal na začiatku, tak jednoznačná odpoveď je, že ScrumMaster by mal mať také schopnosti, ako vyžaduje situácia tímu, teda rozdiel medzi tým, čo sa od tímu požaduje a čo je schopný plniť. Ak je to tím ľudí, ktorý agilné metódy nikdy nepoužívali, tak ScrumMaster musí byť veľmi skúsený a zručný. Naopak v tíme, ktorý už agilne funguje dlhšiu dobu a kde je vysoká samoorganizovanosť, ScrumMaster môže mať len veľmi málo úloh a zodpovedností. Preto neexistuje finálny zoznam povinností ScrumMastera. Tento zoznam by musel byť zostavený pre každý tím zvlášť.

Okrem tohto dôležitého faktu, je tu ešte jedna vec, a to, že ScrumMaster nie je iné meno pre vedúceho tímu. Medzi týmito dvoma rolami je veľký rozdiel. V prvom rade je to pozícia voči tímu. Vedúci tímu je v hierarchii nad tímom. Je to niekto, na koho je možné eskalovať problémy a kto je naopak schopný delegovať prácu. Zároveň väčšinou preberá zodpovednosť za výsledok tímu.

veduci.timu

Úlohou ScrumMastera je ale tímu pomáhať. Preto je jeho pozícia vedľa tímu alebo dokonca pod ním. V žiadnom prípade by nemal preberať zodpovednosť a rozdeľovať prácu by mal len v prípade, ak si ju tím nie je schopný rozdeliť sám (čo na určitom stupni samoorganizovanosti musí byť schopný). Ale čo je najdôležitejšie, zatiaľ čo vedúci tímu má vymedzené povinnosti a práva a tie sa prirodzene nemenia, ScrumMaster by sa mal prispôsobovať tímu (to znamená, nevykonávať činnosti, ktoré je tím schopný vykonať sám) a mal by tím viesť k tomu, aby bol schopný čo najviac plniť požiadavky, ktoré sú na neho kladené.

scrummaster

Práva a povinnosti ScrumMastera sa môžu teda časom meniť a pri správnom smerovaní by sa mali zmenšovať a oslabovať. Táto zmena filozofie roly môže byť najväčšia výzva pri prechode na agilné metódy zo starého systému riadenia, pretože ľudia sa len neradi vzdávajú moci kontrolovať a ovládať.

Na záver už len jedna rada ako preniesť na tím viac kompetencií ScrumMastera: nechať jeho pozíciu rotovať. Za určitého dozoru a prispenia zvonku je možné, aby ScrumMastrom bol každý sprint niekto iný. Toto je veľmi dobrý spôsob, ako dať ľudom pocítiť, že prácu, ktorú doteraz vykonával niekto konkrétny dokáže vykonávať každý. Že na nakreslenie grafu alebo zvolanie porady nie sú potrebné nijaké zvláštne danosti. Časom sa môže stať, že pozícia ScrumMastra natoľko oslabí, že už bude skoro jedno, kto to je. A to bude príznak, že tím ide správnym smerom.

Agilné vzory riadenia I.

Za mojich chlapčenských čias ma vždy fascinovala skladačka Lego. Úžasné na tom bolo, že z jednoduchých kúskov ste mohli postavať čokoľvek. Potrebovali ste len tie správne kúsky a vedieť, čo chcete postaviť. Mohli ste si kúpiť pirátsku loď, postaviť ju, potom ju rozobrať, niektoré kúsky dať nabok a postaviť prístav. Čím menšie tie kúsky boli, tým väčšiu ste mali voľnosť v stavaní.

Keď som sa neskôr počas svojej práce stretol s prvými návrhovými vzormi v objektovo orientovanom programovaní, našiel som v nich opäť rovnaký princíp ako malo Lego. Pomocou jednoduchých prvkov, ako je napríklad dedenie, preťaženie, prekrytie metódy alebo polymorfizmy, je možné vytvoriť veľké množstvo rôzne spolupracujúcich tried, ktoré umožňujú pomerne elegantne riešiť aj zložitejšie problémy.

Príklady takýchto problémov a ich riešení:

Problém: Potrebujem vymieňať niekoľko druhov algoritmov, ktoré realizujú jeden proces počas behu aplikácie na základe určitých stavových premenných.

Riešenie: abstraktná trieda + rozhranie + prekrytie metódy + odvodená trieda x počet rôznych algoritmov = vzor „strategy“

Problém: Potrebujem, aby akcia v systéme bola reprezentovaná objektom (kvôli povoľovaniu, Undo / Redo funkciám a pod.)

Riešenie: rozhranie + agregácie + odkaz na metódu = vzor „command“

Samozrejme použitie vzorov nie je také jednoduché, ako som tu popísal, ale mojím cieľom bolo ukázať, že vzory sú skladačky jednoduchých prvkov, ktoré poskytuje objektovo orientované programovanie za účelom riešenia nejakého konkrétneho problému. Existencia vzorov nie je samozrejme obmedzená len na programovanie, ale dá sa nájsť aj v procese testovania, komunikácií klient-server alebo mimo počítačových vied, napríklad v architektúre alebo medziľudských vzťahoch.

A teraz k agilnému riadeniu. Vezmime si napríklad taký Scrum. Je to metóda, ktorá obsahuje niekoľko agilných praktík (produktový backlog, retrospektíva atď.). Čo sa stane, ak si vypíšem agilné praktiky, ktoré obsahuje, niektoré šktrnem, iné dopíšem a potom to zložím naspäť? No mohol by som dostať Kanban. Scrum s Kanbanom sa totiž prekrývajú v niektorých praktikách, ktoré používajú.

Scrum Na Kanban

A práve to ma viedlo k tomu, že agilná metóda môže byť skladačka. Ako Lego. Môžete jednu metódu rozobrať, niektor súčiastky vymeniť a zložiť inú metódu. Stačí len poznať časti, ktoré máte k dispozícii a vedieť, čo chcete postavíť.

Čo sa týka tých častí, tak nám na začiatok postačí The Big List of Agile Practices od Jurgena Appelo-a (mimochodom, jeho blog www.noop.nl vrele odporúčam). Určite nie je úplný, ale obsahuje aspoň základne veci.

Čo sa týka problému, ktorý má metóda riešiť, tak tu sa vrátime späť k návrhovým vzorom. Ako som písal, tie sú určené na riešenie niektorého konkrétneho problému. Ak mám jasné, o aký problém ide, použijem vzor, ktorý ho rieši. Rovnaký postup by sa dal použiť aj pri výbere metódy riadenia projektu. Stačí si len ujasniť, čo potrebujeme.

Takže napríklad: Máme projekt, kde zákazník bude určite meniť požiadavky, ďalej sa projektu bude účastniť tím, ktorý nie je úplne dobre zabehnutý a na záver projekt nemá veľký rozpočet.

Čo potrebujeme:

  • krátke alebo žiadne sprinty, aby sme vedeli reagovať na požiadavky

  • denné meetingy, aby sme zamedzili chaose v tíme

  • Personas, aby sme neprodukovali niečo, čo nikto nebude používať (t.j. odpad)

Takýmto postupom viem identifikovať agilné praktiky, ktoré v metóde potrebujem, aby som sa vyrovnal s požiadavkami na projekt. Treba si totiž uvedomiť, že praktiky, ktoré sú v metóde obsiahnuté určujú jej vlastnosti. Tieto vlastnosti sú zase vyžadované prostredím, v ktorom sa projekt nachádza (t.j. prístup zákaníka, organizácia a pod.).

Prostredie Projektu

A teda na záver. Ak máme návrhové vzory objektovo orientovaného programovania, ktoré sú na riešenie problémov, môžeme mať aj návrhové vzory agilného riadenia na riešenie projektov. Tak ako pri návrhových vzoroch, by časom mohol niekde vzniknúť zoznam vzorov agilného riadenia, kde by boli vypísané zoznamy agilných praktík, ktoré tento vzor obsahuje a vlastnosti, ktoré daný vzor má.

Praktiky v Jurgenovom zozname môžeme v zásade rozdeliť do dvoch kategórií: procesné a objektové (ceremónie a artefakty). Na to, čo to znamená a aké vlastnosti tieto praktiky prenesú na celú metódu, sa pozrieme v ďalšej časti.

Scrum Norris – SCRUM v podaní legendy :)

Nedávno som narazil na úžasnú zbierku SCRUMáckých Chuck Norrisoviek.. celkom slušný útok na bránicu 🙂
Mať tak v tíme Chucka..

Enjoy 😉

  • Chuck Norris is ScrumMaster and ProductOwner – simultaneously.
  • Chuck Norris can do 6-month sprints.
  • Chuck Norris wears Timeboxershorts.
  • Chuck Norris does not move story cards, he moves the taskboard.
  • Chuck Norris does not estimate, he knows.
  • Chuck Norris pairs alone.
  • Chuck Norris starts project with a Roundhouse-Kickoff.
  • Chuck Norris is allowed to appear late at the stand-up.
  • Chuck Norris sits on the stand-up meeting.
  • Chuck Norris has implemented everything at the planning meeting.
  • Chuck Norris does not estimate user stories, user stories estimate him. (This doesn’t translate well.)
  • Chuck Norris writes the code first, then the test.
  • Chuck Norris is not afraid of bugs, bugs are afraid of him.
  • Chuck Norris does not do Kanban. He does not know limits.
  • Chuck Norris does not pull, he pushes.
  • When Chuck Norris says “done”, then it’s “done”.
  • Chuck Norris does not deploy, he develops on the production environment.
  • Just Chuck Norris knows, that a real burn-down requires napalm.
  • Chuck Norris has no burn-down chart. Around him everything is already burnt down.
  • Chuck Norris answers just two questions on the stand-up meeting. Chuck Norris does not know obstacles.
  • Chuck Norris does not prioritize the backlog.
  • Chuck Norris takes two baby-steps at once.
  • Chuck Norris does not use test-driven development. Chuck Norris always drives.
  • Chuck Norris is the prioritized backlog.
  • Chuck Norris is ScrumMaster without being certified.
  • Chuck Norris does not need acceptance tests. Either Chuck Norris accepts or not.
  • Chuck Norris does not need Iteration Reviews or Reflection Workshops. There is no improvement for Chuck Norris’ process.
  • Chuck Norris’ unit tests pass, before he has written the code.
  • Tests doesn’t fail in front of Chuck Norris
  • Chuck Norris writes the code first, never the test(He doesn’t need to test at all).
  • Chuck Norris always wins at Planning Poker.
  • Chuck Norris can keep silent to small-size efforts.
  • Chuck Norris does not need a reference task.
  • Chuck Norris doesn’t do iterative development, it’s right first time, forever.
  • Chuck Norris does not plan to release. Chuck Norris knows what to do.
  • Chuck Norris has a velocity of 50 000 points.
  • Chuck Norris ends the Product Backlog in each iteration.
  • Chuck Norris sidekicks chickens while eating fresh bacon at the stand-up
  • Chuck Norris developed his own crib in one iteration, right after birth
  • When Chuck Norris walks by, tests don’t run, they die in fear
  • Chuck Norris’ velocity is infinite, he can run around the world and punch himself in the back of the head.
  • Chuck doesn’t meet customer requirements, they meet his!

Agile@Slovakia partnerom konferencie Agile Central Europe

Agile Central Europe Logo

Rád by som Vás pozval na konferenciu Agile Central Europe u našich severných susedov, v Krakowe od 8 do 9  apríla.

Konferencia bude podporená medzinárodnou účasťou skúsených speakrov, ktorí Agile nielen poznajú, ale aj používajú. Program pozostáva z dvoch paralelných trackov a Open Space.

Upozornenie: Naša skupina Agile@Slovakia získala vstupenky s 15% zľavou v prípade, že pojdeme viac ako desiati! Rád Vás týmto chcem pozvať.

Ak máte záujem, pošlite email na founders (at) agile.sk

Stránka konferencie: http://agilece.com
Program: http://agilece.com/program/

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.