Agile Estimation and Planning

978d4fCítiť istotu je určite nepohodlné, ale byť si istý, to je na smiech.“ -čínske príslovie

Agilné metódy pomerne výrazne nabúravajú zažité postupy metód tradičných. Nielen že radia preniesť riadenie a zodpovednosť na ľudí, nepísať dokumentáciu (aspoň nie toľko ako predtým) a nerobiť analýzu (aspoň nie príliš dopredu), ale dokonca hovoria o tom, že dlhodobé a presné plány sú na nič. Odhadovanie a na ňom závislé plánovanie by sa malo robiť nepresne alebo krátkodobo. Odhady by mali tvoriť ľudia a zákazník by mal akceptovať neistotu v tom, čo bude dodané. To sú veci, ktoré sú niekedy (a v niektorých situáciach) len ťažko predstaviteľné. Ak vás zmáhajú pochybnosti ako to má celé fungovať, možno by ste mali siahnuť po knihe Agile Estimation and Planning od Mike Cohna.

Kniha je (prekvapivo) o plánovaní a odhadoch. Neobsahuje prakticky žiadne vysvetľovanie agilných metód, a preto nie je vhodná pre úplného začiatočníka. Kniha nie je len popisom postupov a artefaktov plánovania, ale je tiež značnou mierou obhajoba toho, prečo je tento postup správnejší ako tradičný. Ak teda potrebujete nazbierať argumenty v prospech agilného prístupu, v knihe určite nejaké nájdete.

Čo všetko tam vlastne môžete nájsť? Kniha je rozdelená do šiestich častí: 1. Problém a cieľ; 2. Odhad veľkosti; 3. Plánovanie pre hodnotu; 4. Sledovanie a komunikácia; 5. Prečo agilné metódy fungujú a 6. Prípadová štúdia.

Prvá časť skúma plánovanie ako také. Snaží sa identifikovať princípy a ciele plánovania všeobecne. Ďalej postupne vysvetľuje filozofiu agilného plánovania, porovnáva ho s klasickým plánovaním a poukazuje na rozdiely. Ako napríklad vyzerá dobrý plán? Je to plán, na základe ktorého môže zákazník robiť svoje vlastné rozhodnutia. To v preklade znamená, že robíte plán, ktorý je dostatočne presný, aby sa zákazník napríklad vedel rozhodnúť, kedy začať marketingovú kampaň, ale zároveň v sebe obsahuje dostatok priestoru na prispôsobovanie zmenám v budúcnosti.

Druhá časť sa plne venuje procesu odhadovania. Snaží sa objasniť, čo je to story point a prečo je lepší ako reálny človekodeň alebo ideálny človekodeň. Nájdete v nej tiež rôzne techniky na odhadovanie.

Tretia časť sa už zaoberá praktickým postupom plánovania agilného projektu. Ako zostaviť backlog (a čo to vôbec backlog je), ako naplánovať release a ako iteráciu. Prioritizácia backlogu je téma sama o sebe a je jej venované niekoľko kapitol. Prioritizovať sa dá na základe rizika a hodnoty, alebo na základe ROI či Kanov-ho modelu. Táto kniha je jednou z mála, v ktorej nájdete agilné metódy a seriózne tabuľky s prepočtom investovanej a navrátenej hodnoty. Autor sa tiež venuje téme dobrých User Story, ale o nich už existuje samostatná kniha, ktorá ich rozoberá dopodrobna (moju recenziu na ňu môžete nájsť tu: http://agile.sk/?p=568). V knihe sa dá nájsť aj kapitola o zahrnutí neistoty (teda vytvorenia buffera) pre plán alebo plánovania pre viactímový projekt.

V štvrtej časti nasleduje pasáž o vizualizácii a komunikácii plánov a to hlavne smerom k zákazníkovi. Mike ukazuje rôzne typy grafov pre zobrazovanie aktuálneho stavu releasu a iterácie a vysvetľuje, ako s nimi pracovať a ako odkomunikovať taký parameter, ako je rýchlosť (velocity) tímu.

Piata časť je pomerne krátka a obsahuje v skratke argumenty, prečo agilné plánovanie funguje a šiesta záverečná časť obsahuje prípadovú štúdiu plánovania vývoja softvérového projektu – počítačovej hry. Posledná kapitola je obzvlášť dobrá, ak si všetku tú teóriu z predchádzajúcich kapitol neviete predstaviť v praxi.

Kniha Agile Estimation and Planning podáva vysvetlenia v oblasti, ktorá je pre projekt jedna z kľúčových. Ak už máte predstavu o agilných metódach alebo ich už nejakým spôsobom používate, ale to plánovanie sa akosi stále deje po starom, pretože ten nový spôsob pôsobí príliš exoticky, môže byť táto kniha dobrý sprievodcom ako ďalej. Každopádne to, že sa na približne 300 stranách venuje len tejto téme, je dostatočný priestor na to, aby bola rozpytvaná pre potreby ľubovoľne odborného publika.

Majster v každom z tímu

majster.v.kazom.z.timuAgilné metódy ponúkaju veľa možností ako zrealizovať riadenie tímu a vedenie projektu. Z tejto množiny rôznych ceremónií, artefaktov, postupov a praktík je možné si zvoliť a nasmerovať tak ďalší rozvoj Scrumu v projekte alebo celej firme. Jedna z takýchto praktík je aj rotácia scrummástera. Teda keď je každý sprint (alebo iné obdobie) majstrom scrumu.

Túto praktiku sme asi pred dvoma rokmi zaviedli v našej firme (v tíme s približne 8 ľudmi) a po týchto dvoch rokoch môžem povedať, že to bola jedna z najlepších zmien. Najprv je ale potrebné si vysvetliť, čo to presne (aspoň v našom prípade) znamená. Tím bežal už niekoľko rokov pod vedením vedúceho tímu. Ten zabezpečoval riešenie všetkých problémov, technologický dohľad, aj samotnú realizáciu sprintu. To posledné znamenalo zvolávať a moderovať porady, pripravovať backlog, riešiť akékoľvek problémy, ktoré súviseli s prácou ľudí v rámci Scrumu. Práve činnosti z  tejto kategórie sa ukázali ako vhodné na oddelenie a ich realizácia prešla na samotný tím. Namiesto toho, aby sme však zvolili jedného (toho správneho?) scrummastera, nechali sme ľudí v tíme v tejto pozícii sa striedať. Krok to určite nie je jednoduchý a vyžadol určitú dávku odvahy a podpory vedenia. Odmenov bolo, že to prinieslo ešte viac bonusov ako sa pôvodne očakávalo.

Samotná rotácia prebieha tak, že každý sprint je scrummasterom niekto iný z tímu. Nerobí sa žiadny rozdiel medzi úlohou človeka v tíme, preto tester je rovnako dobrý ako programátor a naopak. Úlohou scrummastera je zvolávať porady (denná, plánovacia, retrospektíva) a moderovať ich (t.j. držať vecnú diskusiu a sledovať čas). Okrem toho, pripravuje tabuľu s úlohami pre sprint a ešte niekoľko drobností, ktoré súvisia so sprintom. A to je vlastne všetko. Je to v podstate rovnejší medzi rovnými. Takto to už funguje 2 roky a prinieslo to niekoľko výhod:

  1. Väčšia zodpovednosť tímu – tým ,že ľudia majú viac pravomoci a riadia si svoju prácu sami, cítia za ňu väčšiu zodpovednosť. Takéto zapojenie do práce je veľmi cenné.
  2. Objavenie prirodzených lídrov – robiť scrummastera nie každému úplne sadne, ale zvládnu to všetci. Veľmi rýchlo sa však ukázalo, kto sa v tej úlohe cíti ako ryba vo vode.
  3. Ľahšie fungovanie tímu – chvíľkový pobyt na pozícii človeka, ktorý ma na starosti hladký priebeh sprintu každému dovolí pochopiť, čo scrummaster potrebuje od ľudí z tímu. Prestali sa objavovať prípady zabudnutia aktualizácie tabuľke, keď každý zistil, ako ťažko sa kreslí graf, ak nemáte aktuálne údaje.
  4. Nové prvky (impluzy) do fungovania tímu – iný scrummaster, iný človek. Rôzni ľudia sú postupne stavaní do pozície človeka, ktorý sa pasuje s (niekedy opakujúcimi sa) chybami. To prinieslo nové nápady a riešenia, ktoré by inak asi ostali skryté.
  5. Lepšie pochopenie Scrumu – lepšie raz vidieť ako 100x počuť a lepšie raz zažiť ako 100x vidieť. Každý sa na chvíľu dostane do kože scrummastera a otestuje si problémy, s ktorými sa pasuje. To viedlo k lepšiemu pochopeniu toho, prečo sa na dennej porade stojí a ako vlastne funguje burn down chart.
  6. Sprinty získali svoj charakter – určité prvky v sprinte si scrummaster môže prispôsobovať podľa seba. Každý sprint tak získava osobitný charakter toho, kto ho vedie. To narúša stereotyp a robí prácu zábavnejšiu.

Rotáciu scrummastera v našom tíme hodnotím jednoznačne ako pozitívnu vec a spätné preklopenie na pôvodný spôsob je v súčastnosti nepravdepodobné. Samozrejme to nie je len tak. Chce to trochu riskovať, chce to správnu firemnú kultúru a chce to aj prípravu – s úplne novým tímom ľudí to spraviť nemôžete (alebo áno?). Každopádne sa takto do tímu prenáša časť zodpovednosti a moci rozhodovať a to môže byť najväčší problém. Pre niekoho, kto je zvyknutý držať opraty riadenia pevne v rukách je predstava, že sa toho vzdá a dokonca, že to budú postupne robiť všetci ľudia v tíme, asi nereálna. Ale to už je len opäť o tom, že je potrebné sa vyrovnať s určitým pocitom neistoty v budúcnosti. Je to rovnaké, ako keď projekt nemá nakreslený gantov diagram s presným popisom na polrok dopredu. Namiesto toho má release plán, ktorý odpovedá na otázky nie presne, ale v intervaloch. Tieto veci sprevádza ten istý pocit neistoty ako pri rotácii scrummastera. Je to niečo, na čo je ťažké ale nevyhnuté si pri agilných metódach zvyknúť. Vieru v to, že všetko sa dá riadiť a určiť dopredu, môže ľahko zbúrať zajtrajšie ráno.

Agilný projekt = Tehly a piesok

Produkty sú pri klasickom projektovom riadení pripravené na začiatku veľmi podrobne. Projektový manažér plánuje projekt od začiatku tak, aby v ňom boli všetky úlohy, často až do najmenších detailov. A aj vrátane “bezpečnostnej vaty 10-15%”. Robí to v dobrej viere, že projekt je naplánovaný, odhadnuteľný a realizovateľný. Detailné plánovanie sa však v praxi zrúti ako domček z kariet v momente keď sa požiadavky zmenia. A to znamená “čoskoro a vždy“.

Agilný projekt má samozrejme tie isté úskalia. No agilita dovoľuje flexibilitu rozsahu požiadaviek, čo by produktový vlastník mal využiť. Využiť aj tým, že backlog bude obsahovať vlastnosti rôznej náročnosti (veľkosti).

Prediktívny aj agilný plán majú tie isté východiská, no agilný projekt je  realizovaný odlišným spôsobom:

  • Agilný projekt má síce dohodnuté dátumy dodania, no obsah dodávky je možné zmeniť. V tradičnom projekte sú väčšinou pevne dohodnuté dátumy, rozsah a často aj rozpočet. To znemožňuje pružne reagovať na zmeny.
  • Plán vždy obsahuje veľké požiadavky, tzv. eposy (v anglickej literatúre sa používa slovo epics). Produktového vlastníka zaujímajú práve eposy vytvárané na základe vízie produktu. Príklad: Správa zákazníkov, Správa produktov, Prehľady.
  • Plán obsahuje niekoľko malých, no konkrétnych požiadaviek, ktoré sa majú dokončiť v jednej alebo dvoch nasledujúcich iteráciách. Nie pre celý plán, len pre niekoľko iterácií! Tieto menšie požiadavky, stories, vznikajú iteratívnym a/alebo inkrementálnym rozdelením eposu. Príklad: Pridanie nového zákazníka, Pridanie kontroly údajov do formulára, Mesačný výkaz účtu

Agilný plán by mal obsahovať  “tehly aj piesok”. Eposy (tehly), ktoré tvoria základ aplikácie a stories (piesok), ktoré tvoria detaily.

Produktový vlastník tak má čas pripravovať eposy dopredu, zatiaľ čo tím má čas konkrétne požiadavky (stories) implementovať a dodávať.

Toto je základ dobrého agilného projektového plánu. Ako ale určíme, ktoré eposy potrebujeme skonkretizovať na stories a kedy?

Čo majú spoločné agilné metódy a kuchynský budík?

pomodoro.techniqueMožno ste už mali tú príležitosť zažiť naozaj funkčný Scrum. Prechádzate sa po miestnosti, kde sedí tím a vidíte, že jeho práca je ako dobre namazaný stroj. Na burndown charte je jasne vidieť, že to ide so sprintom dole z kopca, vývojári komunikujú, zákazník spolupracuje. Proste paráda. A potom si sadnete za svoj stôl a pozriete sa na tú hromadu práce, ktorú vám treba robiť. Dokumenty, ktoré treba spripomienkovať, články, ktoré ste chceli preštudovať a dopísať ten mail, ku ktorému sa neviete prinútiť. Možno si v takú chvíľu pomyslíte, aké by to bolo super, keby ste aj pracovali tak plynulo a efektívne. Aké by to bolo super, keby existoval Scrum pre jedného človeka. No. On možno aj naozaj existuje. Hovoria mu Pomodoro Technique.

Pomodoro je technika, ktorú pravdepodobne vymyslel Francessco Cirillo a jej hlavným účelom bolo udržať vaše sústredenie na to, čo práve robíte. Už to samo o sebe je dostatočný krok vpred, ale technika bola ďalej vylepšovaná, až sa z nej stal systém na riadenie času (time-management). Pomodoro technika má mechanické srdce, ktoré udiera v intervale presne jednej sekundy. Je to totiž kuchynský budík v tvare paradajky, ktorý odmeriava váš čas, počas ktoré sa máte sústrediť. Po 25 minútach si môžete dopriať 5 minútovú prestávku (dôležité je robiť čokoľvek iné, čo nesúvisí s predtým vykonávanou prácou) a potom si dať ďalšie pomodoro. Po štyroch pomodorách máte nárok na polhodinovú prestávku. Ak počas pomodora dokončíte úlohu zo zoznamu, škrtnete ju a ďalšie pomodoro venujete ďalšej položke. Podstatné je, že počas pomodora robíte len jednu vec, pre ktorú bolo pomodoro vyhradené a vyrušenie eliminujete podľa možnosti na čo najmenšiu mieru.

Možno zatiaľ nie je jasné, čo má pomodoro s agilnými metódami. Tak poďme ďalej. Zoznam úloh, ktoré pomocou pomodora máte spracovať (tzv. Today List), si plánujete každé ráno z takzvaného Activity List, kde máte všetky potenciálne úlohy. Čokoľvek, čo vás cez deň vyruší, si zapíšete do jedného z tých zoznamov podľa toho, aké je to súrne. A teraz tá zaujímavejšia časť. Pri plánovaní zoznamu pre daný deň odhadujete koľko pomodor vám daná činnosť zaberie a zo štatistík, ktoré si evidujete, viete koľko pomodor za deň približne stihnete, takže viete čo si pre daný deň máte naplánovať. Na konci každého dňa okrem toho robíte retrospektívu o tom, ako presne sa vám podarilo úlohy odhadnúť, koľko ste toho stihli, koľko ste mali vyrušení a podobne. Ok. A teraz poďme prekladať do reči Scrumu.

Každé ráno si z backlogu vyberiem do releasu úlohy, ktoré by som mal v tento deň stihnúť. Urobím to na základe odhadu, koľko sprintov mi bude trvať vykonanie úlohy a koľko sprintov priemerne stihnem za deň. Následne spustím sériu sprintov. Počas sprintov nemením na čom pracujem. Keď sprint skončí, oddýchnem, prehodnotím, čo by som mal robiť ďalší sprint a spustím ho. Na konci releasu robím retrospektívu, aby som vyhodnotil svoju úspešnosť v odhadoch aj samotnej práci. Rozdiel medzi pomodorom a Scrumom je často krát len v použitom slovníku.

Tie metódy sú si tak podobné, že si viem predstaviť, že pomodoro je metóda, ku ktorej by sa dospelo používaním Scrumu na riadenie práce jedného človeka a jeho postupným prispôsobovaním. Z tejto podobnosti vyplývajú 2 zásadné výhody. Prvá výhoda je, že ak poznáte jednu z týchto dvoch metód, tú druhú pochopíte veľmi rýchlo. Druhá výhoda je, že rôzne techniky, postupy a vylepšenia pre jednu môžu byť aplikovateľné pre druhú.

Myšlienka o tejto podobnosti nie je tak úplne moja. Vysvetlenie pomodora s občasnými odkazmi na Scrum môžete nájsť v knihe Pomodoro Technique Illustrated od Steffana Nöteberga. Je to jedna z kníh o pomodore a podľa môjho názoru jedna z tých lepších. Ak by sa vám dostala do ruky, tak sa neľakajte obrázkov, ktoré vyzerajú, že ich kreslil žiak základnej školy (v skutočnosti to bol autor). Cieľom obrázkov je sprostredkovať ideu (jeden obrázok = jedna idea) a to sa podľa mňa darí. Autor vás postupne prevedie od dôvodov, prečo sa vôbec pomodorom zaoberať, cez jeho princípy, až po rôzne špeciálne vylepšenia a prípady použitia.

Scrum a pomodoro sú len iné obaly pre tie isté princípy. Každopádne nemusí byť pomodoro to jediné, čo sa vie vykľuť zo stretu sveta agilného riadenia a time managementu. Ak máte vlastné skúsenosti s používaním agilných metód na riadenie vlastnej práce, podeľte sa o ne…

Tvoríme produkt agilne

Softvérové produkty tvoríme mnohokrát ako domy. No dá sa to aj inak a lepšie.

Článok bol publikovaný na Zajtra.sk

Story je v Scrume základným prvkom popisujúcim požiadavky. Je to jednoduchý a zrozumiteľný popis o tom kto, čo a prečo danú vlastnosť potrebuje.

Ako ale popísať komplexný systém v takejto jednoduchej forme? Práve táto otázka je často kladená pri prechode na agilný vývoj.

Stavba

Ako staviate dom? Najprv základy, potom prízemie, prvé spochodie, ďalšie poschodia no a nakoniec strecha? Výsledok, teda dom, je odovzdaný ako celok. Až potom ho zákazník začne používať.

Softvérové produkty budujeme často podobne. Po vrstvách. Najprv datábaza.
Potom (celý) dátový model, ktorým presne zmapujeme požiadavky klienta. Potom pridáme vrstvu s obchodným modelom. Potom vrstvu webových služieb no a nakoniec užívateľské rozhranie.

Výsledok je, rovnako ako dom, použiteľný až na konci. Dôsledkom je, že
vznikajú tímy orientované podľa odbornosti. Tímy databázových špecialistov, web dizajnérov, vývojárov služieb a podobne.

Vertikálne?

Softvér sa však dá vytvoriť aj vertikálne. Skúsme vytvoriť iba jednu vlastnosť. Implementujme iba časť databázy popisujúcej danú vlastnosť, potom časť obchodnej logiky, pridajme metódy do webovej služby a sprístupnime užívateľské rozhranie. Vytvorme funkčný blok. Všetko iba pre jednu vlastnosť. Tú dodajme klientovi. Zákazník ju hneď môže začať používať a poskytnúť nám spätnú väzbu.

Až potom pokračujme ďalšou vlastnosťou. Akokeby náš dom bol zostavený z väčších komponent, napr. izieb, ktoré k sebe už iba primontujeme.

Inkrementálne a iteratívne

Takýto inkrementálny vývoj sa dá ešte zlepšiť iteratívnym vývojom. Iteratívny vývoj zdokonalí detaily. Farba na stenách bude v prvej verzii iba biela. Až potom sa rozhodneme pre detaily a pridáme ich. Podobne ako pracuje maliar. Najprv obrys, potom farby, tiene až nakoniec.

Increment vs iterative

Ako nato v softvérovom vývoji? Najprv vytvorte jednoduchý formulár pre zber údajov. No aj s databázovou časťou a webovou službou. Funkčné zadávanie údajov, nielen jednu vrstvu aplikácie. A používateľ môže zadávať údaje bez ohľadu na krásu formulára.

Potom pridajte kontroly. Prispôsobte poradie prvkov lepšej editácii. Zmeňte vzhľad, aby oslovil klienta.

No v tomto momente je to pre klienta už možno zbytočné. Klient totiž potreboval upraviť, zadať, údaje. A to dostal už dávno. Spýtajte sa ho teda ešte predtým, či to skutočne potrebuje.

Záver

Vždy keď píšete novú story na kartičku, vždy si všimnite či na kartičke nie je napísaný technický termín (databáza, webservice, business model a pod.). Ak áno,potom je táto story podozrivá. Pretože pravdepodobne popisuje horizontálnu stavbu domu. Klienta nezaujíma, že ste pridali tabuľku do databázy, ale nemôže ju použiť. Aká je teda hodnota takto implementovanej
vlastnosti?

0

Zamyslite sa teda už na začiatku, pri písaní kartičiek, na výsledok, ktorý je použiteľný. Prinesie vám veľmi skorú spätnú väzbu ešte v čase, keď kód je ešte v hlavách tímu. V čase keď sa dá jednoducho opraviť.

Úlohy alebo aj niečo viac?

Projektový manažment je o ľuďoch, peniazoch a produkte. Tieto tri časti reprezentujú úlohy. Sú ale úlohy postačujúce?

Náš život je riadený úlohami

Aj vy to tak pociťujete? Taká úloha je často definovaná ako odpoveď na otázky:

  • Čo?
  • Kto?
  • Ako?
  • Ako dlho?

Projekty sú tak tvorené množstvom úloh, ktoré navyše navzájom komplikovane súvisia. Navyše úlohy sú vytvárané v projekte veľmi skoro, už počas tvorby projektového plánu kedy nie je celkom jasné čím daný projekt je, kto ho bude riešiť a aký je rozpočet. Skoro nič nie je isté. Poznáte to aj Vy?

Vo firmách, ktoré sú riadené iba úlohami často postrehnete určitý vzor chovania.

Ľudia si ráno typicky otvoria ďalšiu úlohu (v nejakom elektronickom systéme) a keď je dokončia, tak (v lepšom prípade) ju uzavrú a otvoria si ďalšiu. Pracovný život sa tak časom zmení na cyklus OTVOR-VYRIEŠ-UKONČI. Tím zrazu po nejakej dobe nevie odpovedať na otázku PREČO?. Stráca sa tak poznanie produktu, zákazníka a jeho potrieb. Stráca sa tak chápanie prvotných príčin prečo je vlastnosť potrebná, chápanie kontextu riešeného problému. A tieto straty mňa, produktového manažéra, by mali trápiť. Veľmi. Priam bolieť. Tím dokonca nerozumie pre koho vyvíja a ako je to dôležité pre vašu firmu. Ako to zmeniť?

Stories

Prepáčte, že použijem anglický termín, ale zatiaľ som dobrý preklad do slovenčiny nenašiel. ‘Príbeh’ mi v tomto prípade znie čudne.

Story je požiadavka. No, nie tak celkom, ale v podstate sa tak dá chápať.

Požiadavka, ktorá je náročky v agilnom projekte zapísaná inak. Jednoducho a prehľadne. Na kartu, s ktorou sa dá manipulovať. Story je zapísaná v tejto forme:

 

 

Príklad (a môj odkaz pre Zajtra.sk :))

 

