Tag Archives: SCRUM

Daily stand-up dobre VI. – odpáľ to bez prípravy

Posted on by

V kanceláriách agilných IT firiem nastáva o 9:00 zvláštna vec. Informatici, o ktorých si väčšina ľudí myslí,  že sú svojim spôsobom zvláštni a nekomunikatívni, sa postavia do kruhu a začnú sa rozprávať.

Niektorí členovia tímu sa iba postavia a ‘odpália to’ priamo z hlavy. V takých prípadoch dosť často počuť tzv. “óóóhmovinu”: “Ohhhm, včera som robil, ohhhhm, dnes budem robiť, ohhhhm,….”.

Stretnutie sa takto zbytočne predĺži, óóóhmovina odváza pozornosť a znižuje koncentráciu. Ako sa teda mám ja, člen tímu, pripraviť na denné stretnutie?

Ako sa pripraviť na stand-up

ready steady go

Najčastejšie aplikovaným pravidlom je aktualizácia úloh pred stand-upom.

No ešte lepšie je mať ich aktuálne kedykoľvek. V podstate keď sa pozriete na kanban tabuľu, tak uvidíte kto na čom presne pracuje. Stav výrobnej linky.

Samozrejme, že padnú argumenty proti tejto aktuálnosti: “To mám posúvať kartyvždy po pár minútach? Prečo taká byrokracia?”. Nie, nemusíte. Nikto vás nenúti.

Zvážte ale argumenty prečo áno:

  • Lepšia samoorganizácia tímu. Viem, ktoré karty si môžem vziať a začať na nich okamžite pracovať. Bez obáv, že už na nej niekto pracuje a budeme tak zybtočne robiť na tej istej úlohe viacerí.
  • Lepšia sebaorganizácia. Princípy Getting Things Done  učia, že kľúčom k sebaorganizácii v dnešnom svete plnom úloh, je dať ich všetky preč z hlavy. Či už na papier alebo lepšie na tabuľu. Odbremeňte hlavy od úloh a vytvorte si tak priestor pre kreativitu, ktorá vás určite baví viac.
  • Vysielač problémov. Ak mám problémy s úlohou, tak ich okamžitá indikácia na karte (komentár alebo grafická značka) umožní rýchlejšie naštartovať ich riešenie. Nie až ráno po standupe.
  • Rýchlejšia akceptácia. Dokončením user story môže produktový vlastník okamžite začať s pripomienkovaním, resp. akceptáciou, hotovej práce. Musí sa ale dozvedieť, že story je hotová. Vy Skorá spätná väzba je predpokladom úspechu.
  • Presun karty je o sekundách. Neznalosť aktuálneho stavu bude o hodinách, popr. dni.

Paradoxne až distribuovaný stand-up vás naučí najefektívnejšej príprave.

Keďže musíte byť stručný a jasný, pripravíte si stav úloh pred poradou, napr. do Notepadu . Prejdete si svoje úlohy a pozriete sa na kandidátov na ďalšie. Potom, keď máte rozprávať, už iba vložíte pripravený text do Skype alebo Office Communicatora a rozprávate. Ostatní tak tieto informácie uvidia, aj keď kvalita linky nie je veľmi dobrá, alebo ak nerozumia vašej angličtine.

Pripravujete sa inak a funguje to? Napíšte o tom!

Daily stand-up dobre IV – scrum master. A?

Posted on by

BatmanScrum master pečie denný chlieb tímu na dennom stretnutí.

Práve počas tohto stretnutia sa prejavujú schopnosti scrum mastra. Niečo o scrum mastershipe sa síce dozviete počas certifikačných a iných školení, no iba prax vás naučí.

Tím dobrého scrum mastra nemá problém so samoorganizáciou úloh, s komunikáciou a ani výrazné problémy so stavom úloh. Navyše v takom tíme je vysoká miera sebadisciplíny a zodpovednosti.

Disciplinovaný scrum master pred samotným daily mítingom :

  1. preverí stav nahlásených problémov a zaktualizuje ich zoznam, resp. časť tabule s problémami,
  2. skontroluje aktuálnosť stavu implementačných úloh na Kanban tabuli,
  3. skontroluje, či úlohy majú aktualizovaný zostávajúcu čas implementácie,
  4. skontroluje, či tok (flow) úloh je v poriadku,
  5. preverí, či členovia tímu sa snažia uzatvárať user stories a nie otvárať ďalšie úlohy,
  6. identifkuje novopridané úlohy, ktoré by moli zmeniť záväzok tímu daný na začiatku sprintu,
  7. preverí si vyťaženie členov tímu tak, aby ich naviedol pri samoorganizácii počas mítingu,
  8. overí dohodnuté WIP limity,
  9. spolu s produktovým vlastníkom preveria, či nie sú nutné zmeny v backlogu sprintu,
  10. spolu s inými scrum mastrami overí stav závislých prác, prípadne potreby iných tímov,
  11. preverí, či manažment nemá niečo dôležité z pohľadu organizácie, čo je potrebné odkomunikovať,
  12. skontroluje priebeh burn-down grafu a identifikuje otázne hodnoty, ktoré má s tímom prediskutovať,
  13. prípraví priestor pre denné stretnutie,
  14. pripraví nástroje (napr. zobrazí elektronickú kanban tabuľu),
  15. a  v neposlednom rade vymyslí ako otvorí stretnutie tak, aby sa tím pozitívne naladil.

Čo zmeníte na svojom scrum mastershipe zajtra?

Odkazy:

Daily standup dobre – I. Prečo?

Posted on by

Pôvodný článok na http://scrum.sk/index.php/daily-standup-dobre-cast-1-preco/

Denný stand-up je základnou ceremóniou v Scrum, ktorá je (chvalabohu) v slovenských dolinách aplikovaná často aj bez toho, aby bola oficiálne formalizovaná. Predovšetkým v malých firmách, kde ešte stále je rozhovor základom spolupráce.

Často však po niekoľkých mesiacoch zrazu tieto stretnutia nemajú “šťavu”. Mnoho ľudí nám pri koučingu namieta, že je to strata času. Prečo?

Pripravili sme preto pre Vás krátku sériu článkov o typických chybách, ktorými tímy samé brzdia svoju agilitu.

Čo je cieľom vášho standupu?

Najčastejším problémom je nepochopenie cieľa tohto stretnutia. Členovia tímu a scrum mastri ho považujú za stretnutie, na ktorom sa má reportovať stav projektu formou odpovedí na tri otázky: “Čo si spravil včera, čo budeš robiť dnes a aké máš problémy.”. Áno je pravda, že tieto otázky sú odporúčané. No nie je pravdou, že ich najväčší prínos je v reportingu.

Cieľom standupu je rozpoznať čo náš tím obmedzuje v dokončení našich zámerov dohodnutých počas plánovania, ku ktorým sme sa zaviazali.

Má to teda byť stretnutie viac o blízkej budúcnosti, než stretnutie o tom, čo sa stalo. Má to byť o tíme, nie o jednotlivcoch.

Tím sa má sústrediť na to ako dokončiť prácu, nie na to, ako je implementácia rozpracovaná. Agile je totiž založené na podpore dodávania funkčných výsledkov, ktoré ak nie sú dokončené, tak jednoducho nie sú použiteľné. Navyše trh je nevyspytateľný a zmeny sú dnes už konštantou.

Práve preto by ste ako tím mali byť pripravení aj počas sprintu dodať už dokončené user stories, resp. opravené chyby. Kedykoľvek.

 

Stavy v procese, stĺpce na Kanban tabuli

Posted on by

Článok je prebraný z http://scrum.sk/index.php/stavy-a-stlpce-na-kanban-tabuli/

Kanban tabuľa

Kanban tabuľa je skvelou pomôckou agilného tímu. Vizualizácia stavu úloh umožňuje tímu sa efektívne samoorganizovať a zároveň budovať dôveru v tíme aj mimo neho.

Každý stĺpec tabule označuje stav. A práve počet stĺpcov, teda stavov, je jednou z prvých otázok scrum mastrov počas prípravy tímu.

Odpoveď závisí od spôsobu akým ste sa rozhodli zavádzať Agile. Ste otvorení väčším zmenám? Alebo radšej opatrne a postupne?

Veľká zmena – maximalizácia minima

Pred niekoľkými mesiacmi sme začínali transformáciu v tíme, ktorý vytvára komplexný informačný systém už niekoľko rokov. V skutočnosti to boli štyri tímy so zložitejším procesom vývoja a teda aj s viacerými stavmi.

Ešte pred začatím transformácie sa však tím rozhodol maximálne zjednodušiť workflow tak, aby sa nemuseli vývojári zamýšľať kedy dať kartu do akého stavu. Pre svoju Kanban tabuľu preto zaviedli iba tri stavy.

Kanban simple workflow proces

Výhody sa ukázali okamžite:

  • Jednoznačný stav. Úlohu je nutné spraviť, alebo sa na nej pracuje, alebo je hotová.
  • Veľa kariet. Aj keď to znelo ako zvýšenie byrokracie, v skutočnosti sa ukázalo, že toto rozhodnutie viedlo tím k lepšej príprave počas plánovania. Požiadavky sú rozdelené na viaceré úlohy, ktoré jasnejšie popisujú prístup k riešeniu požiadavky.
  • Lepšie odhady – každá karta má svoj jednoznačný odhad. Je jasné, koľko sa na kartu plánuje a koľko času ešte zostáva. V predchádzajúcom workflow mal tím špeciálny stav označujúci čakanie. A práve v takomto stave karty ‘viseli’ , no tím nesledoval ich trvanie.
  • Organizácia tímu – každá  karta má svojho riešiteľa. Tak je možné lepšie rozdeliť úlohy medzi členov tímu.
  • Adresnosť problému – v prípade problému pri riešení úlohy je možné ľahko identifikovať, ktoré úlohy majú problém a zviditeľniť ich.

Pomalá zmena

Iný tím sa rozhodol, že zavedenie troch stavov nie je možné vzhľadom k ďalším firemným procesom, no identifikovali, že zjednodušenie je nutné. Otázne bolo ako zmeniť proces čo najmenej a zároveň najefektívnejšie.

Jedným z agilných princípov je pozorovanie a adaptácia. Preto sme v tíme začali s vizualizáciou aktuálneho workflow. Od momentu vzniku požiadavky až po dodanie výsledku používateľom. Táto technika sa volá Value Stream Mapping. Obrázok ilustruje príklad výrobnej fabriky.

Value Stream Mapping

Ďalším krokom bolo meranie trvania spracovania úloh v jednotlivých stavoch a pri presunoch medzi nimi. Keďže hlavným cieľom transformácie bolo skrátiť čas dodávky používateľom, zamerali sme na najdlhšie časti, ktoré stálo zato optimalizovať. Optimalizácia však neznamenala, že sa meranie skončilo. Každá lokálna optimalizácia má dopady na celkový proces, a preto je nutné pokračovať v meraní a ďalšej optimalizácii. Je to v podstate neustály proces.

Vizualizácia a meranie zároveň pomohli identifkovať stavy, v ktorých sa úlohy dlho ‘neohriali’. Úlohy boli cez nich iba presúvané. Tieto stavy boli z workflow odstránené čo zjednodušilo aj samotný proces.

Čo sa pýtať pri vytváraní Kanban tabule?

  • Prečo potrebujeme daný stav?
  • Kto potrebuje daný stav?
  • Ako dlho zostáva úloha v danom stave?
  • Má stav zmysel aj v prípade, že úloha nie je vývojová, ale napr.  napísanie dokumentu?
  • Potrebujete stav merať a vykazovať? Pre koho a prečo? Má to súvis s biznis hodnotou?
  • Čo je zbytočné?
  • Neexistujú iné workflow pre rôzne činnosti vývojového tímu? Napr. riešenie podpory, spracovanie kritických požiadaviek, požiadavky na súčinnosť.

Pr_duktívne plánovanie

Posted on by

Článok je prebraný z http://scrum.sk/index.php/produktivne_planovanie/

Počas niekoľkých posledných mesiacov sa mi naskytla príležitosť zúčastniť sa viacerých plánovacích stretnutí tímov s rôznou dobou nasadenia agile. Od úplných začiatočníkov až po starých harcovníkov, ktorí agile aplikujú už viac ako päť rokov.

Zaujalo ma na nich to, že:

  1. Efektivita plánovania nezávisí od trvania aplikácie agile.
  2. Tímy bez feedbacku upadajú do stereotypov a iba aplikujú procesy.
  3. Tímy sa zamerajú na zjednodušenie práce (rozumej lenivejú) a úplne zabúdajú na dôvôdy prečo sa plánuje.
  4. Výsledkom nie je plán, ktorému všetci rozumejú.
  5. Plán nie je plánom tímu, ale plánom jednotlivcov.
  6. Nesprávne pochopenie kedy a ako aplikovať story pointy a kedy hodiny.
  7. Nepochopenie, prečo vlastne odhadovať čas.
  8. Sprinty napriek plánovaniu aj tak nie sú ukončené načas a tím napriek tomu necíti zodpovednosť.

 

