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

Boris Plevza

V tomto rozhovore sa dozviete:

  • čo je to agilný vývoj
  • aké výhody prináša agilné riadenie oproti tradičným vývojovým metódam
  • ako sa prioritizujú úlohy v agilnom vývoji
  • čo je to metodika Scrum
  • z akých ľudí sa skladá Scrum tím
  • čo znamenajú pojmy šprint a backlog
  • ako vyzerá úloha Scrum mastera v tíme
  • na čo by si mali dať firmy pozor pri využívaní metodiky Scrum

Odkazy na najdôležitejšie veci z 18. epizódy

Stačí dať PLAY:

Kde všade môžete počúvať Podnicast?

Klikni sem, ak chceš počúvať na Spotify

Spotify

Klikni sem, ak chceš počúvať na Stitcher

Stitcher

Klikni sem, ak chceš počúvať na Apple Podcasty

Apple podcasts

Klikni sem, ak chceš počúvať na Google Podcasts

Google podcasts

Profil podnikateľa

Celé meno:

  • Boris Plevza

Odkazy na sociálne siete:

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

Ahojte. Vítam vás pri ďalšom Podnicaste. Dnes tu so mnou sedí teamleader a Scrum master agilného Scrum tímu Boris Plevza. Boris ahoj.

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

Som rád, že si prišiel. Chcem urobiť nový koncept pre Podnicast, kedy budeme rozoberať jednu konkrétnu #tému, pobavíme sa o nej a trošku viac si ju priblížime.

Dnes som si vybral tému Scrum, čo znamená agilný vývoj. Je to téma, v ktorej ja osobne cítim veľa nedostatkov. Nikdy som v Scrum tíme nepracoval, nepodieľal som sa na agilnom vývoji a veľmi ma to zaujíma.

Dám ti pár otázok na túto tému aj pre začiatočníkov, aby sme vysvetlili, čo to vlastne agilný vývoj je, ale možno aj pre skúsenejších ľudí, aby si nám povedal, čo funguje vo firme tebe a aké nástroje používate.

Začnime úplne od začiatku, čo je to agilný vývoj a čím sa vyznačuje?

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.

Pozeral som si to manifesto a sú tam 4 hlavné body, ktoré teraz prečítam: 

Ľudia a komunikácia sú viac než procesy a nástroje.

Funkčný softvér je viac než vyčerpávajúca dokumentácia.

Spolupráca so zákazníkom je viac než dojednávanie zmluvy.

Radšej reagovať na zmenu, než sa držať plánu.

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.

To je presne super téma, ktorú som sa ťa chcel spýtať. Z akých ľudí, respektíve pozícií, sa skladá Scrum tím, ktorý funguje agilne?

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.

Čiže tester nerobí nič iné, len pomáha overovať, čo programátori navrhli?

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.

Okrem testera je ešte product owner. Aká je jeho úloha a aké má zodpovednosti?

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.

On je súčasť tímu?

Áno.

Aké sú jeho každodenné úlohy? Čo presne robí product owner, kontroluje, prioritizuje, alebo vyberá tasky z backlogu?

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.

Aké sú ďalšie úlohy v tíme? Sú tam aj developeri?

Á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.

Hovoril si, že aby boli tímy efektívne, majú mať počet členov 3 až 9. Ak sú traja, má každý svoju pozíciu, alebo robí niekto viac? Napríklad je aj developer, ale aj product owner?

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.

Poďme si povedať, čo je šprint a aký býva zvyčajne dlhý.

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.

Čiže máte 9 rôznych Scrum tímov, ktorí pracujú na jednom produkte?

Áno.

Kto to celé manažuje?

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.

Čiže tímy sú samostatné?

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ť.

Čiže, keď je nejaký šprint a majiteľ, CEO povie, že túto funkcionalitu chcem mať, tak  product owner mu povie, ok, dokončíme tento šprint a potom máme čas na tom pracovať?

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.

To určite áno. Spomínal si backlog, ako v praxi backlog vyzerá?

Je to nejaká Trello nástenka, alebo to máte na nejakej bielej tabuli, kde máte všetky úlohy, ktoré potom musíte prioritizovať? A ako prioritizujete, ako vyberáte, ktoré veci sú pre zákazníka najdôležitejšie?

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.

Takže sa tím musí trošku zohrať?

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.

Myslíš si, že ak nejaký programátor, ktorý nikdy nebol súčasťou nejakého tímu a zrazu sa stane súčasťou Scrum tímu, potrebuje nejaký čas, aby sa do toho dostal?

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.

Ako komunikujete? Spomínal si nejaké ceremónie, čo to je? Sú to tie každodenné stand-upy, kedy si poviete čo ďalej?

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á.

To je taký rýchly meeting a kedy robíte zásadné rozhodnutia?

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é.

Čo ak niekto z tímu ochorie, alebo vypadne?

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ť.

Aké nástroje používate vy pre agilný vývoj pre Scrum?

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.

Takže úplne stačí Trello?

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.

Ty si Scrum master, ako vyzerá tvoj deň? Čomu sa venuješ v tíme?

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.

Čiže prenesenie zodpovednosti na celý tím?

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.

Posledná otázka, na čo by si mali dať firmy pozor pri Scrum vývoji?

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. 

Super, ďakujem veľmi pekne za tento rozhovor.

Ďakujem aj ja.

Peter Chodelka
 

Podnikám od roku 2012, takže iba začínam :) Ale aj za tých pár rokov som nadobudol skúsenosti, s ktorými sa rád s vami podelím. Či už z budovania siete Affial, predaju vlastných doplnkov stravy Blendea alebo prevádzkovania rôznych affiliate projektov, akým je napríklad na Kombo. Ale v Podnicaste nebudete počúvať iba mňa, ale predovšetkým úžasných a šikovných slovenských podnikateľov. Naučte sa nové veci, inšpirujte sa a zmeňte tento svet aspoň o kúsok k lepšiemu.

Click Here to Leave a Comment Below 0 comments

Leave a Reply: