Začátkem září proběhla konference Agile Prague. K review svých poznámek jsem se dostal až dnes.

Konference Agile Prague byla skvělá. Kombinace přednášek, open space diskuzí a coaching clinic zajišťovala, že se neustále něco dělo. Vůbec žádné prostoje. Kdo například nechtěl obědvat, mohl diskutovat na open space.

Klasické prezentace byly rozděleny na keynote, talk a case-study. Zmíněné case-study byly stoprocentně praktické - řečník v nich popisoval situaci v konkrétní firmě.

Níže jsou mé poznámky z některých přednášek. Nejde o zápis z přednášek, ale o sbírku informací, které mě zaujaly.

Jutta Eckstein - BOSSA nova

Jutta Eckstein v prezentaci vycházela ze své nejnovější knihy Company-wide Agility with Beyond Budgeting, Open Space & Sociocracy.

BOSSA je kombinace trendů beyond budgeting, open space, sociocracy a Agile. J. Eckstein se vydala do nejistých vod inovátorů a experimentátorů, tedy příliš daleko od břehu pro českou kotlinu.

Beyond budgeting: Pevný rozpočet nás nutí stanovit si jasný cíl, odhadnout finanční náročnost a zjistit, jaké zdroje budeme muset alokovat. Vyřešíme-li tyto tři problémy jinak než pomocí rozpočtu, můžeme se odprostit od command-and-control způsobu řízení.

Open space je facilitační technika. Každý může mluvit o jakémkoliv svém nápadu.

Sociocracy je způsob dělání rozhodnutí pomocí souhlasu (tj. consent, nikoliv pomocí dohody). Takto lze údajně řídit i firmu. Zde jsem skeptický.

Nejlepší citace:

People say “fail fast,” but I know no company where somebody from the top admits a failue.

– Jutta Eckstein

Yves Hanoulle - Individuals and interactions over processes and tools

Yves Hanoulle, coby Agilní kouč, doporučuje: “Sebevědomně se ptejte na jednoduché věci při každé příležitosti.” Například pokud vám někdo řekne, že dělá nějakou Agilní praktiku, zeptejte se: “Opravdu to děláme?” Pomocí otázek odhalujte situace připomínající Dilbertův komix a poukazujte na ně.

• Učte lidi se učit (facilitate learning).
• Zeptejte se na povolení, chcete-li někomu pomoci. (Souhlasím! Nic není horšího než sebevědomý člověk, který se snaží všem pomáhat, čímž jen ukazuje na neschopnost ostatních.)
• Používejte retrospektivu k rozhovorům o osobních věcech.
• Experimentujte. Vytvořte model, proč něco funguje (systémové myšlení). Sdílejte jej s komunitou.

Gracie Koester - Diamonds on the Soles of Your Shoes

Mine the gems of dissatisfaction.

– Gracie Koester

Jak těžit drahokamy z nespokojenosti: Nespokojenost → zlatá pauza → požádejte o pomoc → akce.

• Vytvořte kulturu, kde je žádost o feedback odměňována a očekávána.
• Naučte se, jak na feedback reagovat.
• Zeptejte se na povolení, chcete-li dát někomu feedback.
• Začněte u jednoduchých otázek: Jak se ti líbí ta nová květina v kanceláři?

Marsha Shenk - The social brain is the big boss

• Stres tlumí schopnost zpracovávat cokoli nového.
• Ve stresu spolu hemisféry mozku nekomunikují.
• Učení je pro mozek velmi náročné na energii. Proto se během puberty mozek přesune z fáze “učení” do fáze, ve které více spoléhá na informace, které se do té doby naučil. (Před několika tisíci lety se člověk mohl dožívat přibližně třiceti let, proto tak nějak dává smysl, že mozek utlumí učení už v pubertě a ne později.)
• Snažte se, aby se lidé kolem vás cítili začleněni do kolektivu. Tím se sníží stres a zvedne výkonnost.

Doporučené video: Brené Brown - The power of vulnerability

Andrea Provaglio - Leading Within

Existují 4 druhy naslouchání:

1. Downloading. Zvuk se stáhne, ale nezpracuje. Zatímco druhý mluví, už přemýšlíme, co mu odpovědět.
2. Factual listening. Snažíme se porozumět faktům.
3. Emphatic listening. Používáme empatii, cynismus jde stranou.
4. Generative listening. Přemýšlíme, co by mohlo vzniknout z toho, co nám druhý člověk říká. Propojujeme lidi.

Je důležité se věnovat také té části agility, která není viditelná. Začněme u sebe.

Liam Hutchinson - Everyone Is A Designer

Nejinspirativnější přednáška celé konference.

• Design není krásná grafika, ale to, jak věci používáme.
• Každý zaměstnanec dělá denně desítky drobných rozhodnutí, které ovlivní konečný zážitek zákazníka z produktu.
• Do procesu designu je nutné vtáhnout celý tým a ukázat mu, jak zákazník produkt používá.

Roman Pichler - Building a product users want

Keep in mind why we built this product. Otherwise we may end up with thousands of cool features that nobody wants.

– Roman Pichler

Roman Pichler představil svůj product vision board a vysvětlil, jak funguje. Nakonec ukázal, jak může product vision board fungovat s Lean Startupem.

Jedna z nejlepších přednášek. Tady jsem si uvědomil, že bych si měl o problematice tvorby produktů ještě něco přečíst, abych měl alespoň okrajovou znalost.

Amy Jackson - Agile & HR

Líbil se mi nápad dělat interview formou her. V době, kdy je na trhu nedostatek kvalitních vývojářů, můžete takto uchazeče pro svou firmu nadchnout. (Samozřejmě za předpokladu, že gamifikované interview uděláte správně.)

Alexey Voronin - Open Salaries

Open salaris je praktika, kdy všichni ve firmě znají platy všech ostatních. Prezentace byla koncipována formou case-study a sliboval jsem si od ní, že se konečně dozvím, mohou-li open salaries fungovat v praxi.

Bohužel, case-study se týkala ruské konzultanční společnosti ScrumTrek. Skupinu konzultantů nepovažuji za typickou firmu - již mnohokrát jsem slyšel o věcech, které v takové firmě fungují, ale nemyslím si, že by fungovaly ještě někde jinde. Dle očekávání jsme se mezi řádky dozvěděli, že zveřejněním platů většina platů vzrostla. Pro ScrumTrek to není problém, protože se řídí filozofií, že firma patří svým zaměstnancům, a ti si tedy mohou určovat své platy sami.

Každá žádost o navýšení platu vedla ke sběru feedbacku od kolegů, na základě kterého byla potvrzena nebo zamítnuta. Za nějaký čas si zaměstnanci žádali o zvýšení platu pravidelně, ale ne kvůli penězům samotným, ale kvůli získání zpětné vazby na kvalitu své práce.

S open salaries experimentovalo mj. pár firem v česku, ale rychle od této praktiky upustili.

Doporučené knihy

“Jakou knihu byste doporučil,” zněla otázka na každého řečníka. Tady je seznam knih, které mě během konference nějak zaujaly.

• Diving for Hidden Treasures (Jutta Eckstein, Johanna Rothman)
• Turn the Ship Around! (L. David Marquet)
• Strategize (Roman Pichler)
• The Startup Owner’s Manual (Steve Blank)

“Já jsem vlastně takovej Agilní nihilista. On možná ten Scrum ani takovou hodnotu nemá…” říká Martin Jarčík na videu ze setkání Jak to dělám já. Až po roce jsem si uvědomil, jak moc s touto větou souhlasím.

Donese-li vám někdo jídlo, o kterém bude tvrdit, že je to svíčková, protože obsahuje všechny ingredience svíčkové, neznamená to, že vám takové jídlo bude chutnat. Raději bych si dal improvizovanou specialitu šéfkuchaře, který ví, co dělá, a umí dobře uvařit. Se Scrumem je to podobné. Dáte-li dohromady všechny jeho ingredience, vůbec to neznamená, že se vám výsledek bude líbit, že vás bude bavit a že bude fungovat.

Existují konzultantské společnosti, které mohou vaši firmu dokonce certifikovat, že “provozuje pravý Scrum”. Je to certifikace ingrediencí v trochu jiném světle. Máte-li rádi papíry, budete mít rádi i takový certifikát.

Dva díly Agility

Technická Agilita

Ne s každým kódem můžete naskočit na Agilní vývoj. Bude-li někdo tvrdit, že ano, že jen stačí provést reorganizaci a změnu procesů, nevěřil bych mu. Máte-li v codebase 1000 bugů (a v takovém týmu jsem pracoval), nemůžete dělat Scrum už jen proto, že nejste schopni bug estimovat a tedy nemůžete měřit velocity týmu. Oprava některých bugů trvá i tři týdny (zažil jsem) a pak nejste schopni doručit sprint. Navíc práce na bugu se špatně škáluje - je velmi těžké zařídit, aby na jedné chybě mohl dělat celý tým.

Další kritickou věcí je automatizace. Nemáte-li automatizované testy, nemůžete dělat release na konci každého sprintu. Takže na konci sprintu nebudete mít použitelný produkt a opět neděláte Scrum. I kdyby jste provedli kompletní reorganizaci celé firmy, těch 1000 bugů v codebase pořád zůstane.

Vyřešením problému kvality kódu, automatizace testování, continuous integration / release, unit testů (které téměř žádný vývojář neumí psát dobře a neví o tom), vytváření smysluplných metrik a DevOps praktik se dostáváme to sféry Technické Agility.

Business Agilita

Druhá strana mince je tzv. Business Agilita. Business Agilita bývá definována jako schopnost umět rychle a flexibilně reagovat na změny trhu a požadavky zákazníka. Pro mě Business Agilita znamená nenechat development pracovat na zbytečných věcech, což se z velké části kryje s Lean startup přístupem.

Předpokládejme, že jsme dostali geniální nápad. Založíme sociální síť založenou čistě na audio nahrávkách. Uživatelé mohou nahrávat krátké, 42 vteřinové zprávy, které potom zveřejní svým kamarádům. Nahrávání funguje z počítače i mobilního telefonu.

Začneme pracovat na nové aplikaci. Po devíti měsících vývoje se rozhodneme síť spustit, abychom zjistili, jak na ni budou uživatelé reagovat. A uspějeme… Uspějeme jen v tom, že uvidíme, co se stane. Obrovský příliv nadšených nových uživatelů bych neočekával.

Nestačilo by jen vytvořit úvodní stránku sociální sítě, připravit reklamní video, v němž vysvětlíme, jak síť funguje, a sledovat, kolik uživatelů se na základě těchto informací rozhodne do naší aplikace zaregistrovat? Zpětnou vazbu můžeme získat ještě předním, než napíšeme první řádek kódu! Několik uživatelů sice naštveme, ale všechny ty ušetřené peníze nám to vynahradí.

Každý kousek nově vytvořeného produktu testujeme na uživatelích (cyklus build-measure-learn). Když nemáme jednoho zákazníka, kterému bychom ukázali demo jako ve Scrumu, potřebujeme AB testování a rozhovory s uživateli. Může to být skličující zkušenost, ale jen tak si můžeme být jisti, že opravdu reagujeme na potřeby skutečného zákazníka. Naopak stavěním produktu na domněnkách Product Ownera a věštěním z křišťálové koule jeho nadřízeného se daleko nedostaneme.

Tohle je Business Agilita. Development nedělá zbytečné věci, na potřeby zákazníka se reaguje rychle a svižně. Někdy je potřeba [udělat Pivot]((https://www.forbes.com/sites/jasonnazar/2013/10/08/14-famous-business-pivots/ už v zaběhnutém businessu. Trefit milionový trh napoprvé se nepovedlo ani Twitteru, PayPalu nebo Starbucks.

Zpět na začátek

Technická i Business Agilita firmě pomůže. Nicméně spojíte-li oba díly skládačky dohromady, stane se malý zázrak.

Technická Agilita bez Business Agility nedává smysl, protože development bude pracovat na zbytečných věcech. Business Agilita bez té technické také nebude fungovat dobře. Změny budou trvat dlouho a nezvládne se častý release softwaru (např. už kvůli nárokům na testování). Teprve oba díly společně mohou vytvořit funkční a extrémně efektivní celek.

Navrhuji vrátit se opět na začátek a tam začít. Vraťme se k nedoceněnému Beckovu Extrémnímu programování, dobrým praktikám vývoje, rychlé zpětné vazbě, těsnějšímu propojení prodeje, podpory, vývoje a marketingu. Agilita potom přijde sama.

Vyvíjíte produkt a netušíte, jak budou zákazníci reagovat. Startup znamená stavět produkt v prostředí extrémní nejistoty. Strávíte tři měsíce zjišťováním požadavků zákazníka, šest až devět mesíců vývojem produktu a pak konečně ukážete své dílo zákazníkovi. A uspějete…

Uspějete v tom, že uvidíte, co se stane. S produktem nejspíše nepochodíte. Zákazníci si budou stěžovat, že produkt nefunguje, jak si představovali, že neřeší jejich problém a že ho vlastně vůbec nechtějí používat. To nevadí, něco jste se přece naučili.

Učení je slabá výmluva

Omlouvat svůj neúspěch tím, že jsme se alespoň něco naučili, je slabá výmluva. Opravdu je potřeba trávit devět měsíců vývoje jen proto, abychom se něco naučili? Nejde učení nějak urychlit? Zlevnit? Samozřejmě, že jde. Právě o tomto problému mluví metodika lean startup.

Validated learning

Tzv. validated learning je krok učení, v němž jsme mohli projít celou smyčkou build-measure-learn a něco se naučit. Sestavili jsme MVP (Minimum Viable Product), produkt, který jen tak tak uspokojuje potřebu zákazníka. Produkt jsme ukázali zákazníkovi a “změřili” jeho reakci. Nakonec jsme ze získaných dat vyvodili závěry, které použijeme při dalším vývoji produktu.

Možná, cheme-li uvést na trh novou aplikaci, nemusíme celou aplikaci ihned vyvíjet. Možná stačí jen webové stránky s videem. Nastavíme PPC reklamu a můžeme ihned sledovat, kolik lidí by si aplikaci stáhlo. Takto bychom zjistili zájem lidí ještě předtím, než jsme napsali první řádku kódu. Možná už tady můžeme použít feedback zákazníků a upravit další návrh. Cílem lean startupu je maximálně zkrátit smyčku build-measure-learn a produkt uvádět na trh po nejmenších možných kouscích. I ten sebemenší pokrok ve vývoji jde ihned k zákazníkovi abychom zjistili, jak zákazník reaguje. Touto flexibilitou a schopností učit se rychleji než konkurence lze postavit skvělý produkt, jak píše Eric Ries v knize Lean Startup, i v prostředí extrémní nejistoty.

Během přípravy na mobování v praxi jsem si sepsal několik situací, na které můžeme narazit. Nejsou to mé zkušenosti, čerpal jsem z videí a blogů.

Nevíte-li, co vlastně mobování je, přečtěte si můj první článek.

Je to jako ve slepičinci

Začíná-li tým s Mob Programming, může to v místnosti vypadat jako v kurníku. Každý mluví přes sebe. Každý ví nejlépe, jak daný problém vyřešit. Každý prosazuje své (nejlepší) řešení.

V tomto okamžiku je velmi důležitá role kouče. Vaším úkolem je přimět tým, aby se soustředil na problém, který řeší, a vyřešil jej. Až potom můžete napsat test. A až potom můžete optimalizovat řešení. Odložte tedy optimalizaci na později.

Coding standard

Coding standard je naprosto kritický, chcte-li předejít hádkám o tom, jak pojmenovávat soubory, funkce, jak procházet smyčky a které konstrukce přednostně používat. Mobování prospívá dodržování coding standardu a velmi brzy bude celý kód vypadat jednotně.

Angažovanost

Chcete, aby se do programování zapojil celý tým. Jenže v praxi to vypadá tak, že se jeden člověk chopí klávesnice, píše, píše, píše… Ostatní se chvíli snaží držet krok a jak soustředění poleví, začnou se nudit. Člověk u počítače jim právě ve svých myšlenkách utekl.

Řešení má dvě části. První část je zavedení časovače a pravidelného střídání u klávesnice. Obecně se doporučuje střídat po 7 až 15 minutách (a raději bych se držel spodní hranice, tj. 7 až 10 minut). Experimentujte. Pořiďte si kuchyňskou minutku nebo použijte některý z nástrojů, který už pro tyto potřeby napsali lidé před vámi.

Dejte pozor na to, aby tým konec časového intervalu neignoroval a skutečně se vystřídal. Jednou z možností je po uplynutí časového intervalu celou obrazovku zatemnit.

Druhá část řešení problému angažovanosti je tzv. strong pairing.

Strong pairing

Strong pairing je koncept původně vymyšlen pro párové programování. Intuitivní chování je, že člověk, který má nápad, se chopí klávesnice a začne psát. Druhý kolega se zoufale snaží držet tempo. Tento antipattern se nazývá driver & observer.

Možností, jak z toho ven, je tzv. strong pairing. Člověk s nápadem pokračuje v analýze svojí myšlenky, zatímco klávesnice se chopí jeho kolega. Nabízí se analogie s řízením auta: pokud víte, kudy jet, raději by jste se měli soustředit na nalezení nejoptimálnější cesty. Mačkat plyn, spojku a brzdu může váš kolega. Driver zastřeší komunikaci s autem. Nebudete mu říkat: “Teď přeřaď na trojku.” Necháte to na něm. Soustředíte se na mapu a na cestu.

Podobné je to v programování. Neříkáte řidiči všechny detaily, ale soustředíte se na algoritmy, design, architekturu a testovatelnost.

Jednotné prostředí

Dohodněte se na nastavení mobovacího počítače. Je nepraktické neustále přehazovat editory a zvykat si na nové klávesové zkratky. Použijte jednotné prostředí s defaultním nastavením klávesových zkratek. Jako operační systém většina týmů volí Linux.

Nastavení očekávání

Zkuste TDD. Napište test, implementujte a až nakonec refaktorujte. Styl test first sjednotí očekávání týmu jaký problém se bude řešit a jak se bude řešit.

Ergonomie

Pracujete-li v mobu denně, dbejte na ergonomii. Ne, gauč není ideální. Použijte pracovní židle, velkou obrazovku nebo promítací plátno, před kterým je stůl s klávesnicí. Neseďte bokem k obrazovce, z otáčení hlavy vás bude bolet za krkem.

No branches!

Protože celý tým pracuje na téže věci a code review probíhá v reálném čase, není potřeba vytvářet branche. Vytváříte-li branche, pak neděláte continuous integration.

Obohacením continuous integration o continuous deployment vytvoříte workflow pro continuous delivery. Při continuous delivery přistane s drobným zpožděním u zákazníka všechno, co přistane do codebase.

Paralerní práce

Někdy dává smysl, aby jeden člověk pracoval samostatně. Píšete-li kód, který komunikuje s databází, může jeden člen týmu připravovat příklad takové databáze pro testování. Celý tým stále pracuje na jedné věci, jen jeden vývojář podporuje plynulou práci zbytku týmu.

0 bugů

Někdo je dobrý na TDD a umí psát testovatelný kód, jiný člověk zná výborně programovací jazyk Java, dalšího baví nejvíc databáze.

Bude-li produkční kód psát expert na Javu, použije výborně jazyk, ale jeho kód nebude dokonale testovatelný. Jeho kód nebude ani interagovat s databází optimálním způsobem.

Naopak, píše-li kód celý tým současně, dostane se do produkce jen to nejlepší z celého týmu. Častou zkušeností týmů praktikujících mobování je, že vzniklý kód má nula bugů v produkci. (Je to neuvěřitelné.)

Meetingy

Kdokoliv z týmu může na kterýkoliv meeting, protože každý ví, na čem se pracuje a jaký je stav práce. Týmové meetingy jsou naopak téměř eliminovány. Odejde-li jeden člen týmu, není třeba předávat žádnou práci, protože každý je stoprocentně zastupitelný.

Klasická code review

V klasickém code review objevíte některé chyby v kódu, nikdy se ale nedozvíte, která řešení byla zamítnuta a proč. To vede na doptávání a další diskuze typu: Proč jsme věc X udělali takto, ale ne takto?

Real-time code review neslouží v mobování jen k opravování chyb, ale především k hledání optimálního řešení problému.

Co na to Product Owner?

V jednu chvíli je rozpracována jen jedna věc. Tato jedna věc je rychle doručena. Product Owner by měl být spokojen, protože ihned vidí výsledky práce a může ji testovat na zákazníkovi. Nemá smysl mít rozpracováno pět úkolů současně a nevidět žádný výsledek.

Další věcí je rychlost. Týmy, které úspěšně praktikovaly mobování delší dobu, reportovaly 4 krát více vyřešených tiketů než dříve (při zachování průměrné velikosti tiketu).

Pracujeme jako tým

Na začátku se musíte ujistit, že každý v týmu chce takto pracovat. Tým má společný cíl, všichni pracují na stejné věci ve stejný čas u jednoho počítače. Mob programming nelze nikomu vnutit.

Podaří-li se vám najít ty správné vývojáře a utvořit z nich tým, můžou být vaše code review opravdu toxická. Níže je praktický návod, jak na to.

Posmívejte se

Nejlepší způsob, jak zajistit, aby se daná chyba nikdy neopakovala, je uvést diskuzi slovy: “Nechápu, jak toto mohl někdo napsat…” nebo “Ještě to ani není v repozitáři a už je potřeba to přepsat…” Podobné věty mohou dotyčnému velmi pomoci se zlepšovat a vnášejí nové myšlenky do problematiky, která se řeší.

Říkejte své názory jako fakta

Není potřeba diskutovat nad tím, jestli by tato metoda měla být statická. Ona by měla být statická! To je fakt. Pokud to tak váš kolega nemá, musí to opravit. Je to chyba. Koneckonců, co by vás zrovna on měl co učit o programování. Nejlepší styl psaní kódu je ten váš, protože jste si jej za dlouhá léta vytříbili. V dalším případě délky metod můžete odcitovat několik studií, které ukazují, jak dlouhé metody snižují čitelnost a zvyšují pravděpodobnost chyby. Je zbytečné bavit se o tom, proč jsou metody tak dlouhé. Času je málo.

Nespěchejte

Je-li hodinové core review dobré, desetihodinový maraton bude přímo skvělý. Cokoliv je špatně, musí být opraveno. “Neber si to osobně, ale tvůj kód je kupa hnoje. Bude s ním ještě hodně práce…” Ujistěte se, že jste opravdu poukázali na všechny nedostatky kódu a váš kolega se tak bude moci maximální měrou poučit. Za cenné rady, které jsme mu dali, by vám mohl na závěr poděkovat.

Používejte nástroje

Proč se bavit v kanceláři osobně, když vám vaše firma poskytla tak dobrý nástroj pro code review. Všechny poznámky výhradně pište. Výhoda je, že dotyčný nemusí být v kanceláři přítomen. Vaše poznámky navíc poslouží jako důkaz vašeho pracovního nasazení a vašich znalostí.

Buďte důkladní Proč jsou v kódu dvě “for” smyčky, když by stačila jedna? Proč je v “if” znegovaná podmínka? Proč je na konci řádku zbytečná mezera? Buďte důkladní. Nevadí, že některé kontroly za vás může udělat automatický nástroj. Buďte to vy, kdo nic nepřehlédne.

Nerozlišujte kód od lidí

Není rozdíl mezi blbým člověkem a blbým kódem. Jestli někdo píše špatný kód, musí to být blbec. Místo obecných vět typu “vyhodí-li metoda Func vyjímku, program spadne,” pište přímočařeji: “Vyhodí-li metoda Func vyjímku, spadne ti to.”

U problémů, které jsou v kódu již delší dobu, si vždy dohledejte autora zodpovědného za danou změnu. Tak budete vždy moci oslovit tu správnou osobu, která je za chybu zodpovědná.

Nedejte se snadno

Možná se někdy ukáže, že nemáte pravdu. Ale nedejte se! Poukažte na některá videa o programování, která jste v poslední době viděli. Můžete také říct něco ve stylu: “Četl jsem více knih o unit testování než ty. Co jsi četl ty?” Tím hodíte otázku na hlavu dotyčného a pokud jste vůbec nic nikdy nečetli, code review skončí rychleji než si kolega stihne nějaké relevantní informace zjistit.

Knih, které bych si chtěl přečíst, je mnoho a času je velmi málo. V tomto článku se s vámi podělím o to nejlepší, co se mi osvědčilo.

Audible

Předplatné Audible vám kadý měsíc za 15 USD nadělí jednu audio knihu. Všechny knihy, které jsem zatím poslouchal, byly namluveny velmi pěkně. Vedlejším efektem poslouchání audio knih je, že si pasivně opakujete anglickou výslovnost.

Výběr knih v Audible je poměrně dobrý. Minimálně 30 denní trial zdarma doporučuji k vyzkoušení.

Pocket Cast

Pocket Cast jsou podcasty do vašeho telefonu. A podcasty vám změní život. Z oblasti vývoje software a vedení lidí lze najít několik dobrých českých i anglických podcastů: Život jako hra, Scrum Master Toolbox, Cucumber Podcast, ThoughtWorks a další.

Knihy Play

Knihy Play jsou od Googlu a fungují skvěle na Android telefonu. V Knihách Play jsem našel mnoho titulů, které mi v namluvené verzi (Audible) chyběly. Telefon má většina lidí stále při ruce, takže lze číst kdekoliv.

Blinkist

Krátce jsem zkoušel službu Blinkist. Znáte ty knihy, které mají třista stran a autor na nich popisuje jen dvě zajímavé myšlenky? Blinkist nabízí krátké obsahy z knih a věnuje zvláštní péči vysvětlení klíčových myšlenek knihy. Čtení jednoho obsahu vám nezabere více než 15 minut.

Dle mého názoru je Blinkist výborný pro lidi, které zajímají témata jako je osobní efektivita. Tento typ knih lze opravdu zkrátit na pár stran. Bohužel literatura, která mě v tuto chvíli zajímá nejvíc (např. architektura software), se takto zkrátit nedá.

Čtečka knih

Čtečka knih je pro ty, kdo si mají čas s knihou v klidu sednout. Konfort ze čtečky se ničemu nevyrovná.

Feedly

Používám agregátor obsahu Feedly. Feedly umí číst RSS blogů, které vás zajímají, a vytvořit vám z nich personalizovaný výběr. Výborný nástroj, chcete-li skutečně číst a ne brouzdat po webu.

Osobní Kanban

Kdybych měl ze všech lifehacků vybrat jediný, který nejvíce zefektivní vaše čtení, vybral bych tento: praktikujte osobní Kanban. Všechny knihy, které plánujete přečíst, umístěte na Kanban tabuli a prioritizujte. Takto se vám nestane, že začnete číst něco jen proto, že vám to včera kamarád doporučil a vy zrovna nemáte co dělat. Nemá smysl číst knihu o osobní efektivitě, kterou vám doporučila Audible služba, když se dlouhodobě chcete vzdělávat v leadershipu. A tak dále. Osobní Kanban vám pomůže eliminovat čas ztracený čtením náhodných (lež kvalitních) věcí.

Sloupeček Hotovo na Kanban tabuli vám vždy připomene, kolik jste toho za poslední dobu přečetli.

V jednom z předchozích článků jsem si dělal legraci z pěti principů Kanbanu:

• vizualizujte,
• omezte rozdělanou práci,
• řiďte tok hodnoty,
• mějte psaná pravidla,
• neustále se zlepšujte.

Dnes si tyto principy popíšeme poctivěji.

Vizualizujte

Kanban neříká, co a jak vizualizovat. Začněte tam, kde jste teď: snažte se porozumnět současnému procesu tak, jak se opravdu děje v praxi.

Kanban respektuje všechny role, tituly i rozdpovědnosti lidí ve firmě. Nejdříve porozumějte současnému procesu. Kolik úkolů je průměrně v jednotlivých stavech? Jak dlouho a kde úkol čeká? Kde je úzké hrdlo? Můžeme nějak rozšířit vizualizaci, abychom získali ještě více informací? Co blokuje některé úkoly? Vytvořte vizualizaci, která vám umožní vidět skutečné problémy a dělat lepší rozhodnutí.

Omezte rozdělanou práci

Přepínání kontextu je zlo. Kanban to ví. Kanban chce omezit rozdělanou práci. Kromě zmenšení ztráty z přepínání kontextu má tato změna ještě další pozitivní efekt.

Limit na rozpracovanou práci může vypadat takto: “Tým A nebude mít nikdy otevřeny více než dva tikety současně.” Jakmile tým A jeden tiket zavře, automaticky si otevře další. Tímto dochází ke změně “push” systému, kdy týmu A zadáváme práci, na “pull” systém, kdy si tým A aktivně sám práci bere z připravené hromádky.

Nakonec, méně rozpracovaných úkolů znamená, že to, co se jednou otevře, je rychleji doručeno zákazníkovi. Firma má méně rozpracovaných úkolů “skladem” a doručené dodávky generují zisk.

Limit rozdělané práce, tzv. “Work In Progress” limit, se obvykle označuje zkráceně WIP limit.

Řiďte tok hodnoty

Ne všechny úkoly jsou si rovny:

1. Dodávka zákazníka nemusí být hotova příliš brzy, ale musí být dokončena ve smluveném termínu. V opačném případě by zákazník nemusel zaplatit.
2. Refaktoring a redukce technického dluhu nikdy nespěchá, ale pokud se neprovede, někdy v budoucnu můžeme na nekvalitní kód velmi tvrdě doplatit.
3. Bug v produktu blokující podepsání nového kontraktu musí být řešen s nejvyšší prioritou. Jde o miliony.

Z příkladů je patrné, že některé úkoly ztrácí svou hodnotu rychleji než jiné. Cena, kterou zaplatíme za zpožděné doručení, se nazývá cost of delay (CoD).

Kanban rozlišuje čtyři archetypy (typické příklady) CoD: expedite, fixed date, standard, intangible (intangible = nespěchá, ale v delším časovém horizontu se může vymstít). Maximalizovat tok hodnoty znamená být schopen správně prioritizovat a doručit maximum možné hodnoty.

Mějte psaná pravidla

Stanovte explicitní pravidla pro svůj proces. Pravidla by měla být jednoduchá, dobře definovaná, viditelně umístěná, měla by se vždy dodržovat a současně být připravena být okamžitě změněna.

Dodržování pravidel a připravenost pravidla změnit, spolu souvisí. Velmi špatnou aplikací principů Kanbanu je nastavit WIP limity a nikdy se nepokusit tyto limity překročit nebo snížit. Pravidla jsou pevně dána proto, abychom je mohli porušit.

WIP limity jsou jen jedním typem pravidel. Mezi další pravidla patří definice přechodů mezi stavy na kanban tabuli (kdy je úkol připraven, kdy je dokončen…), způsob alokace kapacit na úkoly, způsob doplňování nových lístečků na tabuli, a například také kdy některý úkol můžeme prohlásit za zrušený a lísteček zahodit.

Neustále se zlepšujte

Zlepšujte se společně pomocí drobných experimentů. Prvním krokem může být zlepšení zpětné vazby, další opatření mohou cílit na problémy odhalené pomocí zpětné vazby.

Příležitostem pro zpětnou vazbu se v Kanbanu říká kadence (cadences). Kadence jsou pravidelné meetingy, které pomáhají dělat postupné změny a zefektivňovat proces. Druhý význam slova “kadence” je časová perioda těchto meetingů, tj. jak často se daný meeting opakuje.

Ideální perioda meetingů vždy závisí na kontextu. Příliš časté meetingy a mrháve časem zaměstnanců, málo časté meetingy a změna nereflektuje aktuální potřeby nebo je příliš pomalá.

S mainstreamovým rozšířením Scrumu to vypadá, jakoby všechny dobré Agilní praktiky přinesl do hry Scrum. Věděli jste, že user stories, planning poker a denní standup jsou praktiky pocházející z Extrémního programování?

User stories

User stories je formát zaznamenávání požadavků z uživatelské perspektivy. Bill Wake, autor knihy “eXtreme Programming Explored”, navrhl akronym INVEST jako memotechnickou pomůcku pro to, jak by měla vypadat dobře definovaná user story:

• Independent (nezávislá; stories lze řešit v libovolném pořadí),
• Negotiable (umožňuje další vyjednávání a specifikaci),
• Valuable (hodnotná pro zákazníka),
• Estimable (může být estomována),
• Small (malá),
• Testable (testovatelná).

Scrum požaduje psaní tiketů ve formátu user story (přesněji říká, že každý přírůstek produktu by měl mít nějakou hodnotu pro zákazníka). User story může být dobrý formát pro novou funkcionalitu, ale omezení se jen na tento formát může vést k opomíjení jiné důležité práce.

Planning poker

Planning poker byl objeven James Grenningem praktikujícím Extrémní programování. Grenning hledal nástroj, který by týmu pomohl trávit méně času odhadováním náročnosti user stories.

Ve Scrumu je za estimace zodpovědný tým vývojářů. Planning poker není povinný, ale je to dobrý způsob, jak tyto estimace dělat. Planning poker pomáhá získat poctivější odhady od celého týmu, zatímco vyvolává diskuzi nad technickými otázkami.

Dobré porozumnění práci na další sprint může být ve výsledku důležitější, než samotné odhady.

Denní standup

Denní standup je praktika z Extrémního programování, které doporučuje udržovat tento meeting krátký. Scrum přejmenovává standup na Daily Scrum, ale nepožaduje, abychom během meetingu stáli.

Mnoho Scrum týmů při Daily Scrumu stojí, protože stání pomáhá udržet účastníky aktivnější a meeting kratší. Scrumem určená maximální doba meetingu je 15 minut.

Scrum jako framework

Scrum není plnohodnotná metodika, je to framework. Framework je rámec, do kterého by si týmy měly zasadit vlastní praktiky a který by jim měl pomoci k neustálému zlepšování. Inspirace z jiných metodik je proto důležitá. Jaké další praktiky doporučuje Extrémní programování? Navštivte můj workshop Extrémního programování, kde se dozvíte skoro vše.

Minimalismus

Porovnáme-li Kanban s jinou Agilní metodikou (Scrum, XP, …), bude Kanban vypadat minimalisticky. Kromě pěti základních principů

• vizualizujte,
• omezte rozpracovanou práci,
• řiďte tok hodnoty,
• mějte psaná pravidla,
• neustále se zlepšujte,

Kanban vlastně nic neříká. Když si tyto principy přečte člověk poprvé, rozhodně neví, co dělat. Právě proto je Kanban zpočátku obtížný.

Kanban jako nástroj

Kanban je nástroj k definování, řízení a zlepšování služeb založených na duševní práci. Mezi takové služby patří vývoj software, design a kreativní činnosti. Kanban, Scrum, Waterfall, Rational Unified Process… to jsou všechno nástroje. Hádat se, který nástroj je nejlepší, je stejné, jako se přít o to, je-li lepší vidlička nebo lžička. Každý nástroj je vhodný na jinou činnost.

Hodnota nástroje k řízení procesů spočívá v tom, že omezuje, co můžeme dělat. Například metoda “udělej vždy správnou věc” je sice stoprocentně úspěšná, ale vůbec neříká, co vlastně dělat. Pokud při aplikaci této metodiky náhodou selžete, pak jste zřejmě neudělali správnou věc a tedy nedodrželi metodu. Takže ano, metoda “udělej vždy správnou věc” je sto procentně úspěšná.

Kanban nás omezuje jen velmi málo (a méně než třeba Scrum). Kanban neříká, co bychom měli dělat, kromě pěti principů. Na praktickou aplikaci je to zoufale málo.

Jak tedy použít Kanban v praxi? Začněte tam, kde jste nyní. Dělejte drobné změny a postupně se zlepšujte. Principy Kanbanu by vám měly pomoci zlepšení hledat. A abyste to všechno dali dohromady, musíte znát mnohem víc, než Kanban. Čtěte o jiných metodikách, lean přístupu a vedení lidí.

Výhodou Kanbanu je, že lze velmi snadno škálovat.

Dva odstavce historie

Kanban je japonské slovo pro “vizuální signál” neboli “kartičky”. Pásoví dělníci v Toyotě používali kanban (malé “k”, zde kanban znamená “kartičky”) aby signalizovali kroky ve výrobě. Vizuální znázornění celého procesu denně pomáhalo lidem při komunikaci a umožnilo další optimalizace - zrychlení výroby a omezení plýtvání.

Druhá vlna použití Kanbanu přišla v roce 2007. Komunita vytvořená pod vedením D. J. Anderson, J. Benson, C. Ladas a dalších ukázala, že Kanban lze úspěšně použít také v obsasti služeb založených na duševní práci.

Přísahám, že už to slovo nikdy neřeknu. KAPACITA.

V minulých týdnech jsem vysvětloval principy Kanbanu mnoha lidem. Spojení “work in progress” označuje rozpracovaný úkol. Počet rozpracovaných úkolů se snažíme omezit, což je druhý základní princip Kanbanu.

Kolik rozpracovaných úkolů je ideální počet na tým? Člověk snažící se přijít na nějaké číslo může uvažovat následovně: čím je tým větší, tím více rozpracovaných úkolů současně si může dovolit. Teoreticky by mohl každý člověk v týmu pracovat na samostatném úkolu. Tohle je tedy maximální kapacita týmu. (A je to tady. KAPACITA je na světě!)

Málokdo při prvním setkání s Kanbanem rozumí spojení “work in progress”, při pojmu kapacita většina lidí přikyvuje. Kapacita týmu udává, jaké množství práce jsem schopen dodat za jednotku času. Jenže… tohle už nemá nic společného s Kanbanem. Tímto se dostáváme k projektovému řízení, plánování kapacit a milníků.

Kanban se vyhýbá všem komplikovaným věcem z projektového řízení. Kanban mluví jednoduše jen o počtu rozpracovaných úkolů. Slovo kapacita do Kanbanu nepatří.

Mob programming je fenoménem posledních let. V rozdělení innovators, early adopters, majority, late majority, řadí InfoQ mobování do vlny early adopters. Odpovědi na otázky typu “jak mobování vůbec může fungovat” jsou známy a některé týmy se mobování aktivně pokoušejí dostat do praxe.

Co je to Mob Programming

Mobování je, když všichni ti úžasní lidé pracují

• na stejné věci,
• ve stejný čas,
• na stejném místě,
• na témže počítači.

Zatímco první tři body mohou znít jako obecný Agilní vývoj, čtvrtý bod je nový, neintuitivní. Mob Programming je continous integration of ideas - tým nepotřebuje code review, standupy ani další meetingy, protože nejlepší ze všech nápadů jsou integrovány do produktu v reálném čase.

Proč bychom takto měli pracovat? Protože to tým tak chce. Mobování totiž rozhodně není pro každého.

Filozofie mobování

Proč používáme k psaní klávesnici? Klávesnice není nejefektivnější způsob, jak komunikovat s počítačem. Vždyť mačkat p-í-s-m-e-n-k-o p-o p-í-s-m-e-n-k-u je strašlivě zdlouhavé. Musíme dlouho trénovat, než se tento způsob přenosu myšlenek do počítače naučíme používat efektivně.

Mnohem lepší by bylo komunikovat s počítačem hlasem. Při programování mu říci: “Vytvoř nový projekt. Napiš main. Vytiskni Hello World!” Bohužel takto technologicky daleko ještě nejsme. Klávesnice zůstává jediným rozumným způsobem komunikace.

To ale nemusí být pravda v týmu. Jeden člověk může s počítačem komunikovat pomocí klávesnice, zatímco ostatní mohou pracovat na vymýšlení všech těch úžasných věcí. Říkáme, že člověk u klávesnice je “driver”, zatímco ostatní jsou “navigátoři”.

Driver nemusí moc přemýšlet. Zkrátka píše. Jde-li o zkušeného člověka, můžeme mu říci: “S třídou Flexi budeme komunikovat pomocí observer pattern. Použijeme signal-slot knihovnu a propojíme ji s funkcemi OnNewEvent.” S juniorem budete naopak komunikovat více detailněji: “Stáhni knihovnu SigSlot a připoj ji do projektu. Z funkce OnNewEvent uděláme slot tak, že před ni přidáme definici SLOT…”

Detailnost vaší komunikace závisí jen na senioritě týmu. Přesto se všichni neustále učí. Do produkčního kódu se dostanou jen nejlepší myšlenky.

Jak to funguje v praxi?

Využít celý tým, aby pracoval jen na jedné věci, se zdá velmi neefektivní. A ano, je to neefektivní. Jenže tato neefektivita je vyvážena obrovskou úsporou času v jiných oblastech. Tak například:

• nejsou potřeba žádné meetingy (kromě 5 minutové denní retrospektivy a plánování),
• není potřeba code review (dělá se v reálném čase),
• tým se narozdíl od jednotlivce nikdy nezasekne na nějakém těžkém problému,
• odpadají případy, kdy se někdo dostane do slepé uličky a musí kód předělávat,
• výsledný kód má extrémně nízký počet budů (lidé nejčastěji říkají, že nula),
• lidé se u programování střídají v různých rolích, jsou odpočatější, což velmi zvyšuje produktivitu,
• kód je přehlednější a udržovanější, což se vyplatí z dlouhodobého hlediska,
• celý tým se učí a zlepšuje,
• hotové věci se ihned zkoušejí - rychlá zpětná vazba od produkťáka nebo zákazníka znamená méně zbytečné práce pro tým.

Největší síla mobování spočívá právě v eliminování zbytečné práce, zbytečné komunikace, zbytečných meetingů. Rád bych otázku “jak může Mob Programming být efektivní” parafrázoval otázkou “jak může programování, ve kterém každý pracuje na svém úkolu samostatně, být efektivní?”

Autor mobování, Woody Zuill, nedoporučuje tuto praktiku každému. Woody společně s týmem hledal způsob, jak by lidé v týmu mohli pracovat společně efektivněji. Výsledkem je Mob Programming. Rozhodně jej zkuste, avčak mějte na paměti, že vaše cesta k efektivnější spolupráci může vypadat úplně jinak.