Potvrzujte

Problém

Členové týmu nepotvrzují. Odesílatel odešle informaci a neví, zda byla protistranou přijata, nebo zda protistrana informaci rozumí.

Řešení

Potvrzování znamená, že odesílatel odešle příjemci informaci a příjemce potvrdí, že informaci přijal správně a rozumí ji. Je to oboustranné ujištění o předání informace.
Toto pravidlo znamená, že na každou osobní či elektronickou formu komunikace v týmu příjemce odpoví ve smyslu „rozumím“, „ok“, „jasné“, apod. V případě e-mailu toto potvrzení zároveň slouží i jako ujištění, že se e-mail neztratil po cestě a byl příjemcem přečten a sdělení je rozumět. V případě možného sporu potvrzování funguje i jako jistý důkazní materiál.
Je zajímavé, že potvrzování je přirozenou součástí uživatelského rozhraní strojů a software. Po spuštění příkazu očekáváme potvrzení, že byl příkaz přijat a stroj jej zpracoval. V osobní komunikaci mezi lidmi je potvrzování běžné v rozhovoru. Ale v elektronické komunikaci často (dle osobního pozorování autora) nepotvrzujeme.
Potvrzování samozřejmě v Kyberii používáme i jako odpověď na přijetí minimalistických hlášení, kdy každý příjemce hlášení odpoví e-mailem „ok“. Každý ví, co se aktuálně děje a ostatní ví, že to ví.

Omezení pravidla

Pravidlo Potvrzování nemá žádné omezení. Lze ho aplikovat kdekoli, kdykoli a obecně v každé profesi, kde dochází ke komunikaci 2 a více lidí.

Odkazy na Agilní Manifest

„Nejúčinnějším a nejefektnějším způsobem sdělování informací vývojovému týmu z vnějšku i uvnitř něj je osobní konverzace.“

„Tým se pravidelně zamýšlí nad tím, jak se stát efektivnějším, a následně koriguje a přizpůsobuje své chování a zvyklosti.“

Principy reengineeringu vs Agilní vývoj

Agilní vývoj software je přirozeným reengineeringem rigidních metodik vývoje, které se zaměřovaly na mechanický postup bez ohledu na lidský (měkký) faktor.

Když si přečtete principy reengineeringu z roku 1994, tak je to beze zbytku aplikovatelné na vývoj software. Takhle se hledá inspirace, stačí spojit a hledat související znalosti, vše důležité je už vymyšleno :) .

