Pokud máte čtyři skupiny pracující na kompilátoru, dostanete čtyřprůchodový kompilátor.
Eric S. Raymond

V poslední době jsem několikrát narazil na Conwayův zákon. Řekl jsem si, že se o něj s vámi musím podělit.

Každá organizace navrhující systém nevyhnutelně vyprodukuje návrh, jehož struktura bude kopií komunikační struktury této organizace.

Na první pohled je to evidentní. Pokud mám dva moduly, které spolu komunikují, musí spolu zákonitě komunikovat i týmy, které je mají na starost. A naopak, pokud mám týmy, které si spolu nepovídají, nemohou si spolu povídat ani jejich komponenty.

Proč je to zajímavé? Protože to má dopad na architekturu systémů. Zjednodušeně řečeno, o architektuře je rozhodnuto dávno před tím, než se s ní vůbec začne. Řekněme, že chcete co nejlépe navrhnout nový systém. Je to velké, takže práci rozdělíte. Arnoštovi zadáte, aby vymyslel jak budou uložena data a Bedřišce zadáte, ať vymyslí jak je zobrazit. Aniž jste si to uvědomili, už jste rozhodli, že aplikace bude mít dvě oddělené komponenty, frontend a backend. Aneb jak píše sám pan Conway:

… samotný akt organizace navrhujících týmů znamená, že určitá rozhodnutí ohledně návrhu již byla učiněna, ať už explicitně nebo jinak. Ať už jsou týmy organizovány jakkoliv, vždy existuje třída alternativ, které nemohu být touto organizací efektivně následovány, protože neexistují nutné komunikační kanály.

Co z toho plyne? Pokud navrhujete něco nového, odsuňte rozhodnutí o organizaci týmů na co nejpozději. Předčasným rozdělením se připravíte o možná dobrá řešení.

Zajímavé je, že ta věta platí i naopak. Pokud už máte existující systém, musíte kolem něj stavět organizační strukturu. Představme si například, že máte úspěšnou aplikaci, ale tým už se rozrostl nad únosnou mez. Je potřeba ho rozdělit. Kvůli Conwayovu zákonu jsou dvě možnosti jak to může dopadnout. Buď se zároveň rozdělí i aplikace a každý tým dostane na starost jednu část. Nebo týmy zůstanou rozdělené jen na papíře. Lidé pracující na jedné komponentě spolu prostě musí komunikovat natolik intenzivně, že nemohou být rozděleni do víc týmů.

Pokud vás to zaujalo, přečtěte si původní článek. Na to, že byl napsán v roce 1968 je pořád zajímavý.

Agilní vývoj nevyřeší žádný z vašich problémů. Jenom je udělá tak bolestivě viditelné, že bude mnohem těžší je ignorovat.
Ken Schwaber

Tento týden jsem byl na konferenci Agile Prague 2013. Chci si tu napsat věci, které bych nerad zapomenul. Berte to prosím jako mix mé nedokonalé paměti, pokusu o dešifrování poznámek a interpretací.

O povaze softwarového vývoje

Nejvíc mi asi vrtá hlavou keynote Scotta Barbera. Vycházel z toho, že pro vývoj SW nemůžeme používat metaforu výroby, ale měli bychom to vnímat spíš jako výzkum a vývoj (R&D). Použil pěkný příklad s vývojem prototypu auta nebo návrhem mostu. Tvrdil, že vývoj software se víc podobá právě takovému vývoji, než následné výrobě nebo stavbě.

Proč je to důležité? Protože pak je potřeba jiný přístup. Při vývoji prototypu auta nemají někoho kdo by dělal výhradně design, někoho kdo by to odpracoval a někoho kdo by to otestoval. Ano, mají tam specialisty, ale všichni dělají víceméně všechno. To docela sedí s agilní snahou o multifunkční týmy.

Kvalitu pak nemá na starost nějaké QA, ale všichni. O tom, jestli to k něčemu je, rozhoduje hodnota toho co se vyvine a ne nějaká uměle určená kritéria.

Má to ale i jiné dopady. Třeba to, že vstupem pro prototyp auta je cíl a vize, nikoliv přesně zadané požadavky. Ty se ujasní až při vývoji samotném.

