Řízení backlogu: jeden seznam práce s prioritou

Řízení backlogu je způsob, jak udržet všechnu čekající práci (úkoly, nápady, nálezy z kontrol a otázky) v jednom seznamu s jasnou prioritou. Ve vývoji přibývá práce z mnoha stran, a když každý proud žije jinde (v e-mailu, v tabulce, v hlavě), část práce se ztratí a jiná se udělá dvakrát. Pak nikdo neumí říct, co je teď nejdůležitější. V článku ukážu, jak práci na vývoji Bondie držíme v jednom seznamu, jak se z něj určuje priorita a jak každá změna kódu nese stopu k úkolu.

Řízení backlogu – jeden seznam, víc zdrojů

Backlog je seznam všeho, co čeká na práci. U nás má čtyři zdroje:

• úkoly z plánu (roadmapy), seřazené po krocích k první verzi pro zákazníka,
• nápady, které přišly během práce a čekají na zařazení (jedna věta s datem); do seznamu práce se dostanou až jako úkol z plánu,
• nálezy z testů a z oponentury, kterou dělají AI agenti v rolích, každý s body a stavem (jak testy nálezy hledají, popisuje článek Testování finančních výpočtů),
• otázky na majitele produktu, vždy s doporučenou variantou.

Každý druh má svůj zdroj, kam se zapisuje. Seznam práce se z nich skládá a ručně se nikdy neupravuje. Kdyby šlo položku změnit v seznamu i ve zdroji, vznikly by dvě pravdy, a to je přesně problém, který popisuji v článku Jeden zdroj pravdy. Ostatní zásady vývoje shrnuje článek Zásady vývoje software.

Nápad bez zápisu neexistuje. Další den si ho nikdo nevybaví, takže se zapisuje hned, i když se na něj dostane až za měsíc. Zápis ale není závazek: nápad zůstává ve svém zdroji a do seznamu práce vstoupí, až když ho majitel produktu zařadí do plánu jako úkol.

Priorita se odvozuje z pravidel

Ruční přidělování priorit má dvě slabiny. Každý považuje svou věc za nejdůležitější a priority časem zastarají. Proto se návrh priority odvozuje z pravidel:

• P1 teď: rozpracovaný úkol a další krok k první verzi, chyba s nejvyšším dopadem (peníze, daň, zákon, data),
• P2 brzy: ostatní kroky k verzi, otázky na majitele, na kterých verze závisí, nálezy s dostatkem bodů,
• P3 později: zbytek, včetně otázek, které na nejbližší verzi vliv nemají.

Body nálezu se počítají z dopadu, četnosti a ceny opravy (jak přesně, popisuji v článku Oponentura v rolích). Ruční značku priority jde přidat do zdroje, když je pro ni důvod (např. termín u daňového poradce). Pravidla a body tedy připraví návrh, rozhoduje ale člověk: pořadí práce v plánu mění jen majitel produktu a ostatní (včetně AI agentů, kteří kontroly dělají) jen navrhují.

U každé položky je navíc vidět, kdo je na tahu: vývoj, nebo majitel produktu. Seznam pak neslouží jen k plánování, ale i k tomu, aby bylo jasné, na koho se čeká.

Backlog v číslech

Ke dni psaní článku (10. 10. 2026) bylo v seznamu práce 32 + 33 + 72 = 137 otevřených položek (úkoly, otázky a nálezy); aktuální stav ukazuje stránka Vývoj v číslech:

Vidíme, že prioritu „teď“ měly jen čtyři úkoly. To je záměr. V praxi platí, že když je v P1 dvacet věcí, není teď nic a práce se rozpadne. Většina nálezů je v P3, tedy jde o drobnosti, které se udělají při práci v dané oblasti. Nezařazené nápady (558 − 242 = 316 bez závazku) v seznamu práce nejsou, jinak by v nich úkoly zapadly. Zbylých 242 nápadů se do plánu dostalo jako úkoly a většina z nich je už hotová, proto je otevřených úkolů jen 32.

Práce ve vlnách a kolize