Možno predpokladáte, že tieto chyby mali tímy, ktoré začínali. No nebolo to tak. Tieto chyby sa objavili v skúsených tímoch. Vedené certifikovanými scrum mastrami.

 

A výsledok? Frustrácie manažmentu z nejasného termínu dodania, čo vedie k neustálym zmenám priorít. To prirodzene frustruje zákazníka aj tím. Navyše to prispieva k nemožnosti plánovania, práve kvôli častým zmenám. A začarovaný kruh je na svete. Plánovanie je frustrácia, ktorá bolí a preto ho chceme mať z krku. Preboha, veď za tie 4 hodiny sa dá toho tak veľa stihnúť naprogramovať.

Pravda starých otcov

Jeden z mojich prvých manažérov ma učil pravidlo brúsenia sekery. Jednoducho povedané, nedá sa len stínať stromy. To aj drevorubač sa musí zastaviť, vybrať si ten správny smer, vybrať stromy a nabrúsiť sekeru. Až potom rúbať stromy tak, aby vládal aj na ďalší deň. Ako je to v IT? (Lepší?) Vývojár chce vyvíjať. Všetko ostatné je balast. Sekera sa brúsi iba ojedinele.

No to brúsenie sekery má niečo v sebe…

Pravda starých agilistov

Agilné princípy ukazujú ako z tejto frustrácie von. Začať treba Agilným Manifestom, ktoré dáva do popredia funkčný softvér. Vytvorený v spolupráci tímu, zákazníka tak, aby bol pripravený na zmeny.

Účelom plánovania je robiť plánovanie, nie vytvárať plány.

Teda:

  • spoznať čo ideme dokončiť počas sprintu,
  • chceme začať s čistým stolom, začať novú iteráciu,
  • stanoviť si tímový záväzok k tomu, čo vieme dokončiť a koľko vieme dokončiť,
  • vytvoriť priestor pre spokojnosť. Spokojnosť tímu, klientov aj manažmentu.

Agenda

Často odpozorovanou chybou je úplne chýbajúca agenda stretnutia. Nepripravenosť z pohľadu organizácie času, postupu, priestorov a potrebného materiálu. Tím jednoducho prišiel na plánovanie a nechal sa unášať. V takýchto prípadoch začujete najčastejšie otázku ”Kedy vlastne máme obed?”. Áno, najčastejšie je práve táto prvou otázkou.

Čo je teda potrebné na plánovanie? Tu je niekoľko postrehov.

Čas

Predpokladajte  trvanie asi 2-4 hodiny podľa pripravenosti backlogu. Je to dlho? Radšej si sadnúť na dve hodiny a dohodnúť než potom zmätene hľadať spôsob riešenia niekoľko dní…

Pripravenosť

Dobrý scrum master pripraví miestnosť. Projektor, laptop, funkčné pripojenie k elektronickej tabuli. Telefón(y), web kamery ak je to potrebné.  Viditeľný časový rámec jednotlivých aktivít. Stopky alebo hodiny merajúce čas. A samozrejme pozve ľudí aj poslaním udalosti do kalendára. Dostatočne vopred. Najmenej 2 týždne vopred.

Dobrý produktový vlastník príde na plánovanie s pripravenými požiadavkami, ich prioritami. S odhadnutou biznis hodnotou, rizikom a MoSCoW. S akceptačnými kritériami. Vo forme, ktorú tím považuje za stav pripravený (definition of ready).

Dobré tímy už vedia čo v sprint backlogu je. Už si ho vopred každý preštudoval, napísal si pripomienky, resp. otázky a vie čo musí spraviť pre dokončenie požiadaviek. Má predpripravené konkrétne úlohy.

P1030082

V takomto prípade dokončí 10 ľudí plánovanie sprintu do 2 hodín určite. Postrehli ste ale tú disciplínu v príprave?

Kartičky

Budete potrebovať kartičky, kartičky, kartičky. A ešte raz kartičky. Zabudnite na notebooky. Plánovanie má byť tímovou prácou (manifesto).