„(Coulson-Thomas, C. 1994) shrnuje ty nejdůležitější principy reengineeringu podnikových procesů, jak se ujasnily během zlaté éry reengineeringu v první polovině devadesátých let:

  • Vnější zaměření na cílové zákazníky a zvýšení jim poskytované hodnoty – zákazníci a koncoví uživatelé musí mít jeden snadno přístupný kontaktní bod, přes nějž si mohou zkombinovat zdroje a lidi, kteří nejlépe naplní jejich požadavky a procesy.
  • Vnitřní zaměření na zapojení maxima lidského potenciálu do těch činností, které objevují a dodávají zákazníkům hodnotu. Tento princip bývá často přehlížen.
  • Podněcovat poznávací a vzdělávací aktivity zaměstnanců vytvářením kreativního pracovního prostředí. Tento princip bývá často zapomínán a nahrazován spíše tendencí vyždímat ze zaměstnanců co nejvyšší výkon za jakoukoli cenu, resp. bez ohledu na důsledky, namísto zlepšení kvality práce.
  • Myslet a konat jak jen možno „horizontálně“, zaměřujíce se na procesy a toky (materiálové, datové i komunikační) procházející skrze organizaci.
  • Z procesu odstranit činnosti, nepřinášející hodnotu. Tam, kde to jde, provádět činnosti paralelně a i jinak zrychlit dobu vývoje a celkové odezvy.
  • Namísto vstupů se zaměřit na výstupy. Měření výkonu a odměňování podřídit výstupům k zákazníkovi.
  • Namísto udržování manažerské kontroly dát prioritu výsledkům. K tomu je třeba změnit roli manažera z původního „velitele“, který kontroluje a velí, na „kouče“, který spíše podněcuje, pomáhá a usnadňuje.
  • Vytvořit síťovou organizaci lidí a činností. V některých sektorech se virtuální organizace stává běžným jevem.
  • Posunovat rozhodování blíže k zákazníkům, přeorganizovat systém odpovědnosti mezi organizací, dodavateli a zákazníky.
  • Liniové vedoucí nahrazovat v organizaci spíše pracovními týmy a „manažery případů“.
  • Podněcovat vlastní aktivitu zaměstnanců a spolupráci. To však vyžaduje od manažerů jistou míru tolerance k chybám.
  • Dbát, aby zaměstnanci byli dostatečně motivováni, dostatečně vybaveni a dostatečně pravomocní k plnění svých úkolů.
  • Kde jen možno, dát zaměstnancům plnou odpovědnost za vedení sebe sama. To však od nich vyžaduje jisté schopnosti v oblasti plánování. Delegování pravomocí by nicméně nemělo znamenat úplný přesun rozhodování na zaměstnance, přinejmenším v oblasti strategického řízení je třeba expertní znalosti.
  • Vyvarovat se přílišné složitosti a mechaničnosti v přístupu k procesům. Nenahrazovat tvořivé myšlení softwarem.
  • Držet počet klíčových procesů na minimu (cca do 12). Všechny musí být zaměřeny na cílové zákazníky. Zejména větší organizace jsou často v pokušení vytvářet manažerské procesy (například tzv. „korporátní plánování“), které trvají příliš dlouho na to, aby byly schopny mít nějaký praktický přínos. Takové procesy typicky postrádají jak externí, tak dokonce i interní zákazníky.
  • Vybudovat systém procesů s krátkou zpětnou vazbou, umožňující jejich přirozenou obměnu na základě praktických zkušeností.
  • Zajistit, aby systém postupného zlepšování procesů byl ve stálé shodě se zaměřením společnosti. Podniky s delší zkušeností s reengineeringem často spojují procesní řízení s TQM (Total Quality Management) – oba přístupy jsou přirozeným doplňkem.“

Zdroje

ŘEPA, Václav. Podnikové procesy. Procesní řízení a modelování. Grada Publishing, a.s., 2007. ISBN: 978-80-247-2252-8

COULSON-THOMAS, C. 1994. Business Process Reengineering: Myth and Reality. London, U.K., Kogan Page Limited.

Minimalistická hlášení

Problém

Vývojový tým vytváří dlouhé zprávy o tom, co dělal. Smyslem takových zpráv je často jen uspokojit management.

Řešení

Hlášením rozumíme překlad z anglického „report“. Je běžnou praxí v informačně-technologických firmách a zejména korporacích, že zaměstnanci generují „hlášení“ (reporty), aby bylo vidět, na čem se pracuje a jaké jsou výsledky práce minulé.

Hlášení je abstraktem práce, jejím souhrnem, které má smysl jen v případě, že práce je příliš složitá na to, aby vypovídala sama o sobě. Hlášení, které je prací samotnou, čili se o nic hmatatelného neopírá, je zbytečné a je třeba jej eliminovat. Rovněž dlouhá hlášení nemají smysl. Hlášení je vždy jen zjednodušeným popisem práce. Pokud je hlášení příliš dlouhé, je rychlejší podívat se na práci samotnou. Dlouhá hlášení se také dlouho píšou a špatně čtou. Přemíra hlášení ukazuje na nevytíženost člověka, který je generuje. Je to jen chabé obhájení potřeby zaměstnance, který je ve skutečnosti zbytečný, proto jen více křičí, aby byl vidět.

Základní myšlenkou je, že hlášení zatěžuje. Pokud však má smysl a nelze se bez něj obejít, je třeba mít je co nejkratší a nejobsažnější.

