Metodika EDPA v2.11.1 | EDPA v2.11.1

1. Shrnutí

Čas se neměří, odvozuje se. Nikdo neloguje hodiny. Nikdo nevyplňuje timesheets.

Člověk deklaruje kapacitu na období. Systém identifikuje work items, na nichž se prokazatelně podílel. Kapacita se ex post rozpadá poměrově mezi relevantní items podle Job Size a míry contribution.

Výsledkem je výkaz, který je vedlejším produktem dodávky, ne separátní administrativní aktivitou.

Model poskytuje dva komplementární pohledy na stejná data:

Per-person pohled: jak se kapacita člověka rozloží mezi jeho items → výkazy, timesheets
Per-item pohled: jak se práce na itemu rozloží mezi lidi → nákladová alokace, audit per deliverable

2. Terminologie

Pojem	Definice	Konfigurace
Iterace	Delivery cyklus. Stories se plánují, dodávají a uzavírají.	1t (AI-native) / 2t (klasicky)
Planning Interval	Plánovací cyklus. Features se plánují, koordinují a vyhodnocují.	5t (4+1 IP) / 10t (8+2 IP)
IP Iterace	Innovation & Planning iterace na konci PI.	Poslední iterace v PI
Job Size (JS)	Relativní odhad velikosti work itemu. Modifikovaná Fibonacci podle WSJF (SAFe 6).	1, 2, 3, 5, 8, 13, 20, 40, 100
WSJF	Prioritizační skóre: (BV + TC + RR&OE) / JS	Per úroveň nezávisle
CW	Contribution Weight — per-item normalizovaný podíl osoby na itemu (Σ napříč osobami = 1.0 na položce).	0–1.0
Signal Weight	Váha jednoho typu evidence signálu (`commit_author`, `pr_reviewer`, `issue_comment`), kterou agreguje `detect_contributors.py`. V configu pod klíčem `signals.*`.	`cw_heuristics.yaml`
Contribution Score	Σ vah fired signálů per (osoba, item). Vstup do per-item normalizace. V kódu jako `contribution_score`.	Automaticky
Derived Hours	Odvozené hodiny, výstup modelu.	Po Iteration Close

Signal Weight → Contribution Score (Σ vah fired signálů) → CW (per-item normalizovaný podíl) → Derived Hours.

3. Architektura modelu

3.1 Tři oddělené vrstvy

Vrstva	Účel	Kde žije
Operational Metadata	Živá delivery data	GitHub Issues + Projects
Capacity Registry	Kapacita lidi, role, FTE	YAML / JSON v repo
Evidence & Reporting	Frozen snapshoty, výkazy, podpisy	/snapshots, /reports, /signed

3.2 Source of truth

GitHub JE source of truth pro: issue hierarchy, ownership, status, Job Size, WSJF inputs, review trail, delivery audit trail.

GitHub NENÍ source of truth pro: hodinovou kapacitu, FTE, derived hours, podpisové stavy. Tyto žijí v evidence vrstvě.

4. Hierarchie work items

Initiative (celý projekt, business case)
  └── Epic (strategický cíl, 6-9 měsíců)
       └── Feature (musí se vejít do Planning Intervalu)
            ├── Story (dodáváno v Iteraci)
            │    └── Task (technická práce, volitelné)
            └── Defect (oprava, na úrovni Story)

Initiative

Epic

Feature

Story

Defect

Task

Každá úroveň má vlastní nezávislý Job Size a WSJF. Feature WSJF se nepočítá ze Stories pod ní.

Úroveň	Job Size rozsah	GitHub mapping
Initiative	1–100 (mod. Fibonacci)	Issue Type: Initiative
Epic	1–100 (mod. Fibonacci)	Issue Type: Epic
Feature	1–100 (mod. Fibonacci)	Issue Type: Feature
Story	1–100 (mod. Fibonacci)	Issue Type: Story
Defect	1–100 (mod. Fibonacci)	Issue Type: Defect
Task	— (sub-Story checklist)	Issue Type: Task

Modifikovaná Fibonacci škála (1, 2, 3, 5, 8, 13, 20, 40, 100) podle WSJF metodiky SAFe 6. Žádné fixní stropy per úroveň — granularita je odpovědnost týmu při refinementu. Při AI-asistované práci může být i Story s JS=20+ realisticky odpracovatelná v iteraci.

WSJF: (BV + TC + RR&OE) / JS BV = Business Value, TC = Time Criticality, RR&OE = Risk Reduction Počítá se per úroveň nezávisle.

BV — Business Value

TC — Time Criticality

RR&OE — Risk Reduction & Opportunity Enablement

JS — Job Size

5. Model: Evidence-Driven Proportional Allocation

5.1 Protokol plánování iterace

Než EDPA odvodí hodiny (ex-post), tým musí naplánovat iteraci (ex-ante). Plánování vyžaduje potvrzenou kapacitu jako vstup.

Potvrdit kapacitu — Každý člen týmu potvrdí dostupnost. Jde o závazek, ne odhad. Externí spolupracovníci vyjednávají alokaci explicitně. Výsledek: availability: confirmed v people.yaml.
Upravit kapacitu na iteraci (volitelné) — Jednorázové odchylky od baseline (PTO, přesčas, nábor) se zapisují jako per-iterace override do people: bloku iteračního YAML — command /edpa:capacity <iterace> --add --person <id> --hours …. Baseline capacity_per_iteration zůstává; engine použije override a vykáže capacity_baseline + capacity_override. Nastav před uzávěrkou (Stage 1 v /edpa:close-iteration).
Vypočítat Planning Capacity — Planning_Capacity = Σ Capacity[P, I] × planning_factor. planning_factor je vlastnost týmu (konfigurováno per tým v people.yaml pod teams:). Výchozí: 0.8.
Vybrat práci — Vytáhni stories z prioritizovaného backlogu (WSJF pořadí) dokud Σ JobSize nedosáhne historické velocity × planning_factor. Neplánuj na 100%.
Buffer — Zbylých ~20% absorbuje support, maintenance, incidenty a neplánovanou práci. Pokud buffer položky generují evidenci, EDPA je alokuje normálně.
Edge case — Pokud žádná neplánovaná práce nenastane, veškerá kapacita jde na plánované položky. Garance Σ = Capacity platí vždy.

Proč 80%? Plánování na 100% vynucuje jeden ze tří failure modes: nedodané stories, přetížení, nebo scope creep. Heuristika 80% je konzistentní se SAFe load factor, Scrum velocity-based planning a Kanban WIP limits. Různé týmy si mohou zvolit různé faktory podle svého support loadu a zralosti.

5.2 Vstupy

Vstup	Zdroj	Příklad
`Capacity[P, I]`	Potvrzeno při Iteration Planning	40h
`RelevantItems[P, I]`	Automaticky z GitHub evidence (Story Done + Feature/Epic/Initiative gates)	6 items přes 4 úrovně
`JobSize[item]`	Custom field na issue	Mod. Fibonacci 1–100
`cw[P, item]`	detect_contributors.py — additivní agregace + per-item normalizace	0–1.0 (Σ na itemu = 1.0)

5.3 Evidence detection

GitHub signal	Signal weight	Detekce
Commit author	4.00	Commit s S-/F-/E-/I-XXX v branchi/zprávě
PR reviewer	2.17	Schválený PR review (vyjma self)
Issue / PR comment	1.46	Komentář (boti vyloučeni)
`/contribute @osoba weight:X`	explicit	Manuální additivní signál — váha X z direktivy
`state_transition`	0	Status přechod (person/at/from→to) — analytics + delivery lead-time, nepřispívá do CW

Signály se sčítají additivně do contribution_score per (osoba, item) — žádný „highest wins"
Per-item normalizace dává cw share: cw = contribution_score / Σ_persons contribution_score
/contribute je rovnocenný signál — nepřepisuje auto-detekci, jen přidává váhu
Default váhy nahoře jsou kalibrované Monte Carlo simulací (1000 syntetických scénářů)

Bez per-role korekcí. CW se počítá výhradně signálovou agregací a per-item normalizací (viz § 5.4 níže). Strategická-role bias se řeší kalibrací signálových vah proti ground truth — pokud BO/PM/Arch dostávají málo, kalibrátor zvedne issue_comment a pr_reviewer váhy. Detail v auto-calibration.md.

5.4 Výpočet — single source, sum-and-normalize

contribution_score[P, item] = Σ signal_weight × signal_fired(P, item) cw[P, item] = contribution_score[P, item] / Σ_persons contribution_score[*, item] score[P, item] = JobSize[item] × cw[P, item] ratio[P, item] = score[P, item] / Σ_{items_of_P} score DerivedHours[P, item] = ratio[P, item] × Capacity[P, I]

CW je per-item podíl (Σ napříč osobami = 1.0 na položce), ne absolutní role-coupled hodnota. Signály sčítají additivně, normalizují se per-item, engine konzumuje hotové cw.
Příklad: Kalkulátor. Plná specifikace: methodology.md § 5.4.

5.5 Matematické garance (dvě)

1. Per-item: Σ_persons cw[*, item] = 1.0 2. Per-person: Σ_items DerivedHours[P, *] = Capacity[P, I] Obě platí strukturálně — z konstrukce sum-and-normalize aggregation a ratio normalizace per osobu napříč iteračními položkami. Engine je při běhu validuje a snapshot odmítne zapsat při porušení.

5.6 Co engine kredituje per typ položky

EDPA pracuje se 6 typy issues (S-, F-, E-, I-, D-, T-). Ne všechny se ale zahrnují do výpočtu hodin stejně:

Typ	Detekce evidence	Engine kredituje	Iteration filter
Story (`S-`)	ano	ano, jen `status==Done`	exact match (`PI-2026-1.1`)
Feature (`F-`)	ano	ano, Done + gate transitions	PI match (`PI-2026-1.x`)
Epic (`E-`)	ano	ano, Done + gate transitions	always (cross-PI)
Initiative (`I-`)	ano	ano, Done + gate transitions	always (cross-PI)
Defect (`D-`)	ano	ano, jen `status==Done`	always (cross-PI) — záměrně
Task (`T-`)	ano	ne — engine `tasks/` neprochází	n/a

Defect cross-PI je záměrné. Defekt se nemusí stihnout opravit v iteraci, ve které byl založen — může přetéct i přes hranici PI. Engine ho proto kredituje vždy v iteraci, kdy přejde do Done, bez filtru na původ. To zachycuje skutečnou délku trvání defektu jako evidenci.

Task není deliverable v EDPA modelu. Tasks jsou míněny jako sub-Story breakdown (checklist na issue), ne samostatná položka pro výpočet hodin. Pokud tým commit referencuje T-XXX, evidence se sice detekuje, ale engine pro tu práci nezíská žádný score — práce by se měla připojit k parent Story.

6. Dual-view CW: dvě otázky, jeden dataset

CW = 0.25 pro reviewera může znamenat dvě věci. Jsou to dvě různé otázky — model řeší obě ze stejných dat:

Per-person normalizace

Otázka: Jak se kapacita člověka P rozloží mezi jeho items?

DerivedHours[P, item] = (Score[P, item] / Σ Score[P, *]) × Capacity[P, I] Garance: Σ DerivedHours[P, *] = Capacity

Výstup: výkaz per osoba pro OP TAK

Per-item normalizace

Otázka: Jak se práce na itemu X rozloží mezi lidi?

ItemShare[P, item] = DerivedHours[P, item] / Σ DerivedHours[*, item] Garance: Σ podilu na itemu = 100 %

Výstup: nákladová karta per deliverable

Pohled	Otázka	Výstup	Garance
Per-person	Kolik hodin P strávil na čem?	Výkaz, OP TAK	Σ = kapacita
Per-item	Kolik lidí a hodin stál item X?	Nákladová alokace	Σ podilu = 100%

7. Konfigurace kadence

Varianta A: Klasická (2/10)

Cyklus	Délka	1.0 FTE	0.5	0.25
Iterace	2 týdny	80h	40h	20h
PI	10 týdnů	400h	200h	100h

Varianta B: AI-Native (1/5)

Cyklus	Délka	1.0 FTE	0.5	0.25
Iterace	1 týden	40h	20h	10h
PI	5 týdnů	200h	100h	50h

Doporučení: začít na A. Po prvním PI vyhodnotit přechod na B na základě velocity a lead time dat.

8. Učící smyčka

Velocity tracking

Story_Velocity = Σ JS uzavřených Stories / iterace Feature_Velocity = Σ JS uzavřených Features / PI Accuracy = Actual / Planned × 100 %

Kalibrace

CW: Po 2–3 iteracích vyhodnotit heuristiku. Rekalibrace signálových vah optimizérem /edpa:calibrate (Monte Carlo + coordinate descent, syntetický korpus).
Job Size: Referenční Story “3” ≠ Feature “3”. Per úroveň nezávisle.
AI: Vykazuješ čas na dodání, ne minuty kódu. AI → velocity, ne výkaz.

9. Implementace v GitHub

9.1 Native Issue Types & custom fields

EDPA je local-first: engine čte lokální git evidence a backlog YAML, GitHub vrstva je volitelná. Pokud tým GitHub používá, Issue Types jsou nativní funkce GitHubu na úrovni organizace (ne labels, ne custom fields). Spravují se přes issue_types.py setup --org <org>. Filtrování: type:Epic, type:Story atd.

Issue Type	Popis
Initiative	Business case, investiční záměr
Epic	Strategický cíl, 6-9 měsíců
Feature	Musí se vejít do Planning Intervalu
Story	Dodáváno v iteraci
Defect	Defekt v existující funkcionalitě
Task	Technická práce

Enabler je label klasifikace (Business vs Enabler), ne Issue Type. Epic může mít label „Enabler“ pro označení Enabler Epicu (SAFe).

Custom field	Typ	Hodnoty
Job Size	Number	Mod. Fibonacci 1–100
BV / TC / RR&OE	Number	Mod. Fibonacci 1–100
WSJF Score	Number	Auto (Action)
Planning Interval	Iteration	5 nebo 10 týdnů
Iteration	Iteration	1 nebo 2 týdny
Team	Single select	Týmové hodnoty
Primary Owner	Assignee	Accountable owner

Co nedržet jako GitHub field: Capacity, Derived Hours, FTE, podpisový stav → patří do evidence vrstvy.

9.2 Engine běží lokálně, GitHub vrstva je volitelná

V2 nemá pipeline GitHub Actions. Engine, výpočet WSJF, iteration/PI close i velocity běží lokálně přes /edpa:close-iteration a MCP nástroje. Atribuci řeší post-commit hook (local_evidence.py) — pro každý commit s referencí na EDPA item emituje commit_author, funguje i offline a na GitLab/Forgejo. Hooky se registrují do .git/hooks/, nebo — pokud projekt používá lefthook — přes vytištěný snippet do lefthook.yml.

Vrstva	Kde běží	Funkce
Engine + výpočet	Lokálně (`/edpa:close-iteration`)	Score, DerivedHours, snapshot + výkazy (MD/JSON/XLSX) + per-item
Atribuce	Lokální post-commit hook	`commit_author` z git historie pro každý item-referencující commit
Velocity	Lokálně (MCP `edpa_flow_metrics`)	Velocity a flow metriky z lokálních dat
Contribution sync (volitelné)	GitHub Action — `--with-ci`	`edpa-contribution-sync.yml`: po merge PR dopíše `pr_reviewer` + `issue_comment` z PR vlákna do `evidence[]`

Kdy nasadit --with-ci: jen když máte signály, které nežijí v git historii (PR reviews, komentáře) a chcete je započítat. Single-dev / review-light / off-GitHub týmy workflow přeskočí — local evidence stačí.

9.3 Timestamp pole

Každý backlog item nese tři timestamp pole (zapisuje engine při přechodech stavů; pokud tým používá GitHub, naplní se z issue):

Pole	Zdroj	Využití
`created_at`	Vznik položky	Cycle time start, item age
`updated_at`	Poslední změna položky	Freshness, řazení
`closed_at`	Přechod do Done	Cycle time end, throughput

Tato pole jsou vstupem pro flow metriky (§ 9.4). Žádný obousměrný sync ani řešení konfliktů — jediný zdroj pravdy je lokální YAML v repu.

9.4 Flow Metrics MCP tool

MCP tool edpa_flow_metrics poskytuje analytiku toku práce na základě timestamp polí:

Metrika	Výpočet	Využití
Cycle Time	`closed_at - created_at`	Jak dlouho trvá dodání položky
Throughput	Počet uzavřených položek / iterace	Prediktabilita, kapacitní plánování
Item Age	`now - created_at` (otevřené)	Detekce stagnujících položek

9.5 Branch naming & DoR

feature/S-200-omop-parser
defect/D-215-upload-validation
feature/F-102-anon-engine

CI check blokuje PR bez reference na issue (S-XXX, F-XXX, E-XXX). DoR: Issue Type, Parent, Job Size, BV+TC+RR&OE, Owner.

9b. ID kolize a renumbering (multi-developer setup)

EDPA alokuje ID lokálně (žádný centrální koordinátor) — pokud dva vývojáři současně vytvoří backlog item ze stejného počátečního stavu mainu, oba dostanou stejné ID (např. oba S-5). Kolize se projeví až při merge druhého PR.

4 vrstvy obrany detekují kolizi co nejdřív + poloautomatický recovery tool:

Vrstva	Kdy	Tool	Co dělá
5	local `git commit`	`validate_ids.py --staged` (pre-commit hook)	Blokuje commit pokud staged backlog má ID nekonzistence (filename ≢ id, missing fields, duplicity)
6	local `git push`	`validate_ids.py --pre-push` (pre-push hook)	Fetch origin, porovná lokálně přidané ID proti `origin/main`. Pokud ID už existuje na mainu → push BLOKOVÁN
7	PR open/sync (server-side)	`.github/workflows/edpa-collision-check.yml`	Spustí `renumber_collisions.py --check`. Při kolizi: comment na PR s instrukcemi + fail check (PR's merge button disabled)
Recovery	po conflictu	`renumber_collisions.py --apply`	Přejmenuje lokální file (`S-5.md → S-6.md`), přepíše `id:`, updatuje `parent:` reference v dependent items, bumpne counter

Standardní recovery flow

git fetch origin
python3 .edpa/engine/scripts/renumber_collisions.py --apply
# Detected 1 collision: S-5 → S-6
git add . && git commit -m "renumber(S-5→S-6): collision with main"
git merge origin/main   # resolve id_counters.yaml conflict (vezmi MAX hodnotu)
git push

Setup pro nový projekt (jednou):

python3 .edpa/engine/scripts/project_setup.py --with-hooks
cp .edpa/engine/templates/github-workflows/edpa-collision-check.yml \
   .github/workflows/

Plný guide s rozhodovacím stromem a běžnými typy kolizí (single / multi / parent-chain / cascading): docs/dev-collisions.md.

10. Výkazy a audit

10.1 Pipeline

/.edpa/snapshots/
  iteration-PI-2026-1.3.json          ← frozen snapshot

/.edpa/reports/
  iteration-PI-2026-1.3/
    vykaz-urbanek.md                   ← čitelný výkaz
    vykaz-urbanek.json                 ← strojová data
    summary.xlsx                       ← souhrnný Excel
    item-costs.xlsx                    ← per-item pohled

/signed/
  PI-2026-1.3-urbanek.pdf             ← BankID podepsaný

10.2 Freeze rule

Po Iteration Close: snapshot je frozen. Evidence se nepřepisuje in-place. Každá oprava je nová revize. Zásadní pro auditní obhajobu.

10.3 Auditni princip

Průkaznost stojí na 5 pilírich:

Lokální git delivery evidence (commit_author, yaml_edit, gate_events, story_activity)
Capacity registry (YAML)
Frozen snapshot (reprodukovatelný vstup)
Reprodukovatelný výpočet (Score = JS × CW; CW = additivní agregace + per-item normalizace)
Podepsaný výstup (BankID, zákon 21/2020 Sb.)

11. Předpoklady a rizika

Předpoklady

Všechny items se uzavírají (nedodané se přesouvají)
Kapacita potvrzena při Iteration Planning
Branch naming dodržen (CI check)
Job Size konzistentní per úroveň
CW se kalibruje po prvních iteracích

Rizika

Riziko	Mitigace
Auditor neuzná	Metodika + snapshoty + BankID
CW neodpovida	Override + kalibrace
Commit bez S-/F-/E-XXX	CI check blokuje PR
PM/Arch bez commitu	Comments + /contribute
0 items pro osobu	Procesní eskalace

12. Srovnání s alternativami

Fixed Split

Předem definované koše (např. 60% Dev, 20% Arch, 20% QA). Hodiny se rozdělují fixně podle role, nezávisle na skutečném příspěvku. Jednoduché, ale nepřesné.

EDPA v2.11.1

Evidence-Driven Proportional Allocation. Hodiny se odvozují automaticky z lokální git evidence (commity, yaml edits, status přechody, in-flight Story aktivita); GitHub Projects + Actions jsou volitelný doplněk. Matematická garance: Σ = Capacity.

Ruční timesheets

Každý člen týmu ručně vyplňuje hodiny. Subjektivní, administrativně náročné, nemá per-item pohled, neauditovatelné bez doplňkové evidence.

Vlastnost	Fixed Split	EDPA v2.11.1	Ruční timesheets
Fixované koše	Ano	Ne	Ne
Prázdné úrovně	Problém	Neexistují	N/A
Per-person pohled	Ano	Ano (primární)	Ano
Per-item pohled	Ne	Ano (dual-view)	Ne
Cross-funkční	Omezená	Plná	Plná
Automatizace	Střední	Vysoká	Žádná
Mat. garance	Složitější	Nativně	Ne

13. Implementační plán

Fáze	Čas	Obsah
Den 1	1h	`/edpa:setup` — vendoring enginu do `.edpa/engine/`, config (`edpa.yaml`, `people.yaml`), seed backlogu
Den 1 (volitelné)	30 min	`--with-hooks` (git hooky), `--with-ci` (contribution-sync workflow), `--with-rules`
Iterace 1	1–2t	Pilotní provoz, první výkazy z `/edpa:close-iteration`
Kalibrace	10 min	`/edpa:calibrate` — rekalibrace signálových vah po prvních iteracích
Retro PI 1	1 den	Kadence, CW accuracy, velocity, dual-view validace

EDPA — Evidence-Driven Proportional Allocation