Můj pohled na Agile Prague 2014

Byl jsem na konferenci Agile Prague. Bylo to poprvé a hned tak se tam nevrátím. Ne, že bych své účasti litoval - našel jsem si tam pár zajímavých myšlenek a odkazů na dodatečné zdroje. Ale celkový dojem z konference mám rozpačitý - pro koho je vlastně určena?

Shrnutí

Můžu se krutě mýlit, ale podle obecenstva bych odhadoval, že tak 70-90 % byli SW inženýři, s převahou vývojářů. Většina z nich buď už má zkušenost s agile, nebo ví o co jde, nebo aspoň po agilitě touží. Pro tuhle kategorii, obávám se, konference mohla nabídnout stěží něco nového, něco inspirativního. Teda kromě "kmenové družby". Sám za sebe bych to shrnul následujícím tweetem:

I want to be inspired hearing a keynote. Well, I'm hearing thousand times said at #agileprague
— SoftWare Samuraj (@sw_samuraj) September 16, 2014

Přišlo mi, že většina přednášek by byla nejvíc přínosná pro kategorii, která na konferenci zcela/téměř absentovala - střední manažment. Nevím, čím to bylo, ale skoro všichni řečníci se drželi na velmi abstraktní rovině. Pořád se mluvilo o problémech, které agile adresuje, ale jen minimálně o konkrétních řešeních. A hlavně, srovnávat (opakovaně!) v roce 2014 (13 let po Agilním manifestu!) vodopád s agilním vývojem... hm, mlácení prázdné slámy?

Co se mi nelíbilo

V následující sekci nebudu psát pozitivní věci - chtěl bych proto předeslat: jde o můj, striktně subjektivní pohled. Pokud něco kritizuji, tak proto, že to nedosáhlo mých očekávání. Nemusí to ale říkat nic o skutečné, nebo obecně přijímané kvalitě. Jsem někdy solipsista... už od dětství.

A směrem k pořadatelům: jsem rád, že takovouto konferenci pořádáte. Vím, že je za tím spousta práce a je fajn mít něco takového v Praze.

Agile != Scrum

Tenhle pocit už mám dlouhodobě. Když "běžní" lidi mluví o agile - a řečníci na konferenci to zhusta autorizovali - tak zazní něco (byť ne tak explicitně) jako:

"Být agile" = "dělat" Scrum

Zajímalo by mě, jestli máte jinou zkušenost? Já když poslouchám diskuze o agile, tak cca 80 % času/prostoru je věnováno klábosení o Scrumu.

Jen výjimečně (a díky za to) zaznělo:

Individuals and interactions over processes and tools

Case Studies

Case studies jsem viděl dvě (Home Credit a Skype) a obě patřily k (informačně) nejslabším příspěvkům na konferenci. Když jdu na case study, tak očekávám, že se dozvím něco z toho, "jak to dělali". Nezajímá mě historie a struktura firmy. A když je na talk 20 minut, tak mě nezajímá ani kontext, v jakém to probíhalo - není na to čas. Chci vědět, jak to dělali! To jsem se ani z jedné case study nedozvěl.

Co si z toho odnáším, tak že v Home Creditu měli problém telefonovat do Asie (technické problémy) a ve Skypu použili na odhady story points, které měly konkrétní velikost (hodiny a dny - takže už jaksi nešlo o relativní, ale absolutní odhady). To asi není to, co řečníci zamýšleli předat publiku.

Zaměření, pointa přednášek

Možná jsem přespříliš kritický, ale poučen Scottem Berkunem očekávám, že přednáška bude mít nějakou pointu, myšlenku, kterou chce sdělit. O to spíš, že trvá pouze 20, 30, max. 45 minut.

Přiznám se, občas jsem se musel během prezentace opakovaně podívat do programu na název přednášky, abych si připomenul o čem je téma. A párkrát jsem se usilovně snažil do posledních sekund nalézt pointu toho, co jsem zrovna půl hodiny poslouchal.

Nekonkrétnost

Několikrát jsem na přednáškách zaslechl rady jako: "We should embrace the Agile Manifesto!", "We need to find leaders!" apod. Aspoň jak jsem to pochopil, nebyly to mobilizační výkřiky - byly to vážně míněné rady, jak řešit předeslané problémy. Ehm, jak? To je to, proč jsem přišel na tuhle přednášku, konferenci. Jak se to dá udělat? Nebo alespoň, kde se mám inspirovat, kde si to můžu dostudovat? Nevím. Nevím, v těchto otázkách víc, než jsem věděl před konferencí/přednáškou.

Bonding

Nejsem mizantrop, jsem jen bytostný introvert. A nesnáším, když mě někdo z pozice autority (řečník, nebo pořadatel) nutí dělat věci, které jsou mi jako introvertovi nepříjemné. Což je třeba diskuze ve veřejném prostoru s cizími lidmi. Nebo se ptát sponzora konference na heslo k wifi!?!?

Wifi

Myslím si, že je v dnešní době faux pas, když není na konferenci k dispozici slušná wifi... pro všechny. Aby to bylo jasné: heslo na wifi pro prvních 100 (z cca 250), není pro všechny. A to tím spíš, pokud poskytnu program konference v elektronické verzi, která vyžaduje být online.

Ano, můžou být legitimní důvody, proč není wifi připojení uspokojivé, či dostačující. Pak je ale férové to říct narovinu. A ne žoviálně odtušit "better be quick". Failure.

Co se mi líbilo

Linda Rising

Jednoznačnou hvězdou konference pro mne byla Linda Rising (@RisingLinda). Tahle agilní babička (72 let!!) doručila jedinou inspirativní keynote celé konference a i její druhá přednáška byla velmi pěkná.

