S Lukášem Linhartem o Scrumu

vítejte u poslechu podcastu you Build it Jan Podcast o všem co potřebujete vidět když chcete provozovat globální internetovou službu tématem vás provázejí Láďa a Vilda dnešní díl je speciální protože kromě mě vy Ládi na které jste zvyklí se k nám připojí host tím je náš kamarád Lukáš linhard neboli almat almat byl prvním zaměstnancem apiary zastával tam funkci cto A hlavně nás najal má zkušenosti s vývojem vedením projektu i se zodpovědností za produkt jako takový a hodně se zabývá produktivitou týmu právě s almaden se budeme bavit o skru almare Vítej a ahoj ahoj ahoj Dneska se chceme povídat o skru protože pro mě osobně já s tím mám velký jako BeF já toho já si nemyslím že to je dobrý způsob jak to dělat a a i zmínka kterou jsme udělali kdysi v nějakým předchozím dílu vyvolala hodně spoustu reakcí takže zdá se že to je jako téma který rezonuje tak jsem se chtěl o tom vlastně pobavit a zjistit co si o tom myslej ostatním Já bych přesně navázal na to protože asi každej vývojář má zkušenost

se skrem ale prostě musí se zeptat jaký skram v každý firmě dokonce V každým týmu bych řek se to dělá jinak Jo a někdy je ta zkušenost dobrá někdy špatná [Hudba] a já mám 80% tý špatný takže skram mu moc nevěřím a proto jsme si pozvali někoho kdo na to má opravdu názor a trochu tomu rozumím Takže almade jak když se tě někdo zeptá jestli jako bys použil scram nebo Měl bys ho někomu vyložit Co to skram je tak jak ty se na to

koukáš No já se vždycky nejdřív zeptám na co ho chcete použít a musím říct že mě baví ten úvod protože já jsem myslel že jste říkali že chcete abych skram kritizoval ale teď jsem stavě skoro do pozice že bych ho měl hájit tak to bu muset nějak rozetnout ale já jednak jako souhlasím s tím že skram on byl kdysi nějak definovaný napsali se o tom nějaký knížky a že jo byl nějaký ten začátek poom co bylo Manifesto akorát oni tenkrát chytře řekli že to jako není metodika ale je to framework a že na tom frameworku máš budovat a tím se z toho stala taková trošku jeda že jo jako prostě framework pro vlastní ticketing systém a díky tomu z toho vznikají výstupy který podle podle mě nejsou jako úplně porovnatelný a ale myslím si že je v tom několik hlavních nápadů který můžou dávat smysl podle toho co člověk dělá protože jako další věc která Eh je v tom skram schovaná na kterou se zapomíná že jo ono to jako mělo nějakej kontext ono to vznikalo v nějaký době že

jo převážně v 90 to znamená eh software se ještě lisoval na CD když jste jako Měli štěstí a e už už jste měli CDčka ještě ne diskety A to znamená že ten relase cyklus byl úplně jinej než Na co jsou eh lidi dneska zvyklí a v tom v tý metodice se to odráží a teprv pak se to nějak jako měnilo e Takže moje otázka první by byla jestli teda ještě shipujete CDčka a Nebo už děláte něco jinýho a není to tak blbá otázka jak to zní protože jsou firmy co šuj CDčka E jako že jo když když jsou diskonekt datacentra eh když si dělaj up Story co mají gatekeeping který muu kterej jako nejde obejít tak přece jenom je člověk tlačený k těm velkým Rů a ne k tomu Continuous delivery takže eh moje první otázka je jako co co je kontext k čemu to chcete použít v našem v našem kontextu my se bavíme vlastně vo vo tom kdy ta věc je as a Service to znamená ne Právě si nedávají CDčka nebo nedávaj

seminár který si rasou jednou za x že v momentě kdy člověk dělá jako desktopový software nebo něco takovýho tak to jako furt asi dává smys smysl nebo minimálně nějaká část ale v kontextu právě jakoby toho software Z Service kde kde najednou jako se rozmaže to co je release ve skutečnosti že jo protože já můžu vlastně udělat tři releasy za den jako můžu nebo N dělám jednom za čtvrt roku záleží tam spousta jako faktorů Tak já třeba právě vlastně mám pocit že to jako že ten scram nebo já jsem velkej fanoušek Angel manifesta ale People a process Přesně tak ale a teď to je o tom ta zformovaná verze scamu vlastně je užitá jak říkáš na nějakej konkrétní na nějaký konkrétní místo dobu proces způsob jakým jako způsob dodávání toho softwaru který se vlastně v tom jako s Service světě totálně mění A kde já najednou scram považuju za strašný blok a chtěl bych jako furt jet Jako Agile ale ne scram ex možná možná První otázka je existujou alternativy No já si myslím že to je

největší Jako problém s kramu že to je v podstatě jediná jako z formalizovaná široce používaná metodika protože Co Co je jinýho máš jako kanban ale většina lidí používá kanban jako máme kartičky a posíláme je zleva doprava To je všechno e nic proti tomu je to jako dobrá metodika ale není to není to nějak jak rozvitý nepomáhá to neřeší to spoustu problémů který člověk při tom vývoji musí dělat jako jak pracovat s odhadem jak pracovat jak dělat nějakej sakh Band prostě jak to navazuje na produktový plánování to tam není vyřešený eh shapeup se profiluje jako enti Scrum ale když se člověk podívá na ty Core nápady který v tom jsou tak já mám pocit že to je naopak Návrat ke kořenům zamu e protože h ono se na to podle mě dá dívat ještě nejenom jako tak že děláš teda nějaký relase pro nějakej upstore A já si myslím že druhej validní způsob kdy použít scram je když chceš řídit software pomocí v podstatě sponzoringu jako nebo budgetu jako tady máme Budget na tři tejdny toho vývojového týmu já za

ty tři týdny chci něco vidět a ta metodika měě organizuje k tomu aby na konci těch tří týdnů bylo něco co jde doručit co co jde ukázat zákazníkům utratily se na to ty peníze který já jsem chtěl a jdem dál a Eh tam já mám pocit že jsou trošku ty kořeny toho scrumu že když se člověk podívá na backround těch lidí tak jako hodně lidí okolo toho scrumu byly v podstatě okolo agentur jako agenturního vývoje a vývoje softwaru na zakázku Což vlastně dneska už taky je míň protože to co se dřív dělalo jako software na zakázku se dneska produkovalo jako dřív měl každej SHC svůj vlastní eshop dneska prostě vezmeš Spotify a jako nemá nemá cenu to řešit ne Spotify shopify e shopify No jo tady Tady je vidět tak často prodávám boty a poslouchám poslouchám streamovanou hudbu No nebo Shoptet u nás v Čechách no dobře nebo Shoptet ale vlastně spousta toho C vývoje se produkovala že jo právě do nějakýho SAS continous Ler a tak ale myslím si že furt může bejt prostředí kde tady ten

přístup je validní a myslím si že třeba jako u některejch přístupů toho Zero to one to vlastně může bejt validní na začátku toho vývoje kdy řekneš jako já dávám měsíc dva na nějakej experiment a na konci toho chci mít něco co Buď funguje nebo ne A myslím si že to je třeba jako jeden z klíčových aspektů jak scamu Eh tak Shape upu kterej hodně lidí opouští v momentě kdy scram implementuje e a to je že jako to co se nestihne na konci sprintu se má upustit A má se naplánovat další Sprint který má svůj další sprint Goal ke kterýmu Lidi jdou který navíc ta původní metodika vůbec nic neříká o nějakých jako estimate kartičkách Story Poch pling pokru tam nic takovýho není tam se říká Jako tady je sprint Goal tam bysme za ty tři č tejdny měli bjt Jdem k němu a jeden z cílů toho je na konci mám teda nějaký něco co má možná nějak uřezaný rohy ale můžem to jako ukázat zákazníkům Co je náš další sprint Go a to co se n

stihlo by se jako mělo opustit Protože to je něco co jako že přesáhlo ten Budget ale nemělo by to vadit Protože ty bys měl down skupovat tak abys měl nasaditelný software a znova se ptáš co je naše největší byznys priorita co má největší přínos zákazníků ale jako v praxi Jsem většinou viděl takový to No ale tady nám z toho vypadly bugy a No ale tady ty věci jsou ve skutečnosti jako fix scope a ne variable scope a musíme je dodělat a teď jako ale není to úplně na další sprint a vlastně zároveň máme qa a navíc jako jsme to nasadili a teď máme Production incidenty A co teď jako s tím a to to že ta původní metodika úmyslně nepokrývá oni říkaj že jsou Development metodolog jako že to je eh vlastně jako code Production metodika a ne jako kompletní product Life Cycle metodika ale to už se nějak do těch dalších iterací nedostalo No to je asi ten problém ne jakoby že dneska těžko budeš osamoc osamoc vaně ne nebo jakoby jenom vyvíjet že jo většina firem vyvíjí

bug fixuje provozuje tu věc my se bavíme v kontextu you Build It You Run it máš celej ten Life Cycle že jo proto ten fit Možná vývojáři neviděj protože vlastně přesně ten problém je v tom pojmenovaný že já 90 % věcí co ve sprintu Nestihneme se přelije do dalšího sprintu automaticky a ve spoustě týmů jsem ani sprint góly jsme nedělali Což mě docela štvalo protože si myslím že to dobře umělo motivovat tým protože když jsem dělal v jednom týmu eh na začátku roku tak tam jsme to hodně dělali vždycky jsme si tu primární fakt jsme hodně tlačili aby ten sprint Goal jsme doručili a bylo to fakt jako i motivační pro ty lidi takže to jako funguje ale to přelejte roluje to jak nějakej sisifos jo prostě Al ta z idealizovaná verze ta zidealizovaná verze je fantastická tu chci jo Řeknu si kam protže to je v podstatě takhle jakoby je to pro mě to je masivně intuitivní takhle jako já když mám dělat nějakej projekt tak takhle ho udělám Mám tady nějaký cíle prostě chci dosáhnout tohodle cíle tady