Rozdiely voči úlohe? Story jasne popisuje kto, čo a hlavne prečo to potrebuje. Tým, že je popis stručný, je aj požiadavka pomerne presne popísaná a je navyše malá rozsahom. A teda ľahko manažovateľná. Dá sa pomerne ľahko určiť kto je schopný story riešiť a ako dlho bude trvať jej riešenie. Dá sa ľahko implementovať v krátkom časovom intervale a sledovať jej priebeh.

Všimnite si veľmi dôležitú vec. Story nepopisuje AKO problém riešiť. Prečo? Lebo človek, ktorý požiadavku zadáva to nevie. A ani by nemal chcieť vedieť. Nato tu máme lepších expertov, vývojový tím.

Backlog

Bohužiaľ ďalšie anglické slovo. Backlog je utriedeným zoznamom stories.
Na rozdiel od zoznamu úloh je tak backlog popisom produktu, nie činností a aktivít. Tento zoznam nie je len utriedený, ale navyše stories sa líšia v detailoch popisu. Čím dôležitejšie tým presnejšie. Tie najmenej dôležité sú často popísané iba titulkom, napr. Finančná analýza

Backlog je spravovaný produktovým vlastníkom. Iba on určuje dôležitosť, poradie, stories v backlogu. To on pridáva detaily tak, aby najdôležitešie úlohy boli popísané čo najpresnejšie. Tak aby vývojový tím ich vedel implementovať.