S kartami sa ľahko manipuluje, ľahko sa prioritzuje, delí, vytvára nový obsah. Backlog sa jednoducho dá rozdeliť medzi viacero ľudí, zparalelniť prácu. Plánovanie tak bude intenzívne, efektívne a produktívne. Až keď skončíte plánovanie, až potom zadajte všetky karty do nástroja. Ak to urobíte všetci z tímu, tak zadať niekoľko desiatok kariet vám nezaberie viac ako pol hodinu.

P1050046

Aké je to s jedným laptopom a projektorom? Prduktívne. Všetci sedia okolo stola so založenými rukami a v tom lepšom prípade pozerajú na stenu. V bežnom prípade sa hrajú s telefónom pod stolom. Preto prduktívne.

Hmm, notebook

Ok, maximálne jeden, ak váš backlog je v elektronickom nástroji. Aby ste sa vedeli prehrabať v referenciách a ďalších potrebných informáciách. No prineste sprint backlog aj na kartičkách. Malá komplikácia, ktorá zvyšuje produktivitu.

Definícia Hotovo

Prineste si aj vašu definíciu Hotovo. Aby vám pomohla ako šablóna pri písaní úloh. Možno budete potrebovať viacero definícií. Pre user stories alebo chyby.

DoD

Rýchlosť a história

Aby ste sa vyhli zbytočnému deleniu požiadaviek na úlohy, do sprintu má produktový vlastník zaradiť iba toľko stories, koľko tím stihol dokončiť v predchádzajúcich sprintoch. Koľko story pointov bolo realné dokončených.

velocity

Kapacita

Zrátajte kapacitu tímu. Koľko dní budú členovia tímu v práci. Koľko hodín denne sa vedia venovať backlogu. Každú úlohu potom odhadnite v hodinách a nakoniec skontrolujte, či ich stihnete dokončiť.

Aby ste si vedeli overiť, či náhodou ste si nenaplánovali príliš veľa práce na sprint, ktorú nemáte možnosť stihnúť.

Kapacita

A výsledok plánovania?

Výsledkom dobrého plánovania sú:

  • prioritizované user stories,
  • dohodnuté akceptačné kritériá,
  • identifikované riziká,
  • rozdelené user stories na implementačné úlohy podľa definície hotovo a podľa charakteru požiadaviek,
  • odhadnutý čas imlementácie úloh,
  • overená možnosť dokončenia sprint backlogu podľa kapacity tímu a podľa dostupnosti jednotlivých členov tímu,
  • pocit, že vieme takýto sprint dokončiť.

Pocit je často pravdivejší než akákoľvek matematika….

Veľa úspechov pri plánovaní ďalších sprintov, ktoré sa vám podarí dokončiť.

Fyzický vs. elektronický Scrum

Posted on by

fdsafdsf4564Scrum, ako aj iné metódy riadenia (či už pre tím alebo osobné), vyžaduje určité nástroje na realizáciu. Zoznam, grafy a iné artefakty, ktoré sú pre beh metódy nevyhnutné. Tieto nástroje môžu existovať vo forme elektronickej alebo fyzickej. Elektronická forma predstavuje rôzne špecializované softvéry alebo prispôsobené všeobecnejšie nástroje (Calc, Excel..), zatiaľ čo pri papierovej je to najčastejšie samotný papier alebo tabuľa (magnetická, korková …). Diskusia o tom, ktorá z týchto foriem je vhodnejšia, je prakticky nekonečná a to z jednoduchého dôvodu: univerzálna odpoveď na túto otázku neexistuje. Respektíve existuje odpoveď, ktorá ale nepomáha problém riešiť, a to je: pre každý projekt je vhodná iná forma. Keď už ale príde na lámanie chleba, musíte si vybrať…

To, čo pomáha sa dostať z tohto bludného kruhu otázky a odpovede je fakt, že každá z týchto foriem má svoje výhody a nevýhody. Práve tento zoznam bonusov a potenciálnych rizík by mal byť prostriedok, ktorý umožní zvládať túto dilemu. Je potrebné len zvážiť, ktoré vlastnosti sú pre váš projekt najdôležitejšie a vybrať. Poďme sa teraz bližšie pozrieť na jednotlivé výhody a nevýhody.

Elektronika

