Quelltext der Seite Když zavádíte Scrum, těchto pět chyb vás zdrží

Denní standup držte na patnáct minut. Každý odpoví na tři otázky: co jsem udělal, co budu dělat, co mi brání. Nesklouzávejte k řešení problémů během standupu. Problémy řešte po něm v menší skupině. Typická chyba českých týmů je, že standup se změní v reportování manažerovi. To zabíjí zodpovědnost. Tým si má organizovat práci sám. Pokud někdo nedodržuje dohody, řešte to na retrospektivě, ne na standupu.<br><br>Začněte malou sadou testů, které pokrývají nejčastější cesty uživatelů. Nesnažte se automatizovat všechno najednou. Testovací prostředí udržujte oddělené od produkčního a data pro testy připravujte skriptem, ne ručně. Nestabilní testy, které jednou projdou a podruhé ne, jsou horší než žádné – lidé jim přestanou věřit a začnou je ignorovat. Pokud test opakovaně selhává bez skutečné chyby v aplikaci, opravte ho nebo smažte.<br><br>Malé funkce a jedna odpovědno<br><br>Prvním krokem je sestavit produktový backlog. Vlastník produktu musí být jedna osoba, ne výbor. Backlog nemá být seznam všech nápadů, ale prioritizovaný seznam položek, které přinášejí hodnotu. Uživatelské příběhy pište krátce: role, cíl, důvod. Vyhněte se technickým detailům, ty patří do akceptačních kritérií. Pokud tým nemá jasnou vizi, každý sprint se zvrhne v hádku o tom, co je důležitější. Vlastník produktu musí být dostupný a rozhodovat. Pokud tomu tak není, Scrum skončí jako demokracie, která nikam nevede.<br><br>Scrum v malém týmu do pěti lidí může být zjednodušený. Nemusíte mít odděleného Scrum mastera na plný úvazek. Stačí, když se role ujme jeden člen týmu a střídá se. Důležité je, aby měl mandát odstraňovat překážky. V českých firmách často chybí podpora vedení. Pokud manažeři chtějí vidět pokrok v tabulkách a grafech, ale nejsou ochotni změnit styl řízení, Scrum nepřežije. Nejprve si sedněte s vedením a vysvětlete, co budete potřebovat: důvěru, čas a prostor pro chyby. Bez toho se každá změna vrátí do starých kolejí.<br><br>Jak nastavit sprint, aby dával smysl Sprint plánujte na dva týdny. Delší sprinty ztrácejí zpětnou vazbu, kratší jsou hektické. Na plánovací schůzce vyberte jen tolik položek, kolik tým reálně zvládne. Kapacitu neodhadujte podle pocitu, ale podle historie – kolik příběhů jste dodali v minulých sprintech. Definujte „hotovo": co znamená, že je úkol dokončený. Bez toho budete na konci sprintu řešit, zda je něco hotové, nebo ne. Během sprintu se snažte neměnit zadání. Pokud to nejde, přerušte sprint a naplánujte nový. Časté změny za pochodu zabíjejí tempo.<br><br>Jakmile zvládnete základy, začněte používat větve. Pro každou novou funkci nebo opravu si vytvořte samostatnou větev a do hlavní větve slučujte až hotovou a otestovanou práci. Tím se vyhnete tomu, že rozpracovaný kód blokuje ostatní změny. Pokud pracujete sami, může se to zdát zbytečné, ale zvyk se vyplatí ve chvíli, kdy se k projektu připojí kolega nebo když se potřebujete rychle vrátit k poslední stabilní verzi. Slučování řešte průběžně, ne jednou za měsíc – čím déle větev žije, tím větší konflikty vás čekají.<br><br>Nakonec myslete na zálohu a sdílení. Lokální repozitář je fajn, ale poškozený disk znamená konec. Nastavte si vzdálený repozitář, kam budete pravidelně nahrávat změny. I když pracujete sólo, získáte tím klid a možnost pracovat z jiného počítače. Před každým nahráním si projděte, co přesně odesíláte, ať neposíláte rozdělanou práci nebo citlivá data. Verzování není jednorázový úkol, ale návyk. Čím dřív ho přijmete za vlastní, tím méně času strávíte hašením požárů a tím víc prostoru zbyde na skutečné programování.<br><br>Ruční testování je nenahraditelné tam, kde rozhoduje lidský úsudek. Patří sem ověření plynulosti přechodů, chování aplikace při příchozím hovoru, práce s oprávněními, přepnutí do režimu na pozadí nebo rotace displeje. Testovací scénáře pište jako krátké kroky s jasným očekávaným výsledkem. Typická chyba: tester zapíše, že „aplikace se zasekla", ale už neuvede, na kterém zařízení, s jakou verzí systému a po jaké konkrétní akci. Bez těchto údajů vývojář chybu neopraví.<br><br>Začněte tím, že si vyberete nástroj. Dnes je standardem Git, ale klidně můžete použít i jiný distribuovaný systém. Rozdíl pocítíte hlavně v tom, jak pohodlně se větví a slučují změny. Pro webové vývojáře je klíčové, aby šel snadno propojit s editorem a abyste nemuseli přemýšlet nad každým příkazem. Nainstalujte si Git, ověřte verzi v terminálu a nastavte si jméno a e-mail, které se budou zapisovat do historie. To je vše, co potřebujete pro první commit.<br><br>Jak uspořádat první repository, aby se v něm dalo vyznat Než začnete verzovat, rozhodněte se, co všechno má být součástí repozitáře. Do něj patří zdrojové kódy, konfigurační soubory bez citlivých údajů a dokumentace. Naopak nikdy necommitujte hesla, přístupové klíče, složku s nainstalovanými závislostmi ani vygenerované soubory. Vytvořte soubor .gitignore a vypište do něj všechny cesty, které mají zůstat stranou. Tím předejdete tomu, že se do historie dostane něco, co budete muset složitě mazat. Pokud už se citlivý údaj do repozitáře dostal, nestačí ho přepsat novým commitem – musíte historii přepsat nebo klíč okamžitě zneplatnit.