Kanban, lehký úvod

Rok se sešel s rokem (skoro), takže je nejvyšší čas, říct si zase něco o Kanbanu :-)  Přiznám se, v těch minulých článcích jsem to trochu flákal, moc se mi nechtělo do popisu, co to vlastně Kanban je. Tak to napravím.

Co je to Kanban?

Když mám definovat Kanban jednou větou, obvykle říkám: Kanban je metoda-nástroj na zefektivnění procesu. Kdybych měl přidat druhou: Kanban lze aplikovat na libovolný proces - je jedno, jestli jde o Scrum, nebo vodopád. A konečně: Ten proces už musí existovat - Kanban neříká nic o tom, jak vyvíjet software.

Abych pravdu řekl, nikdy jsem nepřemýšlel na tím, jestli je Kanban využitelný i mimo oblast softwarového vývoje - jestli ano, tak mě to asi ani moc nezajímá. Jestliže kdekoliv dál v článku mluvím o procesech, mám na mysli procesy, jejichž smyslem je vytvoření, výroba, doručení software.

Abych vás neochudil o plnokrevnou definici, tak Wikipedia říká:

"Kanban is a method for managing knowledge work with an emphasis on just-in-time delivery while not overloading the team members. In this approach, the process, from definition of a task to its delivery to the customer, is displayed for participants to see and developers pull work from a queue."

A abych vás obohatil ještě o trochu víc, tak David J. Anderson (jeden z duchovních otců Kanbanu a autor jeho bible) praví:

"In software development, we are using a virtual kanban system to limit (team's) work-in-progress ... to a set capacity and to balance the demand on the team against the throughput of their delivered work. By doing this we can achieve a sustainable pace of development so that all individuals can achieve a work versus personal life balance."

Co Kanban (určitě) není?

Lidé mají velmi často pomýlené představy, co to Kanban je. Pojdmě si ho proto definovat i negativně:

• Kanban není metodologie. Často se setkávám se snahou srovnávat Kanban a Scrum. To je nesmyslná snaha. Kanban neříká vůbec nic o tom, jak máte dělat software. Neříká nic o tom, jak dělat (a jak často) plánování, nebo releasování. Neříká vůbec nic o tom, kdy máte co(koliv) udělat. Neobsahuje žádné ceremonie (denní meetingy, review, statusy projektu atd.). Chcete-li dělat vývoj software metodicky, najděte si nějakou metodiku, Kanban vám v tom nijak nepomůže.
• Kanban není proces. Pokud děláte software, musíte mít nějaký proces - můžete ho mít definovaný explicitně (třeba pomocí nějaké metodiky), nebo implicitně (což může v lepším případě znamenat intuitivně, nebo v tom horším chaoticky). Každopádně, pokud chcete používat Kanban, musíte už takový proces mít. Kanban se totiž vždy aplikuje na proces, je to taková "poleva".
• Kanban není agilní praktika. Kanban bývá často zmiňován ve společnosti agilního vývoje. Což je daný tím, že on se s agilními metodikami velmi dobře pojí, velmi dobře je doplňuje. Ale Kanban stejně tak dobře můžeme aplikovat na krystalicky čistý vodopád, či libovolný jiný "rigidní" způsob vývoje.
• Kanban není nástroj na project management. Pokud jste projekťák, může vám Kanban pomoci - asi největším přínosem pro vás bude předvídatelnost procesu a dodávek. Ale nijak vám nepomůže projekt řídit. Neřekne vám nic o potřebných zdrojích, o termínech, nijak nezohledňuje rozpočet projektu atd. Platí to samé jako u procesů a metodik - Kanban vám neřekne "jak to máte dělat".
• Kanban není všelék (stříbrná kulka). Kanban může některé vaše problémy vyřešit. Ale jenom některé. Lidé jsou nepoučitelní a tak se pořád najdou tací, kteří čekají na zázrak, který nepřichází. Kanban je dostatečně nový (a neznámý), aby sváděl některé manažery a "decision makery" k nereálným očekáváním. Je to ohraná písnička, ale... ani tentokrát mesiáš nepřijde.

Jaké přináší benefity?

V předešlé sekci jsem popsal, co Kanban není, což může na někoho působit negativně a vzbudit otázky: je to vůbec k něčemu? Nepomůže nám to ani s metodikou, ani s procesem, ani s project managementem. Proč se tím tedy zabývat?

V prezentaci na konci článku těch důvodů najdete víc, já bych z nich vypíchnul tři, které považuji za nejdůležitější:

1. Kanban odstraní z procesu neefektivitu. Tohle je jeho kvintesence. Kanban pojímá práci jako proud, plynutí. Vše, co brání plynulosti procesu se snaži odstranit.
2. Omezením rozpracované práce se zvýší kvalita. Tím, že se vývojáři (a další role) soustředí (ideálně) pouze na jeden úkol, měla by se zvýšit kvalita jejich výstupů.
3. Kanban zavádí změny postupně, inkrementálně. Tohle je zajímavé z "politických" důvodů. Jednak směrem nahoru, k managementu, kdy se drobné změny rozložené v čase prosazují snáze a jednak směrem dolů, k lidem, jež jsou/budou denními účastníky procesu - lidé bývají vůči změnám rezistentní a konzervativní, takže opět - drobné změny se spíše skousnou.

Kořeny Kanbanu

Prapůvod Kanbanu lze hledat v Toyota Production System (TPS). Součástí TPS je i kanban system - systém pro řízení just-in-time produkce, nicméně (softwarový) Kanban se inspiroval i v jiných aspektech TPS, třeba filozofii kaizen (kontinuální zlepšování), nebo konceptu muda (odpad, neproduktivní činnost).

TPS je silně inspirativní systém. S ohledem na softwarový vývoj je jednou z jeho prvních adaptací Lean Software Development (LSD) - agilní metodika, která sice není tak populární, jako Scrum, ale třeba pro oblast enterprise určitě vhodnější. Kanban přejímá z LSD některé jeho nástroje, za všechny bych zmínil třeba teorii front.

Kanban také intenzivně čerpá z teorie omezení - Theory of Constraints (TOC). Jednou z implementací TOC je metodika Drum-Buffer-Rope (DBR), která je přímým předchůdcem Kanbanu.

5 základních principů

Kanban je definován pomocí pěti základních (core) principů, které si postupně rozebereme.

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

Vizualizuj workflow

Celý Kanban se hodně točí kolem vizualizace a vizualizace workflow, patří k tomu nejviditelnějšímu, na co můžeme narazit. Tato technika není ničím specifická, už před vznikem Kanbanu ji využívaly ostatní agilní metodiky.

Fyzický Kanban board

Princip je jednoduchý:

• Vezmeme tabuli (Kanban board) a rozdělíme ji na vertikální sloupce (swim-lines) podle jednotlivých stavů našeho workflow (tyto stavy se často kryjí se stavy v issue tracking systému (ITS)).
• Práci, kterou potřebujeme udělat, rozdělíme na části (nazývané tasky) stejné, či podobné granularity. Tasky jsou prezentovány lístečky/kartičkami.
• Každý, takto identifikovaný task, umístíme na Kanban board do odpovídající swim-liny.

Fyzický Kanban board

Kanban board může mít buď fyzickou, nebo elektronickou podobu. Fyzický board se většinou řeší klasickou bílou tabulí (whiteboard), kam lze lístečky přilepit, připnout magnetem apod. Elektronický board je někdy poskytován ITS (třeba JIRA Agile (dříve GreenHopper plugin)), nebo lze použít samostatný nástroj (zkuste zagooglovat, je jich spousta).

Je lepší použít fyzický, nebo elektronický Kanban board? Záleží na kontextu. Fyzický se dobře vyjímá v openspacu a dobře se před ním dělají stand-up meetingy. Pozitivní psychologický efekt je, že board je vidět neustále a tak každý člen týmu (i náhodný kolemjdoucí manažer) mají okamžitý přehled o stavu projektu. I z osobní zkušenosti (pokud to jde) doporučuji použít fyzický Kanban board.

Elektronický Kanban board (JIRA plugin GreenHopper (nyní JIRA Agile))

Omezením fyzického boardu je jeho, ehm fyzičnost, čili jde použít pouze lokálně. Pokud máte distribuovaný tým, bude elektronický board lepší volba - alespoň jako primární zdroj pravdy. Fyzický board se dá nicméně v této situaci také využít, byť jen jako sekundární nositel informace.

