Velvon debriefieng II. — Organizace vývoje
V tomto příspěvku se budu věnovat feature developmentu od nápadu až po rollout uvnitř jednoho týmu. Od začátku jsme chtěli mít tým a product ownera zodpovědného za návrh, provedení, rollout a správu toho co vyvinou. Features měly být vlastněný od začátku, kdy vzniká idea přes pilotní fázi ověření v podobě minimum testable produktu až po lovable pruduktu, product ownerem a to včetně rollout skrze feature toggles. Velkou výzvou byl vývoj a architektura mobilní aplikace včetně server API, které nutně potřebovaly.
Měli jsme tzv. feature týmy. Ty měly na starosti jednotlivé business domény v bance např. tým na platby, tým na úvěrové produkty, tým na onboarding klientů atd. Tyto týmy dokázaly připravit kompletně backend. Dále existoval mobilní tým, který měl na starosti vývoj iOS a Android aplikace pro mobilní bankovnictví. Mobilní tým byl sdílený pro všechny feature týmy, které neměly mobilní vývojáře. Feature týmy byly zodpovědné za poskytnutí use case oriented API, opak low level technického API, které mezi sebou používaly mikroslužby, viz. design pattern Backend for frontend (dále budu v textu používat zkratku B4F).
Výhoda přístupu s distribuovaným B4F do feature týmů spočívala v tom, že skutečně jedinou částí, která zůstala mimo plánovací kapacity a rozhodovací pravomoci týmu, byl vývoj samotné mobilní aplikace. V roce 2018 jsme internetové bankovnictví nezvažovali. Nevýhoda, alespoň v našem provedení, spočívala v tom, že feature týmy poskytovaly různá B4F API. Přesně podle vzoru každá ves jiný pes. Někdo REST, někdo RPC někdo GraphQL. To nebylo vůbec po chuti mobilním vývojářům, kteří museli pro různé části používat různá API, podle toho na čem zrovna pracovali. V zoologické zahradě API přístupů bylo složité vytvářet alespoň trochu sdílenou a znovupoužitelnou úroveň abstrakce, nad kterou by bylo možné stavět reaktivní UI.
Z tohoto důvodu jsem se rozhodl, že půjdeme cestou centralizované B4F služby. Výhody měly být právě v jednotném přístupu na úrovni API, který bude maximálně vyhovovat mobilnímu vývoji. Mobilní tým si s B4F týmem zvolili GraphQL, které se ukázalo jako správná volba. Obzvláště poté, co jsme se v půlce roku 2019 rozhodli začít s vývojem internetového bankovnictví. To mohlo plně využít existující GraphQL API.
Nejenom já, ale všichni jsme si byli vědomí faktu, že jsme technický problém vyměnili za organizační a plánovací problém. Najednou jsme měli mimo plánovací a rozhodovací kapacity feature týmů mobilní vývojáře i B4F tým. Tenhle problém jsme chtěli vyřešit tím, že jakmile najdeme svatý grál toho, jak dělat dobře mobilní API a vybudujeme celou infrastrukturu kolem B4F, umožníme feature týmům kontribuovat do B4F dle modelu interního open source ala Spotify.
Budoucnost vypadala růžově. Alespoň než jsme se začali zaobírat real time chováním aplikace. Původní architektura používala na pozadí push notifikace, kterými se aplikace dozvěděla o tom, že se na backendu něco stalo a přes API si stáhla data. Nebylo to ani spolehlivé ani rychlé.
Začali jsme proto zvažovat WebSockets, ale s nimi byl tehdy problém v infrastruktuře Azure. David Vávra, tehdy náš lead Android developer, přišel s myšlenkou změnit mobilní architekturu a posunout jí reaktivním směrem. Zkoušeli jsme různé služby a nakonec jsme si vybrali Google Firestore, o kterém jsme se zmiňoval v prvním díle.
Google Firestore byl správná volba, ale každý chléb je o dvou kůrkách. Čím dál tím více bylo jasné, že zmiňovaná kontribuce z feature týmů do B4F bude složitá. Architektura postavená na jednoduchém principu HTTP request-response, se kterým má zkušenosti každý vývojář, se změnila CQRS architekturu. Feature týmy dokázaly provádět jednoduché změny, ale cokoliv složitějšího obhospodařoval B4F tým.
Organizačně a z pohledu plánování to bylo složité. Feature tým A s product ownerem X se musel dohodnout s mobilním týmem a B4F týmem. Jedna story se groomovala minimálně třikrát ve feature týmu, v B4F týmu a ještě v mobilním týmu. Protože B4F tým a mobilní týmy (iOS, Android) byly sdílené a tudíž úzká hrdla, muselo dojít k centrálnímu plánování a prioritizaci. Mobilní a B4F kapacita byla každých 14 na příděl. Na koho se nedostalo, ten si mohl maximálně chystat backend, se všemi negativy, které přístup per partes — dělam backend a teprve potom frontend — přináší.
Chtěli jsme, aby měl product owner kompletní kontrolu nad celou feature — backend, mobilní (iOS, Android), internetové bankovnictví a B4F. Tento model jsme vyzkoušeli s týmem, který pracoval na onboardingu nových klientů a s týmem, který pracoval na úvěrovém produktu. Prostě jsme do těch týmů doplnili vývojáře s daným skillsetem — iOS, Android a B4F pokud bylo potřeba. Chtěli jsme s touto transformací pokračovat dále. V čem byl problém?
Všechny týmy se po nějaké době sehrály a vytvořily si vlastní modus operandi (řízení, QA, forma groomingů, odhady, příprava a forma stories v JIRA, retrospektivy) a kulturu, ve které fungovaly. Jakýkoliv zásah by byl velmi citlivý ať už bychom šíbovali s vývojáři jakkoliv. Zvažovali jsme mít model core mobilního týmu a guildu mobilních vývojářů. Všichni mobilní vývojáři by byli v guilde, abychom zachovali sdílení informací core vs features, a chodili by na omezenou dobu do feature týmů a vraceli se zpět. Chtěli jsme to ověřit v pilotní fázi na dalších týmech, ale bohužel k tomu již nedošlo.
V hlavě mi stále vrtá, jakým způsobem to šlo udělat lépe a kladu si otázku zdali bylo možné mobilní aplikace, internetové bankovnictví včetně patřičného server API (GraphQL + Google Firestore) vyvíjet a testovat distribuovaně ve více týmech a koordinovat pouze její release a rollout v app store. S tím je spojená celá řada otázek, na které by bylo třeba odpovědět.
- Jak řídit architekturu aplikace, případně zavádět konvence a pravidla, kterými by se vývoj řídil. Příklad? Zřejmě by nebylo šťastné, aby jeden tým by používal MVVM pattern a jiný tým MVP pattern.
- Feature týmy neměly v každém sprintu stejný workload pro mobilní vývojáře. Musel by existovat backlog technických aktivit nebo by musely vývojáři pomoci v jiných týmech.
- Výrazný nárůst headcountu (iOS, Android, web, zastupitelnost) vedoucí k větším feature týmům a s tím spojená komplexita scrumové rutiny.
- On-call support (pohotovost) za v podstatě sdílenoucode base B4F mikroslužeb poskytujících server API (GraphQL + Google Firestore)
Uznávám, není to příběh se šťastným koncem. Pokud vás téma organizace engineeringu zajímá doporučuji články od Nick Tune.
- Product-aligned vs Capability-aligned Organisation Design
- Should We Create a Shared Service? A Decision-making Checklist
- Organisational Dysfunctions Mirrored as Architectural Complexity
A samozřejmě https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/