Ak sa rozhodnete použivať elektronický nástroj, je výber taký široký, až to začína byť nepríjemné. Vybrať si môžete buď nástroj, ktorý je šitý priamo na vašu metódu, ktorý vám dá presne to, čo potrebujete, ale na druhej strane vás môže obmedzovať, ak potrebujete niečo naviac. Alebo si môžete siahnuť po univerzálnejšom nástroji, ktorý si budete musieť najprv prispôsobiť. Teraz mám na mysli vyššie spomínané nástroje ako Calc alebo Excel, s ktorými viete robiť naozaj veľa, ale chce to vedomosti a čas. Rozdiel medzi týmito dvoma kategóriami je hlavne v tom, že s tým prvým si kupujete aj metódu, s tým druhým nie. Prečo ale po softvérovom nástroji siahnuť:

  1. prístup z rôznych miest – toto je asi najdôležitejšia výhoda. Pre distribuovaný tím je elektronická forma prakticky nevyhnutná. Ale členovia tímu nie sú jediní, ktorých stav projektu môže zaujímať. Riadiaci pracovníci, obchodné oddelenie alebo zákazník. Alebo hoci aj ten monitor vo vstupnej hale, ktorý vysiela Sprint Burnd Down Chart náhodným okoloidúcim.

  2. vyhľadávanie – jednoznačne jednoduchšie ako pri fyzickej forme.

  3. prenositeľnosť – kopírovanie, zálohovanie, dlhodobá archivácia.

  4. ľahký prechod na papier – rôzne grafy a zoznamy je často možno jednoducho vytlačiť a získať tak ich fyzickú formu.

  5. automatizácia – systém dokáže automaticky za vás vykonávať niektoré práce. Kreslí graf, počíta priemery, posiela e-maily…

Fyzické nástroje

Pod pojmom fyzické nástroje si môžete predstaviť akékoľvek jednoduché prostriedky, pomocou ktorých viete v reálnom svete zobrazovať stav projektu. Tabuľa, papier, fixa, pero, nálepka, magnet, lepiaca páska, špagát, žiarovka, siréna atď. S hotovými fyzickými sadami pre Scrum som sa zatiaľ príliš nestretol, ale ak prehľadáte internet, určite nájdete dostatok inšpirácie. Prečo ale siahnuť po fyzickej forme:

  1. sloboda – jednoduché nástroje vám umožnia vytvárať ľubovoľné zložité objekty. Obyčajná popisovacia tabuľa s fixou a sadou lepiacich papierikov poskytuje neuveriteľné množstvo možností kombinácií toho, ako ich dokopy použijete. Niečo nefunguje, tak ako potrebujete? Zahodíte a nahradíte iným riešením. Ak nefunguje ani to, skúsite niečo iné. Takáto sloboda ohnúť nástroj do požadovaného tvaru môže byť pri softvéry problém. A že by mali mať ľudia navrch oproti nástrojom hovorí už aj samotné Agile Manifesto.

  2. hmatateľnosť – svet softvéru alebo poskytovania služieb má oproti klasickej priemyselnej výrobe jednu nevýhodu – to, čo firma vyrába, s čím sa každý deň pracuje, nie je hmatateľné. Na prvý pohľad to nemusí vyzerať až tak podstatne, ale je dôležité si uvedomiť, že spoločnosť za posledné desaťročia prešla revolúciou, zatiaľ čo my ľudia sme skôr evolučná záležitosť. Hmatateľné predmety je možné si podávať, rozostavovať ich v priestore, ukladať na kopy alebo hoci aj hádzať do koša. Všetko toto sú pre ľudí prirodzené činnosti, preto aj práca s fyzickými nástrojmi je prirodzenejšia.

  3. jednoduchšia viditeľnosť – ak sa nerozhodnete pre nejaké komplikovanejšie riešenie ako je zapnutý projektor, alebo každodenné tlačenie stavu na papier má elektronická verzia jednu nevýhodu – je uzamknutá do vášho monitoru. Oproti tomu je fyzická často umiestnená na nejakom viditeľnom mieste, a teda je omnoho ťažšie ju prehliadnuť (pre vás, manažment alebo kohokoľvek, koho by to mohlo zaujať). Stačí len otočiť hlavu.

Myslím, že rozhodnutie o forme by malo padnúť pre každý projekt zvlášť a dokonca, že by malo byť možné ho zmeniť, ak sa ukáže, že druhá forma je vhodnejšia. Každopádne je možné tieto formy udržiavať aj obe naraz – synchronizovať. To si ale vyžaduje viac úsilia, a teda je otázne či to naozaj stojí za to. Takto sa síce dajú získať výhody obidvoch foriem, ale zaplatíte za to monotónnou každodennou prácou a rizikom, že sa synchronizácia rozíde.

