Během svého působení v oboru vývoje softwaru jsem byl svědkem týmů, které „nábožně“ přejímaly metodiky technologických gigantů typu Google nebo Spotify, v naději, že se jim podaří napodobit alespoň zlomek jejich úspěchu. Implementovaly inženýrské postupy společnosti Google nebo model týmů společnosti Spotify, aniž by vzaly v úvahu obrovské rozdíly v rozsahu, kultuře a obchodních potřebách. Tento přístup často vede k frustraci a rozčarování, když se nedostaví očekávané přínosy.
Je důležité si uvědomit, že ne každá organizace funguje ve stejném měřítku nebo má stejné zdroje jako tito giganti. Středně velký podnik, který se snaží napodobit autonomní týmy Spotify, může například narazit na problémy, když postrádá základní kulturu důvěry a vyspělého prostředí DevOps, které Spotify pěstuje.
Tato imitace se vztahuje i na nástroje. Nezřídka se stává, že se tým rozhodne pro distribuovanou architekturu microservices pomocí Kubernetes jen proto, že je to trend mezi předními technologickými společnostmi, a ignoruje přitom režii a složitost, kterou to obnáší. To může vést ke scénáři, kdy se tým potýká s provozními problémy distribuovaného systému, přestože by stačila jednodušší monolitická architektura.
Dalším příkladem je slepé přijetí mantry „move fast and break things“. To, co funguje u Mety s jejím rozsáhlým týmem inženýrů a robustní infrastrukturou, se může ukázat jako katastrofální pro firmu s menší uživatelskou základnou a omezenými zdroji na zvládnutí případných následků rychlých a nekontrolovaných změn.
Tyto zkušenosti zdůrazňují, že vývoj softwaru není jen o procesu, ale také o kontextu a porozumění. Skutečné přijetí procesu se vyznačuje hlubokým pochopením jeho principů a promyšlenou implementací, která zohledňuje jedinečný kontext týmu. Cargo kult se oproti tomu zaměřuje na replikaci na úkor porozumění, což vede k rigidní a neefektivní implementaci procesů.
Jak rozpoznat cargo kult a vyhnout se mu
Rozpoznat cargo kult není tak složité – stačí se zeptat „proč“. Proč právě tento postup? Proč používáme tento nástroj nebo metodu? Pokud odpověď zní „Protože to tak dělá úspěšný tým!“, a ne vysvětlení související s vašimi konkrétními potřebami, můžete mít co do činění s cargo kultem.
V kontextu životního cyklu vývoje softwaru (SDLC) se otázka „proč“ stává mocným nástrojem introspekce a zlepšování. Vezměme si například tým, který přijme určitou agilní metodiku, jako je Scrum nebo Kanban, jen proto, že slyšel, že dobře funguje u jiných úspěšných týmů. Mohou začít pořádat každodenní stand-up schůzky nebo vytvářet nástěnky Kanban, aniž by plně chápali důvody těchto postupů.
Předcházení cargo kultu začíná vzděláváním. Protilátkou proti cargo kultu je kultura zvědavosti a učení. Týmy se musí snažit pochopit principy, které stojí za postupy, jež přijímají. Klíčová je proto komunikace – pokládejte otázky, diskutujte o postupech a ujistěte se, že celý tým chápe „proč“. Týmy je třeba podporovat v tom, aby pochopily principy, které stojí za jejich nástroji a postupy.
Závěr
Cargo kult ve vývoji softwaru slouží jako varovný příběh, který nám připomíná důležitost porozumění před napodobováním. Na naší cestě vývojem softwaru se snažme kriticky zhodnotit své postupy, přijmout promyšlené osvojení procesů a odolat svodům cargo kultu. Pamatujme, že cílem přijetí procesu vývoje softwaru není jeho doslovné následování, ale usnadnění poskytování hodnoty – a toho nelze dosáhnout napodobováním. Vyžaduje to pochopení, přizpůsobení a neustálé zlepšování.
jsou povinná.