Pět tech­nik agilního řízení, které fungují

Česká spořitel­na právě prochází další vlnou agilní trans­for­ma­ce, s čímž sou­visí řada školení a webinářů. V tom­to šestidíl­ném ser­iálu se podíváme na něko­lik oblastí, které jsou pro zdařilou proměnu large-scale vývo­je soft­waru stěže­jní, a podrob­něji je roze­bereme.

Lidé v týmech by se měli méně ori­en­to­vat na své konkrét­ní role a aktiv­i­ty, naopak by měli být otevřenější celku. Čas­to ve fir­mách vídám, že pokul­hává jed­na 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šich­ni navzá­jem čeka­jí nebo něk­do dělá věci, které nej­sou potře­ba, pro­tože zrov­na nic jiného neumí. Scrum staví na tom, že lidé v týmu při­j­mou zod­pověd­nost nejen za to, co sto­jí na jejich viz­itce, nýbrž za celek.
Že zač­nou spolupra­co­v­at mno­hem úže­ji, navzá­jem mezi sebou.
To vyžadu­je, aby se učili i věci, které v popisu práce nema­jí, a zároveň byli v co nejčastějším kon­tak­tu s uži­vatelem – opět všich­ni. Né že s klien­tem komu­niku­je jeden prostřed­ník a ten pak infor­ma­ce tlu­močí (čti: zkres­lu­je) ostatním.

Scrum zná sko­ro každý, nebo o něm ale­spoň slyšel. Jenomže větši­na lidí, které znám, ho zaži­la nato­lik pokřiveně, že ho vní­ma­jí neg­a­tivně. Jako byste šli za špičkovým dietolo­gem, který vám dá sadu doporučení pro zdravý živ­ot nebo hub­nutí, jenže vy si z toho vyzo­bete jen to, co vám sedí. Kaž­do­den­ní cvičení? To se mi nechce. Omez­it sacharidy? Ale což, večerní dortík si přece neode­přu. A pak byste si stěžo­vali, že odborníkovy rady nefun­gu­jí a vy nehubnete.

V malém týmu lze scrum nas­tavit celkem snad­no, a komu se to poved­lo, výz­nam­ně z toho těží. Těžkosti ale přicháze­jí u týmů velkých. Intu­ice velí rozdělit velký pro­dukt na malé zahrád­ky a každý tým ať si pracu­je na té své. Tím ovšem vznika­jí obrovské neefek­tiv­i­ty, které nikdo pořád­ně nevidí.

Když velká skupina lidí pracu­je na složitém řešení, napřík­lad bankovním pro­duk­tu, je nes­mírně přínos­né, když spolu pravidel­ně komu­niku­jí všich­ni navzá­jem a ale­spoň do určité míry zna­jí všech­ny (větši­na) týmy celé řešení (nebo ale­spoň více než jed­nu zahrád­ku). Výhodou pak je, že jakko­liv se v čase mění pri­or­i­ty, celá velká skupina je schop­na je násle­dovat. Pokud je ale celek rozdělený na malé zahrád­ky, na nichž si každý okopává jen svůj záhonek, vel­mi čas­to se stává, že lidé pracu­jí na totál­ních zbytečnos­tech. A ani o tom nevědí, pro­tože nema­jí ponětí o zbytku mimo svou zahrád­ku. Neza­jímá je to. Firmy takhle nezříd­ka vyhazu­jí velké peníze. Právě tohle je jed­na z věcí, která čas­to drhne. Nechce se nám cvičit, pře­s­tat pít pivo a jíst slad­kosti. Jenomže když to dokážeme a prvot­ní nepo­hodlí překonáme, mohou se dít zázraky.

V tom­to ser­iálu se chci věno­vat pěti nejdůležitějším prak­tikám v large-scale vývo­ji. V něk­terých jde o typ­icky měkké doved­nos­ti, v jiných o tvrdé, další jsou kom­bi­nací obou. Na co se v dalších dílech můžete těšit?

Spec­i­fi­ca­tion by exam­ple spočívá na dvou pilířích. Celé pro­duk­tové týmy komu­niku­jí pří­mo s uži­vatelem, aby všich­ni porozuměli jeho potře­bám ste­jně. Poté společně vymys­lí řešení a zapíšou ho for­mou tzv. speci­fikace přík­la­dem. Konkrét­ní kroky, konkrét­ní hod­no­ty, konkrét­ní výsled­ky. Tak každý lépe pochopí, jak se má nová funkčnost cho­vat, a zároveň je snad­né proměnit speci­fikaci v autom­a­ti­zo­vaný test, který nám kdyko­liv ověří, že se soft­ware stále chová, jak bylo zamýšleno. 

Trunk-based devel­op­ment nutí všech­ny vývo­jáře inte­grovat svůj kód do hlavní větve kaž­dou půl­hod­inu, né jed­nou za 14 dní na kon­ci sprintu. Kdyko­liv se něco rozbi­je, 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 fun­go­va­lo, i s nedokončený­mi funkčnos­t­mi. Vyžadu­je to samozře­jmě vysoké pokry­tí testy. 

Refac­tor­ing je čin­nost, která probíhá neustále, niko­liv nára­zově. Ve světě vývo­je pro­duk­tů se kód neustále mění, pro­to musí být snad­né ho v první řadě přečíst. Opět to vyžadu­je dobré pokry­tí testy. Doufám, že začíná být zře­jmé, že tech­ni­ka spec­i­fi­ca­tion by exam­ple má přínos nejen v propo­jení celého týmu s uži­vateli, ale i ve vytvoření záchyt­né sítě auto­mat­ick­ých testů. 

Kon­te­jner­izace vývo­jového prostředí. Na velkých pro­duk­tech býva­jí vývo­jová prostředí složitá a je dobré, aby měl každý vývo­jář a každý tým ste­jné. Namís­to zdlouhavých a nepřes­ných wiki stránek je tren­dem celé prostředí strčit do kon­te­jneru. Týmy se tak mohou soustřed­it na vývoj namís­to řešení nas­tavení svého PC.

Def­i­n­i­tion of done je kon­cept, který popisu­je, co všech­no se musí stát, aby­chom konkrét­ní kus funkčnos­ti mohli považo­vat za hotový, začít ho použí­vat nebo pře­dat klien­tovi. Vytváří to trans­par­ent­nost napříč týmem i poža­davky na kval­i­tu, která se pak snáze dlouhodobě udržuje.

Každá z těch­to pěti tech­nik má své nes­porné ben­e­fi­ty sama o sobě. Když se ale spo­jí dohro­mady, není výsled­ný efekt krát pět, nýbrž na pátou! Vzniká obrovská syn­ergie, lidé jsou hrdí na svůj pro­dukt, který je kval­it­nější a je snazší ho měnit a přizpů­sobo­vat poža­davkům klien­tů. Podrob­něji se každé z těch­to oblastí budeme věno­vat v samostat­ném článku. Těšte se – už zanedlouho!