Ako bolo na Open Space Meetup v Bratislave

Posted on by

V utorok 2.4. sa v Bratislave stretli ľudia aplikujúci alebo zaujímajúci sa o Agile. Tentokrát sme sa rozhodli venovať iba diskusii a rozhovorom s cieľom spoznať prístupy iných tímov.

Tu je zoznam diskutovaných tém a postrehy z diskusie. Ďakujeme za toto neuveriteľné množstvo postrehov v priebehu pár hodín.

Fixná cena projektu a Scrum

  • Chceme sa zbaviť fixnej ceny
  • Fixná cena veľkých projektov (2 roky)
  • Použitie MoSCoW prioritizácie ako možnosti pre identifikáciu vlastností, ktoré zákazní ľahko oželie, resp. termínovo posunie
  • Zmluvy niektorých spoločností obsahujú aspoň % možného oneskorenia termínov
  • Fixná cena spôsobuje dlhú prípravu a podrobnosť zmluvy
  • Diskusia o nových systémoch  (presná cena, dátum, rozsah) alebo údržbu (možný scrum)
  • Stanovenie ceny na konci analýzy, niektoré spoločnosti robia analýzu v samostatnom sprinte, na konci ktorého sa stanový rozsha a následne cena
  • Fixná cena spôsobuje často drastické zmeny v internej implementácii produktu, čo vedie k zhoršeniu kvality produktu
  • Modul v extra platbe
  • Ako aplikovať Agile na subdodávateľov?
    • Zahrnúť ich do agilného tímmu na dennodennej báze ako regulárnych členov tímu
    • denné scrumy
    • spoločné plánovanie, retrospektíva a demo
    • Dávate pokuty? Ako sa vyvíjajú vzťahy?
  • Odporúčané postupy z Ganthead.com: počet iterácií, výkonnostné ukazovatele, cieľové náklady, rozsah a stanovenie min-max ceny, pevný počet iterácií, lean

Nové požiadavky – prijať alebo neprijať?

  • Rozdiel či požiadavky prichádzajú do produktového alebo sprint backlogu
  • Rozdiel či ide o funknčnú požiadavku, zmenovú alebo chyby
  • Väčšina preferuje neprijať požiadavku do sprint backlogu
  • V sprinte robíme barter, ak je niečo pridané, niečo iné musí zmiznúť
  • Reprioritizácia ako výhoda pre klienta
  • Sprint chceme mať pevný, zamknutý

Dĺžka sprintov

  • Podľa čoho nastaviť dĺžku sprintov?
  • Zvyčajne sa používajú 1,2,3 týždne
  • 1 mesiac sa ukázal ako málo agilný
  • Problém s posledným týždňom, ak je v sprinte menej práce
  • Plánovanie robíme celý deň
  • Dlhší sprint je lepší pre retrospektívu

Snáď sme Agile

  • Estimácia iba časti produktového backlogu
  • Hotová časť produktu vedie k spokojnosti tímu a zákazníka
  • Nezaujímajú nás hodiny, ale výsledok
  • Ako plánovať a prezentovať prácu na backend-e?
  • Práca na backende musí byť prepojená s frontendom, vytváranie požiadaviek pokrývajúcich celú vertikálu
  • Ako robiť demo ak klient je v zahraničí?
  • 100% priradenie ľudí v tíme na prácu na jednom projekte
  • Je Scrum of Scrum riešením problémov viacerých tímov?
  • Aký je dobrý pomer vývojárov a testerov v agilnom tíme?
  • Multidisciplínny tím je jednoznačne výhodou
  • Zdieľanie ľudských zdrojov medzi viacerými scrum tímami ak ide o špecialistov
  • Robíme FREE  FRIDAY, potom je retrospektíva ľahšia a hodnotnejšia

Scrum mimo softvérového vývoja

  • Digitálna produkcia
  • Automotive
  • Operation
  • ZOH Vancouver
  • Organizovanie eventov, koncertov

Párové programovanie

  • Robí iba jedna spoločnosť
  • Rozhodnutie kto robí párové programovanie s kým
  • Zostavnie dvojíc dobrovoľne
  • Zohľadnenie kapacity
  • Podpora Scrum mastra