Další výhodou elektronického boardu je jeho provázanost s ITS. Kanban board pak bývá "pouhým" snapshotem, pohledem na tasky. Tzn. že odpadá duplikování informace a synchronizace v ITS a na fyzickém boardu.

Elektronický Kanban board (Redmine)

Limituj rozdělanou práci

Všichni to ví, všichni to tak nějak tuší, ale Kanban to říká nahlas: nedělejte na více věcech najednou. Vemte si jednu věc, dodělejte ji a vezměte si další. Nepřepínejte kontext!

Jak říká David J. Anderson v knize Kanban: "As we all know, there really is no such thing as multi-tasking in the office; what we do is frequent task switching".

Přepínání kontextu nemá žádný pozitivní efekt (snad kromě toho, že udržuje mozek v obrátkách). Kanban se k němu staví negativně a otevřeně říká: nastavte explicitní limit, kolik tasků může být v daném stavu workflow. Tomuto principu se říká omezení Work-in-Progress (WIP).

Pokud používáme fyzický board, napíšeme limit tasků nad každou swim-line. Kromě maximálního počtu tasků lze nastavit i minimální, tj. pod jaké množství by počet tasků ve flow neměl klesnout. Problém s WIP na fyzickém boardu je zřejmý - jeho dodržování je potřeba kontrolovat manuálně.

Nastavení WIP na fyzickém boardu

Výhodou elektronického boardu je, že za vás nastavené WIP hlídá. Buď vám vůbec nedovolí tento limit překročit (prostě task nad limit nejde přesunout do "vyčerpaného" stavu), nebo vás aspoň upozorní, že limit byl překročen.

Ať už hlídáme WIP libovolným způsobem, podstatné je, jak se zachováme při jeho překročení. Můžou nastat tři modelové situace:

• Limit WIP máme dobře nastavený. Jeho vyčerpání nám signalizuje bottleneck ve flow. Ten může být buď dočasný, nebo chronický. V prvním případě by se měl zapojit celý tým, aby dočasný, jednorázový problém ostranil. V druhém případě bychom měli zapřemýšlet o změně procesu, flow apod.
• Limit WIP máme dobře nastavený, ale jeho překročení ignorujeme. V takovém případě je Kanban pouze formální záležitostí a je zbytečné ho dělat. Nebo od něj očekávat nějaké pozitivní výsledky.
• Limit WIP máme nastavený příliš vysoko, nebo nízko. Kanban je adaptivní, takže WIP upravíme na přiměřenější hodnoty.

Nastavení WIP na elektronickém boardu (JIRA plugin GreenHopper)

Kruciální otázkou je, jak správně WIP nastavit. Je to podobné, jako s odhady pracnosti. Pokud můžeme, vezme v potaz podobný proces z minulosti. Pokud nemáme s čím srovnávat, vezmeme "expertní odhad". Nastavit WIP podle pravidla 1 vývojář, 1 task, taky není špatný začátek. Podstatné není, jestli WIP nastavíme správně na začátku. Ale že ho v průběhu projektu přizpůsobujeme podle aktuálního vývoje situace.

Měř a spravuj flow

Jedna z věcí, které Kanban převzal z TPS je filozofie kaizen, kontinuální zlepšování procesu. Abychom věděli, že se proces zlepšuje, je potřeba ho měřit.

Jednou ze stěžejních veličin, kterou Kanban používá (a měří) je lead time - čas, za jak dlouho se task dostane z jednoho stavu do jiného, typicky ze stavu To Do do stavu Done. Ale jeden task nás na projektu nevytrhne - proto Kanban častěji pracuje s kumulovaným lead time, tj. za jak dlouho projde flow průměrný task.

Pokud pracujeme s lead time, bude nás zajímat, kolik z něj bylo stráveno "produktivní" prací. Protože jeho "neproduktivní" část je to, co Kanban nazývá waste (a TPS muda) a tento "odpad", neproduktivní činnost se snaží (postupně) odstranit.

Na druhou stranu, ne vždycky musí být lead time, který obsahuje waste, špatnou věcí. Protože to tak může být záměrně. Pokud například máme definovaný stav To Release, ve kterém nám tasky čakají na... release (protože změny nasazujeme hromadně), může být "neproduktivní" čekání tasku v takovémto stavu v pořádku. Nebo taky nemusí, musíme se zamyslet, jestli třeba změna procesu, která umožní kontinuální nasazování tasků nezlepší jak lead time, tak kvalitu celého produktu.

Cumulative Flow diagram (zdroj Paul Klipp)

Průběh a vývoj flow se v Kanbanu často zobrazuje pomocí Cumulative Flow diagramu, což je jeden z nástrojů teorie front. Diagram umožňuje rychlý přehled, jestli jsou dodržováný limity WIP, jestli se v průběhu času zlepšuje lead time a taky "plynulost" našeho systému - pokud Kanban "pracuje" správně, měly by být jednotlivé pruhy v diagramu hladké a s konstantní výškou.

Udělej procesní politiky explicitní

Podstatou tohoto kroku je přesvědčení, že pokud definujeme na projektu explicitní definice procesních politik a shodneme se na jejich porozumnění; přinese nám to benefit, že budeme schopni racionálně a objektivně diskutovat nad jednotlivými issues a následně zapracovat na jejich zlepšení, nebo mitigování s nimi spojených rizik.

Příklady takových politik může být:

• Definition of Done (DoD),
• Work-in-Progress (WIP),
• adresování issues,
• eskalační mechanizmus,
• zodpovědnost v jednotlivých procesních stavech.

Konkrétním příkladem takové politiky může být např. zero-bug-policy:

"Když je na projektu nalezen bug (oproti specifikaci), má automatickou prioritu Critical a musí být přednostně opraven. Tj. nezačínáme nové tasky, dokud nejsou opraveny kritické chyby."

To, že jsou politiky explicitní nejspíš znamená, že jsou někde sepsány. To ale nestačí - pokud jsou pohřbený někde na SharePointu apod., tak jsou v podstatě bezcenné. Naopak, měly by být jednodušše dostupné. Ideální místo je například wiki, která je součástí Issue Tracking systému.

Používej modely pro rozpoznání příležitostí ke zlepšení

Poslední (a nejvíc zanedbávaný) krok v Kanbanu je opět o vizualizaci - používá modely procesů a workflow, na základě kterých pak můžeme zlepšit celkové fungování projektu/procesu. Důvod onoho zanedbávání (já to dělám taky) je prostý, jedná se o dost teoretickou záležitost. Modely, které se běžně používají jsou:

• Theory of Constraints (studie bottlenecků)
• System of Profound Knowledge (studie odchylek)
• Lean ekonomický model (koncept waste)

David J. Anderson k tomu v knize Kanban říká:

"By modeling the workflow of a software development lifecycle as a value stream and then creating a tracking and visualization system to track state changes of emerging work as it „flowed“ through the system, I could see bottlenecks. The ability to identify a bottleneck is the first step in the underlying model for the Theory of Constraints."

Prezentace

Záměr napsat tenhle článek jsem nepojal jen tak z čista jasna. Chystal jsem se na projekt, kde nyní Kanban používáme. A tak, v rámci sdílení znalostí (i pro získání politické podpory) jsem měl o Kanbanu přednášku u nás v práci:

Zdroje

• Kanban, David J. Anderson
• Lean from the Trenches, Henrik Kniberg
• Kanban (development) heslo na Wikipedii

Související články:

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

Certifikace Java EE 6 JPA Developer

Sbírám certifikace a navlíkám je na nit, jako korálky. Už je jich pěkná šňůra. Tak nějak mě to i baví. A člověk si přitom přečte spoustu zajímavých knížek. Tuhle jsem si zase říkal, co mi tak ještě chybí ve sbírce? Ahá! Oracle Certified Expert, Java EE 6 Java Persistence API Developer, to bude něco pro mne.

Trocha historie

JPA vychází historicky z Entity Bean, které byly původně součástí EJB specifikace. V Java EE 5 byla sice už definovaná první verze JPA, která ale pořád tak nějak zůstávala součástí EJB. V aktuální verzi Java EE 6 už jsou EJB 3.1 a JPA 2.0 dvě samostatné technologie (byť stále úzce kooperující).