Vrtá mi to hlavou, pořád nevím jestli s tím souhlasím nebo ne. Na jednu stranu to dává smysl, na druhou stranu to znamená, že skoro všichni dělají software blbě. Hmm, to souhlasí. Že by měl nakonec pravdu? Ale pak by z toho taky plynulo, že Kanban také moc nedává smysl. Vždyť si bere za vzor výrobní linku a ne nějakou vědeckou laboratoř. Jaké jsou pak kroky, které chci sledovat na nástěnce? Divné.

Rozvíjíme Scrum Mastery

Kde jsou Scrum masteři, tam musí být i Scrum otroci.

Pak si asi nejvíc vybavuji přednášku Angella Medinilla o Scrum masterech. Začal tím, že se o podobné roli nedočtete ani v Agilním manifestu, ani v žádné jiné metodice kromě Scrumu. Všichni mluví o samoorganizujících se týmech. Nikde se nedočtete o žádném masterovi nebo ani koučovi.

To je samo o sobě docela zajímavý postřeh. Nejcertifikovanější role v agile světě a je takhle neagilní. To je sice zajímavé, ale ne moc užitečné. To byl až následující slide.

Ukazuje tam různé podoby Scrum Mastera. Začíná to Scrum chlápkem, který plánuje schůze a na denní skrumáži vyslýchá kolegy. Pokračuje přes Scrum mámu, která se o tým stará jako o vlastní děcka a končí opravdovým Pánem Scrumu, který jen tým drobně směřuje a nechává ho se samoorganizovat.

Důležité je si uvědomit, že každý tým potřebuje něco jiného. Některé týmy potřebují mámu, která je bude vodit za ručičku, opravdového Scrum mastera by nepobraly. Platí to i naopak, když dáte rozvinutému týmu někoho, kdo jim bude všechno organizovat, tak to také nedopadne dobře. Na přednášku (ale z jiné konfrence) se můžete podívat tady.

Procesy, produkt, hodnota

Potřebuje lepší diskuzi, ne lepší dokumenty.

David Hussman měl dvě přednášky, které se mnou tak rezonovaly, že už nejsem schopný rozlišit co doopravdy řekl a co je moje interpretace. Obě byly podle mě o tom, že bychom měli odhlédnout od Agilních procesů a soustředit se na ty důležité věci za nimi. Nemáme používat user stories jako lepší verzi případů užití. Měli bychom je používat jako záminku pro diskuzi. Stejně tak ostatní praktiky a procesy jsou jenom prostředkem k něčemu důležitějšímu. Neměli bychom na to zapomínat.

Horší je lepší

Existují jen dva druhy jazyků, ty na které lidé nadávají a ty, které nikdo nepoužívá. Bjarne Stroustrup

Další zajímavé povídání měl Kevlin Henney. Bylo to o architektuře a designu a principu Worse is Better. O co jde? Když odhlédneme od debilního jména, tak jde o to, že je dobré upřednostňovat jednoduchost před skoro čímkoliv jiným. A to nejen jednoduchost designu, ale hlavně jednoduchost implementace. Takže pokud volíme mezi konzistencí a jednoduchostí nebo úplností a jednoduchostí, tak bychom měli vždy volit jednoduchost.

Naznačoval také, že nedokonalá řešení jsou obvykle úspěšnější něž ta dokonalá. Pěkný příklad jsou programovací jazyky. Co je lepší jazyk, Smalltalk nebo C? Přesto zvítězilo C. Nebo takový ten dokonalý operační systém co už si ho nikdo nepamatuje, který porazily Windows.

Vzpomněl jsem si při tom na lidi, kteří jsou schopní strávit měsíce vymýšlením dokonalého řešení, místo toho, aby zvolili horší, ale jednodušší řešení.

Navrhujte odstranitelné věci

Platforma je něco, z čeho se nemůžete dostat bez záchranného člunu.