to jsou věci co musím udělat uděláš tu takovou tu nejvolnější kostru prostě todle se musí stát všechno ostatní jsou méně podstatný a takhle si to z prioritizovat způsobem dojdeš Nemyslím si že sprint je správnej název protože to vzdávání běháním A ty nechceš běhat jako běhat prostě 20 maratonů za sebou ale jasně eh jako Dojdeš tam a pak jdeš a co je co A v ten v ten moment ty musíš evaluovat Co je další cíl že jo A může to bejt z pět těch věcí a může to bejt sprint jako stabilita je problém Musíme to opravit jo děkujeme české ty přítelství se nic nedá nic prostě omlouváme se musíme to opravit jo to je v ale do toho hází vidle v momentě ten provoz že jo kdy najednou přicházej vlastně jakoby výzvy z venku který jako který nejdou naplánovat protože to je Já nějakej Security incident nějaký CV prostě třeba v klu prostě nebo něčem Jako to si nevybírám to musím teď udělat Musí to někdo udělat a jak todleto zakomponovat možná je ten ta největší

Challenge jo no Jako já si myslím že jsem měl docela slušnej úspěch s tím že jsme řekl e protože teda zn se vracíme k tomu kontextu jo protože ono vlastně když na to člověk zavzpomíná tak na tom konci 90 na začátku prostě ty první 2000 že jo bylo ještě běžný že jsi měl separátní qa měl jsi separátní provoz a dost často jsem software se vyvíjel tak že j poslal ty CDčka těm zákazníkům oni si to provozovali a ty si jako další sprinty dělal jako Service Pack v podstatě Jo a ty produkční incidenty byly problém toho zákazníka který okolo toho měl svůj vlastní proces a který ti případně jako eskaloval tvoje bgy který šly do dalších releasů takže to fungovalo Já jsem měl omezený úspěchy když už jsem teda skrt musel používat s jako s tím Robová že jsem řek že Story není Done když je vyvinutá ale když je na produkci takže vlastně jako dostaneš tu Continuous delivery trochu do toho vlastního jako scam cycl a s tím že vlastně skoro všude kde jsem byl tak jsem zaváděl něco čemu teďkon

říkám interruption Shield to znamená v tom týmu je jeden člověk co je prostě mimo vývojový cyklus a jeho úkolem je odstínit zbytek lidí od E od jako vyrušování To znamená že odpovídá když někdo přijde do týmový slacku on primárně odpovídá na slacku e on je po tuhle dobu on call on dělá traj bugů a buď je rovnou opraví a nebo je prostě dá nebo je dá do backlogu aby se teda udělali V dalším sprintu a vlastně řeší a když má náhodou čas tak řeší takový ty drobný automatizace prostě upgrady závislostí eh udělá Ráž upgradu závislostí prostě opraví ty Miner verze Co co jdou a ty větší zase jako hodí na nějakou na nějakou jako Spring Spring B hromadu a to do nějaký míry řeší některý ty problémy ale myslím si že jako to hlavní rozhodnutí co by mělo být Je jako firma jako produktový vývoj děláme fixed scope a nebo fixed time a to se myslím hodně odvíjí od toho jak vypadá náš cyklus předtím jakým způsobem připravujem ty Stories Jak velkou důvěru máme v to že ty Stories tak jak je máme

nadefinovaný vedou k tomu zákaznickému výsledku co my chcem a tudíž jak moc chcem zafixovat ten scope Prostě udělali jsme nějakej research udělali jsme spoustu interview e interviews navíc Tady máme nějaký data Jako z podoční ho testování víme že tenhle skou prostě potřebujem a chcem na tom dělat dokud to není a pak si myslím že ten scram jako moc nefunguje A nebo eh naše jistota ohledně těhlech věcí je málá máme spíš nějakej hunch tady je nějakej tak nějak definovaný nápad prostě do něj Pojďme x tejdnu bušit podle toho jak máme Apetit dát ho ven sbírat data a a za jako zatím jdem dál a tyhle dvě věci jsou podle mě jako fundamentálním konfliktu který je potřeba si rozhodnout a samozřejmě je tam ještě jako ten Element toho že dost často Tohle je v podstatě per Story per nějaký ten sprint Goal a většina tým Podle mě je vlastně pro ně dobrý mezitím přepínat jenom to zas Jako není dobrý pro nějaký rituály nějakou kadenci nějaký to jak lidi fungujou Eh no zároveň teda eh to podle mě cos

říkal ty Láďo ohledně tý schopnosti zformulovat ten sprint Goal Já si myslím že to dost často taky poukazuje na tom jestli ve skutečnosti člověk má produktový tým protože dost často nemá produktový tým dost často má 10 lidí co dělají na osmi věcech a každej z nich je nějakej jako Random fixer nebo má prostě One Man size Project A dělaj spolu jenom kvůli tomu že jako maj jednoho manažera Klasika já teda jako eh J mi připomněl jako podle mýho názoru totální Anti pattern kdy jako 18 lidí hodinu má takzvanej standup kde každej po jednom je vyvolávaný A říká co zrovna udělal a oni teor každe dělá načem úplně Jin oni jako Teoreticky pracujou na jednom jakoby velkým projektu ale každej dělá tak úplně nezávislý věci že to je jakože jakože pro 2 tř lidí je to jako naprosto irelevantní a tak dále a dělají si tadyhle ty cykly Já si třeba osobně myslím že právě ten že ta že vlastně problém v toho v tý možná ne v tom scrumu jako takovým ale nejčastějc v tý

implementaci toho scrumu je že je jako relativně rigidní a není schopnej přepínat mezi tím jako dělám nějakou fci kterou Vím že potřebuju protože je vlastně jakoby vymyšlená a já jí potřebuju a v podstatě když to řeknu eh jako z pohledu H jako naprosto sprostě tak jako já mám Waterfall kterej potřebuju naimplementovat a mám jako a to je to to je ten můj cíl jo protože už jsem to vyzkoumal tak najednou jako ten sprint Já ho protáhnu na třeba šest tejdnů osm tejdnů a prostě dokov ať to nebude hotový že jo protože to je nutný ale ve většině případů mám pocit že se to dělá hrozně formálně a vlastně ten systém je velice rigidní A není z to na todleto přistoupit Většinou to je jako máme sprinty Co jsou 14 dní a vlastně n debatujeme vůbec o tom jestli 14 dní je správně Nebo nebo by to mělo bejt tejden nebo by to mělo bjt měsíc nebo to už se vůbec skoro nedělá jako velice často to je prostě takhle to tady všichni dělají Jo a nebo přesně vě to vedení to takhle

Chce to To jsem slyšel často že vedení to chce chce chce hlášení ve 14 denních cyklech tak nemůžeme udělat tří týdenní ty cykly prostě a hotovo když by nám to dávalo smysl a podobně No v tomhle je schovaných několik věcí teda určitě já ještě jako na začátku nemůžu si odpustit můj oblíbenej býv na standup teda to nás asi víc Podle mě Podle mě se pozná úplně jednoduše jestli máte standup A nebo reporting co na tom meetingu dělá manažer jo přesně tak pokud máte standup Pokud máte standup tak taky říká co dělal a co nedělal a jestli jenom poslouchá tak je to prostě reporting a druhá věc je že přesně Většina standupu se zvrhla do toho co jsem dělal včera co budu dělat dneska ale podle mě framing standupu by měl bejt jak jsme se spli s naším sprint Golem a jsme On TRK s tím co nám zbejvá vaše Side projekty jako že si děláte nějakej compliance trening to je jako hezký a povinný ale nikoho to nezajímá jo a a když když prostě ze

standupu se stane jenom jako reporting kontrola manažera těch lidí tak to dopadne přesně tak jak jste řekli a samozřejmě potom jako většina lidí má neomezený schopnosti Bullshit vat o tom co včera dělali jako když hráli fotbal Jo jako v momentě Kdy máš obhajovat svůj čas tak prostě se něco stane eh Ale s tou dýkou těch Cik Já si myslím že právě to je hodně o tom co je sprint a vlastně sprint směšuje několik věcí jako implicitně který jdou vyřešit odděleně v tom scrumu jsou jako úmyslně daný dohromady protože to dává smysl ale lidi se na ně nedívají odděleně a nesnažej se jako vyřešit odděleně a pak to způsobuje tyhle problémy Jedna Jeden z nich je znamená scram release a tím se vracíme k tomu teda je to code Complete a pak děláme nějakej bug fixy a nějakej release a nějaký prostě další jako věci který nám zase případně haprují s dalším jako sprintem a musíme tam dělat nějakou tejden pauzu nebo co s tím jako děláme druhá věc je reporting to znamená jak informujeme nebo zákazníky nebo nějaký

další stakeholdery o tom jak se hejbeme s nějakým dým plánem a nějakou naší Road mapou třetí věc se potom Nějakej improve nějaký cyklus zlepšování a to je to kde do toho scram zapoj nějaký retro nějaký Action Items a nějaký vylepšování toho procesu jako takovýho eh a pak je plánování Jo to znamená a to je další věc děláme nějaký Bottom up plánování protože N jako plánování ze zdola protože náš tým má dostatečný nové nový dové nový znalosti a produkťák e aby byl schopnej iterovat naad nějakýma metrik nebo znalostma zákazníků to je to co všichni říkají že chtěj a pak většinou dají nějakou čtvrtletní od mapu ze zhora a řeknou Takhle to bude a to Takže jak tyhle dvě věci navazují a jak se podporujou a myslím si myslím si že to je něco co Eh je dobrý se na to podívat odděleně a říct si je to co skram popisuje a to to jak to předepisuje e to co nám dává smysl a nebo ne Protože tohle potom souvisí s tou dýkou těch cyklů protože původní scram říkal no tak ty čtyři

