27. duben 2020 | Hlavní, Blog, Inspirujeme
Tento článek vznikl jako inspirace pro všechny vývojové týmy, které zvažují rozdělení vývojového týmu na menší jednotky a hledají třeba i důvody, proč to nejde. Nabízíme naši zkušenost jako hezký příklad toho, že někdy je možná lepší o věcech dlouho nediskutovat a jednoduše je udělat.
Na začátek pár základních informací o našem vývojovém týmu: vývojový tým, o kterém je řeč, čítá aktuálně 7 vývojářů, 3 QA, 3 product ownery, 1 UX designera, scrum mastra a vedoucího IT. Tým jede přes 2 roky ve scrumu na bázi 14denních sprintů. Vyvíjíme, rozšiřujeme a udržujeme ERP systém pro poskytovatele sociálních služeb CYGNUS 2.
Na začátku loňského roku, kdy jsme měli v týmu ještě o 3 vývojáře méně, jsme začínali narážet na první bariéry v agilním vývoji. Kromě plné zasedačky byly veškeré scrum ceremonie zdlouhavé a zapojení i udržení pozornosti členů schůzek vázlo. Každý vývojář věděl, kterým tématům ve sprintu by se měl věnovat, a ostatní body diskuze jej nezajímaly.
Tehdy proběhl první pokus o rozdělení týmu, kdy jsme cca 2 hodiny o možnostech rozdělení diskutovali a přiznejme si – hledali alibistické důvody, proč setrvat ve stávajícím stavu (co s testem, s code review, se stíháním sprintů). Po dvouhodinovém a bezúspěšném jednání jsme se shodli pouze na jediném, a to, že se o případném rozdělení týmů budeme bavit v menší skupině.
Od června nastoupil do týmu další vývojář a od srpna další dva nováčci a zasedačka začala být opravdu přeplněná. S nárůstem počtu lidí v týmu jsme začínali být neřiditelní a ceremonie byly ještě více únavné. Znovu jsme se tedy v září otevřeli otázku rozdělení týmu v užším kruhu (vedoucí IT, product owneři, scrum master a UXák) a hledali jsme možnosti (možná spíše opět problémy), jak tým optimálně rozdělit. Po několika hodinách ležely na stole 4 varianty rozdělení, ale všechny obsahovaly spoustu slepých cest a problémů.
Na následné retrospektivě na konci jednoho říjnového sprintu, který nedopadl úplně nejlépe, jsme otázku rozdělení opět otevřeli a týmu se zeptali, zda se nechtějí rozdělit a co by takové rozdělení pro všechny znamenalo. Tým návrh na rozdělení přijal velmi rychle a do hodiny vznikly tři menší týmy. Dokonce nás kolegové předběhli v tom, že se rozdělíme a rozdělili jsme se už od následujícího dne, tedy začínajícího sprintu.
Od druhého dne už jely tři samostatné minitýmy, kdy první má 4 vývojáře a product ownera (dlouhodobý vývoj), druhý minitým 2 vývojáře a product ownera (údržbový tým) a třetí 2 vývojáře a product ownera (dočasný tým na oddělený projekt). Nad všemi bdí testerský tým, UXák a scrum master.
Co nám rozdělení přineslo?
Každý tým má focus na téma, které se probírá.
Všechny schůzky jsou kratší a efektivnější.
Výkon týmu se zvýšil o 20 %.
Na hodinové retrospektivě se každý dostane ke slovu.
Product owner už nesdílí backlogy s ostatními product ownery.
Zvýšila se specializace na danou část produktu a snížil se počet dotazů na product ownera.
Sprintový board je přehlednější.
Cíl sprintu (sprint goal) dává celému týmu konečně smysl.
A máme více vzduchu - zasedačka je z poloviny prázdná.
Co musíme nově dělat a dříve jsme nemuseli?
Protože pracujeme na jednom produktu, rozdělení přineslo nutnost synchronizace technologických znalostí vývojářů napříč týmy.
Kde máme rezervy a co chceme v nejbližší době zlepšit?
Sdílený tým 3 testerek nemá pevně stanovenou dobu v jednom týmu, což částečně nabourává stíhání sprintů.
Chyby z produkce padají pouze do jednoho týmu (údržba). To znamená, že jeden tým dělá „to hezké“ a jeden řeší všechny chyby.
Protože se týmy rozdělily, je potřeba review dělat více detailněji.
I když je potřeba stále něco zlepšovat, pozitiva po rozdělení jednoznačně převažují nad negativy a chceme v práci v menších týmech dál pokračovat.
A co vy? Řešili jste, nebo řešíte něco podobného i u vás? Jaké jsou vaše zkušenosti? A jak byste poradili vyřešit QA tým? Budeme rádi za vaše nápady i připomínky.