Hey dude, where is my backlog?

Kde je backlog v agilnom projekte? No predsa na tabuli! Všimnite si prvý stĺpec s názvom Product backlog. Všimli ste si to keď ste čítali minulý diel o viditeľnosti?

Každá sivá kartička popisuje story. Potrebujete zmeniť prioritu? Presňte kartu vyššie alebo nižšie. Na základe čoho? Na základe obchodnej hodnoty vlastnosti.

Tipy

  • Story by mala byť implementovaná maximálne počas polovice iterácie.
  • Story by mala mať aj akceptačné kritéria. Tie sú malým kontraktom. Zvyčajne zapísané počas plánovacích mítingov spolu so zákazníkom, produktovým vlastníkom a tímom.
  • Nezaoberajte sa odpoveďami na otázku AKO. V Scrume budete mať inú príležitosť kedy sa to spýtať. Nie pri definovaní produktu.
  • Story je buď dokončená alebo nie. Neakceptujte Dokončená na 90%. Už len 2 minúty.
  • Dokončená môže mať rôzny výklad. Dohodnite sa čo znamená HOTOVO.
  • Detaily v popise story pridávajte tak NESKORO ako sa dá. Predpokladajte zmenu. Ušetrite čas, ktorý strávite pri podrobnej špecifikácii požiadavky na vývoj. Aj tak sa požiadavka zmení.
  • A na záver najdôležitejšie. Každú novú požiadavku zapíšte na papierik a roztrhajte ho. Pretože iba 20% vlastností je použitých užívateľmi aplikácií. Ostatné je nepotrebný odpad.

