Jak připravit vývojářský tým na první společný sprint
První společný sprint je zkouška toho, jak tým zvládá domluvu, ne jen techniku. Než se pustíte do kódu, musíte si sednout a vyjasnit dvě věci: jak budete sdílet práci v repozitáři a kdo a kdy kontroluje, co kdo napsal. Bez toho se i malý projekt změní v chaos, kde se změny přepisují a chyby hledají těžko. Rozdělení větví není formalita, ale nástroj, který určuje, kdo na čem pracuje a jak se změny dostanou do hlavní linie. Stejně tak kontrola kódu není buzerace, ale způsob, jak si tým předává znalosti a drží kvalitu.
Začněte tím, že si dohodnete model větví. Pro začátek stačí jednoduché schéma: hlavní větev, do které se nesmí přímo commitovat, a krátkodobé větve pro každý úkol nebo opravu. Pojmenujte je jednotně, třeba typ/issue-krátký-popis, aby bylo na první pohled jasné, co daná větev řeší. Délku života větve omezte na jeden až dva dny; dlouhé větve se špatně slučují a vznikají v nich konflikty. Pokud si nejste jistí, jak nastavit pravidla pro pull requesty a schvalování, inspirujte se osvědčenými postupy na vyvojarska.cz, kde najdete konkrétní doporučení pro týmovou spolupráci. Důležité je, aby pravidla platila pro všechny bez výjimky, včetně seniorních vývojářů.
Kontrola kódu musí mít jasná kritéria. Určete, kolik schválení je potřeba, kdo je zodpovědný za merge a jak dlouho může být pull request otevřený. Recenzent by se neměl zaměřovat jen na styl, ale hlavně na logiku, čitelnost a testy. Zároveň platí, že autor nemá obhajovat každý řádek; cílem je najít lepší řešení, ne vyhrát diskusi. Zaveďte pravidlo, že recenze probíhá do několika hodin, ne dní, jinak se práce hromadí. Menší pull requesty se kontrolují rychleji a snižují riziko, že se do hlavní větve dostane chyba.
Před prvním sprintem si udělejte krátkou zkoušku nanečisto. Vezměte jednoduchý úkol, projděte celý cyklus od větve přes commit až po schválení a merge. Uvidíte, kde se proces zasekává a co je potřeba upravit. Výsledkem by mělo být, že každý v týmu ví, co má dělat, kam psát a koho žádat o kontrolu. Jakmile jsou pravidla jasná a vyzkoušená, první sprint už není skok do neznáma, ale běžná práce s jasnými pravidly.