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)

Mercurial, strategie branch-by-feature

Mercurial je skvělý, distribuovaný Version Control System (VCS, či DVCS), který nabízí velkou míru volnosti, jak s nakládat s verzováním zdrojových kódů. Svobodu většinou chápeme jako pozitivní věc, někdy je ale přílišná nespoutanost na škodu. A tak definování nějaké verzovací strategie prospěje týmu i projektu.

Proč mít verzovací strategii?

Verzovací strategii branch-by-feature jsme s úspěchem použili na stávajícím projektu. Důvody, proč jsme si něco takového definovali byly dva:

• Když jsem se mihnul na předcházejícím projektu (taky Mercurial), žádná strategie, či konvence definovaná nebyla . Člověk pak slýchal řeči jako: "Proč to furt merguješ?", "Vznikaj ti tam anonymní branche." a "Tam by's měl používat rebase.". Prostě klasický, tohle-tady-všichni-ví a takhle-to-děláme-ale-tobě-jsme-to-neřekli.
• Chtěli jsme mít na nadcházejícím projektu formalizované code review.

Takže jsme se zamysleli, chvilku nad tím špekulovali a pak jsme, spolu s podporou dalších nástrojů, došli k následující strategii.

Strategie branch-by-feature

Princip téhle strategie je jednoduchý a dá se popsat jednou větou: Pro každou novou feature (nebo bug) se založí nový branch. Hotovo, vymalováno.

A teď trochu obšírněji. Na počátku je v repozitory pouze jeden permanentní branch. Zpravidla se mu říká development branch. Z něj se odlamují další branche pro vývoj - feature branche. Co přesně tyto branche představují, záleží na granularitě položek, do kterých jsme si práci rozdrobili. Může to být user story, feature, requirement, task. Ideálně je to něco, co evidujeme v issue tracking systému (ITS).

Probíhá běžný vývoj a všechny komity jdou do (odpovídajícího) feature branche. Když je vývoj hotový, proběhne code review a pokud jsou změny akceptovány, zamergují se do development branche a feature branch se zavře. Pokud jsou změny zamítnuty, provede se náprava, komitne se do feature branche, následuje code review atd.

Pokud jsou v této fázi nalezeny nějaké bugy, přistupujeme k nim stejně jako k feature. To jest, bug branch -> code review -> merge do development branche.

Verzovací strategie branch by feature

Po nějakém čase vznikne release branch. Pokud jsou v něm nalezeny chyby, vzniká bug branch a po code review přichází merge jak do release, tak do development branche.

Celý postup se dá shrnout do následujících bodů:

1. Vytvoření nového feature/bug branche.
2. Development.
3. Změny projdou code review.
4. Uzavření feature/bug branche.
5. (Bugfixy jsou zamergovány do release branche.)
6. Změny jsou zamergovány do development branche.

Z pohledu příkazové řádky vypadá proces takto:

$ hg branche fb-logging
$ hg commit -m 'Logging feat. has been developed.'
$ hg commit -m 'Close branch fb-logging.' --close-branch
$ hg update default
$ hg merge fb-logging
$ hg commit -m 'Merge branch fb-logging -> default.'

Zcela záměrně se vyhýbám popisu code review. To proto, abych nekradl materiál svému kolegovi Banterovi, který již jistě brzy napíše článek, o tom, jak to děláme (je to fakt cool, tak se těšte). Nicméně, ve vztahu k Mercurialu si nemůžu odpustit, jak to vypadá procesně. Přepokládám, že všichni čtete plynně BPMN ;-)  takže dalších slov netřeba. Mercurial aktivity jsou v oranžovém rámečku.

Code Review proces (oranžové jsou aktivity v Mercurialu, modré v RhodeCode)

Drobná a příjemná vylepšení

Což o to, proces, jako takový, je pěkný. Na někoho je ale možná trochu komplexní. Přece jenom, když mastíte celý život všechno jenom do trunku, může to být trochu moc věcí najednou. Tady je pár věcí, které nám to o něco usnadnili.

Konvence

Konvence jsme měli nastavené jednak pro názvy branchů a jednak pro komitovací komentáře. Název nového branche se skládal z prefixu a čísla issue v ITS. Prefix byl buď fb- (feature branch), nebo bb- (bug branch). Např. fb-42, bb-1024.

Konvence pro komentáře by se daly rozdělit do tří skupin: běžné komentáře, při zavírání branche a při vytváření releasu. Konvence samotná by se v Mercurialu dala pohlídat pomocí hooku, ale nedokopal jsem se k tomu, ho napsat. Pro "běžné", vývojové komentáře jsme měli konvenci WIP #nnn; some comment. WIP je zkratka pro Work In Progress, nnn je id issue v ITS. Např. WIP #1561; Payment button has been removed.

