hledat

Začněte vyhledáváním výše

  1. Domů
  2. Články
  3. Přeměna domény není hračka, ale existují přístupy, které ji zjednoduší!

Přemě­na domény není hrač­ka, ale exis­tu­jí přís­tupy, které ji zjednoduší!

Anna Holzmannová
Přeměna domény není hračka, ale existují přístupy, které ji zjednoduší!

V prostředí banky, které se mění rych­le­ji než saz­by hypoték, není snad­né dlouhodobě udržet týmy, pro­cesy a pro­duk­ty v opti­mál­ní kondi­ci. Důkazem toho je i příběh domény Pro­tec­tion v České spořitel­ně, která se v posled­ních měsících vypořádává s pořád­nou výzvou. Jaké přís­tupy jí při změně pomáha­jí a co bylo tře­ba nas­tavit jinak?

Od izolo­vaných týmů k jed­not­né síle  

Domé­na Pro­tec­tion začí­nala v bance jako samostat­ný tribe, který měl tři E2E týmy podle typů pojištění. Tyto týmy se léta vyví­je­ly odd­ěleně, až mezi nimi vznikly těžko překonatel­né tech­no­log­ické i lid­ské bar­iéry. ​„Když neby­lo dost práce, lidé jen řešili tech­no­log­ický dluh nebo odcházeli pra­co­v­at jinam, odkud se zpravid­la už nevraceli,” popisu­je Michal Pavlusek, který změ­nou domény prochází. 

Bylo jas­né, že bez zásad­ní změny se domé­na dál nepohne. Pro­to se rozhodli odbourat překážky mezi týmy, sjed­notit tech­nolo­gie, nas­tavit jeden společný back­log mís­to tří a pos­tup­ně vytvořit jeden sil­ný IT tým, který opět dokáže táh­nout za jeden provaz. Tím začal příběh přeměny, díky které se mohla domé­na vrátit zpátky na koleje. 

Nezmeške­jte žád­né novinky ITT

Potře­ba změny  

Domé­na se rozhod­la vydat vlast­ní ces­tou, načež bylo tře­ba ujas­nit si směr, jakým se vydá, vyžá­dali si bankovní kouče, vytipo­vali klíčové lidi v doméně a pustili se do práce. ​„Vel­mi složitá byla změ­na mind­se­tu. Pokud tým nemá zkušenost s tím, jak takový způ­sob práce oprav­du fun­gu­je, diskuse čas­to končí jen u obav, proč to nejde,“ dodává Michal. Navíc každý tým měl jiný pro­dukt, jiné složení, jinou velikost a řešil jiné problémy. 

Po dlouhém ladění pri­or­it a přípravě školení se rozhodli pře­chod spustit, i když neby­lo vše sto­pro­cent­ně připravené. Všech­ny IT kapac­i­ty se převed­ly do jed­no­ho velkého IT týmu pří­mo pod IT Domain Lea­da, zatím­co busi­ness týmy zůstaly tři. Zrušili se původ­ní squadové cer­e­monie a nahradi­la je celodoménová setkání. Právě ta se ukáza­la jako klíčová pro sdílení know-how a pro­lomení bar­iér mezi lidmi. 

Bez práce nej­sou koláče  

První měsíce neby­ly jednoduché. Každý sprint vypadal jinak než ten před­chozí — sbírání zpět­né vaz­by a neustálé upravování způ­sobu práce. Domé­na tak procházela nepřetrži­tou změ­nou. Zlom nastal v květ­nu, kdy mohla celá domé­na, včet­ně IT i busi­nes­su, absolvo­vat tří­den­ní školení Shift-left s Kar­lem Smut­ným, zaměřené na Soft­ware engi­neer­ing, Spec­i­fi­ca­tion by Exam­ple (SBE), Trunk-based devel­op­ment, Test-dri­ven devel­op­ment a další přís­tupy. ​„Bylo to to nejlepší, co jsme mohli v tu chvíli udělat. Prob­lémy, které jsme tam řešili, byly přes­ně ty, se který­mi jsme se už něko­lik sprintů potýkali. Nakonec se z toho školení stal takový malý doménový team­build­ing a zpět­ná vaz­ba byla vynika­jící. Poz­i­tivní se i ukáza­lo, že uchazeči ztratili obavy spolupra­co­v­at s kýmko­liv z domény,“ dodává nadšeně Michal. 

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