Práce jde ve vlnách: vlna práce (několik úkolů za sebou), pak stabilizace celku, pak sloučení do hlavní větve. Nápad, který přijde během vlny, se zapíše, ale do práce vstoupí až mezi vlnami. Výjimkou je chyba v hotové funkci, ta se opravuje hned (v tomto případě vlna počká).

Před zařazením úkolu se kontrolují kolize: sahá na stejná data, obrazovky nebo výpočty jako jiný úkol? Pokud ano, nejdřív se postaví společný základ jednou a oba úkoly ho použijí. U větších věcí (např. nový výpočet nebo nový modul) předchází zařazení krátká analýza hodnoty a složitosti. Co nemá hodnotu vzhledem ke složitosti, se nedělá.

Každý commit má úkol a funkci

Úkol má jednu hlavní funkci z katalogu produktu. Kdyby se týkal víc než tří funkcí, rozdělí se. Každý commit, který mění aplikaci, pak na konci nese štítky:

oprava: <co se změnilo>
Úkol: <číslo úkolu z plánu, nebo nález>
Funkce: <hlavní funkce, další dotčené>
Verze: <rozsah | dopad | oprava | pokyn>
Changelog: <věta pro uživatele, nebo „ne“>

Commit se změnou aplikace bez štítků kontrola při ukládání odmítne. Díky tomu umíme ke každé funkci dohledat, které změny ji měnily, a ke každé změně, proč vznikla. Věta pro uživatele se rovnou sbírá do seznamu změn příští verze, takže ho před vydáním nikdo nepíše z paměti.

Verze a její rozsah

Co do rozpracované verze patří, určuje jeden soubor s rozsahem (seznam úkolů, které verze má obsahovat). Stav verze (kolik je hotovo, co zbývá) se z něj počítá. Štítek u commitu říká, jestli změna patří do rozsahu, nebo je mimo: nutná souvislost s úkolem v rozsahu (štítek „dopad“), drobná oprava, nebo výslovný pokyn majitele.

Podíl práce mimo rozsah sledujeme. Když roste, verze se rozpadá do drobností a ztrácí směr. Pro první verzi pro zákazníka máme měřitelnou bránu: žádný otevřený nález s vysokým dopadem, žádná nerozhodnutá otázka v penězích a právu, zelená stabilizace a odsouhlasení daňovým poradcem a právníkem.

Hygiena backlogu

Seznam, do kterého se jen přidává, za pár týdnů přestane být užitečný. Po každé dávce kontrol proto proběhne hygiena. Dělá ji AI agent v roli, jakou ve scrumu má scrum master: nic nemění, jen navrhuje. Hledá:

• duplicity, tedy stejný nápad nebo nález zapsaný dvakrát z různých stran,
• nález, který už má úkol a nemá se řešit podruhé,
• hotový úkol s visícím nálezem (úkol je odškrtnutý, ale nález, kvůli kterému vznikl, zůstal otevřený),
• staré položky a přetížení P1, tedy víc položek „teď“, než jde opravdu dělat najednou.

Pravidlo, které z toho plyne: úkol je hotový, až když jsou uzavřené i nálezy, které na něj byly předané. Každý dostane záznam „opraveno“ s commitem a testem, nebo se změní na nápad či nový úkol.

Otázky na majitele produktu

Vývoj se nemá zastavit kvůli otázce, nicméně odpověď je potřeba dostat včas. Otázky proto jdou dávkově a každá má doporučenou variantu na prvním místě s důvodem. Ptáme se jen na skutečná rozhodnutí, tedy změnu chování pro uživatele, oprávnění, peníze, soulad se zákonem nebo cokoli nevratného. Technické drobnosti rozhodne vývoj a zapíše, proč.

Když otázka po dohodnuté době zůstane bez odpovědi, platí pracovní předpoklad podle doporučení. Je zapsaný a jde vrátit. Rozhodnutí majitele se zapisují s datem a důvodem, aby se stejná otázka nekladla dvakrát.

Závěr

Úkoly, nápady, nálezy a otázky mají své zdroje a seznam práce se z nich skládá, ručně se needituje. Priorita se odvozuje z pravidel a v P1 má být jen pár položek. Pořadí práce mění jen majitel produktu a každý commit nese úkol, funkci a vztah k verzi. V den psaní článku měly prioritu „teď“ čtyři úkoly ze 137.