Její keynote měla název The Power of the Agile Mindset a dala by se zhustit do věty Na počátku bylo slovo. Celé to bylo o tom, jakou úžasnou schopnost máme k dispozici - jedinou větou můžeme určit trajektorii skupiny na dlouhou dobu a doširoka rozevřít nůžky mezi úspěšnými a neúspěšnými. Mezi těmi, kteří hledají řešení a těmi, kdo hledají chyby a viníky. Mezi těmi, kdo na sobě pracují a kdo o sobě lžou (aby vypadali lépe). A mezi agilním a fixním mindsetem.

Paul Klipp

Paul Klipp byl jediný řečník, kterého jsem před konferencí znal. Těšil jsem se na něj a nezklamal mě. Ba co víc, překvapil mě. Jeho přednáška se jmenovala Improve your communication skills dramatically without saying a word. Jako jediný speaker mluvil bez slidů(!) a součástí byla i 3minutová meditace(!!), která však do přednášky organicky zapadla.

Je zbytečné, abych tady přepisoval a parafrázoval Paulovu myšlenku - doporučuji přečíst si jeho blogpost Improve your communication skills by learning to listen, nebo se aspoň podívat na přípravnou mind mapu.

Organizace jako doprava

Zábavná a osvěžující byla přednáška Hanse Brattberga Traffic, Organizations and Lean, kde přirovnával fungování firmy (a hlavně přístup k projektům) k dopravním situacím. Křižovatka v Hanoi, kruhový objezd na Champs-Élysées, šestiproudá dálnice, couvání v jednosměrce atd.

Každé srovnání kulhá. Ale tady nešlo o nalezení analogie, ale o zobrazení určitých zákonitostí pomocí nadsázky. Třeba že couvání v jednosměrce je vlastně podvádění (protože se nám nechce objíždět blok). Na druhou stranu, jak Lean, tak doprava pracuje s flow, kapacitou apod., takže něco podobného tam bude.

Produktové flow nestačí

I když osobně nepovažuju Kanban za (striktně) agilní záležitost, přece jen mě dost překvapilo, že na konferenci o něm nebylo vůbec nic! Nejvíc se mu blížila přednášky Martina Burnse Product Flow Is Not Enough!. De facto to bylo o Kanbanu, i když, jestli si dobře vzpomínám, tak slovo Kanban tam ani jednou nezaznělo. Nebo to bylo o Lean? ;-)

Martin měl taky velmi pěkné, ručně malované slidy, které bohužel nejsou (zatím?) dostupné. Můžete je ale vidět v jeho přednášce na YouTube. (V Praze mluvil o moc líp = plynuleji, ale Kanban fakt neřekl.)

Total Recall, eh, Terraforming

Další (nejen) zábavná přednáška byla od Caludia Perroneho: Terraforming Organisations: Journey of a Lean Changer. Tahle přednáška hodně vycházela z Toyoty a Lean, plus A3 Thinking, ale směřovala k originálním nástrojům ("myslící" karty a Popcorn flow, viz slidy níže).

Nicméně, to co mi hlavně utkvělo v hlavě, je slide kdesi z prostředka prezentace:

Terraforming organisations from Claudio Perrone

Krásně to ilustruje můj pocit z většiny implementací Scrumu, co jsem jich v enterprise viděl - vývojáři si vesele "scrumují" a nad nima je zabetonovaný klasický hierarchický manažment.

#NoEstimates

Na #NoEstimates jsem poprvé narazil v knize Kanban in Action. Je to zajímavá myšlenka, s Kanbanem se velmi dobře pojí a řečník Vasco Duarte ji přednesl srozumitelně. Čím se Vasco, bohužel, moc nezabýval - jak to udělat na začátku projektu. Studijními zdroji taky zrovna neplýtval - prostě to stavěl jako takové postuláty. A publikum bylo asi dost zaskočené, protože se na to taky nikdo nezeptal.

Catering

Ruku na srdce - dobré jídlo ke konferenci patří a já jsem byl spokojený. Obědy byly chutné, dortíky dobré, kafe (na konferenci) slušné, džusů dostatek, nemůžu si stěžovat :-)

Co jsem si odnesl

Ačkoliv jsem šel na agilní konferenci, tak to, co jsem si odnesl, se netýká agile, ale leadershipu - víc na sobě pracovat, jako servant leader. Takže z tohohle pohledu jsem spokojený. Ale z pohledu agile jsem zklamaný - vzhledem ke své pozici mám v práci (omezenou) možnost prosadit určité věci, nastavit kulturu, doporučit nástroje apod. A bohužel, v tomto směru si z Agile Prague 2014 neodnáším žádnou inspiraci.

Související externí články

• Agile Prague 2014 (Java crumbs)

Kanban, zprávy z fronty II

Máme za sebou, s týmem, další, úspěšnou implementaci Kanbanu. Projekt pomalu končí, je čas se ohlédnout. Jak to vypadalo, co fungovalo, co je potřeba zlepšit?

O projektu

Vzhledem k tomu, že z bezpečnostního hlediska se jedná o citlivé téma, nebudu psát nic o architektuře a technologiích. Což ale nevadí, protože z pohledu Kanbanu je obsah a typ projektu nepodstatný. Ale ať nám to povídání nevisí ve vzduchu, nastíním business case.

Výsledkem projektu je/bude webová aplikace, s jejíž pomocí si zájemci mohou online zažádat o různé typy víz a povolení (pracovní, k pobytu apod.) a také je eventuálně online zaplatit. Aplikace, jako taková, je velmi hloupoučká, veškerá business logika a workflow zpracování žádosti se děje na backendu, který už není součástí naší dodávky.

