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.