Změny po školení nastaly až s nejbližší celodoménovou ret­ro­spek­tivou, kde všich­ni člen­ové domény připrav­ili pod­ně­ty, co chtějí využít z před­chozích školení. Účast­ní­ci se násled­ně rozdělili do čtyř pra­cov­ních skupin, které pos­tup­ně začaly imple­men­to­vat změny: 

  • Doménové review se sjed­noti­lo do jed­no­ho společného setkání pro všech­ny tři pro­duk­tové squady. Nově se na začátku shrnu­je agen­da a sbírá zpět­ná vaz­ba od stake­hold­erů, aby meet­ingy byly efektivnější. 

  • Stav­ba týmů a doménový plan­ning: Jeden IT tým bude rozdělen na tři ste­jně velké, ideál­ně ste­jně sil­né a ste­jně zkušené týmy s různorodým know how pro­duk­tů, přičemž týmy budou odbavo­vat doménový back­log od sho­ra dolů dle seřazených pri­or­it. Plan­ning je rozdělen na dvě části – roze­brání tick­etů podle pri­or­it a jejich odhad náročnos­ti (Small, Medi­um, Large, XLarge). Pokud tým nestíhá dokončit všech­ny úkoly, ihned to hlásí a týmy se přeskupu­jí podle priorit. 

  • Doménový refine­ment bude probíhat na třech ​„stanovištích“, kde prezen­tá­tor s největší znalostí prob­lematiky před­stavu­je tick­et třem nezávis­lým skupinám. Ty pos­tup­ně ana­lyzu­jí a roz­padá­va­jí zadání, přičemž každá skupina navazu­je na prá­ci té před­chozí. Skupiny se stří­da­jí a jsou náhod­ně ses­tavené, aby pod­porovaly spoluprá­ci mezi týmy. 

Nejvyšší pri­or­i­tou se sta­lo zave­dení Spec­i­fi­ca­tion by Exam­ple (SBE) jako nového přís­tupu k tvor­bě zadání. Tým chce opustit detail­ní tech­nické analýzy a mís­to toho vytvářet zadání pomocí přík­ladů, z nichž se budou gen­erovat autom­a­ti­zo­vané 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 posunu­je vývo­jový tým od poslušného naplňo­vače zadání, které přichází odněkud shůry ke spo­lutvůr­ci. Využívá se hlavně na tzv. back­log refine­men­tu, při kterém pro daný prob­lém tým přichází s vari­anta­mi řešení a potom jed­no z těch­to řešení zapíše pomocí přík­ladů. Tím se posilu­je vaz­ba mezi vývo­jovým týmem a zada­vatelem z byzny­su, ale také znalost prob­lé­mu uvnitř týmu.” 

Účast­ní­ci si na školení vyzk­ouší přede­vším prá­ci s metodik­ou SBE na řadě prak­tick­ých přík­ladů. Naučí se, jak zacházet s neú­plným či roz­porným zadáním, jak odhalit ​„bílá mís­ta“ nebo kon­flik­ty a efek­tivně je před­ložit zada­vateli k doplnění. Seznámí se také s konkrét­ní­mi nástro­ji pro zápis přík­ladů, napřík­lad s jazykem Gherkin v prostředí Cucum­ber, a zjistí, jak tyto speci­fikace násled­ně propo­jit s autom­a­ti­zo­vaný­mi testy. 

Pro­duk­tivi­ta, pri­ori­ta a kon­text 

V rám­ci zavádění změn v doméně zatím chy­bí konkrét­ní data o jejich dopadech. Očekávání jsou však jas­ná: zvýšení pro­duk­tiv­i­ty celé domény, práce zaměřená výhrad­ně na skutečně pri­or­it­ní úkoly a odstranění tech­nick­ých i pro­duk­tových překážek. ​„Díky tomu budou mít IT týmy vše potřeb­né k tomu, aby mohly pra­co­v­at na tom, co je nejdůležitější,“ uvedl Michal. Kromě toho si týmy slibu­jí i lep­ší zas­tupitel­nost a min­i­mal­izaci předávání kon­tex­tu mezi role­mi, které čas­to vede ke ztrátám infor­ma­cí. Refine­men­ty po skupinách a příst­up SBE by měly zajis­tit, že klíčový kon­text budou chá­pat všich­ni stejně. 

Zavádění změn jako SBE a Shift-Left není jednoduché ani uni­verzál­ní. Podob­ně jako u psaní testů, i zde platí, že teorie nes­tačí a skutečné doved­nos­ti přicháze­jí až praxí. Úspěch závisí na mno­ha fak­torech, jako je úroveň týmu, jeho seniori­ta, ocho­ta ke změnám nebo struk­tu­ra týmů. Důležité je se toho nebát, uza­vírá Michal. 

Mohlo by vás také zajímat

Přeměna domény není hračka, ale existují přístupy, které ji zjednoduší!