Team

Šlo o malý projekt, takže i malý tým - 2 vývojáři, 1-2 testeři/integrátoři, 1 technical leader, 1 project leader. Celkově (a konstantně během celého projektu) nějakých pět lidí. Pouze dva členové týmu měli předešlou zkušenost s agilním vývojem, s Kanbanem pak pouze jeden. Tým byl technicky seniorní, žádný junior.

Vizualize

Základním přikázáním Kanbanu je vizualizuj! Všechno, co jde (a dává smysl), vše, co dá lepší viditelnost projektu.

Kanban Board

První věc, která se (obvykle) vyzualizuje, je projektové/procesní workflow. Použili jsme jak fyzický, tak elektronický board. Ten elektronický byl založen na issue tracking (ITS) nástroji Redmine.

Bohužel, Redmine je, jako ITS, dosti nezralý/problematický a pro Kanban nemá žádný použitelný plugin. Problém jsme vyřešili "oklikou přes ruku" (= workaround) pomocí pluginu Wiki Lists, který dává přijatelný výsledek. Elektronický board byl primárním zdrojem informací a stavu.

Elektronický Kanban board (Redmine a Wiki Lists plugin)

Fyzický board byl druhotný zdroj informací. Používali jsme ho jako přirozené místo setkávání týmu (stand-upy). Další výhodou byla jeho neustálá přítomnost v open spacu. Takže všichni viděli :-)

Každý člen týmu byl zodpovědný za synchronizaci svých tasků mezi ITS a fyzickým boardem.

Fyzický Kanban board (stav na koneci projektu)

Co stojí za zmínku na fyzickém boardu: je zde název projektu a číslo aktuálního releasu, grafy statistik (viz dále), bankovky přivezené ze služební cesty. Předpokládám, že stavy workflow jsou samo-vysvětlující. Assignment jsem řešili pomocí labelů (Vit, Lub, Seb atd.).

Design kartiček

Na kartičkách, které na fyzickém boardu představují jednotlivé tasky, může být spousta informací. Na rozdíl od elektronické verze, kde bývá spousta atributů, má kartička jen omezený prostor. Proto je potřeba zvážit, jaké informace na ni dát, aby byla zároveň informačně dostačující a přitom srozumitelná. Velmi podrobně se tomuto tématu věnuje (výborná) kniha Kanban in Action.

My jsme začali a skončili u jednoduchého designu:

• ID z ITS ve formátu #nnn (levý horní roh).
• Zjednodušený název/summary tasku (uprostřed).
• Zkratka komponentu/feature/user story (zeleně, pravý horní roh).
• Délka setrvání ve stavu In Progress (červené tečky dole, tečka = den).
• Indikátor kritické priority (červený vykřičník, nahoře uprostřed).
• Indikátor blokace (červené B, pravý dolní roh).

Design kartiček

Class of Service

Když jsme projekt začínali, měli jsme všechny kartičky žluté. Postupně jsme pak zavedli classes of service. U tohoto konceptu je podstatné, že každá třída má přiřazenou specifickou politiku, jak s ní zacházet. Má třeba jiné workflow, jinou prioritu atd.

My jsme prvně odlišili tasky a bugy jiným workflow a bugy jsme na boardu odlišili růžovými lístečky (červené nebyly ;-)  Protože jsme měli zero bug policy, měl každý bug vždy vyšší prioritu než task.

Později jsme zavedli ještě jednu třídu pro tasky - má neintuitivní název intangible (termín přejímám z knihy Kanban in Action). Do téhle třídy spadají tasky, které nemají přímou, hmatatelnou business hodnotu, nicméně je potřeba je udělat. Jsou to věci jako různé konfigurace, interní dokumentace, refactoring apod. Tato třída měla (s výjimkou přípravy releasu) prioritu nižší, než task.

Třídy služeb (Classes of Service): žlutý - task, růžový - bug, zelený - intangible

Limit WIP

Moje zkušenost je zatím taková, že limitování WIP (Work In Process), je pro účastníky tou nejproblematičtější položkou Kanbanu - lidi vždycky nadávají, když jsou alokovaný na víc než jeden projekt, ale budou do krve hájit svůj "multi-taskinig". Myslím, že tady nás čeká ještě dlouhá cesta pomalé a trpělivé implantace principu stop starting, start finishing.

Malou podporu Kanbanu v Redminu už jsem zmiňoval. Limit WIP v něm nejde nastavit, tak jsme si ho definovali "jenom" jako politiku - každý by měl pracovat v daný čas jenom na jednom tasku. Fungovalo to jen z půlky dobře, vývojáři obvykle toto "omezení" dodržovali, testeři obvykle ne. Celkově bych ale řekl, že pokud je WIP nastavený jenom politikou, může to i přesto dobře fungovat. Chce to jen trpělivě lidi vzdělávat, jít příkladem a s klidem to vyžadovat. Poučení pro mne - být důslednější.

S WIP jde velmi často ruku v ruce otázka, co s blokovanými tasky? Není na to jednoduchá odpověď, částečně se to dá řešit flow, nebo politikou. Ale asi nejlepší je mít poučený tým - jak jsem kdesi četl (možná že Agile Samurai?) "zkušený agilní vývojář nikdy nezačne task, který není schopný dokončit". Čili prvně si task "před-nalyzovat" a odstanit rezistence a pak se teprve do něj pustit. Ne vždycky to jde, ale autonomní a uvědomnělý přístup členů týmu (opak skočím do toho pohlavě, neboli jdu rovnou bušit) mi dost často chybí.

Manage Flow

Kanban má rád autonomní lidi. Já taky. Kanban je pull system - když dám něco do TODO, vyhovuje mi, když to nemusím nikomu přiřazovat, ale libovolný člen týmu si to (podle svých schopností) vezme na starost. Jako team leaderovi mi to šetří obrovské množství času.

Jeden člen týmu měl s tímhle přístupem silný problém, bylo to pro něj příliš volné, "bez pravidel". Opět platí: vysvětlovat, vzdělávat. Plus, Kanban holt není pro každého, někdy si lidé a proces nesednou.

Workflow tasku na tomhle projektu je jedna z věcí, které se nám, myslím, dost povedly. Jedním z podstatných rysů flow byla silná podpora formalizovaného code review (můžete se těšit, až o tom Banter napíše článek).

Za zmínku stojí stav merge. Původně to byl jenom pseudo-stav (neměl svůj obraz v ITS). Ale vzhledem k asynchronní povaze našeho code-review procesu a občasné distribuovanosti týmu (home office, služební cesty), se vyplatilo z něj udělat svébytný stav.

Workflow tasku

Na počátku projektu jsme měli také samostatný stav pro blokované tasky. Ale pak jsme ho zrušili a nahradili blokujícím atributem přímo na issue. Důvod je prostý. Toto byl už druhý projekt, kde jsem měl v rámci Kanbanu stav blocked a vždycky to dopadlo stejně - tento stav se stal odkladištěm (až smetištěm) pro blokované tasky a nikdo (ani já) se moc nesnažil s tím něco dělat, odblokovat je. Řekl bych, že blocked atribute v tomhle funguje lépe a navíc není svázaný jen s jedním stavem - věci můžou být blokované ve vývoji, testování, integraci atd.

Další věc, kterou jsme v rámci flow zavedli byla fronta pro tasky čekající na otestování. Projekt byl z hlediska testerů podhodnocený, takže tasky se nám tam hromadily zcela přirozeně. V Kanbanu je to pěkně vidět - když se vám někde začnou štosovat lístečky, máte (možná) problém. Z hlediska teorie jde o úzké hrdlo a obvykle stojí za to ho trochu rozšířit, nebo odstranit.

My jsme to řešili dvěma způsoby: jednak jsme se zaměřili na automatizaci (Selenium testy), což pomohlo pouze částečně (testy fungovaly spíše regresně, než že by testovaly nově vyvinuté tasky) a jednak jsme úspěšně zalobovali za alokaci dalšího testera.

Statistiky

Se správou flow souvisí také jeho měření. Statistiky jsme používali, ale až takový přínost to pro nás nemělo. Z několika důvodů:

• Se sbíráním statistik jsme začali pozdě. To bylo dané hlavně téměř nulovou podporou a využitelností reportingu v Redminu. Polovinu údajů pro statistiky bylo potřeba získávat ručně. I při malém týmu to bylo dost pracné.
• Změny v našem flow byly celkem drobné. Ve spojení s předešlým bodem, je otázka, jak moc by se změny projevily a jak by to bylo průkazné.

Takže to byla spíš taková zajímavost a zkušenost pro příští projekt. Metriky, které jsme sbírali, byly throughput (propustnost, velocita) a lead time (trvání dokončení tasku).

Týdenní velocita

Statistiky jsme dělali jak pro "obecné" issue, tj. task bez ohledu na jeho typ a velikost, tak pro tasky odhadnuté pomocí triček (T-shirts). Ze statistiky tak např. vyplývá, že průměrná velocita týmu za týden byla 6 tasků, a průměrné dokončení tasku odhadnutého jako S trvalo 2,5 dne. (Dokončení je myšleno tak, jak ho chápe Kanban, takže vyvinuto, zreviewováno, otestováno, deployováno.)

Lead Time podle relativní velikosti tasků

Explicit Policies

Explicitní politiky jsou důležité. Je pak nad čím diskutovat a není to hospodská tlachačka o něčem "co všichni ví" a "takhle se to vždycky dělá". Obecně, nemělo by jich být moc, měly by být jednoduché a měly by být snadno přístupné. Naše politiky jsme měli na projektové wiki a zahrnovaly:

• Stand-up: jaký je jeho smysl a jaké má pravidla.
• WIP = 1: každý dělá v daný čas pouze na jediném tasku.
• Zero Bug Policy: každý reportovaný bug je automaticky kritický a musí být opraven, než se začne pracovat na novém tasku.
• Pravda je v ITS: primární zdrojem stavu projektu je trackovací systém. Každý je zodpovědný za aktuálnost a synchronizaci svých tasků.

Co mi chybělo a ocenil bych, je Definition of Done. Tak příště.

Implement Feedback, Improve Collaborativelly

Na rovinu, tyhle dvě věci nám moc nešly. Sice jsme měli retrospektivy, ale nevzpomínám si, že by to nějak ovlivnilo věci kolem Kanbanu, flow apod. Na jednu stranu to trochu chápu - tým byl Kanbanem nepolíbený, a autonomním se člověk nestane přes noc. Vysvětlovat, vzdělávat, působit. Chce to čas.

Pravidelné týmové aktivity

Následující praktiky nejsou součástí Kanbanu. Ale velice dobře se s ním pojí.

Stand-up

Denní stand-up, agilní to klasika. Pro popis bude nejjednodušší, když ocituju naši politiku:

The main purpose of the stand-up is that the team get the current context of the project.

The stand-up should be:

• short - max. 10 minutes,
• focused - see the main purpose above,
• with participation of the all team members,
• in front of the Kanban board.

The stand-up shouln't be used for:

• discussions which don't involve all the team,
• solving the technical problems.

If such situation happens (discussion, problem),

• it should be rather solved after stand-up,
• ideally in the phone box rather than in open-space,
• only with people who are interested/involved in the problem.

The typical stand-up participation is:

1. What did I do yesterday?
2. What will I do today?
3. What is blocking me.

U stand-upů se mi opět potvrdilo, to co u jiných agilních praktik - lidi, kteří s tím nemají zkušenost, můžou prvně "frfňat". Ale jen do té doby, než "to začnou dělat". Pak přijde něco jako prozření. Problém s akceptací jsme měli u jednoho člena týmu, ale potom, co jsme si to vysvětlili a deklarovali výše uvedenou politiku, už to bylo v pořádku.

Že to dobře fungovalo, můžu ilustrovat faktem, že tým nepotřeboval týdenní statusy (byly by zbytečné), protože stav všichni pobrali během stand-upů.

Retrospektivy

Retrospektivy jsme začali dělat cca v půlce projektu. Pro mne to bylo premiérové téma, proto jsem nechal retrospektivy řídit zkušenějšího kolegu a sám jsem se ponořil do studia. Hodně mi v tom pomohla kniha Agile Retrospectives.

Retrospektivy jsou pro mne ještě příliš čerstvé téma, takže je zatím nebudu hodnotit. Ale pocitově, intuitivně z nich mám dobrý pocit a chci je použít na dalším projektu.

Prioritizace

Prioritizovat je potřeba snad na každém projektu. Někdy víc, někdy méně formálně. V Kanbanu to může být stěžejní záležitost. U nás jsme se domluvili, že prioritizaci budou dělat technical a project leader. Naplánovali jsme to týdně na páteční ráno, aby bylo od pondělí jasno, co si lidi můžou brát.

Moc to nefungovalo, sešli jsme se jen párkrát. Přesto to nějak jelo bez větších zádrhelů, možná tomu napomohla automatická prioritizace vyplývající z classes of service (viz výše). U většího projektu by to asi byl dost problém. Prostě další oblast pro zlepšení.

Odhady

Na projektu jsme zavedli relativní odhady tasků pomocí triček (T-shirt estimations). Používali jsme velikosti S, M, L a XL. Pokud něco mělo velikost XL, bylo potřeba to dále rozbít na menší části. Pro odhadování samotné jsme používali planning poker s odpovídajícími hodnotami karet.

Odhady jsme dělali jednou týdně, většinou to zabralo hodinu. Členové týmu si stěžovali, že to jde pomalu (odhadne se toho málo), na druhou stranu oceňovali diskuzi, která nad tasky vznikla a umožnila tak lépe pochopit daný problém.

Odhady jsme začali dělat přibližně ve stejné době jako retrospektivy, takže neměly tak velký přínos, jak by mohly, kdybysme s nimi začali už na začátku projektu. Pozitivně vnímám, že je dělal celý tým. Naučili jsme se, jak používat trička a na dalším projektu budeme pokračovat.

Zhodnocení

Toto je druhý projekt, kde jsem aplikoval Kanban a potvrdilo se mi, že je to životaschopný a přínosný nástroj. Jako u všeho, co je tvořeno "měkkými" pravidly, hodně záleží na poučenosti lidí v týmu. Jednou z hlavních zkušeností je pro mne: vysvětlování není nikdy dost - tady se budu muset ještě hodně zlepšit. Ale doufám, že už jsem své kolegy naočkoval a příště to bude zase o něco snadnější.

Myslím, že učednická léta už mám v Kanbanu za sebou. Teď je potřeba zaměřit se na pokročilejší témata a zlepšit a dotáhnout do konce věci, jako jsou metriky, třídy služeb, plánování a odhady, používání modelů ad.

Už teď je jasné, že Kanban použiju na příštím projektu. Takže cca za rok si budete moci přečíst další díl tohoto článku. Nebo seriálu? ;-)

Mind Map

Související články

• Kanban, lehký úvod
• Kanban, zprávy z fronty
• Kanban z čistého nebe

Kanban, zprávy z fronty

V létě jsem psal o tom, jak na mne nečekaně spadla implementace Kanbanu (post Kanban z čistého nebe). Turbolence na projektu mě mezitím zavály jinam, nicméně aby moje investice nepřišla nazmar, udělám si jakési lesson learned.

Co je to Kanban?

Protože tenhle článek je hlavně o implementaci Kanbanu, uvedu pouze krátkou definici pro neznalé. Odkazy pro další informace o Kanbanu najdete v článku Kanban z čistého nebe.

Takže. Kanban je metoda pro limitování rozpracované práce (work-in-progress), která vychází z  Lean developmentu a je definovaná pěti základními principy:

1. Vizualizuj workflow.
2. Limituj rozdělanou práci.
3. Měr a spravuj flow.
4. Udělej procesní politiky explicitní.
5. Používej modely pro rozpoznání příležitosti ke zlepšení.

Obecně o projektu

Úkolem daného projektu bylo dodat sadu webových služeb (cca 60 business služeb). Daná technologie je z hlediska Kanbanu nepodstatná. Služby by měly splňovat základní SOA pradigmata - být autonomní, volně propojené (loose coupled), s velkou granularitou (coarse-grained). Implementované služby byly zasazeny do klasické middleware architektury, která vypadala velmi zhruba takto:

Vývoj služeb byl trekován v JIRA: co služba, to (GreenHopper) user story. Z hlediska projektu (Kanbanu) byly všechny dodávané služby unifikované - jejich dodávka se sestávala vždy ze stejných kroků, což Kanbanu (ale stejně tak třeba i Scrumu) vyhovuje. Jednotlivé kroky byly v JIRA vedeny jako technické subtasky dané user story.