tejdny jo protože když si teda loval ty CDčka tak jako každej tejden to nedávalo smysl No ale e pak hodně lidí protože jeden Z původních teda vyloženě i cílů já si pamatuju že v tý původní knížce byl nějakej člověk z Microsoftu Co říkal jako jeden z problémů kterej nám to vyřešilo bylo že produkťák chodili dvakrát denně k týmu a furt chtěli nějaký změny a my jsme neměli žádnou dobu kdy se soustředit a udělat něco skutečně doručit něco většího a skram nám hrozně pomohl v tom že eh prostě na těch na ty čtyři tejdny jsme zvládli doručit nějakou větší funkcionalitu a nechodili nám do toho právě nějaký jako furt změny nebo back reporty donutilo To produkťák si skutečně rozmysl co chtěj na druhou stranu právě v sasu e hodně týmů znám konkrétní případy nebudu jmenovat e to začalo používat jako jo vy chcete opravit ty typu tady na naší landik website No my jsme zrovna začali náš třítýdenní sprints takže to bude za sedm tejdnů No tak logicky jako že začal hledat ten kompromis jako dobře rozumím

tomu že potřebujete nějakej čas na to abyste něco doručili ale jako sed tejdnů na typu What the is happening a tak se z toho začal dít takovej ten kompromis No tak zkracujeme teda na dva tejdny tejden a najednou jako máme prostě Grooming planning a retro každej tejden a vlastně to nikomu ne nedává smysl Tak to děláme každejch x sprintu a vychází z toho nějakej Hybrid že jo Ale myslím si že ten Rot Cos je že ten scram v tom původním kontextu všechny tyhle věci splet dohromady a a lidi je teďkom vnímají dohromady a řešit dohromady i když by vlastně nemusela jenom to má jako spojený s tím skrem Hele a ten shapeup to nějak jako adresuje tyhle vlastně jako problémy m Já co jsem čet vlastně třeba jak to Atakama použí kde jsme byli vlastně že jo na začátku roku e s naším panelem tak mně se tam líbilo že oni vlastně dedik Jou že jo nějakej tým co se stará vo vo Maintenance a vyloženě je to jakoby

projektove.cz toho novýho bingu v oraclu tak jsme řekli dokavaď to nebude hotový tak prostě na to ten tým bude dělat že ten Shape Up mi trochu připomněl tohle jak jsme dělali ty AD HW projekty vlastně a my jsme neříkali že by to byl scram že jo nebo tak a já myslím že ne protože jako zrovna Eh tam bych rád podotknul to cos jmenoval to nebyl technickej dluh to bylo prostě nafoukla se nám testu ta tak že lidi nebyli schopni doručovat potřebujem bejt schopný znova doručovat a ukazuje se že to je problém co se sám nespraví a naopak ten Blink byl do značný míry jako tady je deadline tady je fix scope a prostě se do toho buší dokud na tom každodenním inku není 300 lidí a jako nevyřeší závislosti že A jako špa má několik hezkých nápadů oproti scrumu Jeden z nich je si myslím že zdůrazňuje tu roli toho apetitu oni tomu neříkaj Budget ale říkají tomu Apetit že jo To znamená máme tady česti denní cyklus e jakej máme Appetit do kterejch věcí investovat a to je to je jako ten

fix scope e druhej hezkej nápad je tam to že říkaj eh logovat všechno do backlogu a pak na to Nešahat je kravina e vyřešili To teda tím že jako každej máme svůj vlastní backlock Ale líbí se mi že propaguju tu myšlenku jako když mám dva roky starej bug eh jako vůbec validace toho jestli ten bug ještě existuje může bejt delší než jeho oprava nebo vlastně jako co se děje a většina lidí to řeší pasiv agresiv a prostě nechává to vyhnít a je to většinou protože není kultura říct ne Mhm eh a třetí hezkej nápad co se mi tam líbí je ten productivity Hill protože to je jeden z mejch velkejch bů se skrem kterej je eh jako kterej se materializuje v podobě grum meetingu e a to je že skram má tu ideu že větší projekty jsou rozpadlý na menší tsky s dostatečnou granulitů aby tomu ty lidi rozuměli eh a že tenhle proces se děje v nulovým čase eh a když se to neděje v nulovým čase tak se to v nejhorším stane na tom Grooming

meetingu e kterej se stane v čase Co je jako hodina třeba nebo něco takovýho a všichni myslím si že většina lidí co někdy dělala scram tak jako zažili takový ty čtyřhodinový horror grou meetingy Který stejně nepřipravili na ten na ten sprint a to je proto že tam je podle mě jako falešnej předpoklad že rozpad eh velkýho problému na menšího problémy e ti dá větší přesnost A to není pravda sama o sobě podle mě ten důvod proč rozpad e většího problému na menší problémy ti dává lepší představu o tom co ten problém je a tím pádem KD ho budeš mít hotovej je protože zároveň s tím děláš Discovery toho problému jako takovýho ale u komplikovaných věcí ta Discovery je 80% toho problému Prostě v momentě kdy já už jsem prozkoumal ten systém a vím co mám dělat tak už jsem vlastně hotovej To už to už to stačí napsat to už je to jednoduchý že a to v tom scamu není obsažený je to obsažený v tom shap upu protože jo eh scram že jo ty