Linky

Článok bol publikovaný na Zajtra.sk

Viditeľnosť v projekte je kľúčová

Sledovanie úloh, ich priradenia a progresu je v klasickom manažmente zväčša úlohou projektového manažéra. V agile/scrume je to ale úloha celého tímu. Prečo? Lebo manažment agilného projektu je založený na spolupráci ľudí (viď Roly).

Kľúčom je viditeľnosť, pretože podporuje dôveru klienta, manažmentu a aj ľudí v tíme samotnom. Koľkokrát ste mali pocit, že robíte podstatne viac ako kolega sediaci vedľa Vás? Je to ale skutočne tak? Projektový manažéri možno majú prehľad, no často táto viditeľnosť chýba na úrovni tímu.

Tabuľa

Zabudnite na Microsoft Project. Viditeľnosť projektu pre všetkých v ňom nie je možná. Použite jednoduchú tabuľu rozdelenú na viacero stĺpcov. Každý stĺpec popisuje stav úlohy.

Obrovskou výhodou je, že Vám stačí len letmý pohľad a okamžite viete stav projektu.

  • Máte viac papierikov na ľavej strane? Pravdepodobne je toho pred Vami ešte veľa.
  • Je veľa papierikov v strede? Máte veľa vecí otvorených. A je ich dokonca viac ako členov tímu? Pravdepodobne by ste si mali prečítať niečo o Getting Things Done (GTD).