1. Kontrakt. Definice WSDL a příslušných XSD schemat.
2. Mock. Jednoduchá implementace služby bez orchestrace, business logiky a volání backendů, tak aby frontendové komponenty měly vůči čemu vyvíjet.
3. Implementace. Plná implementace služby včetně orchestrace, volání backendů, číselníkových překladů atd.
4. Unit testy. Unit testy validací, orchestrace, business logiky, fault handlingu apod.
5. Dokumentace. Jednak sebepopisná dokumentace kontraktu, jednak model orchestrace služby v CASE nástroji.
6. Continuous Integration. Build, deployment, unit testing a undeployment v CI nástroji.

Dodávka služby končila nasazením služby na SIT (System Integration Test) prostředí.

Něco málo o týmu

Na projektu jsme začínali dva. Pak to bez varování vyskočilo až na neúnosných 17 lidí, aby se to po nějakém čase ustálilo na rozumných 10 vývojářích.

Tým byl tvořen z 90 % seniorními vývojáři, z nichž všichni se s Kanbanem setkávali poprvé. Lidé v týmu byli přátelsky a pozitivně naladěni a naštěstí se nenašel žádný kverulant, který by se metodiku snažil sestřelit.

Implementace 5 principů Kanbanu

Následujících pět sekcí je gró tohoto článku, aneb jak jsme se vypořádali s implementací jednotlivých principů Kanbanu.

1) Visualize Workflow

Vizualizuj workflow. Workflow jsme měli ve dvou provedeních, ve vztahu master-slave. "Pravda" byla v issue tracking nástroji JIRA, kde jsme používali agilní plugin GreenHopper (jeho Kanban část). JIRA byla mým hlavním nástrojem pro řízení týmu.

Elektronický JIRA Rapid Board

JIRA má pro klasický Kanban Board vlastní název - Rapid Board. Vstupem do něj je běžný JIRA filtr, v obrázku výše jsou vyfiltrované pouze technické subtasky.

Obrazem elektronického workflow v JIRA byl fyzický Kanban Board, vytvořený z whiteboardu a lepicích lístečků. Každý člen týmu měl za úkol synchronizovat své úkoly v JIŘe s fyzickou tabulí.

Fyzický Kanban board

Podobně jako v JIŘe byly vyfiltrovány pouze technické subtasky, tak i na fyzické tabuli byly jenom subtaskové lístečky. Subtasky z jedné user story se v sekci Done lepily na sebe a když byla user story kompletní, nahradily se lístečky lístkem jiné barvy, který reprezentoval danou user story.

2) Limit Work-in-Progress

Limituj rozdělanou práci. Nastavení správného počtu úkolů, které mohou být v jednu chvíli rozpracovaný, je jedním z nejtěžších úkolů v Kanbanu. Hodně tady může napomoct teorie front a samozřejmě empirické zkoušení, testování a měření.

V Kanbanu se někdy nastavuje pouze horní limit, já jsme nastavil horní i spodní a sice spodní limit byl počet vývojářů (velikost týmu mínus teamleader) a horní limit na dvojnásobek vývojářů. Každý vývojář tak musel mít přiřazený minimálně jeden úkol, ale maximálně mohl mít rozpracovaný pouze dva tasky.

3) Measure and Manage Flow

Měr a spravuj flow. Flow se v Kanbanu typicky zobrazuje pomocí diagramu Cumulative Flow, což dokáže i JIRA. Na obrázku níže představují barvy jednotlivé sekce ve flow: oranžová - To Do, modrošedá - In Progress, zelená - Done.

Diagram má dva důležité rozměry. Horizontální délka dané sekce (nebo sekcí) říká, jak dlouho byl průměrně úkol v odpovídajícím stavu. Pokud vezmu například oranžovou a modrošedou barvu (= To Do + In Progress), říká mi tím diagram, jak (průměrně) dlouhý čas uběhl od zadání tasku do JIRy po jeho implementaci. Pokud bych vzal pouze úkoly ve stavu In Progress, dostávám velocitu tasku - jak dlouho trvala implementace úkolu.

Vertikální délka dané sekce říká, kolik bylo úkolů v dané sekci v určitý čas. V případě tasků v In Progress by to mělo odpovídat limitům WIP.

Ideálním stavem pro Kanban je, pokud je "tloušťka" tasků v In Progress (šedomodrá) více méně konstantní a rovnoměrně rostoucí. Alarmujícím příznakem je zvětšující se sekce To Do, což znamená, že se nám fronta začíná zahlcovat.

Diagram Cumulative Flow v JIRA

Tolik teorie. V praxi tady vidím (u sebe) dluh, protože jsme nedokázali měřit velocitu týmu. JIRA sice umí vytvořit diagram kumulativního flow, ale neumožňuje s těmi daty nijak pracovat, tj. nejsem schopen spočítat, kolik tasků je tým schopný udělat např. za týden (velocita týmu) a jak průměrně dlouho trvá implementace úkolu. (Kdybych se mýlil a věděli byste, jak tyto údaje z JIRy dostat, dejte mi, prosím, vědět v komentářích.)

Inkriminované údaje by se daly například spočítat v Excelu, ale ten se mi nechtělo ručně vést, takže jsem na jejich zjištění rezignoval a pouze vizuálně kontroloval diagram, jestli nedochází k nějakým extrémním výkyvům.

Co se týká správy flow, průběžně jsem ho měnil podle zpětné vazby od týmu a také podle vlastní úvahy, jak jsem nad ním přemýšlel a pracoval s ním. Jako příklad můžu uvést nové stavy Blocked, In Test, nebo To Review.

