Zametací tým a neplánovaná prace

Jedna z věcí, se kterou často bojují týmy, které se snaží adoptovat agilní vývoj (bez přívlastku), je neplánovaná práce. Obvyklá rada zní: rezervujte si čas na neplánovanou práci. Při odhadu pracnosti a kapacity týmu s tím počítejte. Já jsem tohle nikde neviděl fungovat bez ohledu na to jak dobrý ten tým byl. Když jsme dělali na začátku roku (možná dříve) re-organizaci týmu byla právě neplánovaná práce jedním z problémů, který nás nejvíce trápil. Neplánovaná práce se především rekrutovala z operativy kolem produkce ať již ve formě řešení složitějších problémů našich klientů, na které nestačilo oddělení péče o zákazníky a nebo technických zádrhelů podle hesla You build You run it. Podle telemetrie jsme viděli, že až 1/3 času se pálí na neplánované práci. Rozhodli jsme se proto o následující týmový setup.

V Zonky jsme měli tři 4–6 členné týmy (velikost není náhodná), které nebyly organizované kolem produktových částí, ale byly univerzální též nazývané T-Shaped. Poznámka na okraj k dělení podle produktových částí. Na tomhle setupu mi vadí nevyvážené rozložení práce a vznikání vědomostních sil. My jsme potřebovali přesný opak, se spoustou nových vývojářů šířit povědomí o celé aplikaci bez ohledu na to, že se tím vývoj zpomalí. Z těchto třech týmů vždy jeden tým dva sprinty (měsíc) hraje roli Zametacího týmu.

Zametací tým nemá planning a priorita jeho práce se řídí následujícími pravidly podle priorit (nechávám je v originále z naší Confluence)

1. Handling production issues during business hours (8/5) (pro-actively watching the #dev-production Slack channel).

2. Handling service desk tickets see Sweeper team dashboard

3. Supporting the back office (business) teams

4. Tickets from backlog. Tickets that are explicitly designated for sweeper team are marked with sweeper_backlog

5. Supporting QA, Test and Release automation initiatives — Jenkins, Tests environments, Docker etc.

Používáme Service desk, přes který k nám tečou všechny problémy z okolního světa. Přeci jenom jeho rozhraní pro zadávání ticketů je mnohem přívětivější než v JIRA. Všechny tickety, které v rámci něj vzniknou, jdou do kanálu ve Slacku, kde si je přebírá Zametací tým. Ten má klasický každodenní standup meeting, takže máme přehled o aktuálnosti dění. Pokud je Service desk prázdný resp. není co zametat — může se stát, že tam napadají feature požadavky, které si zaslouží planning — existuje backlog, do kterého dáváme drobnosti, které by bylo prima udělat. Pokud se ovšem nestihnou, nic se neděje, pořešíme to v rámci bug fixing day(s), ale o tom někdy příště. Kromě toho se vždycky najde spousta práce kolem ať již v oblasti automatizace a nebo podpory zbytku našich back office týmů neboť není větší motivace než když vývojáři vidí plody své práce naživo.

Absolutně nepřekročitelné pravidlo: Zametacímu týmu se nesmí za žádných okolností plánovat úkol, na kterém by cokoliv ve sprintu záviselo. Je to kapacita, kterou si držíte bokem pro případ jakékoliv neplánované práce.

Role zametacího týmu, díky tomu že je putovní, nikomu nijak zvlášť nevadí. Jsou vývojáři, kteří si v ní chrochtají blahem, ale i tací, kteří jsou rádi, že se po měsíci vrací do zaběhnutých kolejí. Díky tomu, že rotujeme celý tým, nemusíme řešit obsazení jednotlivých specializací a dále nám nezanikají automatismy, které v týmech přirozeně vzniknou.

Jediným zádrhelem je předávání rozdělané práce, které vzniká při rotaci týmů. U týmu, který zametání opouští je to jednoduché, protože by na něm nemělo nic produktového záviset — zametací věci se buďto předají následníkům a nebo se to naplánuje do dalšího sprintu — u týmu, který opouští produktový vývoj je to složitější. V případě velkých produktových změn jsme přistoupili k prodloužení turnusu zametacího týmu. Nemožnost rotace produktového týmu mimochodem pěkně ukazuje, že daná věc není pojatá agilně-iterativně. Menší úkoly se totiž lépe předávají resp. se na ně lépe navazuje. K iterativnímu vývoji a agilnímu přístupu patří feature flags, ale o službě LaunchDarkly, kterou k tomu používáme, vám povím někdy příště.