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.