pokročilejší verze víc Technic sní verze scamu mají ten Burn down Charge to znamená na začátku jsme udělali nějaký Story pointy v tom v původně skru hodiny a teď měříme to jak nám to ubejvá k tý nule a šam říká Ne to co byste měli očekávat je že v první polovině toho cyklu ta práce přibejvá vám se tam objevuje čím dál víc tý zbývající práce a někde v půlce byste měli dosáhnout toho že už víte co ten problém a skutečnost to začne ovat k tý nule nebo možná ne k nule ale k tý deliver jako začínáte na začátku děláte Discovery objevujete co se vlastně má dělat z toho vypadávají ty Katy který přibejvá v druhý půlce už to víte a začínáte řezat ty rohy abyste stihli ten zbytek Měli byste dosáhnout něčeho co je jako user deliver B zbytek se upustí e jdem tvořit novej betting table a to podle mě jako mnohem víc odpovídá tomu jak se software skutečně vyvijí určitě no Právě přesně že potom já si pamatuju Ještě když jsem dělal vmc tak jsme měli jako sprinty kde

se dělal ten research aby se z toho mohli udělat ten tikety že jo že třeba jsme tech Lída alokovat research dostatečnej nebo poc že jo na těch věcech aby se z toho potom dal udělat normální tiket že jo No a na tohle ti Adal kouči řeknou že tole to tole se říká Spike a máš mít jako Spike Skies a ty nemaj estimate a maj člověka Jenže pak zase Narážíš na to že aby ti to fungovalo s těma cyklem Tak ty Spiky a ty Stories musej nějak bejt zarovnaný jako s těma sprint a začínáš BT vlastně míň agilní protože uměle zarovnává tady ty věci že jo jo proto mi ten shapeup dává v tomhle taky smysl větší protože to je přirozenost ty nejdřív děláš nějakej design toho Discovery poc a potom to implementuje to je jako běžnej cyklus že jo prostě a a potom ještě integruje A kdo ví co všechno takže eh potom když někdo diktuje že to má bejt za 14 dní všechno A takhle se tak mi to nikdy nedávalo moc smysl a je

pravda že jak jsme se bavili vlastně o Sar a a tom tak já jsem používal kanban že jo ale víceméně to byl jenom jeden velkej backlock A prioritizace každotýdenní prioritizace to nevím jestli se tomu vlastně dá říkat kanban že jo protože vlastně já jsem jenom prioritizovat eh vlastně kapacitu týmu nic víc jsme vlastně ani dělat nemohli že tak to je ta jakoby že jo ty máš Zrovna todleto tahleta jako řekněme Operations práce jako těžko jí můžeš jako nějak sofistikovaně plánovat jako dlouhodobý výhledy a tak dále A Eh To jo ale přece nechceš to je právě to co já vždycky vysvětluju všem co chtěj zavádět tesari nechceš utopit 100% jejich kapacity v tom Operations jo že vždycky to to jo ale já jsem chtěl říct že že nejde udělat tím pádem e že ty jako můžeš dělat sprinty ale jako incident nepočká Takže jako ty prostě jo takže ten systém jako jako v podstatě priorit na kterých se má pracovat je to co se osvědčuje myslím obecně co jsem měl možnost se bavit s lidma který pracují

těhletěch třeba v oci na jakoby nebo i v těch jinejch kch jinejch kových providerů je to tak že oni mají většinou je to tak že mají týdenní prostě týdenní priority jo jakože něco je potřeba něco co jako hoří z byznysového pohledu nebo compliance pohledu nebo cokoli tak to je jako absolutní nutnost Jo a a všechno ostatní a je snažej se tam samozřejmě jako mají nějakým způsobem vykrojit čas na to na tu úpravu nebo vylepšení těch procesů a zlepšení tooling a tak dále a to si myslím že je takovej specifickej věc kterej ž taková věc že nevím jestli má cenu vůbec se zabejvat nějakýma formálním metod jak to dělat jako než si vyrobit vlastně protože vlastní nějakou verzi inspirovanou tím že jo ale tam je spousta jako tam tam je to tak že ten z mýho pohledu většina toho týmu je řízená jakoby s venčí prostě událostem který se dějou mimo jejich kontrolu a jo a já právě přesně myslím že pro takovej typ týmu nemá vůbec ten scram smysl a viděl jsem prostě že se to snažej naordinovat

na každej tým třeba v product developmentu i když jsou tam týmy jako který víceméně dělají jenom tenhle druh práce Jo a a a myslím si že přesně to nefunguje no no že No já jem Já si myslím že to je protože Většinou když se to ordinuje tak je zatím zvolenej reporting Hm že to není proto že někdo by měl pocit že jako všechny týmy se musej alinova v deliverables ale že my chcem mít nějakou informační syntézu ze zdola o tom jakým způsobem se ty projekty hejbou a rozhodli jsme se pro to použít skram Mhm tak tam je teda ještě No pojde že jo jo jo jenom že že jo přesně takový ty jakoby obvyklý jako Critical projects meetings prostě který se odehrávají ve stejný čas Prostě jednou za tejden todleto a očekává se že jednou za 14 dní nebo jednou za měsíc je prostě jako velký a věc se stane prostě Takže kvůli tomu mají všichni 14denní nebo nějaký sprinty a tak dále no já si myslím že tam je ještě jeden jako z pohledu

