Transformace domény není hračka, ale existují přístupy, které ji zjednoduší!

Saša: Často si ani neuvědomujeme, že naše aplikace používají tisíce lidí 

01. 10. 2025

6 minut

V prostředí banky, které se mění rychleji než sazby hypoték, není snadné dlouhodobě udržet týmy, procesy a produkty v optimální kondici. Důkazem toho je i příběh domény Protection v České spořitelně, která se v posledních měsících vypořádává s pořádnou výzvou. Jaké přístupy jí při změně pomáhají, a co bylo třeba nastavit jinak?

Od izolovaných týmů k jednotné síle 

Doména Protection začínala v bance jako samostatný tribe, který měl tři E2E týmy podle typů pojištění. Tyto týmy se léta vyvíjely odděleně, až mezi nimi vznikly těžko překonatelné technologické i lidské bariéry. „Když nebylo dost práce, lidé jen řešili technologický dluh nebo odcházeli pracovat jinam, odkud se zpravidla už nevraceli,” popisuje Michal Pavlusek, který změnou domény prochází. 

Bylo jasné, že bez zásadní změny se doména dál nepohne. Proto se rozhodli odbourat překážky mezi týmy, sjednotit technologie, nastavit jeden společný backlog místo tří a postupně vytvořit jeden silný IT tým, který opět dokáže táhnout za jeden provaz. Tím začal příběh transformace, díky které se mohla doména vrátit zpátky na koleje. 

Shift-left

Testování a kontrola kvality se posunou na začátek vývoje. Díky tomu se problémy odhalí dřív, jejich oprava je levnější a celý vývoj je rychlejší a spolehlivější.

Specification by Example (SBE)

Způsob, jak popsat zadání pomocí konkrétních příkladů místo dlouhých technických dokumentů. Tým tak přesně ví, co má software dělat, a příklady se rovnou používají i pro testování.

Backlog

Seznam všech úkolů, které má tým před sebou. Úkoly jsou seřazené podle priorit, takže je vždy jasné, na čem se má pracovat nejdřív.

Potřeba změny   

Doména se rozhodla vydat vlastní cestou, načež bylo třeba ujasnit si směr, jakým se vydá, vyžádali si bankovní kouče, vytipovali klíčové lidi v doméně a pustili se do práce. „Velmi složitá byla změna mindsetu. Pokud tým nemá zkušenost s tím, jak takový způsob práce opravdu funguje, diskuse často končí jen u obav, proč to nejde,“ dodává Michal. Navíc každý tým měl jiný produkt, jiné složení, jinou velikost a řešil jiné problémy. 

Po dlouhém ladění priorit a přípravě školení se rozhodli přechod spustit, i když nebylo vše stoprocentně připravené. Všechny IT kapacity se převedly do jednoho velkého IT týmu přímo pod IT Domain Leada, zatímco business týmy zůstaly tři. Zrušili se původní squadové ceremonie a nahradila je celodoménová setkání. Právě ta se ukázala jako klíčová pro sdílení know-how a prolomení bariér mezi lidmi. 

Bez práce nejsou koláče 

První měsíce nebyly jednoduché. Každý sprint vypadal jinak než ten předchozí — sbírání zpětné vazby a neustálé upravování způsobu práce. Doména tak procházela nepřetržitou změnou. Zlom nastal v květnu, kdy mohla celá doména, včetně IT i businessu, absolvovat třídenní školení Shift-left s Karlem Smutným, zaměřené na Software engineering, Specification by Example (SBE), Trunk-based development, Test-driven development a další přístupy. „Bylo to to nejlepší, co jsme mohli v tu chvíli udělat. Problémy, které jsme tam řešili, byly přesně ty, se kterými jsme se už několik sprintů potýkali. Nakonec se z toho školení stal takový malý doménový teambuilding a zpětná vazba byla vynikající. Pozitivní se i ukázalo, že uchazeči ztratili obavy spolupracovat s kýmkoliv z domény,“ dodává nadšeně Michal.

„Tím se posiluje vazba mezi vývojovým týmem a zadavatelem z byznysu, ale také znalost problému uvnitř týmu.“