V Kyberii používáme Scrum hlášení, zasílaná 1x denně e-mailem na všechny členy týmu. E-mail posíláme, pokud se fyzicky nemůžeme sejít a pracujeme z domova.

Hlášení obsahuje odpovědi na 3 základní otázky:

  1. Co jsem dělal včera?
  2. Co budu dělat dnes?
  3. Jaké mám aktuální překážky, které mi brání v práci?

Tato jednoduchá forma hlášení umožňuje týmu být neustále v kontaktu a vědět, kdo na čem pracuje. Překážky také mohou být průběžně odstraňovány. Pokud se některý požadavek či práce řeší příliš dlouho, je to impulz k dalšímu zjednodušování či pomoci s vývojem.

Stejná hlášení používáme v Kyberii při vývoji softwaru již od roku 2006 po přijetí pravidel Scrum a naprosto nám to při velikosti týmu 3-5 lidí vyhovuje.

Omezení pravidla

Velké, nepružné korporace, který práci nevidí a na reporty spoléhají. V tomto případě se ovšem jedná o narušení důvěry mezi zaměstnancem a zaměstnavatelem.

Odkazy na Agilní Manifest

„Budujeme projekty kolem motivovaných jednotlivců. Vytváříme jim prostředí, podporujeme jejich potřeby a důvěřujeme, že odvedou dobrou práci.“

„Nejúčinnějším a nejefektnějším způsobem sdělování informací vývojovému týmu z vnějšku i uvnitř něj je osobní konverzace.“

Eliminujte experty

Problém

V týmu existuje expert, který ví něco, co ostatní členové týmu neví či neumí. Expert je však slabým článkem vývojového týmu.

Řešení

Expertem rozumíme člověka, který je odborníkem v dané oblasti či problémové doméně. Charakteristickým znakem je, že expert toho ví víc, než ostatní. Stává se tak autoritou v dané oblasti a jeho znalosti ovlivňují produkt více, než znalosti ostatních, tedy ne-expertů.
S experty je potíž, že jsou těžko nahraditelní. V případě jejich neschopnosti dodávat cenné rady se tým může ocitnout „na holičkách“, protože další expert buď neexistuje, nebo není k sehnání.
V Kyberii jsem se vždy snažil, abychom experty nepotřebovali. Dosáhl jsem toho zavedením dostatečně jednoduché technologie (Ruby on Rails) a využíváním komponent, které jsou maximálně jednoduché. Protože lidé rotují mezi všemi různými rolemi, je expertem každý z nich.
Pokud používáme externí software (např. na úrovni komponent), je základem nedělat příliš mnoho změn v kódu software. Měli bychom co nejvíce trvat na výchozím (default) chování a konfiguraci.
Nejjednodušší je však trvale tlačit na zadavatele (klienta), aby nevyžadoval příliš sofistikovanou obchodní logiku aplikace. Často lze vyjít s menší funkčností, než se původně předpokládalo. Příliš komplexní systémy vznikají proto, že experti uměle tlačí na poptávku, aby byli požadováni, nebo architekt systému nemá zkušenosti či touhu vše neustále zjednodušovat.
V Kyberii máme jen 1 experta, který je jedním z autorů používané relační databáze. Máme ho však jen jako pojistku pro případy, kdy potřebujeme pomoci s laděním dotazů či křížově kontrolovat nastavení databázového serveru. Kdybychom o něj přišli, firmu by to nepoložilo.

Omezení pravidla

Píšeme software, který je tak složitý, že externího experta vyžaduje. V tomto případě bychom měli zkusit redefinovat problémovou doménu a zvážit, zda ji nelze jakkoli zjednodušit.
Případně vyměnit technologii za jednodušší. Takovou, která experta nepotřebuje.

Odkazy na Agilní Manifest

„Jednoduchost–umění maximalizovat množství nevykonané práce–je klíčová.“

„Tým se pravidelně zamýšlí nad tím, jak se stát efektivnějším, a následně koriguje a přizpůsobuje své chování a zvyklosti.“

Nebojte se chyb

Problém