managementu dobrej způsob proč mít fixní sprinty a to je Pokud se hodně často hejbe s lidma mezi tým vně jako pokud ty hodně často potřebuješ měnit sponzoring a přesouvat lidi mezi tým Což vlastně ve velkejch firmách se děje relativně často e protože tam taky dost času už si ty lidi prostě najímají jako resource a mají nějaký level a očekává se že prostě projekt SE naplánuje tak že se řekne Ok tady prostě to je Hel důležitej projekt takže tam budou dvě ic6 p ic5 jako 10 ic4 a pak jako 15 ic2 co to budou dělat a Jaký lidi se nahážu do tady těch krabiček to už nás nezajímá To si vyřešte tamhle jako tři úrovně pod náma tak to vlastně jako může dávat smysl z toho pohledu že víš že ty lidi nevytahá váš v půlce projektu že říkáš prostě jak se jak většina lidí z Velkých firem dobře zná jako organizace jsou v kontinuálním reu Takže všichni očekávejte pro jistotu na konci měsíce další ror možná tenhle měsíc vynecháme Ale jinak jako dodržujeme naši standardní organizační agilitu a tím

pádem jako ukončujete svoje projekty ke konci měsíce aby se nestalo že vám toho jako příliš mnoho skončí ve vzduchu A to je z mýho pohledu jako legitimní požadavek No to jako svým způsobem dává jako je je to rozumný zároveň Já třeba Vzhledem k tomu že Oracle nebo oci dělá ty re orgy tak nějak v týl Tý kadenci jo vnitřně to jako není že všichni jo Bavíme se o tom že v podstatě jakoby tam jako opravdu co měsíc je je někde nějakej posun že jo přehazují se prostě lidi vidlema buďto se přehazují celý pod stromy prostě nebo nebo nebo jenom jako kousky No tak to se Hejbá jenom VP SVP a tam to jde s nima že jo takže no tak to není to to i i i menší oddíly prostě jako i menší pod stromy se prostě přes cvaj občas jo chce říct že Oracle přešel už na to že existujou lidi pod direktorem Já myslel že Direktor rozlišovací schopnost No ano ano ano do jako ano jo ale samozřejmě Jsou tam nějaký sila který jsou že jo udělaný těma SVP

že jo který se nepohnou jo ty ty tam je vidět že to jsou pak odlišný organizace který mají jinak strukturu že jo těch sprintů a jinak strukturu vlastně mnoha věcí Protože prostě vlastně fungujou už úplně nezávisle e na druhou stranu je to je to Trade of kterej jako si myslím že dává možná smysl ve velký firmě ale pokov ať je těch lidí 50 Tak je to asi úplná pitomost jo Já jsem zrovna já jsem zrovna chtěl říct No že je pravda že Eh je zajímavý že skram vidím mnohem víc použitej v malejch firmách a mnohem míň ve velkejch No a taky možná problém že právě přesně začne to ve firmě kde bylo 50 lidí nebo 30 lidí ještě možná míň a najednou oni vyrostou na 500 třeba jo Jo a furt vlastně se snažej uplatňovat stejnou metodiku a potom to začne jako vlastně skřípat No tak tam jsou potom různý ty metodiky na ty Scrum of scams a podobně že na to na to škálování scrumu a tak Ale jak říkám já si myslím že tam

je vždycky potřeba se jako fundamentálně říct jsme fix scope a nebo fix time a jakým způsobem eh jakým způsobem má probíhat ta syntéza toho produktu ovho vývoje vlastně jako na co potřebuješ scam of scams je to kvůli reportingu je to kvůli produktovému plánování a je to kvůli tomu že jako ty týmy ve skutečnosti nejsou autonomní on jako ten scram původně má že jo Taky tu ideu máš fully empowered Team kterej je schopnej obsáhnout celej ten svůj Development Life Cycle což může a nemusí bejt pravda jako reálně a já si myslím že tohleto je zrovna docela jako důležitej Point kterej možná jako vlastně jako z tý zkušenosti jako implementační už zanik je že scram v podstatě důvěřuje tomu týmu že je schopnej to udělat prostě a nemá nemá a je autonomní ten tým je schopnej dělat ten tým je schopnej dělat ty rozhodnutí a ne že potřebuje v podstatě je to jako jednotka která dostává řečeno co má udělat jako no tak ono to bylo dokonce obsažený v tom původním popisu standupu dokonce bylo že na standup jak