Tomuto vývoji odpovídají i certifikace: pro Java EE 5 byla k dispozici pouze certifikace Business Component Developer, která obsahovala jak EJB 3.0, tak JPA 1.0. Pro Java EE 6 už jsou to dvě oddělené větve - Enterprise JavaBeans Developer a Java Persistence API Developer.

A právě tu posledně jmenovanou certifikaci jsem čerstvě absolvoval (jak říkám, sbírám to jak houby :-)  tak bych se rád podělil o své studijní úsilí. Ještě než se k tomu dostanu, předestřu pár informací o certifikaci samotné.

Certifikace v kostce

Jako u všech certifikací téhle úrovně, jedná se o test na počítači v nějakém testovacím středisku. Pokud vás zajímají věci jako cena, trvání, passing score, nebo detailnější rozpis témat, můžete se podívat na stránku zkoušky. Já bych uvedl jen hrubší přehled témat:

• Configure and package JPA Entity classes in enterprise modules
• Create basic JPA Entity classes
• Design a Java application that uses a RDMS
• Ensure data integrity by using Transactions and Locking
• Java Persistence Criteria API
• Java Persistence Query Language
• Optimize database access
• Use JPA relationships
• Use advanced JPA features
• Utilize Entity classes by creating code that uses the EntityManager API

Ne všechny témata jsou zastoupena rovnoměrně - tak nějak subjektivně mi přijde, že velký důraz se kladl na věci jako:

• používání Criteria API
• mapování Map (@Entity a @Embeddable typy jako klíče a jako hodnoty, tj. kdy použít @OneToMany a kdy @ElementCollection)
• transakce a vyhazování výjimek (tohle není až tak JPA, jako spíš EJB a JTA)
• typy a chování zámků (LockModeType) na EntityManageru
• nastavení Cache Mode v persistence.xml, cachování pomocí @Cacheable a čištění cache pomocí Cache.evict()
• použití různých typů EntityManagera (aplikační, transakční, extended)
• přepisování atributů a asociací v @Embeddable pomocí anotací @AttributeOverride a @AssociationOverride
• dostupnost persistence unit v rámci různých typů archivů (JAR, WAR, EAR)

Naopak v minimální míře jsem zaznamenal témata jako základní mapování a Java Persistence Query Language (JPQL).

Co studovat

Kniha Pro JPA 2

Když jdu do certifikace, začínám knihou. Nic lepšího se mi neosvědčilo. V případě JPA 2.0 existuje bezkonkurenční bible Pro JPA 2. Knížka je sice z roku 2009, ale to (výjimečně) vůbec nevadí - pokud vám jde o verzi 2.0, ještě s ní pár let vydržíte. Přece jenom, specifikace tak rychle nestárnou.

(Nicméně pokud netrpělivě vyhlížíte Java EE 7, jejíž součástí bude JPA 2.1, tak už vyšla second edition téhle knihy.)

Podtitul tohohle "špalku" je Masterinig Java Persistence API a titul nelže - provede vás všemi zákoutími JPA a byť z vás neudělá mistra (to bez praxe jaksi nepůjde), poměrně významně pozvedne úroveň vašich znalostí.

Kniha je velmi dobře napsaná, má promyšlený koncept a jednotlivá témata a kapitoly na sebe logicky a plynule navazují. Může po ní sáhnout jak úplný (JPA) začátečník, tak někdo kde přechází z předešlé verze 1.0 a stejně tak, pokud si jen potřebujete oživit některé oblasti. A dá s použít i jako prvotní reference (pokud nepotřebujete jít příliš do hloubky). Tak všestranná kvalitní kniha se jen tak nevidí. A je to ideální zdroj pro přípravu na certifikaci.

Aby byla tahle kniha briliantová, chybí jí jen jeden aspekt - propojení JPA se Springem. Je pochopitelné, že je JPA provázáno s EJB, poněvadž obojí je součástí Java EE. Na druhou stranu, kombinace Spring + Hibernate táhla v uplynulých letech vítězně světem a to tak masivně, že bych čekal, že to nelze opominout. Lze. Takže ve výsledku je kniha jen diamantová :-)

Kniha Java Persistence with Hibernate

Když to jde, tj. je čas a je to vůbec k dispozici, snažím se, pro přípravu na certifikaci, přečíst knihy dvě. V tomto případě byl mojí sekundární volbou opus Java Persistence with Hibernate, na kterém mě lákaly dvě věci - jednak je od Manningu, jehož počiny mě, když ne nadchnou, tak aspoň nezklamou; a jednak je jedním z autorů Gavin King, stvořitel zmiňovaného Hibernate. Plus navíc je tahle kniha žhavě aktuální - ještě stále je ve stavu early access (MEAP) a finální by měla být letos v březnu.

Na tuhle knihu jsem se hodně těšil, ale mám z ní rozporuplný pocit. Předně, je hrozně ukecaná. Ale hrozně. Než se autoři k něčemu podstatnému dostanou, tak to trvá a vysvětlí vám to fakt pořádně.

Pak mi tady chybí, to co se mi tak líbilo na předešlé knize - propracovaný koncept. Přijde mi, že byť autoři směřují k určitému cíli, plují proti větru a křižují perzistentní vody sem a tam. S tím souvisí i další věc: tuhle knihu určitě nepoužijete jako referenci - jakékoliv téma se v ní bude obtížně hledat.

Co je naopak na tomto počinu cenné, je popis vlastností, které má Hibernate nad rámec JPA. Hibernate je totiž jeho implementací:

• Hibernate 3.2 implementoval JPA 1.0
• Hibernate 3.5 implementoval JPA 2.0
• Hibernate 4.3 implementuje JPA 2.1

Protože Hibernate je starší a zralejší technologií, než JPA, tak nijak nepřekvapí, že je i bohatší na různé vlastnosti a je v lecčems napřed. A právě tyhle aspekty (kromě samotného JPA), kniha popisuje. Za všechny bych zmínil třeba možnost definovat anotace platné pro celou persistence unit (třeba @NamedQuery) na tříde package-info.java, což JPA neumí.

Celkovému hodnocení téhle knihy bych se prozatím vyhnul. Ovšem čistě z pohledu certifikace to není moc dobrý zdroj - je příliš rozvláčný, ne vhodně strukturovaný a nejspíš (z hlediska JPA) ani kompletní. Nicméně pro rozšíření kontextu to rozhodně není špatné.

Training tests

Pokud má někdo hodně dobrou paměť, orientovanou na detaily a přesné znění, možná může jít do certifikace jen po načtení literatury. To není můj případ. Většinou si po čase pamatuju cosi ve stylu něco takového tam je, ale přesně si to už nepamatuju.

Takže vždy tak maximálně 14 dní před zkouškou a poslední dobou spíš už jen týden, používám nějakou sadu zkušebních testů, které mi pomohou se "naladit" na ostrý test. Pro JPA jsem dal na doporučení na JavaRanch a si vybral sadu od Enthuware.

Jedná se o sadu čtyř testů, které rozsahem odpovídají certifikaci (tj. 64 otázek, 135 minut). Testy jsou o něco težší, než ten reálný. Po vyhodnocení testu se dají otázky znovu projít, tentokrát s vysvětlením, které je sice dost úsporné, ale pokud jste se předtím neflákali, mělo by to být dostačující. A cena $20 není špatná.

Co mě to přineslo?

Jedním z hlavních přinosů certifikací pro mne vždycky bylo prohloubení znalostí. V případě JPA jsem:

• upgradoval z verze 1.0 na 2.0,
• naučil se pořádně Criteria API,
• přeorientoval se z cachování poskytovaném providerem k tomu definovanému ve specifikaci,
• oživil si věci, které se v nové verzi JPA "až tak neměnily"
• a přečetl dvě dobré knihy.

To vůbec není špatné. Já jsem spokojený :-)

Související články

• Certifikace Java EE 6 Web Services Developer
• Oracle SOA certifikace
• Flex certifikace
• UML certifikace, OCUP Intermediate

Jak se nabírají Javisti na Filipínách

Tak nějak se přihodilo, že poslední tři, čtyři roky dělám permanentně technické pohovory s Java vývojáři. Za tu dobu to byly desítky pohovorů. V nové práci jsem to povýšil na další stupeň, když jsem začal dělat občasné remote interview přes Skype a mohl si tak popovídat třeba s lidmi z Brazílie, nebo Indie.

Minulý měsíc se to posunulo ještě dál. Naše společnost otevírá nové delivery centrum v Manile na Filipínách. Bude to základna naší divize pro asijské projekty. Jedním z primárních kroků je vytvořit core team - technical lead, Java vývojář, C# vývojár, integrátor a validator (tester) - který bude schopný autonomně fungovat a eventuálně se postupně rozrůstat.

Že dělám Java pohovory se o mně (minimálně interně) ví, takže jsem dostal nabídku podílet se na výběru lidí pro nový core team.

Místo činu

Pokud jste, tak jako já, neabsolvovali zeměpis v 80tých letech (do dneška si pamatuju skoro všechny hlavní města světa), možná vám přijde vhod pár informací pro navození prostředí.

Filipíny jsou lidnatá země (98 mil. obyv.), s Českem má bezvízový styk, uředními jazyky jsou Filipínština a Angličtina. Hlavním městem je Manila, která je jedním ze 16 cities, které tvoří metropolitní oblast Metro Manila (12 mil. obyv.). Každá pořádná metropole má svůj business district - v případě Manily je to Makati City, kde se také nachází pobočka naší firmy.

Panorama Makati City (zdroj Wikipedia)

Makati je celkem bezpečný region, kde se nemusíte, jako Evropan, bát chodit po ulicích. Nevím, nakolik je to pravda, ale byl jsem místními opakovaně varován, ať si dávám pozor (nebrat si taxíka na letišti, nenosit telefon v ruce, neustále sledovat svoje věci). Plus určitých věcí si člověk všimne sám: taxikář ihned po vašem nastoupení zamkne dveře, časté kontroly zavazadel v budovách, strážní se samopaly v mrakodrapech. A v den, kdy jsem odlétal, zastřelili na letišti starostu jednoho z filipínských měst. Zkrátka trochu jiný svět, než na který jsem zvyklý.

Pár nezávazných generalizací

Strávil jsem v Makati jeden týden a byl to můj první výlet mimo Evropu, takže by bylo pošetilé z toho vyvozovat nějaké obecné závěry. Spíš to berte jako něco, s čím se můžete setkat, pokud budete v podobné situaci. Takže...

Úroveň kandidátů je o řád nižší než v Praze. Když v Manile někdo řekne, že je senior (a třeba i má odpovídající léta praxe), bude to z našeho pohledu spíš junior. A to co se týče znalostí, zkušeností a bohužel i možností (viz dále). Setkal jsem se třeba s relativně seniorním člověkem, který rutinně psal unit testy, ale bez jediného assertu!?! Prostě to, že produkční kód provolám, je dostatečný test (vážně, on nevěděl, že asserty existují a byl vděčný, že se na pohovoru něco naučil).

Asie je továrna na code monkeys. Slyšeli jste někdy, že by programátoři dělali na směny? Tak na Filipínách je to běžná praxe. Jeden z nejčastějších důvodů pro změnu zaměstnání je, že nechtějí dělat noční směny. Velice často pracují u firem zvučných jmen (Accenture, Oracle, IBM, Logica/CGI), ale pouze jako offshore potrava pro děla. Analýza a QA jsou téměř vždy dělány onshore (z pohledu Filipínců distribuovaně, vzdáleně) a vývojáři dělají jenom mechanickou implementaci tasků, často bez porozumnění principům a souvislostem.

Holky jsou daleko schopnější, než kluci. Sám pro sebe jsem si to nazval "Asian Girl Power". Přiznám se, mám (pracovní ;-) slabost pro holky programátorky. Jsou zodpovědné, pečlivé, cílevědomé, odvádějí velmi dobrou práci (true story). Přesně takhle na mne zapůsobila většina kandidátek na pohovorech. Navíc, oproti českému IT, na Filipínách je běžné, že se holky věnují počítačům - poměr pohlaví na pohovorech byl lehce nakloněn k mužským účastníkům, ale ne nijak výrazně.

School  matters. Když dělám pohovory v Česku, tak zcela ignoruju, jakou má kandidát školu. Kolikrát ani neregistruju, jestli vůbec má univerzitní vzdělání. Prostě české zglajchšaltované školství. Ne tak na Filipínách, kde je situace dost podobná anglosaskému modelu. Pokud jste absolvent University of the Philippines (UP), patříte do extra ligy. Ještě ucházející je Polytechnic University of the Philippines (PUP). A pak už je to jedno. Hodně taky záleží na studovaném programu - pokud místo Computer Engineeringu studujete Electronics Communications Engineering, budete na tom, jako vývojář, dost špatně (co se týká znalostí, teorie a vyhlídek).

Zajímavé také bylo, že všichni kandidáti, bez výjimky, měli bakalářský titul. Žádný magistr, nikdo bez univerzitního vzdělání. Většinou je to tak, že po dodělání bakaláře jdou hned pracovat a školu si pak už nedodělávají.

Všichni Javisti dělají v Eclipse. No comment. (bez ironie ;-)

Místní Silicon Valley je Singapur. Je to tak, pro Jihovýchodní Asii je Singapur houba, která nasává ty schopné a telentované. A pokud je nasaje, už se nechtějí vrátit zpět.

Jídlo je fantastický! Nemusíte být fanoušek asijské kuchyně. Ale ta bohatost a rozmanitost chutí je v Evropě nepředstavitelná. Jeden příklad za všechny - čerstvé mango, oh yeah!! Navíc, filipínská kuchyně je úlně jiná, než thajská, vietnamská, čínská... Pro mne určitě důvod, proč se vracet.

Krab (900 g) v thajské čili omáčce

Jak dělat interview na druhém konci světa?

Cesta na Filipíny trvá letadlem něco mezi 17 a 22 hodinama. Takže si tam nezaletíte jen tak na otočku. Plus je tady časový posun - Filipíny leží v časovém pásmu GMT +8, což znamená dvě věci: jednak budete mít solidní jet lag a jednak se špatně domlouvají remote interview.

Když dělám pohovory v Praze, mám s každým kandidátem phone screen - je to prvotní filtr, jestli vůbec má smysl se s kandidátem vidět osobně. Vzhledem k časovému posunu Filipín jsme tuto možnost zavrhli a vydali se cestou testu. Nemám rád testy. Nesnáším je jako kandidát a nesnáším je jako pohovorující. Nicméně v tomto výjimečném případě jsem je vzal na milost jako přijatelný způsob screeningu.

Na tomto místě bych rád poděkoval svému kolegovi Banterovi, který velkou část testu vytvořil, já jsem do toho jenom tak filozoficko-strategicky kafral. Test je taková směska vytvořená s ohledem na potřebný profil - takže je tam něco z Java language, Java API, Enterprise Javy, SQL, unit testů, UML a Banterův oblíbený FizzBuzz ;-)

Ayala Avenue, Makati

Pokud byste se náhodou chtěli pouštět do podobného testu a chcete, aby měl nějakou vypovídací hodnotu, nezapomeňte si otázky ohodnotit - ne všechny mají stejnou váhu. Taky je dobrý si test na někom nanečisto vyzkoušet, abyste ověřili, že je splnitelný - dal jsem ho kolegovi tady v Praze, seniornímu Javistovi (stihnul to za předpokládanou hodinu, na plný počet bodů).

Výše, v sekci generalizací, jsem psal o nižší úrovni kandidátů. Pro představu, dva nejlepší výsledky z testu byly 17,5 a 16,5 bodu z 24. Průměr byl kolem 10-12 bodů. A výjimečný nebyly ani výsledky se 4 body.

Kandidáti, které jsem viděl na místě, byli profiltrovaný dvěma způsoby - jednak testem a dále už prošli i HR pohovory. Interview byly naplánovány na celý týden, většinou vycházely tak tři na jeden den. Docela záběr.

Agenda pohovorů byla dosti podobná tomu, jak už jsem popisoval v článku Jak dělám Java pohovor. Od té doby jsem to zase o něco vylepšil (o tom někdy příště), ale pro filipínské prostředí jsem to upravil do podoby:

1. Představení pohovorujících.
2. Představení naší firmy.
3. Představení kandidáta.
4. Technické otázky.
5. Java workshop.

První tři body, předpokládám, není potřeba vysvětlovat. Co se ale skrývá pod termíny technické otázky a Java workshop?

Technické otázky

Technické otázky začínám nabídkou: "Můžete mi popsat Váš poslední, nebo poslední úspěšný projekt, z technického pohledu?" Je to pozvolný přechod od CV k technickým záležitostem. Co mě zajímá, je:

• Architektura daného projektu - chci ji namalovat (ideálně na tabuli, nebo aspoň na papír) a popsat. Je zde široké pole pro diskuzi - nad komponentami (technologie), vztahy mezi nimi (protokoly), plusy a mínusy, performance, v jakém kontextu je aplikace vyvíjena atd.
• Jak vypadal tým a jakým způsobem byl řízen. Sem spadají role v týmu, metodologie a procesy, komunikace v rámci týmu a mimo tým, daily work atd.
• Jak vypadalo řízení projektu z technického pohledu? Čili opět metodiky a procesy, ale i správa issues a nástroje na podporu (a automatizaci) projektu, release management atd., atd.

Hlavním cílem "projektové" otázky je zjistit, jak je kandidát zakotven v softwarovém inženýrství. Pokud není a říká o sobě, že je senior, má u mne docela vážný problém.

Pak už následují čistě technické otázky, které se odvíjejí od kandidátova CV a praxe. Zpravidla se ptám na věci, které by měl kandidát dobře znát. A naopak - neptám se ho na věci, s nimiž nemá zkušenost, byť je bude v budoucí práci u nás potřebovat. Nejčastěji se otázky točí kolem nějaké komponety, či technologie z oblasti "enterprise" Javy, takže buď něco z Java EE, nebo ze Springu.

Někdy se zeptám na věci, které jsou sice minoritně důležité, ale zaujmou mě (catch my eye) - třeba SoapUI, nebo Selenium. Třeba o tom něco ví. Nebo si to tam dali jen tak pro zajímavost. Tak, nebo tak, zajímá mne, jak se k tomu v odpovědi postaví.

Ať už je otázka jakákoliv, začínám zvolna. "Jaký je hlavní princip za technologií XY? Jak to funguje?" A pak jdeme postupně hloubš a hloubš. Na určité úrovni se pak kandidátovy (nebo moje :-) znalosti zastaví. Což je moje ryska na stupnici kandidátovy seniority. A další otázka podobným způsobem. Většinou jsou takové technologické otázky 2 až 3 a strávíme tím zhruba půl hodiny.

Java workshop

Ayala Avenue, Makati

Ohledně Java workshopu se nebudu moc rozepisovat a odkážu vás na budoucí článek. Obecně jde o to, že s kandidátem strávím cca půl až hodinu programováním a diskuzí nad kódem v IDE.

Zadáním je UML diagram "určitého abstraktního řešení" (omlouvám se, zatím nebudu konkrétní). Pokud ho kandidát zná, může ho zkusit vysvětlit. Pokud nezná, vysvětlím ho já. Pak otevřu notebook a to co je na diagramu může kandidát vidět jako kostru projektu v IDE.

Kandidát by měl řešení naimplementovat a napsat k němu unit testy. To, jak kandidát píše kód a jak dobře ovládá IDE je podstatné a zajímavé. Ale daleko důležitější je, jak se mnou komunikuje. Zadání je totiž dosti vágní a tak záleží na kandidátovi, na co se zeptá, s jakým přijden nápadem apod. Jak reaguje na otázky, které průběžně pokládám.

Celá seance by měla ideálně připomínat párové programování, nebo code review. Mým cílem je, aby kandidát nebyl ve stresu a v nejlepším případě si to i užil. Ne vždy se to podaří. Ale to je v pořádku, protože to co hledám, není jen technické ohodnocení.

Minimálně stejně důležitý je i cultural fit. Takže pokud někdo nepíše testy, neumí diskutavat nad designem a neumí zdůvodnit své rozhodnutí/implentaci, vidím to jako závažný problém. Stejně tak, pokud někdo dělá pět let v nějaké IDE a neumí ho adekvátně ovládat (fakt se najdou senioři, kteří neznají Ctrl+Space).

(Více o Java workshopu napíšu ve slibovaném článku, kde bych se chtěl podívat na to, proč si myslím, že je to dobrý způsob, jak si otestovat kandidáta.)

Po interview

Tak a máme po interview. Možná měl kandidát ještě nějaké otázky, pár zdvořilostí na závěr a hotovo! Ne tak docela. Je potřeba si kandidáta ohodnotit, možná udělat předběžné rozhodnutí. Pokud je víc intreview v řadě, je dobré si kandidátovo hodnocení nějak "znormalizovat" a zadasadit do relativního kontextu k ostatním - pokud nabírám (i průběžně) více lidí na stejnou pozici, stačí mi, že kandidát překročí určitou laťku. Pokud ale obsazuji jednu pozici z více kandidátů, je dobré mít možnost nějak si je porovnat.

Já jsem si na Filipínách udělal jednoduchou tabulku:

To je, čistě za mne, hodnocení technického pohovoru. Což je, samozřejmě, pouze část přijímacího a rozhodovacího procesu. Je to podklad, který společně s mými poznámkami na CV používám pro diskuzi a argumenaci s ostatním členy pohovorujícího týmu.

A jak to dopadlo?

Možná čekáte, že vám teď řeknu, kolik kanditátů jsme přijali, jaký je jejich profil atd. Neřeknu. Jednak, tenhle článek není o tom, jak se staví core team, ale jak vypadá interview v mém pojetí. A pak, najmout lidi do týmu není otázka jednoho týdne pohovorů - je tam spousta dalších aspektů a i časově je to daleko náročnější.

Nicméně, pokud by vás takové téma zajímalo, můžu vás navndadit na jeden z budoucích článků, který bude o tom, jak se (v Česku) staví tým vývojářů. Zůstaňte na příjmu!

Jeepney, tradiční veřejná doprava na Filipínách

Související články

• Jak dělám Java pohovor
• Jak dělají Java pohovor jinde
• Měl by mít vývojář portfolio?
• Kontrakt místo pohovoru, je to reálné?

Gradle tutorial: tasky (pokračování)

V minulém díle Gradle tutorialu jsme si vystřihli rafinované Hello world a řekli jsme si něco o základním stavebním prvku každého build skriptu - Task, to je to, oč tu běží. A ruku na srdce, milý čtenáři, jistě jsi zvědavý, kam nás naše povídání zavede. Protože to zajímavé teprve přijde.

Závislosti mezi tasky

Tasky téměř nikdy nestojí samostatně. To není nic moc překvapivého. Známe to z Antu, známe to z Mavenu, bylo by divný, kdyby to Gradle dělal jinak. Když si například vezmeme klasický Maven build lifecycle, tak vypadá nějak takhle:

1. zpracuj resources,
2. zkompiluj třídy,
3. zpracuj test-resources,
4. zkompiluj třídy testů,
5. spusť testy,
6. vytvoř archiv,
7. atd.

Tyto jednotlivé úkony (v Mavenu nazývané goals) na sebe logicky navazují a jsou na sobě implicitně závislé. Implicitně znamená, že nemusím závislost jednotlivých tasků (goals) explicitně uvádět - Maven "už to nějak ví", jak si ty tasky má seřadit. Magie? Ne, "někdo" mu to řekl.

Podobné je to i v Gradlu. Některé tasky už mají závislosti definované, většinou je to v rámci nějakého pluginu. Třeba u Java pluginu (o kterém si budeme povídat v příště) vytváří závislosti cyklus, který je velmi podobný tomu Mavenímu. Velkou výhodou Gradlu je, že závislosti mezi tasky se definují velmi jednoduše a navíc nad nimi máme programovou kontrolu.

Závislost tasku se dá definovat buď pomocí property nebo metody dependsOn. Způsob zápisu se může podobat tomu, který známe z Antu, čili přímo při definici tasku:

task first << { task ->
    println "  Working on the ${task.name} task"
}

task second(dependsOn: first) << { task ->
    println "  Working on the ${task.name} task"
}

Anebo můžeme využít nespoutanosti Groovy a závislost definovat v podstatě na libovolném místě:

task third << { task ->
    println "  Working on the ${task.name} task"
}

third.dependsOn second 

Vzhledem k tomu, že zde máme závislost tasků third -> second -> first, výstup by při spuštění tasku third měl vypadat následovně:

Závislost tasků

Zajímovou možností je definovat závislosti tasku dynamicky. Vstupem do metody dependsOn totiž může být closure, jedinou podmínkou je, aby vracela objekt typu Task, nebo kolekci Tasků.

task fourth << { task ->
    println "  Working on the ${task.name} task"
}

fourth.dependsOn {
    tasks.findAll { task -> task.group.equals('sequence') }
}

V uvedeném výpisu je task fourth závislý na všech tascích projektu, které jsou seskupeny pomocí vlastnosti group.

Zdrojový kód na Bitbucketu: 02_TaskDependencies/build.gradle

Přeskočení tasku

Ať už jste agilní vývojáři, kteří milují dynamické prostředí, nebo jste naopak vyznavači petrifikovaného zadání, jedno je jisté - chtěná, či nechtěná, stejně přijde nějaká změna. A tak, jakkoliv je náš pracovní lifecycle vymazlený, bude do něj potřeba zasáhnout. Někdy třeba jen dočasně.

Dynamická práce s tasky může být dost komplexní a vydala by na samostatný článek. My se v rámci tutorialu podíváme na část, která je k dispozici out-of-the-box a sice na způsoby, jak zajistit "nevykonání" naplánovoného tasku.

(Při psaní příkladů pro tuto část jsem měl rozvernou náladu, takže v této sekci bude naším průvodcem jeden z hrdinů mého dětství, klokan Skippy :-)

První ze způsobů, jak přeskočit task, je využití metody onlyIf, pro kterou můžeme definovat predikát. Akce v tasku (a tím pádem i task samotný) jsou vykonány pouze tehdy, pokud je predikát vyhodnocen jako true.

task skippy << {
    println 'I\'m happy, so I jump!'
}

skippy.onlyIf { project.isHappy == 'true' }

V tomto příkladu je task skippy vykonán pouze tehdy, pokud je projektová property isHappy nastavena na true. Pokud takovou property v build skriptu nemáme definovanou, nevadí - přidáme si ji z příkazové řádky pomocí přepínače -P, např. -PisHappy=true.

Přeskočení tasku pomocí metody onlyIf

Další možnost, jak nevykonat task, nebo jeho část, je vyhodit výjimku StopExecutionException. To způsobí, že je zastaveno vykonávání aktuálního tasku a je spuštěno vykonání toho následujícího. Tato výjimka přeruší pouze daný task, build pokračuje dál.

task exceptionalSkippy << {
    if (project.isHappy == 'false') {
        throw new StopExecutionException()
    }

    println 'I\'m happy, so I jump!'
}

Jak je vidět na následujícím výstupu, task exceptionalSkippy nebyl přeškočen (jako v předešlém příkladu), ale byl normálně spuštěn a pak byl někde "uvnitř" přerušen.

Přerušení tasku pomocí StopExecutionException

Třetí možností, jak rozhodnout o vykonání tasku je použití property enabled - task tak můžeme vypnout, nebo zapnout.

V následujícím příkladu máme dva tasky. Task disabledSkippy (který nám řekne, jestli Skippy bude skákat) závisí na tasku skippyMood (který nám oznámí Skippyho náladu). Task skippyMood má možnost vypnout task disabledSkippy.

task skippyMood << {
    if (project.isHappy == 'false') {
        disabledSkippy.enabled = false

        println 'I\'m not happy :-('
    } else {
        println 'I\'m happy :-)'
    }
}

task disabledSkippy << {
    println 'I\'m happy, so I jump!'
}

disabledSkippy.dependsOn skippyMood

Přeskočení tasku pomocí property enabled

Zdrojový kód na Bitbucketu: 03_SkipTask/build.gradle

Task rules, dynamické generování tasků

Už jsem párkrát naznačoval cosi o dynamičnosti Gradle, pojďmě se tedy podívat na něco konkrétního. Co kdybychom potřebovali větší množství tasků, které dělají v podstatě to samé, akorát se to "to" liší nějakými parametry. Můžeme takovou potřebu řešit pomocí principů objektového programování, třeba. kompozicí. To může být docela otrava, hlavně správa a přetestovávání takových tasků.

Co si takhle potřebné tasky nechat dynamicky vygenerovat? Právě od toho jsou tady task rules.

def environments = [
    'DEV': ['url': 'http://dev:8080'],
    'SIT': ['url': 'http://sit:9090'],
    'UAT': ['url': 'http://uat:7001']]

tasks.addRule('Pattern: deploy<ENV>') { taskName ->
    if (taskName.startsWith('deploy')) {
        task(taskName) << {
            def env = taskName - 'deploy'

            if (environments.containsKey(env)) {
                def url = environments[env].url

                println "Deploying to ${env} environment, url: ${url}"
            } else {
                println "Unsupported environment: ${env}"
            }
        }
    }
}

Příklad spuštění jednotlivých task rules

Vzhledem ke své povaze jsou task rules uvedeny v samostatné sekci při výpisu tasků pomocí příkazu gradle tasks:

Výpis pravidel (rules) příkazem gradle tasks

Zdrojový kód na Bitbucketu: 04_TaskRules/build.gradle

Asi v tom bude nějakej háček

Jedním z nejčastějších problémů u tasků, se kterým se můžeme zpočátku setkávat, je záměna konfigurace a definice tasku. Definici tasku už známe - používali jsme ji celou dobu. V rámci definice přidáváme do tasku jednotlivé akce, které jsou pak vykonány během exekutivní fáze. Jen pro připomenutí, akce můžeme do tasku přidat metodami doFirst a doLast a daleko nejčastěji se používá operátor << který je aliasem pro metodu doLast.

Konfigurace tasku slouží... ehm, ke konfiguraci tasku. Podstatné je, že konfigurace je vykonána v jiné fázi buildu. A proběhne pokaždé, i když zrovna daný task nespouštíme. Task lze nakonfigurovat několika způsoby, ten "problematický" má stejnou syntaxi jako definice tasku, pouze je bez << operátoru.

task foo {
    // some task configuration here
}

V následujícím výpisu task pitfall prvně "nakonfigurujeme" a následně do něj přidáme akci.

task pitfall { task ->
    println "Printed from task ${task.name} configuration."
}

pitfall << { task ->
    println "Printed from task ${task.name} execution."
}

Když se podíváme na spuštění tasku pitfall, všimněte si, kdy proběhl "konfigurační" výpis. Ještě před začátkem spuštění tasku (tedy před vykonáním obsažených akcí).

"Vizualizace" konfigurační a exekuční fáze tasku

Druhým častým problémem s tasky bývá následující chyba:

Cannot add task ':exists' as a task with that name already exists.

Což znamená, že se snažíme definovat task, který už je definován někde jinde. Problém bude buď v chybné syntaxi, anebo v praxi daleko častěji, pokud pracujeme s projektem, kde používáme plugin, který task stejného jména již obsahuje. Obdobou téhož je, když si do projektu natáhneme antovské tasky (jeden z budoucích dílů tutorialu) a opět, dané jméno tasku už je použito.

Pokud řešíme druhý případ (duplicitní název/definice tasku), můžeme task explicitně předefinovat. Nemusím zdůrazňovat, že bychom měli vědět co a proč to děláme. Pokud máme buildovací skripty plně v rukou, bude tento problém indikovat chybu v designu buildu. Ovšem v případě, že se potýkáme s nějakým legacy buildem (staré Ant build soubory), může být redefinice tasku nutností.

Task lze předefinovat pomocí property overwrite:

task exists << {
    println 'primary task definition'
}

task exists(overwrite: true) << {
    println 'overwritten task definition'
}

Redefinice tasku pomocí property overwrite

Zdrojový kód na Bitbucketu: 05_TaskPitfalls/build.gradle

Zdrojové kódy

Zdrojové kódy k dnešnímu dílu jsou k dispozici na Bitbucketu. Můžete si je tam buď probrouzdat, stáhnout jako ZIP archiv, anebo - pokud jste cool hakeři jako já :-) - naklonovat Mercurialem:

hg clone ssh://hg@bitbucket.org/sw-samuraj/gradle-tutorial

Co nás čeká příště

O tascích by se dalo povídat ještě dlouho. Ale protože jsem příznivcem hesla better is enemy of done, tasky dnešním dílem opouštíme a příště se podíváme, jak Gradle řeší Java vývoj.

Tento článek byl původně publikován na serveru Zdroják.

Související články

• Gradle, moderní nástroj na automatizaci
• Gradle tutorial: tasky

Související externí články

• Build Script Basics (Gradle User Guide)
• More about Tasks (Gradle User Guide)
• Task (Gradle DSL Reference)

Zdravý programátor

Pokud čtete alespoň polovinu odborných knih, toho co já, asi vám nebude neznámé nakladatelství The Pragmatic Programmer. Pravda, schopnost (spíš posedlost) přečíst kvanta knih jsem získal v minulém století, tak možná už to není tak in.

Takže, i pokud knížky nečtete, ale jste vývojář, který se nebojí v hospodě třísknout do stolu a zvolat na celý lokál: já jsem programátor, kdo je víc?, měla by vám něco říkat jména Andy Hunt a Dave Thomas. Pořád nic? Dobře, dávám vám poslední šanci: The Pragmatic Programmer. Bible softwarového inženýrství. Ano, napsali ji ti dva pánové. A ano, oni založili i to vydavatelství.

Proč se o tom tak vykecávám? Protože tohle parádní vydavatelství si zaslouží trochu promotion. Četl jsem od nich už šest knih a všechny byly skvělé, pokaždé 5 hvězdiček. Takové kvalitě se, s výjimkou Manningu, žádné další nakladatelství ani nepřibližuje. Takže, pokud váháte, jestli od nich něco koupit, anebo jste je doposud vůbec neznali - vřele doporučuju.

Memento mori

Pryč jsou doby, kdy stačilo, aby byl programátor pragmatický. Dnes musí být ještě navíc zdravý. Že by diktát New Age? Ne, jenom realita.

Programátoři (podobně jako rockeři či jazzmeni) vedou ve velké většině dosti nezdravý způsob života. Dokud je člověk mladý, tak to nějak jde. Ale jak začne oťukávat třicítku, tak mu tak nějak dojde, že není nesmrtelný a začnou se ozývat různé bolístky. A tady by měl každý zůstat ostražitý...

Jinak můžete dopadnout, jako já před pár lety - svoji programátorskou vášeň (10-12 hodin u počítače, včetně víkendů) jsem krutě zaplatil - vyhřeznutou plotýnkou. Plotýnka nabořená v míše je kritická věc (můžete třeba ochrnout) a zcela spolehlivě vás odradí od práce s počítačem - nejen, že nemůžete sedět, nemůžete ani ležet, ani stát. Všechno hrozně bolí.

No, vzhledem k tomu, že teď čtete tenhle článek, tak to asi dobře dopadlo. Vysekal jsem se z toho - s pomocí dobré víly a hlavně vlastním úsilím, jsem slezl chirugovi z lopaty a dnes žiju běžný život jako "předtím". Opět vášnivě programuji (i když rozumně - snažím se dodržovat XP Eight-Hour Burn), své děti vyhodím bez problémů metr nad hlavu, běhám, plavu atd. Všechny tyto věci mi doktoři zakazovali. (A pak jim věřte. ;-)

The Healthy Programmer

Kniha The Healthy Programmer od Joea Kutnera sice nenabízí tak srdceryvný příběh, jaký jste právě dočetli :-)  Nabízí ale něco jiného - jak se takovým problémům vyhnout. Knihu dobře vystihuje její podtitul: Get Fit, Feel Better, and Keep Coding. Nejdůležitější je to poslední - Keep Coding - protože jestli chcete programovat (nebo dělat cokoliv jiného na počítači) ještě za 10 let, budete s tím muset něco udělat. Čas, biologie a mechanika jsou neúprosné a pracují proti vám.

Zdroj The Healthy Programmer

Jádro knihy vám neprozradí nic nového, prostě: jezte zdravě, cvičte, dávejte si pozor (a pečujte) na oči, záda a zápěstí, buďte aktivní atd. Co je ale na knize unikátní, je způsob, jak jsou tyto věci vysvětlovány a jak byste k nim měli přistupovat.

Kniha totiž radí přistupovat ke svému zdraví agilně. Pro daný aspekt si udělat test a pak iterativně refaktorovat danou kvalitu, až test projde. Dostane se i na Pomodoro a kaizen. Všechny změny jsou malé a postupné. Smyslem není jen vyřešit váš aktuální problém (nadváha, bolesti zad či hlavy, únava apod.) a upozornit na (závažná) rizika, která se s vývojářským životním stylem pojí, ale hlavně najít systém, který pro vás bude udržitelný po zbytek vašeho (programátorského) života. A taky vás bude bavit.

Všechny věci, které autor doporučuje jsou podepřeny vědeckými studiemi. Pokud někde korelace není prokazatelná, tak na to upozorní. Kniha obsahuje obrovskou sumu referencí, na vědecké články a další literaturu. Abych pravdu řekl, tolik odkazů jsem v publikaci ještě neviděl.

Zakončil bych prvním citátem, který jsem si podtrhnul. Myslím, že knihu velmi přesně charakterizuje.

"Agile processes are characterized by an iterative and incremental approach to development, which allows us to adapt to changing requirements. The method you use to stay healthy shouldn't be any different."

Kontrakt místo pohovoru, je to reálné?

Největším pracovním tématem posledního čtvrt roku je pro mne vytváření týmu. Potřebuji sestavit skupinu 10 vývojářů. Zatím je přijata cca třetina lidí a ta težší část mě teprve čeká - vytvořit týmovou kulturu a tým zapracovat a rozpohybovat.

Posleního čtvrt roku žiju pohovory. Dělám technická interview, dosti podobná tomu, co jsem před časem popsal v článku Jak dělám Java pohovor. Je to pro mne živé a přitažlivé téma - kromě toho, že je to (téměř) každodení zkušenost, tak sleduju různé články na internetu. Většinou v angličtině. K dnešnímu postu mě ale inspiroval článek, který je... ve slovenštině.

Riki Fridrich navrhuje v článku Kontrak namiesto pohovoru alternativu ke klasickému výběrovému řízení - místo pohovoru si kandidát střihne maličký projekt. Riki nepřichází s ničím novým - před rokem o tom psali Jeff Atwood, Jon Evans, letos Nelly Yusupova a Tommy Morgan. Takže to je myšlenka, která rezonuje. Minimálně na internetu.

V čem je problém?

Všemi výše uvednémi články prosvítají dvě základní myšlenky:

1. Pracovní pohovory jsou neefektivní.
2. Nejlepším způsobem, jak si (z několika úhlů) otestovat nového vývojáře, je zadat mu malý, ale reálný projekt.

Riki jde u druhého bodu ještě dál, když říká, že "to je budoucnost najímání seniorních ajťáků".

Jsou pracovní pohovory neefektivní?

Pracovní pohovory jsou tak neefektivní, jak neefektivní si je každý udělá. A to platí pro obě strany. Říct, že pracovní pohovor je neefektivní, je stejné, jako říct, že neefektivní je třeba Scrum. Nebo psaní unit testů. Nebo kontinuální integrace. Mám pokračovat?

Všechny právě zmíněné "činnosti" jsou nástroje, které nám pomáhají v naší práci. Je přece na nás, jestli je budeme používat efektivně (a správně). A je velmi důležité si uvědomit, že všechny tyto nástroje fungují v určitém kontextu (moje oblíbené slovo :-)

Myslíte si, že např. softwarový projekt bude úspěšný jen proto, že "nasadím" nějaký z těchto nástrojů? Já nevím jak vy, ale já už jsem viděl dost špatných implementací Scrumu (mmch. je zajímavý, že zainteresovaní vývojáři to většinou vidí, jako úspěch, i když projekt šel do kytek).

Podobné je to i s pracovním pohovorem. Není to žádná stříbrná kulka. Pohovor, to je jen taková "kvalifikace do závodu". Co v člověku opravdu je, se ukáže teprve během zkušební doby. Jak říká Rands, až teprve po 90 dnech budou obě strany vědět, na čem jsou. Neexistuje žádná zkratka.

Takže, ať už děláte takový skvělý pohovor jako já ;-) nebo jedete v obvyklé korporátní nudě, pořád je to jen jeden stupínek na dlouhé cestě. Pohovor bude tak efektivní, jak efektivní si ho uděláte - ať už jste kandidát, nebo zaměstnavatel.

Projekt místo pohovoru?

Je to hezká myšlenka. Místo příkladu do šuflíku - opravdový projekt. Místo programování na tabuli/papír - programování v oblíbeném IDE. Místo akademických algoritmů - reálný problém. Místo stresující nudy - práce, která baví. OK, myšlenka je to inspirativní. Co ale musíme udělat, aby byla proveditelná?

