Softwarový tým

Paměť pro vývojový tým

Jak tým 5 vývojářů používá UAML k zachování kontextu rozhodnutí, technického dluhu a lessons learned.

Problém

Každý vývojový tým zná situaci: nový člen přijde a ptá se „Proč jsme to udělali takhle?" — a nikdo neví. Klíčová rozhodnutí se ztrácejí v Slacku, JIRA tiketech a hlavách lidí.

Ztráta kontextu — ADR (Architecture Decision Records) píše málokdo
Opakování chyb — technický dluh se hromadí, protože nikdo neví proč
Onboarding trvá měsíce — nový vývojář nemá přístup k „tribal knowledge"
Rozhodnutí bez důkazů — „To jsme rozhodli na standupu v prosinci" — ale kde je zápis?

Řešení s UAML

Federation — každý vývojář má vlastní UAML instanci. Týmová vrstva se synchronizuje, osobní poznámky zůstávají privátní. Knowledge sharing bez ztráty soukromí.

                # Záznam architektonického rozhodnutí

                uaml.learn(

                    "Zvolili jsme PostgreSQL místo MongoDB protože potřebujeme

                    ACID transakce a relační integrita je pro billing kritická.",

                    topic="adr",

                    tags="database,billing,rozhodnutí",

                    data_layer="team"

                )

                # Za 6 měsíců — nový vývojář se ptá

                vysledky = uaml.search("proč PostgreSQL")

                # → Přesný kontext rozhodnutí + kdo ho udělal

Co tým ukládá

ADR — architektonická rozhodnutí s odůvodněním
Technický dluh — proč je ten hack v kódu a kdy ho opravit
Lessons learned — co se pokazilo a jak jsme to vyřešili
Onboarding znalosti — „Jak nastavit dev prostředí", „Kde jsou credentials"
Retrospektivy — závěry ze sprintů s akcemi

Výsledky po 3 měsících

🚀 Onboarding z 3 týdnů na 1 týden — nový člen najde vše v UAML
📉 Méně opakovaných chyb — lessons learned jsou hledatelné a propojené
🧠 Odolnost proti odchodu — když vývojář odejde, znalosti zůstávají
📊 Lepší retrospektivy — data-driven, ne „pocitové"