jako může přijít kdokoliv ale rozděluje se to na slepice a prasata eh protože když se dělá když se dělá Hemenex e tak eh jenom pr jenom prasata se skutečně mají dávají svou kůži na trh a slepičky co tam jenom přidávají vajíčka tak ty mají sedět v rohu A ty na tom standupu nemají mluvit Ok Jo jo přesně tak to bysme měli vystřihnout naopak to je perfektní popis že jo jako jem se setkal na na meetingu jako kterej byl jako řekněme věcný a nebylo v něm příliš mnoho managementu a mnoho jako e procesů tak to bylo jako are you Pick or chicken aha h ale to se vracíme k tomu jako proč tam to management proč chce reporting a on potřebuje ten reporting on jako potřebuje vědět co se v tý firmě děje a teď je jako otázka jestli eh a a vlastně ten reporting by neměl bejt standup ten reporting by měl bejt ten Scrum Burnout a a ty sprint outcomes a to je samozřejmě jedna z těch to je to je jako další věc Já si myslím že skram

obecně vlastně funguje velmi dobře když funguje ale ne jako ty nástroje na debugging toho když nefunguje nejsou moc dobrý nebo respektive Jakmile někdo začne debugovat scram tak to celý začíná být přesně takový to peklo na jaký jsou lidi zvyklí že jako na tom standupu lidi mikrom managu prostě je ta visibilita ale ponořují se do toho lidi který tomu nerozuměj takovým tím jako Seal managementem že jo jo to

jezný no ale samozřejmě jako a tady to je ten moment ky kdy si můžeš říct dobře scram nefunguje nebo si můžeš říct scram funguje ale vy jste ho blbě implementovali A nebo se teda můžeš zeptat jak to opravit a já si myslím že ta část jak to opravit se řeší málo a vlastně my myslím si že jeden z problémů co trošku máme jako Industry je eh málo se bavíme o tom jaký jsou ty Způsoby jak dělat ten produkto Vej vývoj mimo nějakej scram a teda nějaký kartičky je něco co je mezitím jaký jsou navazující problémy pro produktový vývoj jakým způsobem vlastně produktový management a Development na sobě navazuje jako v éře Continuous delivery a ve všem tomhle A nějakým způsobem to popsat Já si myslím že tam jsou jsou prostě furt ještě rezervy eh i proto že ze scamu v nějakej moment se stal prostě jako ideologie e tak ideologie a identita a to to je potom jako vždycky vždycky těžký o tom víc nějakou diskuzi e a myslím si že to je furt ještě

prostor kterej který se dá prozkoumat líp A strukturovaně pro mě je vždycky otázka jestli dává smysl nebo takhle jinak eh pro mě ta otázka vždycky stojí jako jak naimplementovat ten ten scram pro ten danej kontext protože jakoby ty ideje řekněme ty idee s těma já jakoby souhlasím většinou Problém je v tom že ty implementace jsou jako řekněme nějakým způsobem E jako rigidní nebo jsou jako přenesený vod někud jako takhle nám to fungovalo teďka v ten moment chybí mechanismy jak to opravit jo jo jo jo že jo to je jasný jo jako to je prostě jak lidi fungujou že jo že tak fungovalo to támhle tak mi to bude fungovat i tady e ty změníš kontext takže to vlastně vůbec Tak bejt nemusí já si myslím že ses dotknul jako ještě jedný věci a to je že podle mě hodně těch metodik který eh nějakým způsobem se snaží řídit vývoj jsou mikromanagement způsobený tím že

eh vývoj říděj lidi který s vývojem nemají zkušenosti a mají Problém rozpoznat jako bullshity Bullshit a výmluvy od reálných problémů a to se potom do toho jako hodně propisuje a já si myslím že dobrej způsob jak to vysvětlit je že jako vývoj je taková věc která je hodně kolaborativní je tam jako hodně nejistot je tam hodně vymyšlení samozřejmě nějak se to řídit a odhadovat musí Ale je to hodně organická věc a je podobná takový jiný věci se kterou tady už máme jako ST let zkušeností a tím pádem bysme jme taky měli mít ty dobrý metodiky na odhad vývoj Story pointy a to kdy co má bejt a ta disciplína se menuje management A Eh je to myslím dobře vidět právě eh i na tom blbým standupu že když jsem po manažere chtěl aby říkali co dělali včera a co budou dělat dneska tak polovina z nich se mi snažila vysvětlit že to jako nejde jo že ta jejich práce je prostě nestrukturovaná A je tam spousta těch adhoc meetingů a prostě eh nedá se to plánovat takhle dopředu jak

je tam rozdíl oproti vývoji a jde to já jsem chodil na standupy jako Direktor jde to ale je to myslím dobrej způsob jak předat jako tomu managementu kde je ten problém toho když se snažíš rozdělit vývoj na jednotlivý tud otázky který jsou vytvořený dopředu a od tý na hodiny co by to to u to toho managementu je to efektivní to je jiná otázka Hele Alm Díky díky za to žes byl náš host Podle mě to bylo super inspirativní a doplnilo to skvěle o čem jsme se Už bavili No jo díky moc prní test s hostem uvidíme jak to vůbec jako vlastně vyleze z toho Uvidíme kolik vám to odebere