Obava z výskytu chyb paralyzuje tým a snižuje rychlost uvádění softwaru do produkčního prostředí. Tým či klient trvá na podrobném testování ze všech možných stran a napříč všemi případy užití.
Lepší je přijmout fakt, že chyby se mohou vyskytnout a často se nic opravdu kritického nestane.

Řešení

Tuto radu nelze použít v případě vývoje kritického systému, který si chyby nemůže dovolit. Ovšem kolik systémů je opravdu kritických?
Spolehlivost implikuje pomalost, protože je zapotřebí více testů, revizí kódu, plánování uvolnění verzí či simulací krizových scénářů. Pokud si však můžeme dovolit komfort občasné nestability či chyb, můžeme vyvíjet rychleji.
Typicky je spolehlivost přeceňovaná. Na otázku „jak má být váš software spolehlivý“ klienti odpoví„na 100%“. Klienti samozřejmě chtějí spolehlivý software. Spolehlivost je dnes považována za standardní vlastnost a jakákoli nestabilita či výpadek jsou vnímány negativně. Když se však zamyslíme, mnoho systémů si může dovolit krátkodobou nestabilitu v řádu vteřin či minut. Hlavně, zaručit dlouhodobě 100% spolehlivost ani není technicky možné.
Zkusme s klientem uzavřít dohodu, že přijme občasnou nestabilitu či výskyt chyb výměnou za systém, který je aktualizován denně a možné chyby budou opraveny v řádu vteřin či minut. Pokud bude souhlasit, můžeme razantně zjednodušit a zrychlit vývojové cykly a přejít na denní aktualizace. Výsledkem je lepší adaptace na okolní svět pomocí rychlosti vývoje a neustálé a viditelné inovace.

Omezení pravidla

Jak bylo řečeno, kritické systémy si chyby nemohou dovolit a musí být tak stabilní, jak je to jen možné.
Pokud klient není součástí vývojového týmu, chyby nemusí chápat a požaduje kompenzace za výskyt chyb. V tomto případě se snažíme chyby minimalizovat, ovšem je třeba pochopit, že 100% stabilita ve skutečnosti neexistuje.

Odkazy na Agilní Manifest

„Naší nejvyšší prioritou je vyhovět zákazníkovi časným a průběžným dodáváním hodnotného softwaru.“

Nepište dokumentaci

Problém

Máme software, ke kterému existuje dokumentace. Lepší je ale dokumentaci nemít.

Řešení

Toto pravidlo vychází z myšlenky, že software musí být jednoduchý a na první pohled zřejmý. S výjimkou systémů, které jsou komplexní z důvodu extrémně složité problémové domény (letadla, raketoplány, jaderná elektrárna) a software, sloužící k napsání dalšího software (API, programovací jazyky či nástroje) lze jakýkoli software napsat jednoduše tak, aby žádnou dokumentaci nepotřeboval.

Obecně lze říci, že dokumentace popisuje software, jaký by měl být, nikoli, jaký doopravdy je.

Za hlavní nevýhody dokumentace považuji:

  • Pracnost a cenu – dokumentace je jen další produkt, který je třeba psát. Práci je třeba zaplatit. Množství odvedené práce a cena za výsledný produkt tak roste.
  • Pomalost – dokumentace zdržuje od práce, protože uživatel nad softwarem nemusí přemýšlet. Místo přemýšlení čte dokumentaci a nepracuje.
  • Složitost – dokumentace obvykle popisuje kompletní systém, nikoli část, kterou uživatel zrovna potřebuje. Protože je mix potřebné funkcionality odlišný uživatel od uživatele, je třeba dokumentaci přečíst celou, než uživatel najde, co potřebuje.
  • Zprostředkovanost – dokumentace popisuje systém slovy jejího autora, nikoli slovy uživatele, který bude software používat. Nemusí tak být jasné, co se vlastně popisuje.
  • Nuda – psát dokumentaci a číst dokumentaci je nuda.
  • Zastaralost a potřeba aktualizace – s jakoukoli změnou v rozhraní software je třeba aktualizovat dokumentaci. Pokud na to zapomeneme, je dokumentace neaktuální a dohledání, co je a co není aktuální je úmorné.
  • Podřadná práce – nikdo ještě nezměnil svět tím, že napsal dobrou dokumentaci.

Dobrý má být software, nikoli jeho dokumentace. Potřeba dokumentace je tedy rezignací na jednoduchost.

Omezení pravidla

API, kritické systémy, systémy, ve kterých se musíme podřídit metodice (státní správa, korporace, apod.) dokumentaci typicky potřebují.

Odkazy na Agilní Manifest

„Hlavním měřítkem pokroku je fungující software.“

„Jednoduchost–umění maximalizovat množství nevykonané práce–je klíčová.“

Vyhoďte analytiky II.

Problém

Samotnému kódu předchází analýza, tvořená analytikem, který netvoří výsledný kód, v horším případě ani neumí programovat.

Řešení

Analytik je prostředník, který překládá řeč klienta do řeči programátora. Tím samozřejmě přidává další informace z touhy po zjednodušení a vyjasnění. Analytik nevytváří dlouhodobý produkt, jen jeho odraz. Jeho motivací je mít na konci kompletní a správnou analýzu software, za který klient zaplatí. Samotné analýzy se stávají jen produktem, který popisuje produkt.

Nezavrhuji analýzy obecně. Pokud má některý diagram smysl (například popis síťové infrastruktury, na které software poběží), ať se udělá. Zavrhuji však analýzy, které existují jen proto, aby naplnily předurčené šablony či postupy, ale ve finále jsou zbytečné. Analytikem z pohledu funkce má být vývojář a klient dohromady. Pokud se shodnou na řešení, může se rovnou programovat bez potřeby formálně definovat funkčnost.

Potíž s analýzami je obecně ta, že sice popisují systém, ale ne v konečné formě – jen v takové, jaká bude předložena pro další konstrukci systému. Konečnou formou je ale přece systém samotný ve své finální funkčnosti. Analýza zůstane vždy jen receptem, kuchařkou, na jejíž čtení je třeba odborné vzdělání. Typicky programátor analýze rozumí, ale klient nikoli. Proto klient nemůže verifikovat, zda je analýza správně. Analytik funguje jen jako překladatel mezi teoretickým a praktickým světem, ale vždy pracuje s abstrakcí. Abstrakcí je třeba se vyvarovat, protože je lze chápat různými způsoby.

Lpění na analýzách znamená, že systémy jsou ve finále odrazem myšlení analytiků, ne klientů, kteří software vlastní a budou ho používat každý den. Proto jsou dnešní softwarové systémy složité, každý má jiné ovládání, na jejich užívání a provoz je třeba školení a zavádění změn je velmi pomalé. Je to důsledek práce analytiků a jejich lpění na zbytečně složitém světě. Pro analytiky je důležitější analýza samotná, ne finální systém. Proto se nazývají „analytiky“, nikoli „uživateli“, či „tvůrci“. Analýzu považují za nejdůležitější část své práce.

Jestliže je software tak složitý, že část myšlenek je třeba odložit na papír, je lepší software zjednodušit či jej rozšiřovat později. Často se ukáže, že zpočátku zamýšlená funkcionalita není časem třeba. Požadavky je proto jednodušší řešit, až když nastanou a není možno je dále odkládat.

Analýzy vznikly z předpokladu, že psaní softwaru je drahé. Proto bylo třeba předem pečlivě rozmyslet, co se bude psát, aby se psalo co nejkratší dobu a práce se nedělala zbytečně. Dnešní softwarové technologie však umožňují generaci velkého množství kódu automaticky (např. Ruby on Rails a jejich „lešení“ – scaffolding), existují vývojová prostředí pomáhající s vývojem (Integrated Development Environment – IDE), automatické kontroly kódu, generace testů apod. Vypracování analýzy zadání tak může být časově náročnější než vypracování reflektujícího kódu.
Kód samozřejmě může být odrazem chybně pochopeného zadání. V tomto případě byl kód psán zbytečně. Ale v případě analýzy je riziko dvojnásobné – chybně pochopené zadání analytikem se odrazí v chybné analýze a tak vyústí v napsání chybného kódu. Náklady na projekt pak rostou. A když nepotřebujeme analýzy, nepotřebujeme ani vyhrazené analytiky. Existence samostatné role nemá smysl.

Proto je lepší rovnou začít psát. Zpočátku nedokonale, s otázkami, s pozorností jen na další problém, ne dále. Celkový koncept systému má držet klient samotný, nikoli kus papíru, psaný analytikem, který k systému nemá osobní vztah. Analýza je pouze obhájením budoucí práce. rozkladem problému na menší části, které však nejsou vidět jako celek. Tuto vlastnost má pouze finální systém.

S odvahou mohu uvést, že potřeba vyhrazeného analytika je selháním poslání softwarové společnosti, rezignací na jednoduchost, snahou krýt si záda a zdůvodnit často nesmyslně vysokou cenu software. Softwarová společnost má psát software, nikoli dělat analýzy. Jediným měřítkem úspěšnosti je spokojený klient, nikoli naprogramování systému dle analýzy.

Omezení pravidla

Existenci analytiků akceptujeme, pokud se tým zavázal v přijetí metodiky, která existenci analytiků nařizuje nebo je předpokládá.
Nebo pracujeme pro společnost, která tyto metodiky používá a náš tým je pouze minoritní či jednorázový dodavatel řešení.
Rozhodnutí nad potřebou analytika by však měl být svěřen do rukou týmu a být výsledkem skutečné a odůvodněné potřeby, nikoli vůle nadřízeného či jakékoli metodiky.

Odkazy na Agilní Manifest

„Nejúčinnějším a nejefektnějším způsobem sdělování informací vývojovému týmu z vnějšku i uvnitř něj je osobní konverzace.“

„Hlavním měřítkem pokroku je fungující software.“

„Nejlepší architektury, požadavky a návrhy vzejdou ze samo-organizujících se týmů.“

Zrušte role

Problém

Vývojový tým je rozdělen na role, kde každá z rolí znamená specializaci a vymezení se oproti rolím ostatním. Existence rolí znamená, že si v týmu budujeme experty, pěstujeme nenahraditelnost a software se píše pomaleji, protože role si sebou předávají práci a v případě chyby se dohadují, kdo za co může. Role je zodpovědná jen za svou část práce. Ve finále nemá odpovědnost nikdo za nic.

Řešení

Role je vymezení odpovědnosti na vyhrazené lidi, kteří mají expertní znalost, nechápou systém jako celek nebo je jejich role tak specifická, že více nejsou schopni pojmout. Lepší je role nemít vůbec.

Formální neexistence vývojových rolí (programátor, tester, analytik, integrátor, podpora, apod.) znamená, že každý člen týmu umí zastoupit jakoukoli práci, která je zrovna třeba.

Výhodou je vzájemná zastupitelnost a stejná úroveň znalostí napříč celým týmem. Je pochopitelné, že každý člověk v týmu inklinuje k jisté specializaci a některé úkony dělá raději, než jiné. V Kyberii však vyžadujeme, aby každý z členů týmu uměl udělat práci od návrhu až po produkční nasazení. Nemůže se například stát, že někdo z týmu neví, jak provést instalaci nové verze do produkčního systému.

Znalost celého vývojového cyklu a všech jeho částí dává lepší pohled na software. Klienta vývojové fáze či úkony nezajímají. Klient chápe a chce používat software jako celek. A je nutné, aby to vývojář viděl stejně.

Spojení a rotace práce znamená přijetí odpovědnosti za software jako celek. Nemůže se tedy stát, že vznikne spor „vývojář to napsal správně, ale integrátor to udělal špatně“. Všichni jsou za software odpovědní společně.

Omezení pravidla

