Agile a automotive

Jak jste si možná všimli, agilní metodologie je ve světě vývoje softwaru současným trendem. Mnoho společností se při implementaci agilu odvrací od dříve hojně používaného waterfall modelu. V mém případě to bylo stejné. Pro našeho klienta pracuji už více než 2 roky. Waterfall byl používán v celé společnosti a všichni s ním byli spokojení. Pak přišlo rozhodnutí, že kompletně celá společnost přejde na agilní metodiku. Do plánování této změny se investovalo dost zdrojů. Pro nás jako testery to znamenalo v první řadě migraci veškeré naší práce z TFS do JIRY, která je jako nástroj pro agilní přístup vhodnější. Tento proces byl dlouhý a únavný, ale nakonec se nám podařilo mít v JIRE kompletně novou strukturu a začali jsme ho naplno používat. Tohle byl ale jen začátek...V tomto článku jsem pro vás sepsal s jakými dalšími překážkami či objížďkami jsme se na této cestě setkali, a jak se nám je podařilo překonat.

Co to vlastně agile je

Skutečnost, že máme v naší firmě školení o agilu a někteří z nás mají dokonce i certifikát ISTQB Agile Extension, nám přechod na novou metodiku značně usnadnila. Hlavní problém byl v tom, že prakticky všichni ostatní kolegové na projektu neměli vůbec žádné zkušenosti s agilním přístupem. Z tohoto důvodu společnost uspořádala několik školení, kde se všichni mohli dozvědět, o čem ten agile vlastně je.

Lidé zjistili, kdo je  Product Owner nebo Scrum Master, mohli se seznámit s tím, co je backlog a že práce je rozdělena do epiců, které jsou dále rozděleny do user stories. Na konci jsme se pokusili rozdělit některé epicy do user stories a odhadnout jejich náročnost pomocí planning pokeru. Nikdo nevěděl, co má dělat. Neměli jsme tušení, jak odhadnout user stories, jelikož jsme byli zvyklí pracovat pouze s manday. Nyní jsme nevěděli, kolik MD je jeden story point, takže jsme netušili, jaké číslo ukázat. To vedlo k masivnímu nadceňování nebo podceňování  user story.

Záchrana komunikace

V našem projektu jsou sprinty dlouhé dva týdny. V prvním sprintu (tento sprint jsme použili jako nulový, abychom se naučili základy) jsme nebyli schopni dodat téměř nic. Lidé z toho byli vystresovaní a začali mít o nové metodice pochybnosti. První retrospektiva, kterou jsme měli, byla velice negativní. Jedním z hlavních bodů byl systém odhadování náročnosti: „Jak můžeme odhadnout práci někoho jiného?“ zaznělo jako největší argument.

Náš Scrum Master se snažil všechny uklidnit, že je to jen začátek, že se všichni učíme s novou metodikou pracovat, a že to bude časem lepší a lepší. Dalším problémem byla komunikace. Musíte být schopni rychle a efektivně komunikovat, a protože jsme neseděli všichni v jedné místnosti (jak je u agilu obvyklé), stal se z toho problém. Snažili jsme se ho vyřešit pomocí komunikačního nástroje Slack a alespoň jedné koordinační schůzky týdně. Tyto dvě věci pomohly zlepšit komunikaci v našem týmu.

Boj s časem

Další velkou věcí, pokud jde o agilitu, jsou ceremonie. Denní stand-upy, plánování, demo, retrospektiva. Pro agilní projekt jsme byli dost velký tým (přes dvacet lidí rozdělených do dalších tří sub týmů). Byl tu však problém, jak to všechno časově skloubit. S tolika lidmi bylo prakticky nemožné dokončit všechny naše ceremonie včas. Mohli jsme mít plánovací okno na dvě a půl hodiny, ale plánování stejně trvalo okolo čtyř hodin. Bylo potřeba probrat každou user story s mnoha tasky pro každého člena týmu. Všichni z týmu měli svůj názor a své otázky ohledně konkrétní story.

Pak tu byly stand-upy. Rutinní proces, který by za normálních okolností neměl trvat déle než 15 minut. Každý den jsme měli stand-up, který ovšem trval 45 minut! Takto dlouhé stand-upy nám vzaly v součtu spoustu času, který jsme mohli využít k práci na konkrétním úkolu. Když tedy přišla další retrospektiva, všichni si na tuto časovou ztrátu stěžovali.

Zkrocení času

Proto bylo po nějaké době potřeba zavést optimalizační změny. Bylo rozhodnuto, že naše ceremonie budeme pořádat odděleně. Každý sub tým měl pak své vlastní ceremonie. Dva sub týmy, jejichž prací byl reporting, zůstaly v jedné místnosti, jenom odděleny, aby mohly lépe komunikovat a aby se jejich následná práce nepřekrývala. Tracking tým byl v další místnosti, protože i když patřily pod stejnou platformu, jejich činnost byla odlišná a obvykle tato činnost musela být provedena před prací Reporting týmu (práce Reporting týmu závisela na práci Tracking týmu).