Support vs. vývojový tím

  • Kedy odovzdať funkčnosť?
  • Chyby a dĺžka sprintu
  • Investícia do testovania zmenšuje nutnosť supportu
  • Plánovanie opráv chýb v sprinte
  • Kapacita a skúsenosti ľudí
  • % kapacity chyby vs. funkčnosť
  • Tímy hasičov

Klient a Agile tím

  • Aj klienta je treba naučiť agile
  • Funkčný softvér výhoda
  • Ukazujeme funkčnosť
  • Vyššia dôvera
  • Kontrola vs. odovzdanie, akceptácia
  • Učíme ich “pádom” aplikácie

Iné

  • Máme vytvorenú definíciu HOTOVO
  • Metriky pre odhad nasledujúcich sprintov
  • Rátame iba reálne ukončené a akceptované produktovým vlastníkom
  • Ako transformovať spoločnosť na agile spoločnosť?
  • Vzťah agilných a neagilných tímov v spoločnosti
  • Čo je nasaditeľná verzia?

Projektový manažér == Scrum Master?

Posted on by

V posledných dňoch mám čoraz väčší dojem, že niektoré veci musíme ako komunita dôraznejšie ozrejmovať,  vysvetľovať a trvať na správnom použití.

V tomto príspevku sa chcem viac zamerať na význam roly Scrum Master. Prečo? Pretože počas posledného týždňa som našiel päť článkov (jeden dokonca publikovaný na nemenovanej unverzite), ktoré nesprávne vysvetľujú kto je Scrum Master, čo má robiť a ako to má robiť.

Dôvodom je možno slovenčina, do ktorej sa tento pojem Scrum Master veľmi ťažko prekladá. Majster Scrumu? Hmm, v profesionálnom prostredí to znie zvláštne. Ja osobne tento pojem práve preto takto neprekladám. No významovo je tento preklad vynikajúci.

Projektový manažér (v terminológii Scrum-u „ScrumMaster“)

Chcel by som sa venovať asi najväčšiemu nepochopeniu, ktoré som objavil.

Nie, nesprávne. Toto sú dve roly, ktoré majú za úlohu riešiť iné aspekty. Áno, často je to ten istý človek. No tento človek má na vešiaku dva kabáty. Raz môže byt projektovým manažérom, inokedy scrum mastrom. Dokonca z praxe poznám mnohých projektových manažérov, ktorý sa radšej stali Scrum Mastrom.

Prečo? Pretože  Projektový manažer <> Scrum Master.

Pretože projektový manažér sa má zaoberať časom, rozpočtom, zdrojmi a kvalitou. To sú atribúty akéhokoľvek projektu. A projektový manažér ich má držať pokope tak, aby výsledok projektu bol dodaný načas, v rozpočte s danou kvalitou, vyvinutý vybraným tímom.

Projektový manažér je na svete kvôli PROJEKTU.

No Scrum Master sa týmto primárne vôbec nemá zaoberať. Scrum Master sa zaoberá:

  • Vyrovnávaním cesty, po ktorej kráča tím.
  • Snaží sa skoro rozpoznať prekážky, snaží sa ich odstrániť aj za pomoci organizácie.
  • Snaží sa tímu pomôcť, aby bol efektívnym.
  • Robí denne prácu, ktorá by iných blokovala.
  • Prináša a udržuje viditeľnosť stavu projektu tým, že komunikuje s tímom a inými tímami
  • Synchronizuje tím s inými tímami
  • Pripravuje a moderuje (pozor, nevedie!) porady a diskusie.
  • Komunikuje s organizáciou – produktovým aj projektovým manažérom.
  • Zaoberá sa procesom vývoja.
  • Koučuje (vyučuje) agilné techniky v tíme. Také aké práve tímu pomôžu. Musí mať prehľad o tejto problematike a mal by vždy vedieť trochu o tom viac ako členovia tímu.

Scrum Master je na svete kvôli TÍMU.

Máte na tento zoznam ako projektový manažér v dnešnej dobe čas?

Základná smernica retrospektívy

Posted on by

Skúste prečítať túto vetu nahlas všetkými členmi tímu na začiatku vašej retrospektívy…

Bez ohľadu na to, čo zistíme,

chápeme a pevne veríme,
že každý robí tú najlepšiu prácu akú môže,

vzhľadom na to, čo pozná,
podľa svojich schopností a zručností,

podľa  situácie, ľudí a zdrojov,
ktoré sú k dispozícii.