[update 13. 2. 2013] V komentáři jsem dostal odkaz na výborný obrázek, kde je Cumulative Flow diagram krásně vysvětlený:

Jak rozumět diagramu Cumulative Flow (zdroj Paul Klipp)

[/update]

4) Make Process Policies Explicit

Udělej procesní politiky explicitní. Procesní politiky jsme měli v podstatě pouze dvě, jednu z nich nepsanou. Ta definovala jak a kdo je zodpovědný za jednotlivé tasky v průběhu flow. Ačkoliv vznikl její model (viz další bod), nebyl do týmu v daném čase publikován.

Kromě toho existoval na týmové wiki dokument s Definition of Done (DoD) pro jednotlivé technické subtasky. Tento dokument byl na wiki z toho důvodu, že jak už jsem psal výše, jednotlivé user story byly unifikované, takže nebylo potřeba uvádět DoD pro každý subtask do JIRy, ale dal se použít jeden centrální dokument vůči kterému šlo úkoly validovat.

5) Use Models to Recognize Improvement Opportunities

Používej modely pro rozpoznání příležitostí ke zlepšení. Tenhle ten princip jsem dosti dlouho ignoroval, protože jsem nevěděl jak ho uchopit a z počátku mi přišly daleko důležitější první tři principy Kanbanu. Nicméně, jeden model jsem nakonec vystřihnul. Jeden obrázek je za tisíc slov, takže jak fungovalo "samoobslužné" zpracování tasků:

Model flow

Barvy v obrázku odpovídají jednotlivým stavům v diagramu cumulative flow (To Do, In Progress, Done). Pokud přišel požadavek na novou službu, team leader jej rozpadl na jednotlivé subtasky (kontrakt, mock atd.) a zadal je do JIRy, kde je zprioritizoval.

Vývojáři si potom sami brali prioritní tasky a implementovali je. Hotové úkoly, ve stavu Done, pak reviewoval team leader.

Zlepšení flow, které mne díky tomuto jednoduchému modelu napadlo (ale už jsem neměl čas je zrealizovat) je přesunutí Review na roli vývojáře. Podobně, jako si vývojáři sami brali nové tasky, brali by si sami i tasky na review.

Jak se totiž v praxi ukázalo, Review bylo úzkým hrdlem flow. Jeden člověk (team leader) bude těžko zvládat dělat review a ještě držet agendu 10-15 lidí v týmu. Což je logické, byť to nemusí být na první pohled zřejmé.

Pravidelné týmové aktivity

Samotný Kanban neřeší další týmové náležitosti, ale pro lepší dokreslení řízení projektu je tady taky uvedu.

Denní stand-up

Ráno jsme dělali klasický stand-up meeting. Nepoužívali jsme Scrumovské: "co jsem dělal včera a co budu dělat dneska?" Protože Kanban je zaměřený na flow a odstraňování jeho překážek, zněla otázka:

Co budu dneska dělat a co mi v tom brání?

Týdenní code review

Jednou týdně, v pátek, probíhalo code review, kdy se procházely kontrakty, implementace služeb, unit testy, zkrátka věci definované v Definition of Done. Review probíhalo (s celým týmem) check-outem z verzovacího systému, procházení kódu v IDE a jeho promítání na stěnu, tak aby to viděl celý tým.

Týdenní design review

Jednou týdně, ve středu, probíhalo design review, kdy se procházely návrhy orchestrací služeb, jejich implementací apod. Review probíhalo (s celým týmem) u whiteboardu, kde se ručně kreslilo zadání a diskutoval design.

Shrnutí

Jak už jsem psal v úvodu, Kanban byl pro mne novinka a z počátku jsem k němu přistupoval opatrně. Přece jenom, pár zmršených implementací Scrumu už jsem viděl a Kanban je něco ještě daleko novějšího.

Nicméně, snažil jsem se k tomu přistoupit zodpovědně a myslím, že se nám Kanban podařilo naimplementovat rozumně, korektně a funkčně.

Pokud bych to měl nějak celkově shrnout, myslím, že Kanban je životaschopný způsob, jak řídit vývojářský tým. Je vhodný nejenom pro supportní typy tasků (jak se obvykle traduje), ale i pro vývoj nových funkčností a systémů. Ve velmi dobré symbióze funguje Kanban s vývojem middlewarových služeb, protože požadavky na nové a úpravu stávajících služeb se jaksi přirozeně frontují.

Pokud bych tedy měl někdy v budoucnu volnou ruku ve výběru metodiky, o Kanbanu bych velmi vážně uvažoval.

Související články:

• Kanban z čistého nebe
• Kanban, ultimátní kniha
• Lean ze zákopů

Lean ze zákopů

Když už se do něčeho pustím, tak pořádně. Sotva jsem tak dočetl jednu knihu o Kanbanu, už jsem schroustal další. Tentokrát jsem si vybral dílko od Henrika Kniberga, které vyšlo v mojí oblíbené edici The Pragmatic Programmers.

Henrik pracuje jako Agile & Lean coach a v knize Lean from the Trenches, s podtitulem Managing Large-Scale Projects with Kanban, zpracoval formou case study svoji zkušenost s koučováním 60ti členného týmu švédské policie :-) který interně vyvíjel nový "digitální vyšetřovací systém". To zní skoro až exoticky, ale nebojte, slovníček švédštiny hledat nemusíte - celá knížka je napsána s ohledem na projekt a softwarový vývoj a reálie jsou zcela nepodstatné. Co naopak je podstatné, je že tým používal Scrum, XP a Kanban a projekt úspěšně zvládl.