Jak se později ukázalo, bylo to jedno z nejlepších rozhodnutí, jaké šlo tehdy udělat. Efektivita ceremonií prudce vzrostla. Tým, kde bylo najednou místo cca dvaceti lidí okolo osmi, si mohl lépe a efektivněji promluvit o tom co bylo skutečně potřeba udělat. Stand-upy začaly trvat jen asi 15-20 minut a ušetřený čas bylo možné věnovat vývoji.

Vyzkoušení nového přístupu

Další skutečnost byla, že jsme nebyli agilní ve svém nejčistším smyslu a znamenala, že jsme byli stále rozděleni na vývojáře, testery a analytiky. Moje práce byla pořád čistě testerská (tj. vytváření, údržba a samotná exekuce testovacích scénářů). Jelikož jsem byl seniorním testerem na projektu a měl jsem z kolegů největší znalosti o SQL, zaměřil jsem se hlavně na SQL skripty. Vedení JIRY (správa a údržba) byla na bedrech mého dalšího seniornějšího kolegy, jehož role by se u waterfall projektu dala nazývat test manažerem. Jelikož taková role v agilních týmech neexistuje, tak se tento kolega také zapojoval do přípravy a exekuce testovacích scénářů. Měli jsme i dva juniorské testery, kteří se učili SQL skripty a pomáhali vytvářet testy uživatelského rozhraní. Tento přístup fungoval dobře a v každém sprintu jsme mohli mít vše hotové.

Vytváření propracovanějších odhadů

S vylepšeným přístupem jsme se začali všichni více snažit. Abychom lépe pomohli odhadovat náročnost všech stories, vytvořili jsme referenční story (story, která leží přibližně uprostřed stupnice náročnosti a je vhodnou kandidátkou k porovnání s jinými stories). V našem případě jsme vzali všechny stories, které jsme doposud udělali, a znovu jsme odhadli jejich náročnost. Každý vzal jednu story a připevnil ji na tabuli s takovým počtem bodů, který považoval za optimální pro vybranou story. Pokud někdo další měl pocit, že to není úplně vyhovující, započala diskuze se zbytkem týmu o konkrétní story a za krátkou dobu jsme měli ohodnocené všechny story, které jsme do té doby udělali.

Nakonec zbylo jen pár konkrétních kandidátek. Vybrali jsme story, která měla všechny fáze vývoje - aktualizaci databáze, vývoj, testování. Tato zdánlivá maličkost pomohla lépe porozumět celému procesu odhadu náročnosti. Po tomto procesu byly naše odhady mnohem přesnější a díky tomu se i odpovídajícím způsobem zvýšila naše celková úspěšnost odhadů náročnosti.

Produktivita roste s každým sprintem

Lidé si zvykli na to, že by každý měl být online na Slacku a připraven odpovědět na jakoukoli otázku, která mu přijde. Musím zde vyzdvihnout práci našeho Scrum Mastera, který se velice snažil naučit novou metodiku a všem nám pomohl sžít se s novou metodologií práce. Jeho meetingy byly nakonec velmi organizované, naslouchal konkrétním potřebám týmu a věděl, co je nutné udělat. Celou dobu měl pravdu. Potom, co jsme si na nový způsob práce zvykli, začali jsme se zlepšovat. Bylo vidět, jak se do týmu vrací nadšení a lidé jsou navzájem přátelštější, protože vědí, že se na sebe mohou kdykoliv spolehnout. V následujícím sprintu jsme byli schopni splnit většinu našich tasků (nemohly být splněny pouze ty, které byly závislé na jiných týmech) a dokonce i některé tasky nad rámec plánu, které se vzaly z backlogu. Tým začal fungovat jako dobře namazaný stroj. Každý věděl, s kým mluvit, každý věděl, co má dělat, a kdy co dodat.

Závěr

Toto byl můj první agilní projekt, takže i když jsem věděl, co to agile je, co přináší a jak teoreticky může fungovat, nikdy jsem neměl šanci zažít to v praxi. Takže pro mě osobně byl přechod z waterffalu do agilu obtížnou, přesto velmi zajímavou zkušeností. Zjistil jsem, že strach z nového přístupu nebyl opodstatněný. Teď si myslím, že projekt funguje mnohem lépe, než kdykoli předtím, když jsme pracovali waterfall přístupem, a je dokonce i mnohem zajímavější. Pokud tedy s touto metodikou nemáte vůbec žádné zkušenosti, nebojte se ji zkusit, protože nakonec to stojí za to.