Vývoj software je obtížná disciplína a ve většině organizací čelí spoustě problémů – opakované změny v architektuře, technologiích i na trhu, neuvědomovaný boj s Conwayovým zákonem, systémy, které přerostly jeden tým, časté reorganizace, zmatené množství delivery frameworků atd.

Podle autorů knihy organizacím chybí rozumný model práce, který neignoruje lidský a týmový rozměr a dbá na přiměřenou kognitivní zátěž. V této knize pak takový model navrhují.

#knihy
@knihy

https://blog.wuwej.net/2024/01/04/matthew-skelton-manuel-pais-team-topologies.html

@wuwej @knihy Možná relevatní ke zmíněné knize?

https://www.linkedin.com/posts/vaughnvernon_teamtopologies-dddesign-activity-7148042660056870912-65lQ?utm_source=share&utm_medium=member_desktop

@janbartosik pročetl jsem, ale úplně nevím, proti čemu se vymezuje. Asi proti některým argumentům zvenčí - kniha neřeší monolit versus microservices a myslím že ani nucené dělení (jenom) podle kognitivní zátěže.

@segedacz Tak dobře zavedená korporace dokáže semlít cokoliv, co si budem povídat 🙃.

@wuwej @knihy základní myšlenková chyba, kterou autoři Team Topologies dělají, je v pojmu "týmová kognitivní zátěž". Vycházejí z pojmu "kognitivní zátěž (jednotlivce)", která znamená, jak moc je můj mozek PRÁVĚ TEĎ zatížen, když řeším nějaký složitý problém. Tato zátěž samozřejmě má horní limit. Oni z toho ovšem vyvozují, že existuje i horní limit pro množství kódu, které jednotlivec (a potažmo i tým) zvládnou spravovat, což je ovšem úplně něco jiného.

@batusek Asi v tom je rozdíl, ale rozhodně bych neřekl, že je to základní myšlenková chyba. Okamžitá kognitivní zátěž souvisí mírou znalostí, kterou už mám, a množství znalostí které mám (které aktivně udržím) zase ovlivní množství kódu, které zvládnu spravovat.

(Znám to z praxe víc než dobře, tým se zodpovědností za desítky systémů se utápí v operativě, údržbě, snaze udržet informace o tolika různorodých systémech, nemožnosti je rozumně posouvat atd. atd. 🤷‍♂️)

@wuwej pořád to vnímám jako dvě různé věci. Když mám hodně znalostí, úkol zvládnu rychleji. Ale kognitivní zátěž mi u toho může vyletět na maximum. Zároveň z toho, že jedu na maximální zátěž, nevyplývá, že víc znalostí už se mi do hlavy nevejde. Což autoři tvrdí - že na tohle je limit - a tím pádem jediný způsob jak se to dá řešit je rozsekat velkou codebase na kusy a zavést vlastnictví kódu - neboli tzv. komponentové týmy. Za je to myšlenková chyba.

@batusek Ok, asi nepoužili správný pojem (neuvědomuju si, jestli to tam takhle popsali, dohledával jsem si definici kognitivní zátěže až teď).

Ale když tomu budu říkat třeba "informační přetížení", tak to pořád vede k rozdělování a následným týmovým topologiím (a že tam strop je, to vidím denně).

Čili uznávám, že dělají myšlenkovou chybu s pojmem, ale neshledávám v tom žádné zpochybnění knihy/topologií.

@wuwej dobrá debata. Já v tom právě to zpochybnění knihy vidím. Autoři se snaží ukázat, že nějaký strop existuje a dělají to tak, že si ukradli pojem z psychologie, kde ten strop dokázaný. Nicméně strop pro množství znalostí neexistuje, resp. je hodně dynamický.
Takže když vidím, že jednotlivec/tým se blíží k nějaké hranici, tak nemusím jenom rozdělovat produkt/codebase, aby náhodou tu hranici nepřekročili, ale můžu se pokusit tu hranici posunout, což má úplně jinou dynamiku.

@wuwej Například:
- můžu snížit množství technologií / programovacích jazyků, aby se tým rychleji orientoval
- můžu zvýšit pokrytí testy, aby měl větši jistotu, když dělá refaktoring
- můžu snížit časový tlak a dát jim víc času na naučení
atd.
Rozdělení produktu na komponentové týmy je jenom jedno z opatření, které má nějaké dost zásadní následky. Například se hodně špatně vrací zpátky. A dost časo není nutné. Viděl jsem týmy běžně fungovat v codebase která měla statisíce až miliony řádků kódu.

@batusek Jo, dobrá debata, díky za ni.
S tím stropem, musím to lehce poupravit - ono to zní jako kdyby byla nějaká hranice, do které to je dobré, a od ní už průšvih. Ale tak to není, je to spíš jako stále houstnoucí prostředí. Čím hlouběji (dál za hranicí), tím je všechno větší problém. K dynamičnosti - ok, jasně, všechna ta opatření mohou hranici posunout, nebo když použiju svůj příměr, "zředit prostředí". Když je jeden produkt, klidně s velkou codebase, nemusí to nutně být na rozdělení.

@batusek Moje optika knihu potvrzuje, ale já jsem v extrémní situaci, kdy nejde o jeden produkt, ale desítky produktů nebo velkých komponent s řadou různých technologií. Potom žádné opatření moc nepomůže, protože už jenom rozumět byznys fungování všech produktů je příliš mnoho
- snížit množství technologií / jazyků - ok, pro tým bude jednodušší, ale byznys znalosti se nezmenší
- pokrytí testů - ok, vývoj bude méně rizikové, ale byznys znalosti se nezmenší

@batusek - snížit časový tlak - každý produkt má svůj tlak, mnoho produktů, mnoho tlaku, málo šance na prosazení

Takže možná na to koukám natolik nekriticky, jak kritickou situaci vídám.

Každopádně, pokud správně rozpoznáme, že jsme za hranicí, pak jsou topologie dobrá cesta, ne? Nebo je tam ještě nějaká další chyba?

@wuwej podle mě nejsou. Je to na delší povídání, ale komponentové týmy (např. "enabling" nebo platformové nebo subsystémové) vedou k mnoha dysfunkcím, např. k efektu "všichni jsou zaneprázdnění, ale nic se nedoručuje". Doporučuju k přečtení něco z LeSSu, např. https://less.works/less/structure/feature-teams nebo https://www.amazon.com/Scaling-Lean-Agile-Development-Organizational/dp/0321480961, kapitola "Component Teams" od strany 155.

@batusek Aha, ok. Z pohledu scrumu, i škálovaného, jsou všechny tři ostatní typy týmů špatně a všechno je zvladatelné ve feature týmu. Teoreticky to chápu a stoprocentně tomu fandím. prakticky ovšem často vidím nepřekonatelné překážky (korporace v agilní transformaci).
Ať už v situaci kdy po vzniku feature / produktových týmů leccos zbyde, nebo tým potřebuje nějakou službu jednou za rok a proniknout do ní by stálo násobně víc než si ji nechat dodat od platformového týmu.

@batusek A ano, je to něco za něco, takže platformový tým může být a často je bloker. Tahat všechno dovnitř zase vede k riziku snižování kvality a nutnosti mít silné community of practice, component mentory atd., což se zase obtížně udržuje v chodu.

S další diskuzí už bych musel být konkrétní, což pochopitelně nemůžu, takže asi budeme pomalu končit 🤫.

(K LeSSu jsem četl https://blog.wuwej.net/2019/06/06/craig-larman-bas-vodde-large-scale-scrum.html)