Zavření branche se skládá ze čtyř Mercurial příkazů (commit, update, merge, commit, viz výše) a obsahuje dva komentáře ve formátu:

• Close branch <branch-name>.
• Merge branch <branch-name> -> default.

Za zmínku stojí mergovací komentář, ze kterého by mělo být jasné, odkud kam merge proběhnul.

Komentáře při zavírání branche

Releasovací komentáře byly celkem čtyři a obsahovaly klíčové slovo [Release].

Komentáře při vytváření releasu

V předešlém popisu vás možná zarazilo, že jak pro zavření branche, tak pro vytvoření releasu je potřeba spustit čtyři Mercurial příkazy. Dělat to ručně by byla značná otrava a hlavně by celá konvence brzo erodovala do chaosu. Šťastni kdož používají automatizaci, neboť jen ti vejdou do křemíkového nebe.

Mercurial alias

S používáním aliasu přišel kolega Banter, takže mu za to patří dík a rád ho zde zvěčním. Alias samotný vypadá dost ošklivě, zato jeho použití je elegantní. Jedinou vadou na kráse je, že jsme nepřišli, jak alias spustit z grafických nástojů, jako je SourceTree, nebo TortoiseHg, takže ještě budeme muset zapracovat na tom, aby tuto fičurku mohli používat i kolegové, kteří ještě nepřišli na to, jak cool je používat command line ;-)

Alias stačí přidat do souboru ~/.hgrc a spouští se jednoduchým příkazem hg close-feature nnn, kde nnn je (v našem případě) čístlo issue v ITS, tj. to, co je za prefixem fb-.

[alias]
close-feature = ![ -z "$1" ] && echo "You didn't specify a branch!" && exit 1; \
                if hg branches | grep -q "fb-$1"; \
                    then $HG up fb-$1; \
                         $HG commit -m 'Close branch fb-$1.' --close-branch; \
                         $HG pull; \
                         $HG up default; \
                         $HG merge fb-$1; \
                         $HG commit -m 'Merge branch fb-$1 -> default.'; \
                    else echo "The branch fb-$1 does NOT exist!"; \
                fi

Gradle release task

Náš projekt buildujema Mavenem. Chvilku jsem se snažil napasovat Maven Release plugin na naši branchovací strategii, ale pořád to nějak nebylo ono - je to prostě moc šitý na SVN. Pak jsem ztratil trpělivost a odpovídající chování si napsal jako Gradle task. Časem se z toho snad vyklube Gradle plugin.

Task samotný tady uvádět nebudu, protože je asi tak na tři stránky. A taky potřebuje ještě trochu poladit. Zkrátka ještě není zralý na to, abych ho dal z ruky. V podstatě ale dělá pouze to, že přepíná branche, šolichá s Mercurialem a manipuluje s verzí v pom.xml. A dělá to ty hezké komentáře, co jsem uváděl výše.

Pros & Cons

Celý výše popsaný koncept jsme vymysleli ještě před projektem. Pak přišel projekt a emotivně musím říct, že nám to krásně fungovalo. Jako hlavní benefit vidím, že jsme si formalizovali proces code review a s výše uvedenou branchovací strategií to bylo velice efektivní. Dalším plusem byla, "úhledná" práce s Mercurialem, kdy byla radost se prohrabávat verzovanou historií.

K negativům bych zařadil komplexnost. Pokud by nám nešlo o code review, asi by tato strategie byla zbytečná. Zatím mi taky chybí nějaká podpora v grafických a automatizačních nástrojích. Jako milovníkovi CLI mi to osobně nijak nevadí, ale musím myslet taky na ostatní členy týmu (bývalý kolega jim říkal "makáči" :-)  pro které by mělo být používání nástrojů co nejsnadnější.

Je to všechno?

Abyste dostali plný obrázek, jak to celé fungovalo, chybí nám jeden velký dílek skládanky - jo, code review. Takže pokud vám něco nedává smysl, tak je to možná proto, že jsem v tomto článku celkem důsledně odpáral použití dalších dvou nástrojů, které byly s branchovací strategii organicky provázané - issue tracking system a RhodeCode, nástroj, ve kterém jsme, pomocí pull requestů, řešili code review.

Popis code review je na samostatný článek. Tak snad ho Banter brzo napíše a já sem pak lísknu odkaz. A jinak doufám, že vám zmiňovaná strategie branch-by-feature přijde inspirativní.

Happy branching! :-)

Mind Map

Související články

• Mercurial, jak nastavit P4Merge jako nástroj pro vizuální merge a diff

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

Code review checklist

Nedávno jsem v práci prezentoval, jaké přínosné věci používáme na aktuálním projektu. Vyzkoušeli jsme si spoustu zajímavých nástrojů a praktik a v podstatě to byla taková laboratoř, kdy ty funkční záležitosti použijeme na dalším projektu. Mind mapa níže shrnuje přehled prezentovaných témat.

Jedním z nejcennějších realizovaných konceptů pro mne je, že se nám podařilo naimplementovat funkční a efektivní code review. (Doufám, že kolega Banter o tom brzy napíše článek.) A co čert nechtěl, po zmiňované prezentaci se nejvíc diskutovalo právě code review. Jedním z výstupů téhle diskuze je, že by bylo dobré mít nějaký code review checklist.

Já takový checklist nemám, protože ke code review přistupuju intuitivně (což ale neznamená, že nevím, co přesně chci, naopak). Nicméně pro potřeby diskuze jsem si sesumíroval, co by v takovém checklistu mohlo být.

Pozitivní věci na projektu (code review je fialový)

Co je to code review?

Ač se pojem code review používá v oblasti softwarového inženýrství dosti zhusta, má celkem nejednoznačný obsah. Pro někoho to je výsledek nástrojů jako je SonarQube, PMD, FindBugs ad. Tyto nástroje řeší tzv. statickou analýzu kódu a jsou výbornými pomocníky při udržování kvalitního kódu.

Ale code review, tak jak ho chápu já, začíná tam, kde tyto nástroje končí. Prostě tam, kde stroje selhávají, či nestačí, přichází ke slovu "stará dobrá ruční práce". Dalo by se to také nazvat jako asynchronní peer review.

Co je to code review checklist?

Checklist ((kontrolní) seznam bodů) slouží k tomu, abychom na něco nezapomněli. Třeba koupit chleba a mlíko cestou z práce. V případě code review jde o to, nezapomenout projít některý z aspektů, které chceme v rámci review kontrolovat.

Hlavní oblasti

Věci, které tak nějak intuitivně kontroluji při code review by se daly shrnout do těchto základní oblastí:

• Konvence
• Design
• Best-practices
• Závislosti
• Pokrytí testy

Konvence

Kdekoliv dochází k nějaké sociální interakci, jsou přítomny konvence. Buď již existují, nebo se začnou vytvářet. V dnešní době, kdy je vývoj software téměř vždy týmovou prací, je taková sociální (u některých programátorů a adminů spíše asociální) komunikace nevyhnutelná. Z hlediska code review, bych vypíchnul dva body, pro které je dobré konvence nastavit a dodržovat/kontrolovat:

• Formátování zdrojového kódu napomáhá jeho čitelnosti, pochopitelnosti, orientaci v něm atd. Tahle oblast se dá z větší části kontrolovat pomocí statické analýzy kódu (např. v Javě nástroj Checkstyle), ale některé věci zkrátka nejde nacpat do (automatických) pravidel. Domluvte se na nich, dodržujte je a váš reviewer vás bude mít rád ;-)
• Pojmenování. Věci by měly mít správná jména. Bude pak jasné, k čemu slouží, když se o nich budeme bavit, budeme více méně na stejné platformě a kdokoliv nový to lépe a rychleji vstřebá. Typicky, je dobré mít jmennou konvenci pro komponenty, balíčky, třídy, metody a proměnné. A cokoliv dalšího, co dává smysl a bude se vyskytovat ve více instancích.

Konvence jsou velmi rozsáhlé téma. A stejně jako u spousty dalších věcí, o kterých budu psát, dochází k jejich přesahu do jiných oblastí. Berme to rozřazení do základních kategorií jako velmi volné.

Design

Tohle je moje oblíbené téma, a tak zde budu mít nejvíc položek. Je to taky z toho důvodu, že kontrola designu je pro mne jedním z hlavních cílů code review. Kdybych si měl vybrat jenom jeden aspekt, který revidovat, byl by to jednoznačně design.

• Konceptuální diskuze. Důvod, proč často zamítnu reviewovaný kód je, že zavádí nějakou konceptuální změnu designu, která nebyla předem diskutovaná. Tohle má dvě složky. Jedna je subjektivní - mám určité designové preference a jelikož jsem většinou zodpovědný za architektonická rozhodnutí, tak je to moje právo a zodpovědnost. Druhá složka je týmová - pokud někdo "partizánsky" propašuje změnu, která bude ovlivňovat ostatní členy týmu, je to jasný důvod k zamítnutí. (Jen pro jistotu, partizánský zde má negativní konotace.) Obojí se dá jednoduše řešit zavedením designových review, kterých se účastní celý tým a kde se řeší design ještě před implementací.
• Testovatelnost. Nejsem TDD evangelista (v dnešní době?!), ale koncept a zkušenosti s unit testy mne jako vývojáře hluboce ovlivnily. Myslím si, že největší přínos a benefit unit testů je, že mají pozitivní vliv na design produkčního kódu. Kód, který je obtížně testovatelný, je prostě špatný.
• Konzistence. Systém/aplikace by měl být konzistentní napříč různými vrstvami, tj. odpovědnost jednotlivých vrstev/komponent, přístup ke zpracování výjimek, používané datové typy (třeba by pomohl kanonický datový model), přístup k logice (objektově, funkcionálně) atd.
• Znovupoužitelnost. Na úrovni knihoven, komponent, tříd, metod.
• SOLID. Systém/aplikace by měl respektovat dané/zvolené paradigma. V případě OOP by měl být "SOLIDní". Takže: Single responsibility, Open-close, Liskov substitution, Interface segregation, Dependency inversion. A objektový. Atd.
• Logování by mělo být smysluplné, odpovídající a se správnou severitou a formátováním. Občas mě zaráží, jak málo vývojáři přemýšlí u logování nad tím, že aplikace poběží většinu svého životního cyklu na produkci.
• Vyvarovat se: duplicity, komplexity, zanořené logiky (cykly, podmínky), věcí napevno napsaných v kódu (hardcoded). A smrtelně nebezpečné choroby DIY.

Zdroj: Dilbert.com

Best-practices

Best-practices asi není úplně nejlepší název pro tuto kategorii. A určitě není vyčerpávající a jistě mi leccos propadlo sítem.

• Kód by měl být čitelný a srozumitelný. Čitelný znamená, že po něm "oko dobře plyne", čemuž můžou napomoci konvence. A srozumitelný ve smyslu, že business logika by měla být jednoduše pochopitelná.
• Externalizace. Některé věci by v kódu neměly být vůbec: konfigurace, internacionalizace, to co patří do properties, řetězce literálů. Často je něco řešeno konstantama, místo použití enumů.
• Okomentovaný kód. Jestli je v kódu Javadoc se dá zkontrolovat statickou analýzou kódu. Jestli jsou ty komentáře aktuální, smysluplné a říkají to, co by měly, to už nám žádný nástroj neřekne. Pokud je kód čitelný a pochopitelný, mělo by v komentáři být popsaný hlavně výjimečné, či překvapující chování.
• Zakomentovaný kód. Jednoznačně vyhodit! Už nikdy se nepoužije a bude tam hnít roky.
• Neadresné TODO. Podobně jako zakomentovaný kód. Pokud mají vaši vývojáři potřebu si psát do kódu TODO, ať se tam aspoň podepíší. Stejně už se k tomu nejspíš nikdy nevrátí. Možná je to moje úchylka, ale nesnáším (měsíce, či roky staré) TODO v produkčním kódu.
• Komity do VCS by měly být malé, časté, smysluplné a měly by řešit pouze jedinou věc. A měly by mít rozumný komentář, ideálně nastavený konvencí. Když vidím komit/changeset, kde někdo opravil "půlku internetu", otevírá se mi imaginární kudla v kapse.

Závislosti

Ve zkratce, měli bychom si dát pozor, co nám kdo do aplikace/systému zatáhne. To se týká hlavně externích knihoven, ale také interní závislostí mezi jednotlivými vrstvami a komponentami.

Není to tak dávno, co jsem si tuhle říkal "proč je ta (Java EE) aplikace tak veliká?". Vypíšu si strom závislostí a ona je tam přibalená půlka Springu?!? Uf.

Pokrytí testy

Přiznám se, jednou jsem dělal na aplikaci, která měla 96% pokrytí testy. Ale jinak, nejsem žádný fanatik přes testy. Nicméně "rozumné" a "dostatečné" pokrytí testy by aplikace měla mít. Zejména business logiky. Naopak, není potřeba testovat platformu, či frameworky.

A kde je ten checklist?

Jak jsem psal v úvodu, tento článek je zamyšlením, co by v code review checklistu být mohlo. Možná, kdybych přemýšlel dost dlouho, tak bych dal dohromady i nějaký reálný checklist. Ale nechci. Mám rád, když jsou nastavená nějaká pravidla, ale musí umožňovat dostatek volnosti. Aby se dalo dýchat, aby nepotlačovaly invenci a motivaci. Diskuze je daleko důležitější, než mít nějaký papír na odškrtávání.

Mind map

Jak dělám Java pohovor II: proč nedávám testy?

Image courtesy of Michal Marcol
FreeDigitalPhotos.net

Je to už nějaký pátek, co jsem napsal (úspěšný) článek Jak dělám Java pohovor. Byl to pro mne výsledný stav určitého vývoje a shrnutí zkušeností z vedení technických (převážně Java) pohovorů, kterých jsem měl tehdy za sebou pár desítek.

Hned od počátku jsem měl štěstí, že mi nikdo nemluvil do toho, jak má interview vypadat. A jsem za tu důvěru vděčný. Taková svoboda mi vyhovuje, takže jsem si jednotlivé kroky pohovoru sestavil a vymyslel podle sebe.

