Metodika EDPA v1.0.0 | EDPA v1.0.0

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. Upravená Fibonacci.	1, 2, 3, 5, 8, 13, 20
WSJF	Prioritizační skóre: (BV + TC + RR) / JS	Per úroveň nezávisle
CW	Contribution Weight — míra zapojení osoby na itemu. Nezávisle per osoba.	0.15–1.0
Evidence Score	Surový součet signálů aktivity z GitHub. Detekční vrstva.	Automaticky
RS	Relevance Signal — normalizovaný signál odvozený z Evidence Score.	Automaticky
Derived Hours	Odvozené hodiny, výstup modelu.	Po Iteration Close

Evidence Score je detekční vrstva → Relevance Signal je matematický vstup → Contribution Weight je podíl → Derived Hours jsou výstup.

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é)

Initiative

Epic

Feature

Story

Task

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

Úroveň	JS max	GitHub mapping
Epic	20	Issue Type: Epic
Feature	13	Issue Type: Feature
Story (2/10)	8	Issue Type: Story
Story (1/5)	5	Issue Type: Story
Task	—	Issue Type: Task

Nad limitem se item rozpadá. Granularity guardrails vynucují rozumnou granularitu.

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

BV — Business Value

TC — Time Criticality

RR — Risk Reduction

JS — Job Size

5. Model: Evidence-Driven Proportional Allocation

5.0 Iteration Planning Protocol

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 capacity.yaml.
Vypočítat Planning Capacity — Planning_Capacity = Σ Capacity[P, I] × planning_factor. planning_factor je vlastnost týmu (konfigurováno per tým v capacity.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.1 Vstupy

Vstup	Zdroj	Příklad
`Capacity[P, I]`	Potvrzeno při Iteration Planning	40h
`RelevantItems[P, I]`	Automaticky z GitHub evidence	6 items přes 3 úrovně
`JobSize[item]`	Custom field na issue	Fibonacci 1–20
`CW[P, item]`	Z evidence / manuální override	0.15–1.0
`RS[P, item]`	Normalizováno z Evidence Score	0.25–1.0

5.2 Evidence detection

GitHub signal	Evidence Score	Typický CW
Assignee na issue	+4	1.0 (owner)
Explicitní `/contribute` příkaz	+3	explicit
PR author referencující item	+2	0.6 (key)
Commit author s ref v message	+1	0.25 (reviewer)
PR reviewer	+1	0.25 (reviewer)
Issue / PR comment	+0.5	0.15 (consulted)

Threshold: Evidence Score ≥ 1.0
Heuristika: nejsilnější signál → výchozí CW
Override: /contribute @osoba weight:0.6
Commit count se nepřevádí na čas

5.3 Výpočet — dvě varianty

Auditní varianta (Full): Score[P, item] = JobSize[item] × CW[P, item] × RS[P, item] DerivedHours[P, item] = (Score[P, item] / ΣScores[P, I]) × Capacity[P, I]

Provozní varianta (Simple): Score[P, item] = JobSize[item] × CW[P, item] DerivedHours[P, item] = (Score[P, item] / ΣScores[P, I]) × Capacity[P, I]

Doporučení: začít provozní variantou. Evidence Score a RS zachovat ve snapshotu pro auditní obhajobu.

5.4 Matematická garance

Σ DerivedHours[P, item] = Capacity[P, I] Součet odvozených hodin je přesně kapacita osoby na Iteraci. Platí pro obě varianty. Vždy. Bez výjimky.

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. PM podhodnocen? Arch nadhodnocen?
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 Custom fields

Field	Typ	Hodnoty
Issue Type	Issue type	Initiative, Epic, Feature, Story, Task, Bug
Job Size	Number	Fibonacci 1–20
BV / TC / RR	Number	Fibonacci 1–20
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 GitHub Actions

#	Action	Trigger	Funkce
1	WSJF Calculator	Field change	Auto-výpočet WSJF
2	Contributor Detector	PR merge / review	Detekce kontributorů + evidence
3	Iteration Close	Manuální dispatch	Snapshot + výkazy (MD/JSON/XLSX) + per-item
4	PI Close	Manuální dispatch	Agregace iterací
5	Velocity Tracker	Iter/PI close	Velocity JSON + dashboard

9.3 Branch naming & DoR

feature/S-200-omop-parser
bugfix/S-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, Owner.

10. Výkazy a audit

10.1 Pipeline

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

/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:

GitHub delivery evidence
Capacity registry (YAML)
Frozen snapshot (reprodukovatelný vstup)
Reprodukovatelný výpočet (Score = JS × CW × RS)
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 v1

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 v1.0.0

Evidence-Driven Proportional Allocation. Hodiny se odvozují automaticky z GitHub delivery evidence (commity, PR, reviews). 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 v1	EDPA v1.0.0	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	6h	GitHub org, Projects setup, custom fields
Tyden 1	3 dny	Actions 1–2 (WSJF + Contributor Detector)
Tyden 2	2 dny	Actions 3–5 (Iteration Close + PI Close + Velocity)
Iterace 1	1–2t	Pilotní provoz, první výkazy, kalibrace CW
Retro PI 1	1 den	Kadence, CW accuracy, velocity, dual-view validace

EDPA — Evidence-Driven Proportional Allocation