Navyše ak takáto tabuľa je v miestnosti, v ktorej je aj tím, tak zmenu, resp. progress, v projekte postrehnete už len periférne keď kolega vstane a presunie papierik.

Distribuovaný tím?

Hmm, pre distribuovaný tím nebude asi jednoduché dosiahnuť takýto vizuálny manažment.

Niektorí sa snažia tabuľu fotiť, potom fotky posielať alebo zdieľať cez wiki do inej lokácie. Výsledok? Nepoužiteľné, pretože vidíte iba rozloženie papierikov, nie detaily. Jediným riešením je dobrá elektronická aplikácia.

Stačí vidieť a byť videný?

Nie, nestačí. Ak by manažment projektu mal byť iba v presúvaní papierikov, tak v podstate nemáte tím.
Základom je komunikácia. Scrum preto odporúča jednoduchú techniku nazývanú denný standup:

  • Tím sa stretne pred tabuľou každý deň v ten istý čas, ktorý vyhovuje všetkým.
  • Každý člen tímu má jednu minútu na zodpovedanie troch otázok. Len jednu minútu nič viac. Čas je najcennejším.
  • Na čom som pracoval včera?
  • Na čom budem pracovať dnes?
  • Aké mám problémy?
  • Potrebujte prebrať viacero detailov? Pokračujte na inej porade a len tí, ktorí majú čo povedať. NIe celý tím.