Knížka je rozdělena do dvou částí, z nichž ta první How We Work obsahuje zmiňovanou case study a jednotlivé kapitoly jsou často koncipovány formou How We ..., např:

• How We Sliced the Elephant
• How We Involved the Customer
• How We Handle Urgent Issues
• Why We Limit the Number of Bugs in the Bug Tracker
• Why We Don't Use Story Points
• How We Do Version Control

Druhá část, nazvaná A Closer Look at the Techniques, potom krátce rozebírá jednotlivé techniky, principy: Agile, Lean, Scrum, XP a Kanban.

Knížka se velmi dobře čte a i přes svůj krátký rozsah (176 str.) je nabitá cennými informacemi. Zájemcům o Kanban/Lean rozhodně doporučuji.

Kanban, ultimátní kniha

Posledně jsem psal, jak jsem přišel ke Kanbanu jako slepej k houslím. Jedním ze zmiňovaných zdrojů v článku je knížka Kanban od Davida J. Andersona. David je jedním z pionýrů Kanbanu v softwarovém vývoji a jeho kniha má aspiraci (a velmi slušný potenciál), stát se biblí této zajímavé metody.

Na to, jak je Kanban jednoduchej je kniha poměrně obšírná (280 str.). Tematika je velkoryse rozebrána ve dvaceti kapitolách, rozdělených do čtyř částí:

1. Introduction
2. Benefits of Kanban
3. Implementing Kanban
4. Making Improvements

Každá kapitola je ukončena sekcí Takeaways, kde je v hutných bodech shrnut její obsah. To je šikovná věc, protože až se bude člověk jednou k daným tématům vracet, tak takový rychlý přehled se jednak umožní rychle zorientovat a jednak může sloužit jako reference (bez té omáčky v textu).

Jako zajímavější mi přišly první tři části knihy, které byly zaměřeny velmi prakticky. V poslední části už jsem se občas ztrácel, protože se zde řeší ekonomické modely, teorie omezení (Theory of constraints) apod., což není úplně můj šálek kávy (nicméně, přečet jsem to).

Pokud bych měl z knihy vypíchnout nějaké zajímavé momenty, tak to budou spíše ty, které nesouvisí přímo s Kanbanem (ale velmi dobře mu konvenují) a které rezonují i s mojí osobní zkušeností:

"Issue management and escalation are core disciplines that provide a big return. Improving them should be a priority even for the most immature teams."

"Use of peer reviews, pair programming, unit tests, automated testing frameworks, continuous (or very frequent) integration, small batch sizes, cleanly defined architectures, and well-factored, loosely coupled, highly cohesive code design will greatly reduce defects."

"As we all know, there really is no such thing as multi-tasking in the office; what we do is frequent task switching."

"Many 'softies' prefer conference calls for coordination meetings rather than face-to-face. This has a negative impact on the level of trust and social capital in their workforce, but it facilitates efficiency."

"Trust is a hard thing to define. Sociologists call it social capital. What they've learned is that trust is event driven and that small, frequent gestures or events enhance trust more than larger gestures made only occasionally."

Knihu můžu opravdu vřele doporučit. uvnitř najdete opravdu hard-core Kanban, se spoustou rad, jak jej implementovat, široké uvedení do kontextu, plus navrch i nějaká ta teorie.

Kanban z čistého nebe

Trochu nečekaně jsem dostal na stávajícím projektu na starost nový, teprve vznikající tým. A že prý (nařízeno shora) jedeme Kanbanem. Inu, proč ne. Akorát že o něm nic nevím. Takže jsem se pustil do studia, protože něčemu nerozumět, to pro mne není příjemný stav.

Pročetl jsem několik internetových článků, z nichž bych vypíchnul:

• Introduction to Kanban
• Kanban Applied to Software Development - aneb od tradičního Kanbanu k softwarovému vývoji.
• Vizualizing Agile Projects using Kanban Board - pravidlo č. 1: vizualizovat.
• One day in Kanban land - komiks :-)
• Tutorial - Tracking a Kanban Team - JIRA tutoriál pro GreenHopper.

Dále, protože jsem nelítostný čtenář, jsem zakoupil knihu. Vybral jsem si titul Kanban :-) od Davida J. Andersona, což je jeden z prvních early adopters Kanbanu v SW vývoji, takže jistě člověk povolaný.

Knížku mám zatím rozečtenou, tak se o ní nebudu předčasně rozepisovat. Ale když už jsem ji zmínil, ocituju z ní principy, na kterých Kanban stojí. Principy samotné jsou vysvětleny ve výše uvedeném článku Introduction to Kanban a jelikož k nim zatím nemám z vlastní zkušenosti co podotknout, skromně pomlčím. Tak tedy:

1. Vizualizuj workflow.
2. Limituj rozdělanou práci (work-in-progress).
3. Měř a spravuj flow.
4. Udělej procesní politiky explicitní.
5. Používej modely pro rozpoznání příležitosti ke zlepšení.

Poslední věc, kterou bych zmínil (jako výchozí stanovisko), je nástrojová podpora, kterou máme k dispozici. Jako issue tracking nástroj používáme JIRu, do které máme plugin GreenHopper pro agilní projekt management, který umí mmj. i Kanban.

Zatím jsem si s JIRou dosti hrál, abych vyzkoušel možnosti, které nabízí a prozatím můžu říct, že pro Kanban má dobrou podporu. Jenom není úplně jednoduché to nějak nastavit. Respektive, nastavení je triviální, ale vzhledem k jednoduchosti Kanbanu je potřeba celý proces vymyslet - Kanban vás v tomto nijak nenavede - a to jednoduché nemusí být.