Nastavení prostředí. Aby kandidát mohl začít na něčem vyšívat, musí si nachystat nástroje. Jak dlouho mu to může trvat? Třeba je firma tak vyspělá, že nejenom že má build (nebo dokonce release) na jeden klik. Dokonce má na jeden klik i nastavení prostředí. Takový ty věci, jako vývojový (aplikační/webový) server, potřebné pluginy do IDE (ve správných verzích), všechny závislosti pro build, deploy a běh aplikace atd.

Řekněme, že tohle všechno je na jeden klik a když to bude hodně komplexní, tak to bude trvat maximálně 30 minut (berme, že konektivita pro stahování artefaktů je v dostatečné kapacitě). Build je taky na jeden klik a opět, když to bude hodně komplexní, tak dejme tomu 10 minut. Takže včetně uvaření kafe, za hodinu je kandidát připraven vyvíjet.

Mno. Zrovna jsem tenhle týden dostal od kandidáta na pohovoru otázku, jak dlouho u nás trvá příprava prostředí pro vývoj. A upřímně jsem odpověděl, že když jsem si rozcházel projekt, na kterém teď vypomáhám s nějakými change requesty, trvalo mi to tři dny. Ten projekt je specifický a má to svoje objektivní důvody. Ale je to realita, která se čas od času přihodí.

Obecně, moje zkušenost (v oblasti enterprise Javy) je, že rozchození projektu trvá řádově man days. Nevím, možná je to extrémní situace. Když jsem před 10 lety programoval v PHP, tak jsem si: 1) zkopíroval z disku zdrojáky, 2) hodil je na Apache (mod_php) a 3) a začal bastlit ve Vimu, tak to mohlo trvat tak 20 minut. (Teď trochu kecám - tehdy jsem bušil ve Slackwaru a celý LAMP jsem si kompiloval ze zdrojáků. Takže i s přípravou serveru to trvalo o dost dýl. Ale dejme tomu, že to zanedbáme.)

Máte zkušenosti z jiných domén? Jak dlouho trvá nastavit prostředí v Ruby? V Pythonu? V Erlangu? V Androidu? Myslím reálné business projekty.

Sdílení artefaktů. Kandidát bude potřebovat s firmou sdílet nějaké artefakty. V první řadě, bude potřebovat někde získat zdrojový kód. A zpátky komitovat svoje změny. Co nějaká dokumentace, Wiki? Nějaké konfigurační artefakty, které nejsou přímo součástí aplikace?

Pokud jste na GitHubu (nebo jiné, obdobné hostingové službě), máte vyhráno. Nejste na GitHubu? A safra! Kdo bude s vaším kandidátem řešit problémy s konektivitou, nastavením práv apod.? Nejde o to, že by to bylo složité (zatím to vždycky fungovalo ;-) a kandidát by si s tím neuměl poradit. Problém je, že to "žere" čas, který má kandidát na projekt.

Sdílení informací. Kolik artefaktů, vyjma aplikace samotné, vám na projektu vzniká? Jste agilní a máte jich minimum? Znalosti a kontext se sdílí v týmu hlavně orálně (stand-upy, statusy atd.)? Nebo máte naopak hodně formálních artefaktů? Věci jako specifikaci, analytický model, guide lines atd.

A teď. Kolik času kandidátovy zabere, aby vstřebal alespoň nutné minimum, které mu umožní na projektu začít?

Znalost technologií. Třeba firma dělá v něčem křišťálově čistém - víš, nevíš. Abych pravdu řekl, nic takového mě nenapadá. Děláte v JavaScriptu? Kolik frameworků znáte opravdu dobře? Děláte v PHP? Totéž. Pokud bych vzal v potaz doménu Java frontend frameworků, tak pravděpodobnost, že kandidát zná, či má zkušenosti právě s tím vaším, je tak 10 %. OK, pokud dělal s (nějakým klonem) JSF, tak se to může blížit i 50 %.

Moje frontendová zkušenost za cca 8 let v Javě? Co projekt, to jiný framework. Pokaždé se to učíte znova a znova. Když to vezmu chronologicky: Servlety, HTMLB (zná to někdo?), Wicket, RichFaces, Vaadin.

U backendových technologií to není tak divoký, ale stejně. Celkem běžně potkávám na pohovorech lidi, kteří třeba 5 let dělali v JDBC a ani nezavadili o JPA, nebo něco podobného.

Takže jaká je pravděpodobnost, že kandidát bude technologicky sedět na potřeby firemního produktu? Pokud to nebude 80-90 %, co s tím? Jak dlouho se bude nové technologie učit? Nebo si oživovat ty staré (třeba přes dvě, tři nekompatibilní verze)? Jaký to bude mít vztah k našemu projektu?

Je to reálné?

V předešlé sekci jsem načrtnul některé z problémů (jistě ne jediných), které by bylo potřeba vyřešit, aby byl "přijímací" projekt proveditelný. Všechno jsou to technické záležitosti, v podstatě jenom prerekvizity. Už jenom u těchto předpokladů mám vážné obavy, že by se jejich splnění mohlo vejít do pár hodin, maximálně jednoho dne. Ale dejme tomu, že by to šlo.

Další sadou výzev bude nastavení firmy a její kultura. Kandidát by ideálně měl dostat za svůj projekt zaplaceno. Kde se ty peníze ve firmě vezmou? Některé společnosti fungují striktně nákladově - vezmou se ty peníze z budgetu projektu? Nebo z nějaké režijní činnosti? Kdo za to bude odpovědný? Jakým způsobem se budou ty náklady vyúčtovávat? V maličkým startupu nad tím můžeme mávnout rukou. Ve větší firmě to bude show-stopper.

Také nemůžu nezmínit věc, která mi přijde velmi kritická - součinost firmy s kandidátem. Zdá se mi to, nebo se furt nikdo nepoučil, že přidáním lidí na projekt se vývoj zpomalí (Brook's law)? Pokud přijímáme jednoho kandidáta, (časové) náklady na součinost se v běžné práci ztratí. Pokud ale potřebujeme najmout tým lidí - a neříkám, že najednou - znamená to zasekat se v podpoře kandidátů na půl roku dopředu. Na full time. To si nedovedu představit. A to mám se zaškolováním lidí na projektech, řekl bych, celkem bohaté zkušenosti.

A pak nám zbývá poslední, esenciální ingredience. Kandidát. Chápu, že když chce někdo dělat pro firmu svých snů, udělá pro to opravdu hodně. Doplňte si dle svých preferencí Google, Twitter, ThoughtWorks, GitHub, Stack Overflow, Apache, Canonical... já nevím, co ještě. Takže když vám taková firma zadá vstupní projekt, rádi ho uděláte a ještě to budete považovat za čest.

Jenže, kolik takových firem je? Jedno promile? Co ty ostatní, kde pracuje 90 % těch vývojářů, co nejsou špičkový? Ruku na srdce, kolik z vás by šlo do týdenního projektu (byť placeného) s nejistým výsledkem?

Aby kandidáti do něčeho takového šli, museli by změnit svůj mindset. Nedávno jsem v článku Měl by mít vývojář portfolio? psal o tom, že na pohovorech chci vidět kandidátův kód. Nemám srovnání, ale odhaduju, že jsem v tomhle spíš výjimka. Je to vidět i na přístupu kandidátů - někteří jsou tím dost zaskočeni. Někteří dají do placu kód, který není zrovna oslnivý. A zlomek jich tento požadavek prostě ignoruje.

Takže můj pocit je, že pro majoritu vývojářů by psaní vstupního projektu bylo příliš velkým myšlenkovým veletočem.

Závěr

Myslím, že myšlenka dát vývojáři místo pohovoru projekt, je zajímavá. Ale realizovatelná tak v jednom procentu případů. Velmi specifických případů. Asi půjde o nějaký startup, kde to nebude problém procesně a technicky. V případě kandidáta půjde asi o excelentního bušiče kódu, který zrovna šťastně odpovídá technologickému nastavení firmy. A práce bude pro kandidáta tak zajímavá, že mu to za ten projekt bude stát. To je dost výjimečná konstelace.

Související články

• Jak dělám Java pohovor
• Měl by mít vývojář portfolio?
• Jak dělají Java pohovor jinde

Související externí články

• How to Hire a Programmer
• No Shortcuts, No Mercy: The Bloodsport of Recruitment
• 5 Tips for Hiring a Great Web Developer
• How We Hire Developer at Treehouse
• Hiring Developers: You're Doing It Wrong
• On Hiring Good Engineers