Zo začiatku vám to bude pripadať ako ďalšia zbytočná porada, ale pri dobrej organizácii je tento míting veľmi efektívnźm spôsobom zdieľania informácii o stave projektu. Najdôležitejšie pre mňa pri tomto spôsobe je, že mnoho informácií vám prejde cez hlavu. Informácie, ktoré sa vynoria v momente keď ich budete potrebovať. Tzv. AHA moment.

Tipy

  • Papierik presúvajte v momente, keď sa mení stav úlohy, nie raz týždenne.
  • Použite rôzne farby pre rôzne typy úloh.
  • Niektoré tímy používajú farbu podľa toho, kto na úlohe pracuje. V agilnom projekte ale chceme mať tím multidisciplínnym, a preto ja osobne to neodporúčam.
  • Indikujte problémy s úlohou vizuálne. Pripnite farebný špendlík, resp. malý červený papierik.
  • Rôzne tvary zlepšia prehľad.
  • Rozdeľte stĺpce na viacero stĺpcov ak váš process je komplikovanejší.
  • Vyhradťte si čas tabule na tzv. parking lot. Parkovisko úloh, ktoré tím nie je schopný samostatne riešiť, resp. nie je zatiaľ jasné čo s úlohou.
  • Tabuľa nie je len pre IT projekty. Obrázok hore zobrazuje úlohy operation tímu.
  • Vytlačte si malé fotky alebo avatarov reprezentujúcich členov tímu. Urobte niečo pre rozveselenie.
  • Používate dovolenkovú aplikáciu? Dajte fotky dovolenkujúcich do samostatnej časti tabule. Jendoduché nie?