K architektuře se vztahovala i přednáška Marca Anhnveho o návrhu. Hlavní teze byla, že je potřeba už při návrhu myslet na to, jak se dané věci budeme za čas zbavovat. To že nás prý donutí dělat věci dobře odizolované, komponentizované a zkrátka jinak dobré.

No to je asi všechno, byly tam i jiné zajímavé přednášky, ale tolik mě nezaujaly. Nicméně mám v plánu zkusit nebo se zamyslet nad

• 0 bug policy – nesušit si bugy na jindy
• Pravidelné jednoduché měření výkonu komponent
• Mít pro každou schůzi kritérium úspěchu, aneb vědět na začátku jak poznáme, že k něčemu byla.

Zaslechnuto v tramvaji:

Ona: Kam pojedeme na dovolenou?
On: Letadlem.
Ona: Cože?
On: Co se divíš, letadlem.
Ona: Ale to přeci není místo kam jet na dovolenou.
On: Jak to, že ne? Všichni létají na dovolenou letadlem. Navíc je to nejbezpečnější a nejrychlejší. To snad chceš jet autem?

Zaslechnuto v zasedačce:

Ona: Jaký je cíl tohoto projektu?
On: Dodat vlastnosti A, B a C
Ona: Cože?
On: Ano, dodat vlastnosti A, B a C.
Ona: Ale to přeci nemůže být cíl.
On: Jak to, že to ne? A, B a C byly stanoveny jako nejvyšší priority. To snad chceš dělat na vlastnosti D?

Zaslechnuto v jiné zasedačce:

Ona: Jaký je cíl pro zlepšení výkonnosti našeho produktu?
On: Nasadit Žůžo Akcelerátor 2.0™
Ona: Cože?
On: Co se divíš, nasadit Žůžo Akcelerátor 2.0™.
Ona: Ale to přeci není cíl jak zlepšit výkonnost.
On: Jak to, že to ne? Žůžo Akcelerátor 2.0™ je nejlepší na trhu. Sníží zátěž procesorů nejméně o 37%. To snad nechceš dělat nic? Vždyť víš jak si zákazníci stěžují, že je náš produkt pomalý.

Cvičení:

1. Jaký je rozdíl mezi Bahamami a letadlem?
   Odpověď:

2. Proč nám letadlo jako cíl dovolené přijde absurdní, ale nasazení Žůžo Akcelerátoru 2.0™ jako cíl pro zlepšení výkonnosti ne? V čem je rozdíl?
   Odpověď:

3. Ve svém okolí najděte nejmarkantnější příklad záměny cíle a prostředku. Tušíte jaký je skutečný cíl?
   Odpověď:

4. Na čem právě teď pracujete? Víte jaký je cíl? Víte jaký to bude mít dopad? Kolik peněz to ušetří nebo vydělá? Víte komu to udělá radost a proč?
   Odpověď:

5. Zamyslete se, jestli váš cíl není jen prostředkem k něčemu jinému? Pokud ano k čemu? A není toto náhodou prostředek k něčemu jinému? Znáte všechny tyto cíle? Jak daleko dokážete zajít, než vám z toho šibne?
   Odpověď:

6. Za jakých podmínek není letadlo správná volba při cestě na dovolenou. Za jakých podmínek nejsou vlastnosti A, B a C to nejlepší co můžeme udělat? Za jakých podmínek není Žůžo Akcelerátor 2.0™ nejlepší prostředek pro zlepšení výkonnosti?
   Odpověď:

7. Jsou nějaké negativní dopady záměny cíle a prostředku? Pokud ano, jaké?
   Odpověď:

8. Můžete dojít k cíli, který neznáte? Jak poznáte, že jste ho dosáhli?
   Odpověď:

9. Pokud neznáte cíl, jak víte že zvolený prostředek je nejlepší?
   Odpověď:

Doporučená literatura:

[1]E. M. Goldratt and Cox, The goal: a process of ongoing improvement. Great Barrington, Mass.: North River Press, 2004.
[2]“5 Whys,” Wikipedie. 05-Sep-2013. https://cs.wikipedia.org/wiki/5_Whys
[3]“SMART metoda,” Wikipedie. 27-May-2013. https://cs.wikipedia.org/wiki/SMART_metoda