Wuwejův zápisník

Anton Březina: Agilní transformace

09.07.2020 23:38, Wu | knihy | komentáře -

obálka Agilní transformaceKnihu bych si pořídil tak jako tak, ale podtitul Proč bývá tak křehká? mou objednávku notně uspíšil. Mám samozřejmě hromadu svých vlastních teorií a poznatků o křehkosti agilní transformace, ale tím spíše jsem byl zvědavý na pohled někoho dalšího.

Knihu jsem se rozhodl napsat poté, co jsem několik let v praxi čelil nadšenému zavádění agilních metodik do vývoje a až na malá vítězství (ačkoliv hodně oslavovaná) byly přínosy v lepším případě sporné. Z konferencí, agilních kaváren, osobních i internetových diskuzí a pracovních pohovorů jsem pak nabyl přesvědčení, že mé zkušenosti rozhodně nejsou ojedinělé. (Str. 7)

Ano, sporné přínosy a neustálé přizpůsobování – v kontrastu s ideálem a fungováním, jaký skutečně agilní vývoj (a agilní společnost) dokáže přinést.

Kniha si neklade za cíl být učebnicí nebo příručkou agilního vývoje. Není ani adorací agilního vývoje, ani se nesnaží o jeho zatracení. Ve skutečnosti se snaží o zdůraznění, na co si dát pozor, aby výsledek úsilí věnovaného agilní transformaci byl pozitivní, a ne negativní. (Str. 7)

Obsah zahrnuje vše podstatné – od vysvětlení důvodů (Proč vůbec být agilní?), přes shrnutí dosavadních tradičních rolí (Programátor, Tester) a vysvětlení rolí nových (Scrum master, Produktový vlastník),

Produktový vlastník je jedna z nových rolí, na kterou se odkazuje zejména scrum. Pro agilní transformaci je tato role naprosto klíčová. Produktový vlastník musí mít vizi, musí ji umět přetavit na uživatelské scénáře a musí být schopen spravovat očekávání zákazníků. Musí zvládat umění dělit velká zadání na malé, konkrétní úkoly, které dokáže malý tým (pro konkrétní představu 6+-3 členů) plnit tak rychle, že je v reálném čase možné sledovat pokrok. (… ) Na základě mých osobních zkušeností a pozorování je právě nepochopení a podcenění této role největší překážkou agilní transformace. Nestačí pouze přejmenovat a přeškolit projektové manažery na produktové vlastníky. Jde o mnohem víc. (Str. 67)

nutnost podpory managementu (a rizika open space, outsourcingu, nenahraditelných zaměstnanců), potřebné fungování týmu (Schůzky a mítinky, Denní scrum, Sprint, jeho plánování a revize, Vydání nové verze, Retrospektiva sprintu, Správa chyb, Každodenní priority, Transparentnost) až po empirickou podporu procesů a škálování.

Učebnicový scrum třeba roli testera vůbec neuvádí – týmy jsou pouze vývojové a správně by měly mít všechny schopnosti potřebné k dodání produktu. Jednou z těchto schopností může být třeba i schopnost manuálního testování – schopnost předvídat chování uživatelů. Testeři v agilních vývojových týmech by proto měli sami sebe přestat vnímat jako audit kvality, který svým podpisem stvrzuje použitelnost řešení v produkčním prostředí. Stejně tak hnidopiši („máš tam chybu – koukej si to opravit“) a mistři obskurních scénářů to budou mít v agilních týmech nelehké. Než pálit čas hledáním chyb v nikým nepožadovaných částech funkčnosti a jejich opravami, měl by se celý vývojový tým společně soustředit na zamezení samotného vzniku chyb. Kvalita musí být zabezpečená napříč celým životním cyklem produku. Měřit na samotném konci tohoto cyklu, zda tam je, ji nijak nezabezpečí. (str. 41)

