18. Boris Plevza: Scrum - agilná metodika riadenia vývoja softvéru #tema

V tomto rozhovore sa dozviete:

Stačí dať PLAY:

Profil podnikateľa

Celé meno:

• Boris Plevza

Odkazy na sociálne siete:

• LinkedIn
  

Základné informácie:

• Boris je teamleaderom a Scrum masterom agilného Scrum tímu
• agilný vývoj je alternatívny spôsob vývoja softvéru k málo flexibilnému "vodopádovému modelu"
• jednou z najpopulárnejších metodík agilného riadenia vývoja softvéru je metodika Scrum
• Scrum pozostáva z princípov, ktoré tímom pomáhajú
  
  • dodať funkčný produkt v krátkych cykloch
  • zaručiť rýchlu spätnú väzbu
  • umožniť neustále zlepšovanie
  • uľahčiť rýchlu adaptáciu na okolité vplyvy a zmeny
• Boris vyštudoval Finančný manažment na Univerzite Komenského v Bratislave

Prepis 18. epizódy podcastu s Borisom Plevzom

Ahoj Peťo. Ďakujem, že si ma pozval do Podnicastu.

Agilný vývoj je tu s nami už dlho. V roku 2001 sa v Utahu na jednej chate zišli softvéroví inžinieri, vývojári, špecialisti vývoja a vývojári softvéru a po pár dňoch spísali Agilné manifesto. Je to voľne dostupná informácia, ktorú nájdete na Agilemanifesto.org, kde sú špeficikované priority agilného vývoja a zoznam pravidiel.

Je to manifesto, na základe ktorého vznikajú rôzne frameworky, ktoré sa snažia implementovať tento proces do vývoja softvéru. Jeden z nich je aj SCRUM. Je jednoduchý na pochopenie, ale je veľmi ťažké ho praktizovať. O tom, prečo je to tak, si môžeme povedať neskôr.

Agilný vývoj je vývoj, ktorý by mal fungovať interaktívne. Agilné tímy majú nastavené určité obdobie, kedy sa snažia dodať čo najväčšiu hodnotu zákazníkovi.

Už posledný bod hovorí, že je proti štandardnému spôsobu plánovania, v softvéri sa to volalo waterfall - vodopády. Robila sa analýza, následne prišli programátori, ktorí podľa analýzy a analytikov vyvinuli nejakú časť a trvalo to strašne dlho. Zákazník bol vlastne od toho odtrhnutý. Dostal produkt, ktorý fungoval, niekedy až po pol roku, či roku. Vtedy zistil, že sa zmenili podmienky aj nejaké požiadavky a ten softvér je nepoužiteľný.

Preto sa hľadal spôsob, ako vymyslieť niečo, ako dávať zákazníkovi spätnú väzbu, alebo ukazovať mu už nejaké funkčné prvky softvéru, aby to bolo v čo najkratšom časovom rámci. Preto vznikli rôzne agilné frameworky, napríklad Scrum, kde tímy pracujú v šprintoch. To znamená, že je interaktívna časť, kedy má tím na konci dodať nejaký malinký výsledok, či už je to zmenený formulár systému, alebo pridanie nejakej malej funkcionality, ktorá sa dá tímom stihnúť za dĺžku toho šprintu.

Ukáže ho zákazníkovi, v našom prípade je to product owner, alebo skupina product ownerov, ktorí majú informácie a plus stakeholderi vo firme, ľudia, ktorí majú produkt nastarosti v širšom meradle a kompletne ho zastrešujú po rôznych firemných štruktúrach. Na konci majú vlastne demo.

Tím teda demonštruje funkcionalitu ľuďom, ktorí vedia povedať, či sa im to páči, alebo by potrebovali ešte niečo zmeniť. Predstav si, že toto sa deje každé 2 týždne. Niektoré tímy, ktoré robia s technológiami, vedia dodávať aj za jeden týždeň. Čiže zákazník dostane spätnú väzbu za jeden týždeň a vie sa k tomu vyjadriť. To je jednoducho úžasné. To predtým nebývalo a ja práve toto vidím ako veľkú výhodu agilného vývoja. Na druhej strane na to, aby tímy takto dobre fungovali, potrebuješ mať dobre postavený tím.

Teória je taká, že by malo byť nie menej ako 3 ľudia, nie viac ako 9 ľudí. V našom prípade máme ideálne 5 vývojárov, ktorí sa vedia dopĺňať. To znamená, že vedia produkt vyvíjať na rôznych častiach nezávisle, ale samozrejme vedia sa aj viacerí dopĺňať na jednom probléme.