Pravidlo nelze použít, pokud ve společnosti existuje pevná organizační struktura nebo se používají příliš složité technologie, při kterých je nemožné pojmout celý cyklus vývoje software jedním členem týmu. V tomto případě doporučuji firmám vytvořit virtuální organizaci, zkrátit vývojový cyklus na týdenní iterace a nasadit jednodušší technologii.

Odkazy na Agilní Manifest

„Nejlepší architektury, požadavky a návrhy vzejdou ze samo-organizujících se týmů.“

„Dodáváme fungující software v intervalech týdnů až měsíců, s preferencí kratší periody.“

Technologie je jen nástroj

Problém

Používáme technologii, která je zastaralá, pomalá, složitá či drahá. Díky tomu máme potíže doručit software včas, nejsme schopni používat krátké vývojové cykly, provoz systému je drahý a práce samotná není zábavná.

Řešení

Při psaní softwaru lze použít prakticky jakýkoli mix různých technologií. Je však třeba chápat, že technologie je jen nástroj, nikoli cíl. Technologie je sluha, nikoli pán. Nemá smysl držet se za každou cenu technologie, která je posvěcena velkou společností a nechat se ukolébat falešným zázemím „velkého“ autora.

Jestliže umíme vyřešit úkol jednodušeji pomocí třeba i primitivních nástrojů, použijme je. Například pro automatické spouštění kódu na serveru určitou hodinu není třeba používat složité plánovače jako je Quartz Scheduler, pokud si vystačíme s obyčejným unixovým Cronem.

Technologie nesmí být invazivní a nezměnitelná. Je třeba mít svobodu technologii v případě potřeby změnit. Některé technologie je obtížné změnit (např. relační databáze) ale podobných závažných rozhodnutí je málo. Pokud jsme otroky technologie, pak píšeme software nikoli pro zisk klienta, ale pro technologii samotnou.

Množství technologií, použitých při vývoji a provozu softwaru by mělo být co nejmenší. Každá nová technologie vyžaduje další znalost, kterou vývojový a administrátorský tým musí znát. Zvyšuje se tak míra komplexity celého systému a tím i pravděpodobnost výskytu chyb. Správa systému je dražší, protože roste množství softwaru, které je nutné pro naše běhové prostředí, prodlužuje se instalace systému a zvyšuje se počet monitorovacích nástrojů.

Obecně platí, že technologií by mělo být tak málo, kolik je třeba pro minimalistickou a klientem akceptovanou funkčnost našeho softwaru. Důležitý je výsledný software, za který je klient ochoten zaplatit, nikoli technologie. K čemu je software, používající špičkovou technologii, pokud nefunguje, nebo pracuje jinak, než klient očekával?

Z důvodu odpovědnosti je vhodné, aby technologie použité při vývoji volili samotní vývojáři. Hlavně oni s technologií budou pracovat každý den a za kód, který technologii používá jsou odpovědní. Pokud mají odpovědnosti, mají mít i pravomoci.

V Kyberii jsme neváhali změnit kompletní technologii půl roku před finální verzí, zahodili jsme práci za několik let v jazyku Java a přepsali systém Yeti do Ruby on Rails. Celou ságu popisuji v přednášce Ruby on Rails – Zapomeňte na Javu.

Omezení pravidla

Důvodem pro používání špatné technologie či příliš velkého množství technologií může být neznalost či nezkušenost vývojového týmu, snaha držet jednu platformu (např. Java), smluvní či manažerská závislost na externím dodavateli, nutnost podporovat starší systém či prostá pohodlnost vývojářů naučit se technologii novou.

Odkazy na Agilní Manifest

„Nejlepší architektury, požadavky a návrhy vzejdou ze samo-organizujících se týmů.“

„Jednoduchost–umění maximalizovat množství nevykonané práce–je klíčová.“

„Hlavním měřítkem pokroku je fungující software.“

Pracujte

Problém

Zabýváte se činnostmi, které nepřináší konkrétní hodnotu, nelze je prodat a nenaplňují cíle, kvůli kterým byla firma založena. V případě softwarové společnosti je problémem nepsaní zdrojového kódu.