Není to úplně jednoduchá věc, začít takhle z ničeho - není na to žádný mustr, informací je pomálu, není se moc koho zeptat, protože HR vám nejspíš neporadí a ten kdo dělal technický pohovory před váma, už nejspíš ve firmě nepracuje.

Proč nedávám testy

Jednu věc jsem věděl jistě - nechci používat žádné testy. Je s podivem, jak moc jsou testy na pohovorech rozšířené. Protože když uvážíme, jak malou mají, v daném kontextu, vypovídací hodnotu (osobně bych dokonce řekl mizivou) a jak velkou vyžadují režii na údržbu, aby aspoň k něčemu byly; člověk by řekl, že to za to nestojí.

Trochu to chápu. Když už jednou někdo ty testy vytvoří, tak je může dát kandidátovi klidně slečna z HR. On už to pak někdo vyhodnotí. Takže na první pohled se to zdá jako jednoduchý, efektivní a objektivní způsob ohodnocení kandidáta. Ani jedno z toho není pravda.

V první řadě, testy testují něco, na co kandidát téměř jistě nebyl připravený. Je téměř jisté, že ten obskurní syntaktický příklad, který v testu máte, nikdy v životě v praxi nepotkal. Ať už vám ta "chytrá" knížka, nebo internet, podle kterých jste to sestavili, tvrdí cokoliv. A nejde jen o to, že jsou příklady vycucané z prstu, problém je, že se na ně nedá nijak připravit - když si chci udělat certifikaci, vím, co se potřebuju naučit, jaký bude rozsah, co se dá použít ke studiu apod. Když jdu na pohovor, nevím nic - dostanu (nejspíš nekvalitní) test a záleží jen na štěstí, nakolik se moje zkušenost z obrovského Java kontinentu kryje s tématy v testu.

Šíře Java landscape je další problém. Co chcete vměstnat do rozumné délky testu? Dejme tomu, že by test měl trvat hodinu, předpokládaný čas na otázku je tři minuty (takže kandidát nad tím nebude moc přemýšlet a jen vysype z hlavy, na co si vzpomene), což vychází na 20 otázek. Kolik otázek věnujete Java SE? Kolik Java EE, kolik Springu? A co něco souvisejícího, třeba databáze, nebo skriptování? Taky máte dojem, že to jen škrábete po povrchu?

Možná si říkáte, zaměříme se jen na technologie, které používáme. OK, používáme na projektech Spring, tak budou testy o Springu. Právě jste se připravili o polovinu schopných lidí, kteří by u vás mohli pracovat. Na druhou stranu, třeba to tak chcete - jednodruhové, vyšlechtěné, single-malt vývojáře.

Dalším problémem testů je jejich aktuálnost. Jak často vychází major verze nějakého frameworku/platformy? Když vezmu v potaz Java EE (verze 5 až 7), tak za poslední čtyři roky bych takový test musel předělat dvakrát až třikrát (beru v úvahu, že reálné využití se nekryje s vydáním specifikace). Kdybych řešil jen Spring (verze 2.5-4.0), jsem na tom podobně.

A zmíním ještě jednu věc. Máte uni-sex testy "one-size-fits-all", které dáváte všem, bez ohledu na úroveň seniority? Máte pro každou senioritu zvláštní test? Jestli chcete dělat testy v rozumné kvalitě, budete s tím mít dost práce.

Co nějaká výjimka?

V tom, proč nedávat testy bych se mohl pitvat ještě dlouho, ale myslím, že pár zdatných (a dostačujících) důvodů jsem uvedl. Na druhou stranu, přeci jenom, nenašel by se nějaký případ, kdy testy u pohovoru dávají smysl? Přiznám se, nedávno jsem testy taky jednou použil. Či spíše přesněji: akceptoval je a podílel se na nich.

Byl to ale velmi specifický případ. Měl jsem možnost podílet se na nabírání Java vývojářů na Filipínách. Nabírat vývojáře na druhé straně světa není úplně jednoduché. Jádrem přijímacího procesu byl osobní pohovor, kdy za stranu zaměstnavatele se na něm podílely osoby z Česka (já), Francie a USA. Když už si to konečně naplánujete interně, že se sejdete na druhé straně glóbu, je podstatný, aby vám na pohor přišli už jenom relevantní lidé.

První filtrování udělalo místní HR. Jako druhý filtr jsem navrhoval klasický phone screen, ale vzhledem k časovému posunu (Česko-Filipíny +7 hodin) jsme se nakonec shodli právě na testech - hlavně z důvodu jejich asynchronicity. Napsal jsem tedy (s vydatnou a převážnou pomocí kolegy Bantera) test, který by byl takovým "rozumným" filtrem. Opravdu jenom filtrem, nic víc - pokud někdo neprošel testem, nemělo smysl se s ním vidět osobně.

Na tomto testu jsou podstatné tři věci, které ospravedlňují jeho existenci: kontext, účel a trvanlivost. Kontext je, myslím, jasný - pohovory na jiném kontinentu zkrátka normálně nedělám. Účel jsem už také zmínil, šlo o pouhý filtr, při celkovém hodnocení kandidáta jsem k testu nijak nepřihlížel. No a "trvanlivost" - šlo o jednorázovou záležitost, ten test jsem od té doby neviděl, vidět nechci a kdyby náhodou, bylo potřeba řešit najímání vývojářů v Jižní Americe ;-)  začal bych ze stejné pozice: testy raději ne.

Výzva

Jestli děláte pohovory a dáváte na nich testy - zkuste se nad těmi testy zamyslet. Dávájí vám to, co od nich očekáváte? Je nějaká jiná cesta, jak dosáhnout stejného výsledku? Troufám si tvrdit, že bez testů se vám podaří najmout kvalitnější lidi. Zkuste to, jen tak se posunete dál.

Mind Map

Související články

• Jak dělám Java pohovor
• Jak se nabírají Javisti na Filipínách
• Jak dělají Java pohovor jinde
• Měl by mít vývojář portfolio?
• Kontrakt místo pohovoru, je to reálné?
• Geek, který zapadne

Cesta samuraje, rok třetí

Uběhl třetí rok a samurajský meč je stále ostřejší. Jen poslední dobou nějak zahálí. Má smysl brousit měč, když se pak nikdy nepoužije? Někdy je to možná lepší. Ale dost planého filozofování, panta rhei.

Výpadek psaní

V uplynulých měsících jsem toho moc nenapsal. Poslední čtyři měsíce loňského roku vůbec nic a za celý letošek jsem se dopracoval ke čtyřem článkům. To je velmi tristní výsledek. Má to svoje důvody a jak to tak bývá, sešlo se jich víc dohromady. Čím to bylo?

V první řadě, loni v létě jsem začal po čase opět běhat a v zápětí nato jsem se (v období přechodného sebevědomí) přihlásil na Pražský maraton. Do té doby to pro mne byl nepředstavitelný cíl, ale říkal jsem si, že když na tom budu tvrdě pracovat, tak to zvládnu.

V rámci přípravy jsem naběhal tisíc tréninkových kilometrů, které sice zajistily, že jsem maraton v květnu bez problémů zaběhnul (a užil si to), ale také to ukrojilo pořádný kus mého volného času. Času, ve kterém jsem dříve psal.

Dalším, byť minoritním, důvodem ne-psaní je Gradle tutorial, který jsem začal loni psát. Chtěl jsem trochu diverzifikovat své čtenáře a tak jsem se domluvil se serverem Zdroják, že bych publikoval primárně u nich a pak teprve u sebe na blogu.

Měl jsem tehdy vypracovaný pravidelný rytmus tří článků za měsíc, který vyplýval z toho, že jsem pravidelně psal. Bohužel, nepředvídatelnost publikování na Zdrojáku mi tento rytmus rozhodila, což ovlivnilo i pravidelnost psaní - ve výsledku to totiž znamenalo napsat o jeden článek měsíčně navíc. Což jsem chvíli zkoušel, ale nefungovalo to, bylo to zkrátka už moc.

Posledním důvodem je, že jsem de facto neměl doma k dispozici notebook na psaní. Sdílet v rodiné konstalaci notebook je totéž, jako se prát o ovladač k televizi. A jelikož já svým psaním na blog peníze nevydělávám, bylo o vytížení notebooku rozhodnuto.

Bylo by hezké říct, že jsem tyto problémy a výzvy vyřešil a nyní budu zase psát jako dřív. Částečně ano, ale co se počítá, jsou hotové, dodělané věci, takže uvidím. Rád bych se dostal do tempa dva články za měsíc, tak mi držte palce.

Práce

Hodně článků, které jsem napsal, nějakým způsobem kolidují s mojí prací. A protože třetí rok Software Samuraje se kryje se změnou zaměstnání, rád bych se ohlédl i zde.

Když jsem před rokem hledal novou práci, chtěl jsem něco, kdy bych mohl skloubit tři věci, které mne baví: team leading, SW architekturu a Java development. Štěstí se na mne usmálo a přesně takovou práci jsem našel. A po roce jsem stále spokojený a moc se těším na ten další. Kdyby vás zajímalo, o co jde, sepsal jsem o tom článek Hledám do svého týmu Java vývojáře, článek je pořád aktuální.

Z témat bych vypíchnul:

Team leading: mám dosud nevídaný luxus - můžu si sestavit svůj vlastní vývojářský tým. Už vybírám víc jak rok a zatím jsme na osmi lidech. Už dlouhodobě o tom plánuju sepsat článek, řekl bych, že bude hodně zajímavý :-)