Užitočné odkazy

A nakoniec otázka, ktorú by ste sa mali spýtať pred odchodom z práce.

Článok bol publikovaný na http://www.zajtra.sk/zivot/340/manazment-projektu-inak-klucom-je-viditelnost.

Workshop Scrum v reálnom živote, 7.4., Bratislava

Chcete produkovať rýchlejšie a kvalitnejšie ako konkurencia? Komplikujú Vám časté zmeny projektov život?

Scrum, agilný projektový framework, mení spôsob vývoja a dodávania produktov s výrazným zameraním na prispôsobenie sa meniacim sa požiadavkám zákazníka, skrátenie cyklu vývoja, zlepšenie tímov a zvýšenie kvality.

Registrovať

Workshop Scrum prakticky umožní Vašim tímom pochopiť základy frameworku, roly a ich zodpovednosti, agilné postupy pri vývoji a agilné metriky. Naučíte sa ako pracovať s množstvom požiadaviek a ako odhadnúť agilný projekt.

Scrum spoznáte praktickými príkladmi a hrami, ktoré budete môcť aplikovať aj vo svojich tímoch. Táto forma je overená stovkami účastníkov v minulých rokoch.

Prečo?

  • Pochopíte Scrum, roly a ceremónie. Dozviete sa o agilných princípoch a iných metódach.
  • Aplikujete Scrum prakticky počas workshopu.
  • Naučiť sa plánovať s prispôsobením sa častým zmenám.
  • Spoznáte spôsoby prioritizácie požiadaviek Vašich zákazníkov podľa obchodnej hodnoty.
  • Porozumiete ako je potrebné zmeniť myslenie pre zrýchlenie vývoja.
  • Naučíte sa praktické hry a príklady, ktoré pomôžu Vašim tímom pri adaptácii agile.

Pre koho?

  • Senior manažment – ak uvažujete o transformáci Vašej spoločnosti
  • Produktový manažment –  ak potrebujete pracovať s množstvom požiadaviek a chcete dodávať kvalitné produkty načas.
  • Projektový manažment – ak chcete riešiť dilemu trojúholníka rozpočet , rozsah a čas.
  • Vývojári, testeri a iné roly v tíme

Zažite Scrum prakticky!

Agilná transformácia formou hry

Keď pred pár týždňami nás kontaktoval Zsolt Zsuffa z Budapešte ohľadom participácie na Agile Meetupe, ponúkli sme rôzne témy krátkeho školenia. S prekvapením sa však Zsolt priamo spýtal na agilné hry. Zaujali ho naše skúsenosti a výsledky a tak chcel skúsiť touto formou stmeliť aj agilnú komunitu v Maďarsku. Pre nás to bola možnosť konečne po prezentáciách urobiť aj niečo praktické, čo ľudia budú môcť vyskúšať aj vo vlastných firmách.

Prechod na agilné technológie je  v dnešnej dobe aktuálnym v mnohých spoločnostiach. Spoločnosti sú zväčša zamerané len na výsledky, ktoré sa dajú merať. V mnohých prípadoch však chýba niečo oveľa dôležitejšie, čo agile priam vyžaduje – zmena myslenia. Táto zmena vyžaduje čas a skúsenosti. Nedá sa naučiť, musí sa zažiť. Je to dospievanie. V takomto prípade je zlyhanie dokonca cennou skúsenosťou, ktorú chceme zažiť často a skoro, hlavne ak ste na začiatku transformácie.

Agilné hry sa stávajú (podobne ako v živote dieťaťa) katalyzátorom vývoja a stávajú sa tak lepidlom ktoré prepája teóriu s praxou. Sú možnosťou ako sa naučiť robiť agile na príkladoch. S pomocou kouča takto tímy nemôžu zlyhať pri učení ako agile robiť.

Hry hrajeme počas tréningov na Slovensku aj v zahraničí už niekoľko rokov. V Budapešti sme sa zamerali na hry vybrané pre transformáciu spoločností na agile:

  • vytvorenie tímu a jeho samoorganizácia
  • pochopenie problémov a zvyraznenie ich podobnosti v celom softvérovom priemysle
  • identifikácia dôvodov prečo agile vzniklo
  • naučenie sa ako robiť agile, ako pracovať v časových iteráciách, ako samoorganizovať nielen tím, ale aj prácu, prečo je jednoduché zadanie požiadavky často efektívnejšie než dlhé dokumenty
  • ako sa zlepšiť použitím retrospektívy

Originál viď ScrumDesk: Serious Play – accelerate your transition to Agile