22. března 2014

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.


Kanban for Skeptics
Pro JPA 2: Mastering the Java™ Persistence API
Hibernate Search by Example
Mastering Redmine
The Healthy Programmer
Book of Vaadin: Vaadin 7 Edition
Vaadin 7 Cookbook
JBoss AS 7 Configuration, Deployment and Administration
Log4j
Mercurial: The Definitive Guide
Gradle Effective Implementation Guide


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


Start with Why: How Great Leaders Inspire Everyone to Take Action
The Power of Habit: Why We Do What We Do in Life and Business
The Last Lecture
Team Geek: A Software Developer's Guide to Working Well with Others
Steve Jobs: Ten Lessons in Leadership
Scrappy Project Management: The 12 Predictable and Avoidable Pitfalls Every Project Faces


Související články

4. března 2014

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:

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


Související články: