Když se kód čte jako věta, chyby mizí samy
Při budování pyramidy postupujte postupně. Začněte tím, že zmapujete stávající sadu testů a spočítáte poměr mezi vrstvami. Pak se zaměřte na posílení základny — napište chybějící jednotkové testy pro nejkritičtější logiku. Snižte počet end-to-end scénářů tak, že je převedete na integrační testy (místo proklikávání celého UI testujte jen API a služby). Nezapomeňte na metriky: měřte dobu běhu jednotlivých vrstev a počet flaky testů (testů, které občas selžou). Pokud sledujete tyto ukazatele, máte objektivní základ pro rozhodování — a konečně testy začnou být užitečným nástrojem, ne zdrojem frustrace.
Nezapomínejte ani na technické praktiky. Scrum sám o sobě neřeší, jak psát čistý kód nebo jak testovat. Pokud tým dělá velké integrace jednou za měsíc, žádný Scrum vám nepomůže. Zaveďte průběžnou integraci a automatizované testy hned od začátku. Jinak budete místo doručování funkcí trávit čas opravováním chyb, které vznikly při slučování větví. To je častý důvod, proč české týmy Scrum zavrhnou – ale chyba není v metodice, ale v opomíjení technického základu.
Když se program nespustí: nejčastější chyby a jejich řešení První spuštění často skončí chybou. Nejběžnější problém je, že jste zapomněli zavřít složené závorky nebo že máte v kódu nesprávný název metody. Další častá chyba je použití nesprávného datového typu. Pokud chcete načíst číslo, musíte vstup z klávesnice převést na číselný typ pomocí metody Convert.ToInt32 nebo int.Parse. Bez této konverze program skončí výjimkou, když uživatel zadá text místo čísla. Před převodem je vhodné zkontrolovat, zda vstup není prázdný.
Klíčové je správně nastavit role. Product Owner není manažer, který rozdává úkoly, ale člověk, který rozumí byznysu a umí rozhodovat o prioritách. Scrum Master zase nehlídá dodržování pravidel, ale odstraňuje překážky a učí tým sebeřízení. V praxi se často stává, že vývojáři očekávají, že jim Product Owner přesně řekne, co mají dělat. To je omyl. Tým musí sám odhadovat náročnost a plánovat, co zvládne ve sprintu. Bez toho Scrum zůstane jen mrtvou formou.
Než začnete psát kód, ujistěte se, že máte nainstalované vývojové prostředí. Stačí libovolný textový editor, třeba Poznámkový blok, ale pohodlnější je použít Visual Studio Code s rozšířením pro C#. Po instalaci vytvořte novou složku pro projekt. Otevřete terminál a přejděte do této složky. Zde spustíte příkaz pro inicializaci projektu, který vytvoří soubor s příponou .csproj a hlavní programový soubor. Tento krok je klíčový, protože bez správné struktury projektů nebude překladač vědět, kde hledat vstupní bod.
Na závěr si připomeňte, že úspěch B2B projektu se nepozná podle počtu napsaných řádků kódu nebo dodaných dokumentů. Pozná se podle toho, jestli lidé nástroj skutečně používají a jestli jim usnadňuje práci. Proto po dokončení klíčové fáze proveďte důkladnou kontrolu s reálnými daty a porovnejte výsledky s původními metrikami. Pokud se čísla neshodují, je to signál k úpravám, ne k obhajobě. Jen tak se vyhnete situaci, kdy máte funkční, ale nepoužívaný systém, který nikomu nepřináší hodnotu.
End-to-end testy by měly být jen špičkou pyramidy — obvykle 5–10 % všech testů. Testují kritické uživatelské cesty, jako je registrace, přihlášení, vytvoření objednávky apod. Spouští se v reálném prohlížeči nebo přes API, takže jejich běh trvá minuty až desítky minut. Proto je důležité, aby se nespouštěly při každé změně kódu, ale až po úspěšném průchodu nižších vrstev. To lze zařídit pomocí fází v CI: po commitu běží jen jednotkové a rychlé integrační testy, end-to-end se spouští jednou denně nebo před vydáním. Pokud byste je spouštěli po každém commitu, vývoj se zpomalí a lidé je začnou ignorovat.
Na závěr si osvojte pravidlo: psát kód postupně, po malých částech, a po každé části spustit program. Tím snadno odhalíte, kde se stala chyba. Pokud aplikace stále nefunguje, přečtěte si chybovou hlášku. Není to nepřítel, ale užitečná informace, která říká, kde hledat problém. Po prvním úspěšném spuštění si zkuste upravit program, aby přijímal víc vstupů nebo aby počítal s desetinnými čísly. Tím získáte jistotu a připravíte se na složitější projekty.
Jak vyčíslit neviditelné, když nemáte data z minulosti Prvním krokem je rozlišit činnosti, které jsou přímo spojené s úkolem, a ty, které jsou jen jeho okolím. Například psaní nové funkce je přímá práce, ale její integrace do stávajícího systému, konfigurace testovacího prostředí nebo ladění rozhraní s jiným týmem jsou skryté náklady. U každého úkolu si položte otázku: co musí být hotové, aby funkce fungovala v ostrém provozu? Seznam těchto činností si napište a odhadněte čas na každou z nich zvlášť. Klíčové je nepodcenit opakovanou práci – pokud úkol vyžaduje změny ve více částech systému, počítejte s časem na synchronizaci a testování všech variant.