Pět technik agilního řízení, které fungují

Česká spořitelna právě prochází další vlnou agilní transformace, s čímž souvisí řada školení a webinářů. V tomto šestidílném seriálu se podíváme na několik oblastí, které jsou pro zdařilou proměnu large-scale vývoje softwaru stěžejní, a podrobněji je rozebereme.

Lidé v týmech by se měli méně orientovat na své konkrétní role a aktivity, naopak by měli být otevřenější celku. Často ve firmách vídám, že pokulhává jedna věc: člověk dělá jen to, co má v popisu práce, nic dalšího. A to má za následek stav, kdy na sebe všichni navzájem čekají nebo někdo dělá věci, které nejsou potřeba, protože zrovna nic jiného neumí. Scrum staví na tom, že lidé v týmu přijmou zodpovědnost nejen za to, co stojí na jejich vizitce, nýbrž za celek.
Že začnou spolupracovat mnohem úžeji, navzájem mezi sebou.
To vyžaduje, aby se učili i věci, které v popisu práce nemají, a zároveň byli v co nejčastějším kontaktu s uživatelem – opět všichni. Ne že s klientem komunikuje jeden prostředník a ten pak informace tlumočí (čti: zkresluje) ostatním.

Scrum zná skoro každý, nebo o něm alespoň slyšel. Jenomže většina lidí, které znám, ho zažila natolik pokřiveně, že ho vnímají negativně. Jako byste šli za špičkovým dietologem, který vám dá sadu doporučení pro zdravý život nebo hubnutí, jenže vy si z toho vyzobete jen to, co vám sedí. Každodenní cvičení? To se mi nechce. Omezit sacharidy? Ale což, večerní dortík si přece neodepřu. A pak byste si stěžovali, že odborníkovy rady nefungují a vy nehubnete.

V malém týmu lze scrum nastavit celkem snadno, a komu se to povedlo, významně z toho těží. Těžkosti ale přicházejí u týmů velkých. Intuice velí rozdělit velký produkt na malé zahrádky a každý tým ať si pracuje na té své. Tím ovšem vznikají obrovské neefektivity, které nikdo pořádně nevidí.

Když velká skupina lidí pracuje na složitém řešení, například bankovním produktu, je nesmírně přínosné, když spolu pravidelně komunikují všichni navzájem a alespoň do určité míry znají všechny (většina) týmy celé řešení (nebo alespoň více než jednu zahrádku). Výhodou pak je, že jakkoliv se v čase mění priority, celá velká skupina je schopna je následovat. Pokud je ale celek rozdělený na malé zahrádky, na nichž si každý okopává jen svůj záhonek, velmi často se stává, že lidé pracují na totálních zbytečnostech. A ani o tom nevědí, protože nemají ponětí o zbytku mimo svou zahrádku. Nezajímá je to. Firmy takhle nezřídka vyhazují velké peníze. Právě tohle je jedna z věcí, která často drhne. Nechce se nám cvičit, přestat pít pivo a jíst sladkosti. Jenomže když to dokážeme a prvotní nepohodlí překonáme, mohou se dít zázraky.

V tomto seriálu se chci věnovat pěti nejdůležitějším praktikám v large-scale vývoji. V některých jde o typicky měkké dovednosti, v jiných o tvrdé, další jsou kombinací obou. Na co se v dalších dílech můžete těšit?

Specification by example spočívá na dvou pilířích. Celé produktové týmy komunikují přímo s uživatelem, aby všichni porozuměli jeho potřebám stejně. Poté společně vymyslí řešení a zapíšou ho formou tzv. specifikace příkladem. Konkrétní kroky, konkrétní hodnoty, konkrétní výsledky. Tak každý lépe pochopí, jak se má nová funkčnost chovat, a zároveň je snadné proměnit specifikaci v automatizovaný test, který nám kdykoliv ověří, že se software stále chová, jak bylo zamýšleno. 

Trunk-based development nutí všechny vývojáře integrovat svůj kód do hlavní větve každou půlhodinu, ne jednou za 14 dní na konci sprintu. Kdykoliv se něco rozbije, dozvíme se to okamžitě a hned to můžeme řešit. Díky tomu je snazší udržet celé řešení, aby neustále fungovalo, i s nedokončenými funkčnostmi. Vyžaduje to samozřejmě vysoké pokrytí testy. 

Refactoring je činnost, která probíhá neustále, nikoliv nárazově. Ve světě vývoje produktů se kód neustále mění, proto musí být snadné ho v první řadě přečíst. Opět to vyžaduje dobré pokrytí testy. Doufám, že začíná být zřejmé, že technika specification by example má přínos nejen v propojení celého týmu s uživateli, ale i ve vytvoření záchytné sítě automatických testů. 

Kontejnerizace vývojového prostředí. Na velkých produktech bývají vývojová prostředí složitá a je dobré, aby měl každý vývojář a každý tým stejné. Namísto zdlouhavých a nepřesných wiki stránek je trendem celé prostředí strčit do kontejneru. Týmy se tak mohou soustředit na vývoj namísto řešení nastavení svého PC.

Definition of done je koncept, který popisuje, co všechno se musí stát, abychom konkrétní kus funkčnosti mohli považovat za hotový, začít ho používat nebo předat klientovi. Vytváří to transparentnost napříč týmem i požadavky na kvalitu, která se pak snáze dlouhodobě udržuje.

Každá z těchto pěti technik má své nesporné benefity sama o sobě. Když se ale spojí dohromady, není výsledný efekt krát pět, nýbrž na pátou! Vzniká obrovská synergie, lidé jsou hrdí na svůj produkt, který je kvalitnější a je snazší ho měnit a přizpůsobovat požadavkům klientů. Podrobněji se každé z těchto oblastí budeme věnovat v samostatném článku. Těšte se – už zanedlouho!