Když tým sklouzne do chaosu, Scrum pomůže najít řád

První práce v IT není o tom znát všechny frameworky zpaměti. Firmy běžně přijímají juniory, kteří umí základy, ale hlavně přemýšlí a nebojí se zeptat. Nejčastější chyba? Čekat, až budete „připravení". Připravený nikdy nebudete. Místo toho se zaměřte na to, co už umíte, a na schopnost to prodat v pohovoru i v praktickém úkolu.

Logickým vyústěním kvalitní ochrany je také pravidelné testování vlastní implementace. Zkuste si úmyslně poslat token s pozměněnou deklarací role, s prošlým datem nebo s neplatným podpisem. Sledujte, jestli server vždy správně odpoví chybovým kódem a nezanechá v odpovědi žádné citlivé údaje. Jen tak si ověříte, že vaše API skutečně odmítá neplatné tokeny a že je nastavená ochrana opravdu funkční. Bezpečnost není jednorázový úkol, ale průběžný proces, který vyžaduje pravidelnou revizi.

Po přijetí do první práce se připravte na to, že toho budete hodně nevědět. To je normální. Nebojte se dělat si poznámky a požádat o code review od zkušenějších kolegů. Typická chyba juniora je, že se tváří, že všemu rozumí, a pak dělá chyby. Místo toho se ptejte – ať už na interní nástroje, nebo na konvence v kódu. Každý den se snažte zlepšit alespoň o malý krok. Za půl roku budete překvapeni, kolik jste se toho naučili.

Druhý krok je zavedení verzování. Všechno, co souvisí s konfigurací – skripty, Dockerfily, definice prostředí – musí být v git repozitáři. To platí i pro konfiguraci serverů. Pokud nemáte infrastrukturu jako kód, nemůžete ji verzovat, testovat ani snadno obnovit. Typická chyba je, že lidé verzují jen kód aplikace, ale konfiguraci nechávají ručně na serverech. Pak se prostředí liší a nasazení selhává. Uložte vše do repozitáře a vytvořte si jednoduchý postup pro nasazení z něj.

Na závěr si osvojte návyk pravidelného testování s reálnými uživateli, byť jen s kolegy z jiného oddělení. Pozorujte, kde váhají, co hledají a kde klikají omylem. Není to o tom, aby se vám design líbil, ale aby uživatel dosáhl cíle co nejplynuleji. Dobře navržené rozhraní předchází otázkám, chybám a podpůrným lístkům. Pokud budete tyto zásady aplikovat při každém vývoji, rozdíl poznáte nejen vy, ale hlavně lidé, kteří vaši aplikaci denně používají.

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.

Na závěr jedna důležitá věc: Scrum není všelék. Pokud máte tým, který si rozumí, dodává pravidelně a zákazník je spokojený, žádnou změnu nepotřebujete. Pokud ale cítíte chaos, časté přesuny priorit a nízkou předvídatelnost, Scrum vám dá rámec, jak problém pojmenovat a řešit. Začněte malými kroky, komunikujte otevřeně a mějte trpělivost. Agilita není cíl, ale cesta, která vede k tomu, že tým dodává to, co zákazník skutečně potřebuje.

Kromě techniky se připravte i na otázky o týmové spolupráci. Například: „Jak řešíte konflikt s kolegou?" nebo „Co uděláte, když nestíháte deadline?" Zde se vyhněte frázím typu „jsem týmový hráč" a místo toho popište konkrétní situaci z vaší zkušenosti – ze školy, brigády nebo vlastních projektů. Důležité je ukázat, že umíte komunikovat a že nejste uražliví, když někdo kritizuje váš kód.

Prvním kritériem je povaha dat a jejich vztahů. Pokud máte hierarchická data nebo propojené entity, kde klient potřebuje různé podmnožiny polí, GraphQL vám ušetří spoustu práce. Klient si totiž požádá přesně o to, co potřebuje, a vy se nemusíte trápit s tvorbou desítek endpointů pro každou variantu. Typickým příkladem je mobilní aplikace, která potřebuje jen jméno a e-mail, zatímco webová verze chce i adresu a historii objednávek. S REST byste museli vytvořit dva endpointy nebo posílat zbytečně velká data.

Praktický úkol dostanete skoro jistě. Postupujte podle zadání, ale nebojte se zeptat na upřesnění, pokud vám něco není jasné. To je považováno za silnou stránku, ne za slabost. Dbejte na to, aby váš kód byl čitelný – jasné názvy proměnných, krátké funkce a základní ošetření chyb. Rozhodně nekopírujte řešení z internetu bez porozumění. Pokud nebudete umět vysvětlit každý řádek, pohovor nedopadne dobře. Vypadá to jako podvádění a ve skutečnosti to škodí jen vám.

Dalším specifikem je práce s tajným klíčem nebo párem klíčů pro podepisování. Pokud používáte symetrický algoritmus, nikdy nesmí být klíč součástí klientského kódu ani zdrojového kódu v repozitáři. Klíč by měl být uložený v bezpečnostním trezoru nebo v proměnné prostředí na serveru. Pro produkční prostředí zvažte asymetrické podepisování, kdy je privátní klíč jen na straně vydavatele a veřejný klíč slouží k ověření podpisu. To umožňuje decentralizovanou validaci bez sdílení tajemství napříč službami.