Knihu uzavírají přehledové tabulky:

  • Velmi zjednodušené srovnání tradičního a agilního přístupu k vývoji softwaru
  • Velmi zjednodušené srovnání scrumu a kanbanu
  • Nejzákladnější předpoklady pro zavedení scrumu
  • Jak může management bránit agilní transformaci
  • Jak může management podpořit agilní transformaci
  • Kombinování scrumových rolí
  • Nejčastější chyby při agilní transformaci
  • Nejčastější chyby scrum masterů

Ty se mi zpočátku zdály nadbytečné, ale když jsem si v nich zakládal už třetí stránku, uvědomil jsem si, že obsahují opravdu shrnutí důležitých postřehů. Třeba u chyby, kdy je agilní jenom vývoj a ne zbytek společnosti (Str. 189) jsou vyjmenované možné důsledky:

  • (...)
  • management nijak nemění svá očekávání od vývoje (proto právě název "fixed requirements agile neboli fragile"),
  • riziko vzniku jiných zdrojů práce, než je produktový vlastník,
  • bez ohledu na plánování hrozí přidávání další urgentní práce do iterací bez možnosti odmítnutí, byť jen části, protože všechno je důležité,
  • odhadování náročnosti úkolů v časových jednotkách a následné vyžadování tyto odhady dodržet: odhad = závazek,
  • (...)

Do kamene tesat. Ačkoliv bych tedy naprostou většinu věcí v knize podepsal (a pro mě je to potvrzení, že se opírá o realitu a to včetně reality velkých firem a korporací), nebudu zastírat, že pár věcí mě překvapilo a musel jsem si trochu poopravit svůj přístup. Například tohle:

I v tomto případě pořád platí, že zpřesňování zadání by mělo probíhat mimo produktového vlastníka. Ten by se měl správně soustředit na backlog a připravovat zadání, které tým bude vyvíjet v budoucnosti. Ne fungovat jako zákaznická proxy. Není v lidských silách, aby jeden vlastník odpovídal na doplňující otázky deseti členů vývojového týmu a zároveň hledět do budoucnosti. Vývojový tým by měl chybějící části potřebné k implementaci doplňovat sám. (Str. 70)

To mě trochu míjelo (i když praxe k tomu vede jaksi samovolně právě kvůli kapacitě).

Produktový vlastník nenařizuje týmu, jak výsledný přírůstek hodnoty dodá, ani výsledný přírůstek týmu neakceptuje. Poskytuje na něj pouze zpětnou vazbu. Musí vývojovému týmu nejdřív věřit, že svěřené zadání zvládne dodat a pak poskytnout zpětnou vazbu na výsledek. Tím vzniká prostor pro učení a schopnosti týmu i produktového vlastníka společně rostou. (Str. 72)

Kromě znalostí a praxe disponuje autor i schopností tvrzení pěkně pointovat, například u review:

Revize by rozhodně neměla být žádná práce navíc. Nemělo by se například stát, že ve dvoutýdenním sprintu strávíte jeden týden přípravou prezentací pro demo. Předvádí se hotový software – pokud váš software potřebuje speciální přípravu, aby ho bylo možné předvést, hotový není. (Str. 133)

nebo u škálování:

Pokud pojedete na konferenci nebo do agilní kavárny, určitě tam potkáte nějakého nadšence, který bude obhajovat tu nebo onu metodu škálování. Jak musíte eskalovat, když narazíte na problém, jak efektivně sdílet informace, scrumy scrumů, denní scrumy scrum masterů atd. Víte proč tyto vize budou kolidovat s praxí, kterou prožíváte? Ten nadšenec nebude lopata. (Str. 166)

Založil a vypsal jsem si toho ještě mnohem víc, cílem recenze ale není knihu převyprávět. Takže jen závěrečné shrnutí – v češtině docela jistě není lepší kniha o agilním vývoji, a pokud se s ním jakkoliv setkáváte, musíte ji mít.

Odkazy:

nakladatelství KOPP, České Budějovice 2020, ISBN 978-80-7232-521-4, cena 299 Kč

12345
1594330680000

Informace

Kontakt

Google search

Kategorie

Archiv

STRÁNKY ARCHIVOVÁNY NÁRODNÍ KNIHOVNOU ČR

CBDB.cz – Databáze knih a spisovatelů, knihy online