Máme testerov, pretože vyrábame softvér pre hardvér a potrebujeme testovať funkcionalitu aj na hardvéry, ako sa správa, kedže ide o analytické zariadenia.

Pomáha testerom vyvíjať čo najlepší produkt. Čiže áno, funguje to tak, že developer vyvinie nejakú časť, prírastok a agilný tester pretestuje tú maličkú funkcionalitu v rôznych scenároch. Vie mu aj pomôcť, vie vytvoriť systémové a integračné testy, ale to už zachádzame do detailov vývoja. To by som spomenul len okrajovo.

Product owner je vlastník produktu a pomocou Scrum tímu vie zákazníkovi dodať najvyššiu hodnotu. Je to ten, ktorý definuje, ako bude sprioritizovaný backlog, čiže zoznam úloh zoradený podľa dôležitosti a najväčšej hodnoty pre zákazníka. Spolupracuje s tímom na tom, aby počas šprintu vedeli dodať čo najvyššiu hodnotu.

Áno.

To už zachádzame do Scrumových ceremónií, ktorých sa zúčastňuje aj product owner. Môže sa zúčastňovať denného Scrumu.

V našom prípade to znamená, že každé ráno sa stretne celý Scrum tím a preberá, čo sa mu podarilo deň predtým a čo plánuje urobiť v tento deň. Ak má nejaké zádrhely, tak to rieši s ostatnými členmi tímu a pritom im pomáha aj Scrum master, ku ktorému sa ešte dostaneme.

Product owner je tam preto, aby si bol istý, že vývojový tím napreduje požadovaným smerom. Čím je tím dospelejší, tak rola product ownera na denných stretnutiach býva menšia.

Áno. Je to vývojový tím, ktorý má nastarosti to, že dodáva reálne vyvinutý softvér, alebo funkcionalitu. Sú to ľudia, ktorým sa vytvárajú podmienky, aby vedeli čo najefektívnejšie vytvoriť hodnotu pre zákazníka.

V Scrum tíme nefungujú formálne pomenovania. Je to proste tím. Scrum vznikol ako pomenovanie z amerického futbalu, keď stoja proti sebe dva tímy, v podrepoch, zakliesnení a snažia sa v jednej situácii, keď príde lopta, získať ju a spoločne zabrániť súperovi, aby prešiel cez brániaci tím niekde do útoku.

Takto to funguje aj Scrum. Tím sa zaprie, urobí všetky svoje znalosti a schopnosti a spolu vyvinie hodnotu, ktorú dodá na konci šprintu zákazníkovi.

Je to individuálne. Môže to byť od jedného až po 4 týždne. Teória hovorí, že nad 4 týždne tím stráca fokus, ale pri niektorých softvéroch sú šprinty aj 4 týždňové.

Čo je taký štandard a čo som si ja všimol, tak šprinty bývajú okolo 2-3 týždňov. Napríklad ja pôsobím vo firme, kde je 9 tímov, ktorí pracujú na jednom produkte a to chce aj nejakú ďalšiu dodatočnú koordináciu.

V prípade, že je tím osamotený, vie sa rozhodnúť, aká dĺžka šprintu je pre neho najvhodnejšia. Ale ukazuje sa, že 2-3 týždne sú najideálnejšie na doručenie nejakej hodnoty, s tým, že človek má priestor urobiť veci poriadne.

Áno.

Tie tímy s pomocou Scrum masterov spolu koordinujú to, že máme teraz nejaké zadanie (user stories), kde sú nejaké akceptačné kritéria, ako to má všetko vyzerať, ktoré definuje product owner.

Ak tímy vidia, že sa to prelína s prácou iných tímov, alebo je tam nejaký zádrhel, tak to priamo riešia na vytvorenej platforme vždy po plánovaní šprintu. Každému šprintu predchádza plánovanie.

Najvyššia koordinácia je pred začatím šprintu. Keď už šprint začína, presne sa vie, čo sa ide robiť, ak by mal stakeholder potrebu zmeniť nejakú prioritu, čo sa nestáva, tak musí komunikovať iba s product ownerom, ktorý mu to väčšinou zakáže.

Tím musí mať čas, aby mohol dodať to, na čom sa dohodol so všetkými. Ideálne je do šprintu nezasahovať, skôr sa viac snažiť dobre to naplánovať pred šprintom. Potom má tím 2 alebo 3 týždne čas veci dodať.