Nový přístup k plánování a spolupráci v doméně 

Změny po školení nastaly až s nejbližší celodoménovou retrospektivou, kde všichni členové domény připravili podněty, co chtějí využít z předchozích školení. Účastníci se následně rozdělili do čtyř pracovních skupin, které postupně začaly implementovat změny: 

  • Doménové review se sjednotilo do jednoho společného setkání pro všechny tři produktové squady. Nově se na začátku shrnuje agenda a sbírá zpětná vazba od stakeholderů, aby meetingy byly efektivnější. 

  • Stavba týmů a doménový planning: Jeden IT tým bude rozdělen na tři stejně velké, ideálně stejně silné a stejně zkušené týmy s různorodým know how produktů, přičemž týmy budou odbavovat doménový backlog od shora dolů dle seřazených priorit. Planning je rozdělen na dvě části – rozebrání ticketů podle priorit a jejich odhad náročnosti (Small, Medium, Large, XLarge). Pokud tým nestíhá dokončit všechny úkoly, ihned to hlásí a týmy se přeskupují podle priorit. 

  • Doménový refinement bude probíhat na třech „stanovištích“, kde prezentátor s největší znalostí problematiky představuje ticket třem nezávislým skupinám. Ty postupně analyzují a rozpadávají zadání, přičemž každá skupina navazuje na práci té předchozí. Skupiny se střídají a jsou náhodně sestavené, aby podporovaly spolupráci mezi týmy.  

Nejvyšší prioritou se stalo zavedení Specification by Example (SBE) jako nového přístupu k tvorbě zadání. Tým chce opustit detailní technické analýzy a místo toho vytvářet zadání pomocí příkladů, z nichž se budou generovat automatizované testy a dokumentace. 

Na otázku, jaké jsou hlavní přínosy SBE a jak vypadá školení v praxi, odpověděl Robert Batůšek, který v bance školení vede: „SBE posunuje vývojový tým od poslušného naplňovače zadání, které přichází odněkud shůry ke spolutvůrci. Využívá se hlavně na tzv. backlog refinementu, při kterém pro daný problém tým přichází s variantami řešení a potom jedno z těchto řešení zapíše pomocí příkladů. Tím se posiluje vazba mezi vývojovým týmem a zadavatelem z byznysu, ale také znalost problému uvnitř týmu.”  

Účastníci si na školení vyzkouší především práci s metodikou SBE na řadě praktických příkladů. Naučí se, jak zacházet s neúplným či rozporným zadáním, jak odhalit „bílá místa“ nebo konflikty a efektivně je předložit zadavateli k doplnění. Seznámí se také s konkrétními nástroji pro zápis příkladů, například s jazykem Gherkin v prostředí Cucumber, a zjistí, jak tyto specifikace následně propojit s automatizovanými testy.

Zajímá vás práce v IT?

Produktivita, priorita a kontext

V rámci zavádění změn v doméně zatím chybí konkrétní data o jejich dopadech. Očekávání jsou však jasná: zvýšení produktivity celé domény, práce zaměřená výhradně na skutečně prioritní úkoly a odstranění technických i produktových překážek. „Díky tomu budou mít IT týmy vše potřebné k tomu, aby mohly pracovat na tom, co je nejdůležitější,“ uvedl Michal. Kromě toho si týmy slibují i lepší zastupitelnost a minimalizaci předávání kontextu mezi rolemi, které často vede ke ztrátám informací. Refinementy po skupinách a přístup SBE by měly zajistit, že klíčový kontext budou chápat všichni stejně.

„Díky tomu budou mít IT týmy vše potřebné k tomu, aby mohly pracovat na tom, co je nejdůležitější.“

Zavádění změn jako SBE a Shift-Left není jednoduché ani univerzální. Podobně jako u psaní testů, i zde platí, že teorie nestačí a skutečné dovednosti přicházejí až praxí. Úspěch závisí na mnoha faktorech, jako je úroveň týmu, jeho seniorita, ochota ke změnám nebo struktura týmů. Důležité je se toho nebát, uzavírá Michal.

Mrkněte také na další příběhy zaměstnanců Spořky