Řešení

Smysl má práce samotná, nikoli její příprava, udržování či delegace. Tyto podružnosti nazývám „předstíráním práce“. Čím déle trvá, než člověk skutečně začne pracovat, tím více času promarní a tím více skutečné práce by mohl stihnout. Práci lze vyjádřit jako plnění smyslu, kvůli kterému byla firma založena. Práce znamená trvalý otisk ve společnosti, něco, co firmu posouvá dále.
V případě softwarové společnosti je prací jen psaní kódu, který má smysl a který bude prezentován na další schůzce klientovi. Vše ostatní jsou v podstatě zbytečnosti. Samozřejmě, nelze vždy bezodkladně psát kód. Podpůrné aktivity je však třeba alespoň minimalizovat. Pokud jsou tyto aktivity (např. dotaz klientovi, schůzka) nezbytné, je třeba zkrátit dobu jejich řešení co nejvíce a použít nejrychlejší formu.
Například zavolat klientovi je rychlejší, než mu psát e-mail. Namísto dohadování, který požadavek má smysl je rychlejší napsat prototyp a prostě to zkusit. Namísto dlouhého schůzování je možno poslat e-mail na skupinu s konkrétními otázkami. Pokud je schůzka nezbytná, agendu je vhodné zaslat předem. Pokud máme člověka, který se rád na schůzi rozpovídá nad nedůležitostmi, pak ho příště nepozveme, nebo ho omezíme obyčejnou kuchyňskou minutkou a po jejím zazvonění mu není povoleno promluvit.
Častým důvodem pro odkládání práce je čekání na někoho jiného. Čekáme, až se nainstaluje vývojové prostředí, až vedoucí schválí náš nápad, až klient zodpoví na otázku, až jiné oddělení dodá vyžádané dokument, apod. Ale i v případě čekání lze psát zdrojový kód, nebo nad ním alespoň přemýšlet a vědomě tak připravovat samotné psaní.
Pravidlo lze shrnout do věty „začnete psát zdrojový kód co nejdříve a nedělejte nic jiného“.

Omezení pravidla

Toto pravidlo platí v jakékoli softwarové firmě. Obecně platí, že čím větší společnost, tím více předstírání práce bude, protože vzniká více vazeb mezi zaměstnanci a odděleními, jejichž komunikace vyžaduje čas. Jakékoli jednotlivé zdržení se sčítá. Lze logicky předpokládat, že ve velkých společnostech bude také rozdělena odpovědnost a více úrovní schvalování práce, stejně tak delší tok informací mezi zúčastněnými. V tomto případě je třeba pracovat na nezávislosti vývojového oddělení tak, aby se čekání minimalizovala.
V případě větší společnosti se jako vhodné jeví vytvoření „virtuální organizace“, kde vývojový tým bude pracovat jako „firma ve firmě“ se svými vlastními zásadami, řízením a zodpovědností. Nezávislost má tendenci věci urychlovat a právě virtuální organizace, která je ze své podstaty menší, než obalující společnost bude zřejmě fungovat rychleji a tím se i rychleji dostane k práci.
Dalším problémem aplikace pravidla „Pracujte“ je trvání na oficiálních formalitách, předcházejících či následujících psaní kódu. Například čekání na analýzu, který nemá smysl, ale je součástí oficiálních vývojových pravidel jen brzdí. Stejně tak čekání na výstup testovacího oddělení v případě, že testy může napsat sám vývojář či testovat klient je typickým „předstíráním práce“. V tomto případě je vhodné zavést takové postupy, které podobná čekání eliminují (viz Vyhoďte analytiky a Vyhoďte testery).

Odkazy na Agilní Manifest

„Nejlepší architektury, požadavky a návrhy vzejdou ze samo-organizujících se týmů.“

„Tým se pravidelně zamýšlí nad tím, jak se stát efektivnějším, a následně koriguje a přizpůsobuje své chování a zvyklosti.“