Záleží to od miery detailu a komplexity požiadavky, ale áno, je to taká dobrá zvyklosť nastaviť celý chod firmy, aby tam bola aj nejaká miera detailu, aby to vydržalo 2 týždne. Ak je prostredie, kde sa veci musia meniť na týždňovej báze, aj keď si teraz neviem spomenúť, kde by to mohlo byť, tak sa môže nastaviť aj jednotýždňový šprint. Tým pádom človek vie do toho zasiahnuť relatívne rýchlo. Keď viem veci zmeniť za týždeň je to super, keďže niekedy som čakal pol roka až rok na dodávku softvéru.

Začal by som tým, že poviem ako vzniká backlog. Backlog vzniká ako príprava užívateľských user stories na to, aby ich tím vedel spracovať, aby porozumel všetkému, čo sa od neho očakáva pri zmene softvéru pri vývoji a novej funkcionality.

Tím sa zaväzuje, že to vykoná za nejaký čas. U nás to oceňujeme user pointami. Je to fiktívna hodnota, kedy sa odhaduje náročnosť úlohy. Historicky sa dá zhruba vyrátať objem času, ale nie je to rigidná jednotka. Tím povie aká je tam náročnosť.

Takže tím povie, či je to 1 náročnosť - čo je je jednoduchá, 3, 5, 8, 12 sa už ťažko stíha za nejaký šprint. Je to náročnosť, koľko to bude tímu trvať. Historicky sa dá zistiť a odhadnúť, aká je kapacita tímu. Scrum master a product owner vedia, že tento tím, ak nemajú ľudia dovolenky, vie dodať 42 užívateľských bodov. 

Pre veľa ľudí je to nepredstaviteľné, väčšinou sa ráta, že je to nejaká hodina, v agilnom spôsobe sa to odhaduje skôr v imaginárnych jednotkách. Ak má človek historické dáta, tak sa vie relatívne presne odhadnúť koľko to bude trvať. Keď však tím začína, je to veľmi náročne a nevie sa dokonale odhadovať, ako keď sú ľudia už v 50-tom šprinte.

To je to, čo som povedal na začiatku. Princíp je relatívne jednoduchý. Vedeli by sme tu dlho rozprávať o ceremóniách a veciach, ktoré s tým súvisia, ale mindset ľudí v tíme a ľudí okolo, ktorí tam fungujú musí byť iný.

Veľa ľudí očakáva riadenie - daj príkaz a skontroluj. To znamená, že dostávajú nejaké úlohy, vyberajú si tasky a musia ich splniť do určitého času, kdežto toto je iné. Tiež máme úlohy, ale nie je to také rigidné. Je na ľuďoch, ako sa rozhodnú daný problém vyriešiť. V tom ideálnejšom stave, keď je tím už zohratejší, sa im nehovorí ako majú veci robiť. On sám si vymyslí riešenie a urobí ho.

Určite áno. Je ideálne, ak sa dostane do dobrého Scrum tímu, kde majú ľudia dobré zmýšľanie, ako vyvíjať softvér. Tím je vždy rád, že príde nový človek a vedia ho veci naučiť. Tim je naozaj priateľský a riešia problémy spoločne, bez nejakých emócií.

To býva často problém na začiatku, keď sa tým skladá. Ľudia potrebujú medzi sebou nájsť nejaký spôsob komunikácie. Scrum master a team leader tam častokrát musí aktívne vstupovať, aby vedel tím koučovať.

Najhoršie, čo môže agilný tím postihnúť je, ak vznikajú nejaké problémy v medziľudských vzťahoch. Tím musí mať pokoj a kľud na to, aby vedel dodať čo najviac práce.

Aj. Tím sa stretne aspoň raz za deň na rýchlom meetingu, kde si vidia do tváre. To je ideálne. Ak sú nejakí ľudia, ktorí pracujú mimo Scrum tímu, tak sa v dnešnej dobe používajú rôzne video konferenčné nástroje.  

Je dobré vidieť do druhého človeka, ako sedí za compom niekde v inom kúte krajiny a komunikuje s vami. Je dôležité vnímať emócie na ľuďoch a tím je na tom postavený, že sa začínajú viac vnímať a rozumieť si, prečo tak reagujú a kto si čo vyberá.

V šprintoch by mali mať ohodnocovanie user stories, ktoré sú pripravené. To znamená, že aspoň 2 x za šprint by sa mal tím zísť a mali by diskutovať o riešeniach. Či akceptačné kritériá, ktoré sú v user stories alebo zadaniach, spĺňajú štandardy, že tomu dobre rozumejú a vedia, ako by k tomu mali pristúpiť a na konci to skončí tak, že tím na prehodnocovaní užívateľských stories uhodnotí stories pointami. Vie zadefikovať, koľko zhruba by mohla byť náročnosť vývoja a to je skvelé.

