Příklady

Reálné implementace a případové studie Velocity40 frameworku.

Příklad: FL3 výpočet pro 3 změny

Máme tři záměry:

  • Zavedení dvoufaktorové autentizace
  • Nový dashboard pro uživatele
  • Migrace databáze na novou verzi

Krok 1: Odhady EXI a EVI

Každý záměr se ohodnotí v Planning Pokeru (např. Fibonacciho řada: 1–2–3–5–8–13…).

  • EXI (Execution Index) = složitost, riziko, nejistota realizace
  • EVI (Evolution Index) = přínos, příležitost, hodnota do budoucna
Záměr EXI (složitost) EVI (přínos)
Dvoufaktorová autentizace 8 13
Dashboard pro uživatele 5 8
Migrace databáze 13 8

Krok 2: Výpočet poměru EXI/EVI

Vzorec:

Strategický poměr = EXI/EVI

Čím nižší poměr, tím lepší návratnost (málo složité × vysoký přínos).

Záměr EXI EVI Poměr EXI/EVI
Dvoufaktorová autentizace 8 13 0,62
Dashboard pro uživatele 5 8 0,63
Migrace databáze 13 8 1,63

Krok 3: Interpretace výsledků

  • Priorita 1: Dvoufaktorová autentizace (0,62) – vysoký přínos, relativně menší složitost.
  • Priorita 2: Dashboard pro uživatele (0,63) – skoro stejně výhodné jako 2FA.
  • Priorita 3: Migrace databáze (1,63) – složitější než je její přínos; spíš odložit nebo připravit podpůrné kapacity.

Výstup FL3: tým má jasné pořadí změn podle poměru EXI/EVI.

Na FL2 se pak bude dál rozpadat na segmenty (BVI/EFI), a na FL1 už na konkrétní úkoly v hodinách.




FL2 příklad: „Dashboard pro uživatele"

Krok 1: Rozdělení na menší části

Velký záměr (dashboard) rozdělíme na 3 segmenty:

  • UI komponenty (widgety, filtry, grafy)
  • Datové napojení (API, query, performance)
  • Notifikace a personalizace (uživatelské preference, alerty)

Krok 2: Odhad BVI a EFI

  • BVI (Business Value Index) = přínos pro uživatele/byznys
  • EFI (Effort Index) = odhad náročnosti práce

Použijeme opět Fibonacciho řadu (1–2–3–5–8–13…).

Segment BVI (hodnota) EFI (náročnost)
UI komponenty 13 8
Datové napojení 8 13
Notifikace a personalizace 5 5

Krok 3: Výpočet poměru BVI/EFI

Vzorec:

Koordinační poměr = BVI/EFI

Segment BVI EFI BVI/EFI Nutnost
UI komponenty 13 8 1,63 ANO
Datové napojení (minimální) 8 8 1,00 Ano
Notifikace 5 5 1,00 Ne
Export reportu do PDF/Excel 5 8 0,63 Ne

Krok 4: Interpretace výsledků

  • UI komponenty – ANO + nejlepší poměr
  • Datové napojení (minimální) – ANO (must-have)
  • Notifikace – rovnováha
  • Export reportu – nejnižší návratnost, může se odložit

Výstup FL2: víme, které části dashboardu mají největší návratnost úsilí.

Na FL1 pak tyto části převedeme na konkrétní úkoly v hodinách.




FL1 příklad: „UI komponenty" (z dashboardu)

Krok 1: Rozpad na úkoly

Segment rozdělíme na konkrétní úkoly, které mají max. 8 hodin (1 pracovní den).

Vyjdeme z představy, že budeme stavět základní dashboard se 3 hlavními widgety.

  • Návrh layoutu dashboardu (drátěný model, základní rozložení)
  • Implementace widgetu „Aktivní úkoly" (tabulka, filtry)
  • Implementace widgetu „Graf průběhu" (burndown / velocity)
  • Implementace widgetu „Poslední aktivity" (log, seznam změn)
  • Testování a UI ladění (cross-browser, základní UX)

Krok 2: Odhad v hodinách

Každý úkol má vlastníka a odhad v hodinách (max. 8h).

Úkol Odhad (h)
Návrh layoutu dashboardu 4 h
Implementace widgetu „Aktivní úkoly" 8 h
Implementace widgetu „Graf průběhu" 8 h
Implementace widgetu „Poslední aktivity" 6 h
Testování a UI ladění 6 h

Krok 3: Součet a kontrola kapacity

4+8+8+6+6=32 hodin

To odpovídá zhruba 1 týdnu kapacity jednoho člověka (40 h).

Zbývá rezerva 8h → může pokrýt nečekané úpravy nebo bugfixy.

Krok 4: Interpretace výsledků

  • Úkoly jsou dostatečně granularizované (každý max. 1 den).
  • Odhad je realistický, pokrývá ~1 sprint denního výkonu jednoho člověka.
  • Tým přesně ví, co má kdo dělat a kdy to může být hotové.

Výstup FL1: konkrétní plán práce na UI komponentách dashboardu – 32 hodin / 1 týden pro jednoho člověka.