Jako team leader jsem si vyzkoušel nové věci a zlepšil ty stávající. Třeba mentoring, 1:1 pohovory a retrospektivy.

Teamová kultura: i tady jsem vyhrál loterii, je to asi nejlepší pracovní prostředí, kde jsem jako vývojář pracoval. A mám skvělého šéfa.

Hiring: technical recruitment mě baví. A rád bych o tom napsal pár článků. Za ten rok jsem absolvoval desítky pohovorů a je to interesantní materiál.

Cestování: za poslední půl rok jsem pracovně navštívil tři kontinenty (Evropa, Asie, Afrika) a brzy to bude asi Amerika. Cestování mě baví a je to výborná zkušenost (ne vždy pozitivní ;-)

Metodiky: nějaké metodiky už u nás máme. A já mám možnost je vylepšovat a zavádět nové. Stal jsem se tak trochu Kanban evangelistou. A to je taky vděčné téma ke psaní.

Budoucnost

Co přinese další rok? Chtěl bych se víc věnovat psaní. Dva články měsíčně.

Chtěl bych psát o Kanbanu. Praktické zkušenosti (aktuálně máme za sebou další projekt), i víc osvětové a teoretické věci.

V práci používáme na verzování Mercurial. Moc se mi ten nástroj líbí, takže nějaký ten článek by mu slušel.

Gradle. Můj hřích - chtěl bych pokračovat v tutorialu (a dokončit ho). A taky udělat evangelizaci u nás v práci.

Technical recruitment: chtěl bych napsat o vytváření týmu. A chtěl bych (opět) napsat o tom, jak dělám Java pohovory.

Mind Map

Myšlenkové mapy používám už dlouho, léta. Je to skvělý nástroj. Teď zrovna mám období znovu oživeného zájmu o ně a napadají mě další způsoby jejich použití. Třeba připravit si pomocí mind mapy strukturu článku. Je to docela zajímavý proces. Tak si zkusím zaexperimentovat a tyhle přípravné mapy k daným článkům publikovat.

Související články

• Cesta samuraje, rok druhý
• Cesta samuraje, rok první

Třetí rok s Kindlem

Tak už jsou tomu tři roky, co jsem si koupil Kindle. Loni jsem psal o vynuceném upgradu z Kindle 3 (Keyboard) na Kindle Touch (ani jeden z nich už Amazon neprodává). Letos mne nic takového bohužel a bohudík nepotkalo.

Bohudík, protože mám rád, když věci dobře slouží - předposlední telefon (Motorola Razr2) jsem měl 5,5 roku a ještě pořád bych ho mohl povolat ze zálohy. A Kindle Touch se mě drží jako klíště a snáší se mnou dennodenní útrapy. Už jsme starý parťáci, tak spolu ještě vydržíme.

Bohužel, protože minimálně čtyři vlastnosti aktuálního Kindle Paperwhite se mi moc líbí:

• je o polovinu lehčí a tenčí než Touch,
• má vestavěné osvětlení,
• Vocabulary Builder
• a napojení na Goodreads.

Když už jsme u toho Goodreads, zmigroval jsem tam svůj reading-list, takže se můžete porochnit v mých poličkách. A pokud tam náhodou jste taky a trpíte podobnou úchylkou jako já - lunetická potřeba číst a číst a číst, klidně mě kontaktujte.

Ze ten rok se mi podařilo přečíst 30 knih, taková, řekl bych, všehorodá směska. Následujou ty, které bych označil širokým pojmem "odborné".

Software Engineering