To je samozrejme bežná životná situácia a môže sa stať, že dokonca dvaja nie sú v tíme, v prípade nejakej chrípkovej epidémie. Je na product ownerovi, aby prehodnotil backlog, alebo šprint, ktorý prebieha, aby sa snažil prácu zjednodušiť, alebo rozdeliť ju medzi viacerých ľudí a snažil sa dodať čo najvyššiu hodnotu. Ak sa mu to nepodarí, tak môže user stories aj pozastaviť.

My máme softvér, ktorý sa bežne nepoužíva. Je to dané z nejakého historického dôvodu. Bežne sa používa Jira, bežne sa používa Team Foundation Server (TFS) a používa sa aj Trello. Niektorým tímom stačí mať Kanbany. Záleží od komplexity projektu.

Ja si myslím, že pre malé tímy a tímy, ktorých nie je vo firme viac ako 2-3, je to úplne ideálne na koordináciu. Pri väčších tímoch, kde je vyššia miera koordinácie je dôležitejšie mať nástroj, ktorý si Scrum masteri dokážu modifikovať počas fungovania. Trello minimálne, ale Jira je nástroj, ktorý sa už dá silno customizovať, alebo prispôsobovať požiadavkám jednotlivých firiem.

Ešte taká zaujímavá vec k Scrum masterovi. Ideálne je, keď začne byť tím samoorganizovaný. To je pointa agilného vývoja, že tím dokáže sám riešiť problémy. Ideálne je ak je Scrum master akoby úplne neviditeľný, to je cieľ môjho úsilia, aby som tam nemusel byť.

Je to paradoxné, ale je to tak. Tým, že ja mám rolu spojenú ešte aj s leadershipom aj nejakých technických vecí, tak polovicu času pracujem ako Scrum master a polovicu času sa venujem technickým veciam, people managementu a strategickým rozhodovaniam o projektoch, ktoré majú prichádzať.

Scrum master by mal pozorovať a zistovať, čo sa deje a vhodne do toho vstupovať. Okrem prípravy meetingov zodpovedám za to, že tam tím príde, bude im všetko fungovať, budú mať všetky priestory a možnosť, aby fungovali.

Scrum muster je vlastne servant leader, čiže služobný leader, ktorý slúži tímu. Nie je to tak, že ja som ten, ktorý stojí nad tímom, podsúvam im moje riešenia a moje nápady a snažím sa ich nejako usmerňovať. Skôr pomáham tímu, aby tím dokázal dosahovať to samorozhodovanie a mal vytvorený priestor na to, aby mohol fungovať.

Je to zvláštny prístup v porovnaní s tým, čo tu fungovalo a čo sme mali na školách. Boli sme riadení niekým, kreativita a samorozhodnovanie bolo utláčané do pozadia a teraz sa od ľudí chce to opačné. Aby sa vedeli sami rozhodnúť, dohodnúť so svojimi kolegami a aby vedeli dodať to, na čom sa dohodli.

Tím si zodpovednosť berie tak prirodzene. Nevnímajú to ako zodpovednosť, berú to tak, že my to vieme, robíme to, lebo nás to baví a chceme, aby bol produkt super.

Scrum transformácia nie je ani tak technická transformácia tímov, ale je to skôr transformácia zmýšľania. Väčšina firiem vidí prechod na agilný vývoj ako príležitosť ako ušetriť, pretože agilné tímy majú multifunkčných ľudí, ktorí vedia rôzne odbory od databázy, cez programovania a iné veci.

Čiže by mali ovládať viac, ako jednu špecializáciu a firma by mala vlastne ušetriť. Ak je toto motivácia, tak sa častokrát stáva, že implementácia zlyhá. Prejsť na agilný vývoj a na scrum znamená aj zmenu prostredia, ktoré je mimo IT a vývoja.

Biznis ľudia musia začať rozumieť, že nesmú vyrušovať a musia sa lepšie pripraviť, lebo určite sa to dá. My máme road mapu produktu na roky dopredu a potom už len prispôsobujeme. Ak sa to dá aj v menšom, tak sa to dá určite aj niekde inde. Čiže je to skôr kultúrna zmena. Kultúra vo firme je kľudnejšia. 

Ďakujem aj ja.