Evidence-Driven Proportional Allocation · v2.11.1
Čas se neměří — odvozuje se
EDPA v2.11.1 nahrazuje ruční timesheety odvozením hodin z
lokální git evidence — post-commit hook, yaml edits,
status přechody. Gates mode credituje každý gate (LBC,
design, refinement) a in-flight Story credit zachytí
rozdělanou práci ještě před uzavřením Story. GitHub není
potřeba — volitelná integrace je jen PR-signal contribution-sync
(PR review / komentáře → evidence[]), ne zdroj pravdy.
Timesheety
Zero
Žádné ruční logování
Gates stabilita
0.35 pp
spread pod ±20 % CW (100 MC runs)
Evidence
Local-first
git hooks + log, žádný cloud lock-in
Kalibrace
Monte Carlo
68 000+ záznamů, p<0.001
Novinky
Co je v EDPA v této vlně
PI planning / overview (v2.4)
/edpa:pi-planning vyrenderuje celý SAFe program board
(týmy × iterace, šipky závislostí), PI cíle, ROAM, portfolio, WSJF
a kapacitu do jednoho self-contained HTML — bez
serveru, bez Node, bez sítě. Read-only projekce z .edpa/,
deterministicky regenerovatelná. Závislosti přes
edpa_item_link_dep (s detekcí cyklů).
Gates mode (default)
Engine credituje každý Initiative/Epic/Feature status přechod jako mini-deliverable. Architekti a PM jsou kreditováni za LBC, design a refinement práci napříč gates — ne jen za finální Done. Validováno na 4 PI × 2 iterace simulaci.
In-flight Story credit
Stories v iteraci, které se ještě nedotáhly do Done, dostanou
credit dle yaml_edit aktivity v okně (refinement, AC, DoD).
story_activity_events[] v edpa_results.json
ukazuje které Story dostaly credit a s jakým credit_factor.
Production ready
541 unit testů, 6 E2E proti reálnému GitHubu, 100 Monte Carlo runs
(avg MAD 7.8 % vs ground truth, spread 0.35 pp pod ±20 %
perturbací). Plný operační runbook v
docs/RUNBOOK.md.
Kontext
Proč potřebujeme EDPA?
Nepřesnost
Ruční timesheety jsou subjektivní. Lidé odhadují, zaokrouhlují, zapomínají. Data neodpovídají realitě.
Auditní noční můra
Při kontrole OP TAK nelze zpětně prokázat, kdo na čem pracoval. Chybí evidence, chybí průkaznost.
Administrativní zátěž
Vyplňování výkazů zabírá čas, který by mohl jít do vývoje. Nikdo nemá rád timesheety.
Žádný per-item pohled
Tradiční systémy ukazují pouze osobní výkazy. Kolik stál konkrétní deliverable? Nelze zjistit.
Řešení
Jak EDPA funguje
Systém se skládá ze tří oddělených vrstev, které spolupracují na automatickém odvození pracovních hodin.
Operational Metadata
.edpa/backlog/ YAML · Git
Hierarchie, status, Job Size, WSJF jako YAML frontmatter v repo — jediný zdroj pravdy. Git je audit trail; GitHub není potřeba.
Capacity Registry
YAML config v repo
Kapacita, role, FTE. Potvrzeno při Iteration Planning. Jediný manuální vstup do systému.
Evidence & Reporting
/snapshots · /reports · /signed
Frozen snapshoty, výkazy, BankID podpisy. Immutable a auditovatelné.
Detekce evidence
Signály z gitu (a volitelně GitHubu)
EDPA čte evidence primárně z lokálního gitu:
post-commit hook (a idempotentní /edpa:materialize) zapisuje
commit_author, yaml_edit a state_transition
přímo do evidence[] v YAMLu. Engine je čistý reader —
konzumuje materializovanou evidenci, git při výpočtu už nečte. Volitelný CI workflow může
navíc emitovat pr_reviewer a issue_comment z GitHubu.
Každý signál přidává váhu do contribution_score per (osoba, item);
výsledné CW = score / Σ_persons score (Σ na položce = 1.0).
| Signál | Váha | Zdroj | Popis |
|---|---|---|---|
commit_author | 4.00 | local hook | Commit s S-XXX/F-XXX/E-XXX/I-XXX — post-commit emit |
manual:commit_message | explicit | local hook | /contribute @osoba weight:X v commit body |
yaml_edit:* | 0.5–5.0 | local hook / materialize | block_add, list_grow, scalar_change, create — structural backlog edits (revert −0.5) |
gate_event | js × weight | local hook / materialize | F/E/I status přechod (LBC → design → refinement → Done) |
story_activity | js × 0.40 | engine | In-flight Story s yaml_edit signály v okně |
state_transition | 0 | local hook / materialize | Status přechod (person/at/from→to) — analytics + delivery lead-time, nepřispívá do CW |
pr_reviewer | 2.17 | optional CI | Schválený PR review (volitelný GitHub Actions workflow) |
issue_comment | 1.46 | optional CI | Komentář na issue/PR (volitelný workflow, boti vyloučeni) |
Signály se sčítají additivně; není „highest wins". Default váhy nahoře jsou kalibrované Monte Carlo simulací (1000 syntetických scénářů). Lokální git hook + engine pokrývají běžný delivery flow; CI workflow je čistě opt-in doplněk, ne závislost.
Dual-View analytika
Dva pohledy, jeden dataset
Per-Person
Jak se kapacita člověka rozloží napříč položkami?
Výkaz pro OP TAK
Per-Item
Kolik lidí a hodin stál item X?
Nákladová alokace per deliverable
Klíčové vlastnosti
Proč EDPA funguje
Zero manual input
Žádné timesheety. Výkaz je vedlejší produkt dodávky. Tým pracuje, systém počítá.
Matematická garance
Σ DerivedHours = Capacity. Vždy. Proporcionální alokace zajišťuje konzistenci.
Dual-view analytika
Per-person výkazy pro reporting. Per-item nákladové karty pro management. Jeden dataset.
Audit-grade (BankID)
Frozen snapshoty + BankID podpisy. Právně silnější než papírové výkazy.
Self-tuning
Karpathy loop: compare → adjust → repeat. Kalibrováno Monte Carlo simulací (68 000+ záznamů).
Git-native, GitHub-friendly
Evidence z lokálního gitu (žádný cloud lock-in). GitHub je
volitelný: jediná integrace je PR-signal contribution-sync
(--with-ci), která PR review a komentáře materializuje
do evidence[]. Pro board slouží lokální
/edpa:board HTML — žádný Projects sync.
Prozkoumejte EDPA
Dashboard, case study, prezentace, metodika i evaluace — vše na jednom místě.