5 Pravidel, Jak Nastavit Metodiku Pro Kanban Tak, Aby Fungovala

Největší chyba je rozdělovat práci podle dovedností, ne podle výsledku. Když vytvoříte úkol „napsat API" a druhý „napsat testy", vznikne závislost, která blokuje tok. Lepší je rozdělit práci na vertikální řezy: malá část funkcionality, která projde od vstupu po výstup včetně testů. Takový řez se dá dokončit nezávisle a hned ukáže, jestli odhad sedí.

Dejte pozor na tagy a větve. Každý publikovaný balíček potřebuje vlastní tag, obvykle ve tvaru názvu a verze. Pokud tagy pletete dohromady nebo je vytváříte až po publikaci, přijdete o možnost dohledat, co přesně vyšlo. Stejně tak nestačí jen sloučit pull request; publikace musí být samostatný krok, který proběhne až po úspěšném buildu a testech. Jinak se stane, že se do registru dostane verze, která neodpovídá žádnému commitu.

Monorepo s více balíčky vypadá na začátku jednoduše: jeden repozitář, společná historie, žádné zbytečné publikování. Problém začíná ve chvíli, kdy se jeden balíček odkazuje na druhý a verze se přestanou hlídat. Nejčastější chyba není špatný nástroj, ale to, že vývojáři verze ručně přepisují v manifestech a zapomenou je sladit s tím, co je skutečně publikované.

Každý, kdo někdy nasadil změnu do produkce, zná ten pocit: monitoring začne řvát, uživatelé píšou a je potřeba jednat rychle. Rozhoduje několik málo minut. Nejhorší, co můžete udělat, je začít panikařit a přepisovat kód přímo na serveru. První krok je vždy zmírnit dopad na uživatele, teprve potom hledat příčinu.

Interní závislosti a rozsahy, které lžou Klíčové je, jak zapisujete interní závislosti. Pokud v package.json uvedete konkrétní verzi, kterou jste právě publikovali, build lokálně projde, ale po merge do hlavní větve se rozbije, protože balíček ještě není v registru. Řešení je používat rozsah, který odpovídá strategii: u svázaných verzí stačí odkaz na workspace, u nezávislých je bezpečnější caret rozsah nebo přesné sladění přes nástroj pro správu verzí. Nikdy nenechávejte v manifestu ručně vepsanou verzi, kterou jste si opsali z výpisu.

Praktický postup je jednoduchý. Vytvořte seznam všech licencí a u každé napište, jaké povinnosti z ní plynou. Porovnejte je s tím, co plánujete s kódem dělat. Pokud klient tvrdí, že všechno napsal sám, vyžádejte si potvrzení a uveďte v něm i odpovědnost za případné vady práv. Výsledek předejte právníkovi, který se specializuje na software. Bez tohoto kroku nepodepisujte převzetí ani nezačínejte s úpravami.

Čistý kód nakonec poznáte podle toho, že se v něm dá hledat. Když potřebujete najít, kde se počítá cena, napoví vám název funkce, ne komentář na konci souboru. Komentáře pište jen tam, kde vysvětlují proč, ne co. To, co kód dělá, má být vidět z kódu samotného.

Automatizace musí být součástí CI. Nástroj pro verzování by měl na základě změn v jednotlivých balíčcích sám navrhnout nové verze, aktualizovat interní závislosti a vygenerovat changelog. Vy jako člověk jen potvrdíte návrh. Pokud verze určujete ručně, dřív nebo později vznikne nesoulad mezi tím, co je v repozitáři, a tím, co je publikované. Chybějící kontrola v CI je druhá nejčastější příčina rozbitých releaseů.

Přebíráte projekt od klienta a v repozitáři leží kód, který jste nepsali. První otázka nezní, kdy to spustíme, ale kdo je vlastníkem práv a za jakých podmínek se smí kód dál používat, upravovat a šířit. Licence open source není totéž co vlastnictví. Vlastníkem může být klient, ale licence udává, co s dílem smíte dělat. Dokud to nemáte písemně, pracujete na cizím riziku.

Začněte tokem práce, ne sloupci Prvním krokem je popsat skutečný tok práce od zadání po dodání. Projděte si posledních deset úkolů a zapište, jakými fázemi prošly. Teprve z toho postavte sloupce. Typicky stačí čtyři až pět: čeká, rozpracováno, kontrola, hotovo. Pokud máte víc než sedm sloupců, tým je přestane používat, protože přepínání mezi nimi zabere příliš času. Do sloupců nedávejte fáze, které se překrývají nebo které nikdo reálně nerozlišuje.

Co zjistit dřív, než otevřete první soubor Začněte auditováním zdrojů. Projděte repozitář, závislosti, balíčkovací manifesty a soubory s texty licencí. U každé komponenty zapište název, verzi a licenci. Pozor na kód bez hlavičky a na soubory, které licenci zmiňují jen v komentáři. Rozhodující není, co tvrdí klient, ale co je v projektu skutečně obsaženo. Kopírování cizího kódu bez uvedení licence je nejčastější důvod, proč převzetí skončí právním problémem.

Poslední past je zpětná nekompatibilita. U monorepa se snadno stane, že změna v jednom balíčku rozbije závislý balíček, aniž by to někdo odhalil, protože se testuje jen změněný balíček. Nastavte CI tak, aby se po změně spouštěly testy i pro všechny závislé balíčky. A pokud zavádíte breaking change, zvyšte major verzi a v changelogu to výslovně uveďte. Bez toho budou uživatelé instalovat verze, které spolu nefungují, a vy budete hasit problémy, které vznikly jen nesladěným verzováním.