Otázkou je, prečo je to vôbec otázkou. V IT tímoch zvyčajne počuť, že už žijeme v 21. storočí a že fyzická tabuľa je kopa byrokracie a roboty naviac.

Ak je však tím nový, resp. agile je pre tím novou témou, potom ako konzultanti vyžadujeme fyzickú tabuľu. Pred ňou sa v skutočnosti udeje ďaleko viac zvien, pochopenia, prispôsobenia, komunikácie aj spolupráce než v porovnaní s elektronickou (a to vravíme ako výrobcovia elektronických nástrojov :))

99% tímov aj tak si pripraví obe tabule a udržiava ich súčasne. Prečo? Pretože nástroj ráta, notifikuje, integruje, udržiava ďalšie informácie týkajúce sa úloh. A fyzická tabuľa ukazuje všetku prácu, nielen malé okno. Je priestorom pre spoluprácu a synchronizáciu.

Nie! Fuj! Never! Ever! Nikogda!

Nechajte členov tímu si prácu vyberať. Najlepšie podľa priority. Iba vtedy nastane v tíme naozajstná spolupráca. A dajte pozor, aby si nevyberali tú istú oblasť, resp. typ úlohy.

Môže byť, ale iba pre malý tím. Tak do 4 ľudí, Potom je už náročnejšie sa starať o potreby členov tímu a aj o produkt samotný.

Ak máte talent na produkt, tak radšej sa orientujte na produktový ownership a scrum mastership prenechajte hocikomu v tíme, kto je šikovný organizátor. Taký, ktorý keď zavelí na obed, tak ostatní sa postavia a pôjdu.

Možno to tak vidí klient. Aj vy by ste to tak možno videli, keby ste ním boli. Bodaj by nie, veď za tie roky IT stratilo kredit. Veštko trvá dlhšie, je drahšie, žiadna viditeľnosť. Práve agile však rieši tieto problémy. A je na vás klientovi dokázať, že to môže byť inak.

Nič vám však nebráni premýšľať v kontexte Mus, Should, Could. A pomlcť s tým kleintovi, pretože aj on rád ušetrí prachy a radšej ich investuje do niečoho rozumnejšieho. A práve to mu viee odporúčať. Ak chcete.

V Scrum nie je rola projektového manažéra popísaná. V ideálnom scrume totiž zodovednosti tejto roly sú rozdelené medzi ScrumMastra a produktového vlastníka.

Ale to je ideál. Realita je iná. Firma od firmy, dokonca tím od tímu. Projektový manažér vám môže pomôcť s komunikáciou, rozpočtom, organizáciou, atď. Len sa treba dohodnúť. Napr. prostredníctvom RACI matice.

Nemusí byť. A bum…. teraz si to všetci prečítali a majú prvoplánovaný argument.

Denný nemá zmysel ak ste konštantne na cestách (sales), pracujete na rôznych klientoch, máte veľmi rôznorodé roly, ktorí majú málo spoločné. Iba vtedy by som spravil standup možno raz, možno dvakrát do týždňa.

V skutočnosti ho chcete mať každý deň, aby ste sa učili a vybudovali si schopnosť zastúpiť sa. A byť informovaný, kde kolega skončil, aby ste vy mohli pokračovať.

Áno, ak je požiadavka biznisová. User story pomáha pochopiť kontext používateľa. A zvyčajne (ak je vytvorená správnym postupom), presne cieli na problémy, alebo prácu používateľa.

Formát nie je potrebný pre chyby. Nie potrebný pre technické úlohy, napr. inštalácia servera.

Inak, aj keď sa ťažšie vymýšľa, je pre nás must.

Pozor na slovo task. Hlavne niektoré nástroje zmenili význam tohto slova.

Task/úloha je pre označenie aktivity vedúcej k implementácii požiadavky. Popisuje AKO.

Požiadavka/requirement/user story popisuje ČO, PRE KOHO a PREČO to treba.

Nie, na to je backlog grooming. Retro je o procese fungovania, nie vlastnostiach produktu. Počas groomingu však môžete použiť retro techniky pre identifikáciu nápadov.

Ľahká odpoveď. Nedá sa. Dá sa iba toľko. Vyberte si čo je prvá, čo druhé, čo tretie. Jednoducho priorizujte. Tím vám povie koľko sa dá.

Bude s tým problém, to je jasné. Pretože klientovi bolo sľúbené viac než je možné. Pretože ste možno podliezli cenu. Pretože možno robíte zbytočne komplikované riešenia, ktoré dlho trvajú. A tak neostáva nič iné ako priorizovať.

Odmietnite ich. Najneskôr na sprint planningu. Lepšie na sprint preplannigu, aby stakeholderi, produktový vlastník a architekt ich mal možnosť doplniť, upresniť. Ešte lepšie, zlepšujte ich priebežne.

Dohodnite si definíciu pripravenosti. Skúste si merať koľko bolo požiadaviek pripravených, aby zadávatelia mali spätnú väzbu.

Počas plánovania agilné tímy zvažujú kapacitu 6 hodín na deň. Dôvodom je, že sa empiricky ukazuje, že práve 6 hodín je produktívny čas počas dňa. kedy je človek je schopný sa skoncentrovať na výsledok. Inak povedané, počas 8 hodín práce je človek schopný vyprodukovať výsledok zodpovedajúci 6 hodinám čistého času. Tie zvyšné dve hodiny je čas potrebný na schôdky, operatívu, prepínanie kontexktu, telefonovanie atď.

A keďže chceme dodať to čo sľúbime, radšej plánujeme menej. Neznamená to však, že ľudia na konci dňa majú vykázať iba 8 hodín. Stále pracujeme 8. Ak skončím úlohu počas 6 hodín, tak jedoducho pokračujem s ďalšou na tabuli.