• Agile Retrospectives - hodně dobrá kniha o (agilních) retrospektivách. Zaměřuje se převážně na retrospektivu iterace, ale zmiňuje i rozdílný přístup pro release, nebo projekt retrospektivu. Většina knihy obsahuje popis aktivit pro jednotlivé fáze retrospektivy.
• Good Math - říkal jsem si, že se trochu dovzdělám (a oživím si) v matematice. No, není to špatný, ale moc mě to nenadchlo. Tři hlavní témata jsou čísla, predikátová logika a Turing Machine + Lambda kalkul.
• The Agile Samurai - vůbec ne špatný úvod do agilních záležitostí, taková směska praktických věcí. Ale opravdu jenom úvod.
• Kanban for Skeptics - není to špatná knížka, když už víte, co je to Kanban a potřebujete někomu vysvětlit, proč to funguje - systematických argumentů je tu dost. Bohužel se tam nedozvíte nic o tom, co to Kanban je.
• Pro JPA 2 - bible Java Persistence API 2.0. Použil jsem ji jako podklad pro JPA certifikaci a můžu ji doporučit i jako referenci. Chybí ale jakákoliv zmínka o integraci se Springem. Krátce se o knize zmiňuju v článku Certifikace Java EE 6 JPA Developer.
• Hibernate Search by Example - pokud potřebujete zároveň použít full-text vyhledávání spolu s ORM, tohle je dobrý zdroj i reference.
• Mastering Redmine - Redmine je open source issue tracking nástroj, napsaný v Ruby on Rails. Pokud Redmine používáte, nebo spravujete, je tahle kniha tak 12x lepší než oficiální dokumentace (která je mizerná).
• The Healthy Programmer - tahle kniha vám neprozradí tajemství věčného života. Za to vám ale řekne, jak si vytvořit udržitelný životní styl, který vám umožní dělat programátora ještě za 10 (a víc) let. Napsal jsem o tom blog post Zdravý programátor.
• Book of Vaadin (Vaadin 7 Edition) - pokud fandíte komponentovým frameworkům v Javě (třeba já jo), je Vaadin dobrou volbou (byť je jeho rozšíření na trhu hodně minoritní). Book of Vaadin je oficiální dokumentací, je zdarma a předčí nejednu komerční knihu k danému tématu (kterých moc není). Jediný, co mi v knize chybí, je integrace Vaadinu na další vrstvy a frameworky (Spring, EJB, CDI).
• Vaadin 7 Cookbook - jednoznačně nejhorší kniha, kterou jsem loni četl. Nekoncepční, zmatená, s tipy diskutabilní kvality (trošku autory podezírám z absence praxe). Opravdu si v knize za $20 potřebuju přečíst, jak "přinutím" tlačítko, aby se chovalo jako odkaz?!? I když mi knihu koupil zaměstnavatel, byl jsem naštvaný za vyhozený peníze :-(
• JBoss AS 7 Configuration, Deployment and Administration - výborná kniha o sedmičkovém JBossu. Must have, pokud to s ním myslíte vážně. Kniha je výborně strukturovaná, dobře se čte, má rozumnou úroveň detailu a dozvíte se z ní o věcech, o kterých se moc nemluví, třeba o JBoss CLI, nebo Infinispanu.
• Log4J - kratičký spisek (74 str.) o Log4J. Mnoha, mnoha vývojářům by prospělo, kdyby si to přečetli (a pochopili ;-)
• Mercurial: The Definitive Guide - bible Mercurialu. Zdarma. Na můj vkus se trochu moc mluví o MQ (Mercurial Queues) a chybí některá pokročilejší témata (třeba trošku víc o branchování), ale jinak perfektní opus.
• Gradle Effective Implementation Guide - první a skvělá kniha o Gradlu. Ideální začátek - ačkoliv má Gradle výbornou dokumentaci, pro pochopení kontextu a jak spolu jednotlivé věci fungují, bych doporučil spíš tuhle knihu.

Vít Kotačka's favorite books »

Leadership

• Start With Why - inspirativní kniha, která trpí repetitivností a zbožňováním Applu. Základní idea je prostá: prvně je potřeba vědět proč něco dělám, z toho vyplyne jak to budu dělat a výsledkem je co budu dělat. Aplikovatelné na všechno, od osobních věcí, po globální společnosti. Inspirativní jsou ti (jednotlivci i společnosti), kdo mají (a začínají u) definovaný proč.
• The Power of Habit - všichni známe sílu zvyku. Málokdo si ale uvědomuje, jak moc nás zvyky ovlivňují (jednotlivce, společnosti i státy či národy). A pokud chceme něco změnit - u sebe, v týmu, ve společnosti, je potřeba se zvyky počítat. Nebo vytvořit nové a nahradit jimi ty staré.
• Tha Last Lecture - emocionálně silná výpověď o tom, že dreams come true. (Teda pokud zrovna nemáte rakovinu.) A většinou je za tím cílevědomost a tvrdá práce. Jak říká autor: "I find the best shortcut is the long way, which is basically two words: work hard."
• Team Geek - nepostradatelná příručka moderního team leadera. Pokud nemáte ponětí, co team leadování obnáší, nebo se to chcete "naučit", tohle je určitě (mnou) doporučená literatura. Psal jsem o téhle knize v článku Team Geek, team leader se srdcem.
• Steve Jobs: Ten Lessons in Leadership - snůška blábolů a nekritické uctívání Steva, taková mikro hagiografie. Za $3 to rozhodně nestojí a o leadershipu se nedozvíte nic.
• Scrappy Project Management - knížka o tom, že projekťák "musí mít koule" (platí obrazně i pro ženy ;-)  Jinak je on i váš tým odsouzen k pomalé, bolestivé (a zasloužené) smrti. Doporučené čtení pro všechny, kdo se jakkoliv motají kolem (softwarových) projektů.

Související články

• Druhý rok s Kindlem
• Rok s Kindlem