Kapitola 16: Jak vývoj probíhá a co se čeká od vás

Rozdíl je v tom, kdy se dozvíte špatnou zprávu

Při vodopádovém přístupu se nejdřív celý systém popíše, pak vyvine a nakonec předá. Nejvíce se zapojujete na začátku a na konci a problém se často ukáže až při převzetí. Britská vládní příručka varuje, že takhle můžete 18 měsíců stavět službu, která už neodpovídá politice, technologii ani potřebám uživatelů GDS, agilní vývoj.

Při agilním vývoji vidíte kus fungujícího softwaru po každém krátkém cyklu, orientačně každé 1–4 týdny. Rizika odhalíte brzy, musíte však průběžně rozhodovat a software zkoušet.

Pozor na agilní nálepku na vodopádu

Nejčastější past je „agilní vývoj“ s pevným dvousetstránkovým zadáním a fixní cenou. Nebo agilní smlouva bez vlastníka produktu na straně zákazníka. Česká adaptace příručky 18F říká, že když se dodavatel hlásí k agilnímu přístupu, ale každou změnu řeší dodatečnou objednávkou, „mělo by se vám v hlavě rozsvítit červené světlo“ Česko.Digital, 2022.

Agilní vývoj lze s pevným smluvním rámcem sladit čtyřmi způsoby:

1. pevný rozpočet a termín, proměnlivý rozsah,
2. platba za odpracovaný čas se stropem,
3. fixní cena za MVP, další etapy jako opce,
4. platba za převzatý přírůstek, který splní Definition of Done.

Který způsob se hodí pro váš projekt a jak nastavit cenu, rozebírá kapitola 10.

Kolik času to bude stát vás

Vlastník produktu má být váš zaměstnanec, ne člověk dodavatele Česko.Digital, 2022. Rozhoduje o prioritách, odpovídá na dotazy a přebírá hotové části. Je jako stavebník, který na stavbu chodí každý den: když chybí, zedníci buď čekají, nebo staví podle sebe. Rozhodování výborem a vlastník produktu „na 10 % vedle své práce“ jsou typické brzdy. Pevná cena vlastní řízení nenahradí: u digitalizace stavebního řízení měla smlouva pevnou cenu i termín, a přesto projekty podle právní části auditu neměly obsazené některé role předepsané metodikou ministerstva Audit DSŘ, právní část, 2025 (víc v kapitole 20).

Jmenujte vlastníka produktu ještě před podpisem smlouvy, písemně potvrďte, kolik času mu na projekt uvolníte z jiné práce, a dejte mu mandát: o čem rozhoduje sám a co musí předložit řídicímu výboru. Klíčové uživatele vyberte z lidí, kteří práci opravdu dělají, ne z těch, kteří mají zrovna volno.

Uvedené hodiny jsou orientační odhady přepočtené na 40hodinový týden, nikoli výsledky měření. U klíčových uživatelů jsou na osobu, celková zátěž je tedy několikanásobná.

Součinnost je povinnost, ne dobrá vůle. Role, hodiny a lhůty pro vaše odpovědi zapište do smlouvy a chtějte, aby dodavatel evidoval, na co od vás čeká. Hlídejte i stabilitu priorit: když se mění každý týden, klesá produktivita týmu a zvyšuje se riziko vyhoření DORA, 2024.

Od prvního dne potřebujete přístup k backlogu, repozitáři kódu a testovacímu prostředí. Jen tak vidíte skutečný stav (kapitola 17).

Co od vás tým potřebuje v každém sprintu

Agilní projekt je spíš série malých rozhodnutí než jedno velké. V každém sprintu se od vás čeká:

• seřazený backlog: co je na řadě a proč,
• rychlé odpovědi na dotazy, aby tým nečekal,
• účast vlastníka produktu a klíčových uživatelů na ukázce,
• převzetí hotové práce, nebo jasné „takhle ne“ s důvodem,
• data, přístupy a lidé z jiných útvarů, když je tým potřebuje.

Větší projekty se navíc dělí na fáze. Britská vláda jim říká discovery, alpha, beta a live: zkoumání problému, ověření řešení na prototypech, vývoj pro omezenou a později širší skupinu uživatelů a nakonec ostrý provoz GDS, agilní vývoj. Na konci každé fáze se rozhoduje, jestli pokračovat. Přesně to jsou brány hybridního modelu.