AI assisted code review přímo ve vývojovém studiu
Praktická showcase o tom, jak využít AI v code review procesu s minimem externích závislostí.
Zvoní Scrumu umíráček?
Když se objevily agilní metodiky řízení projektů a Scrum začal být více populární, byl to pro spoustu projektů velký přínos. Namísto dlouhodobého plánování se začalo přemýšlet v kratších intervalech. Z půlročních cyklů se najednou staly dvoutýdenní sprinty. Doba se ale mění, vše je rychlejší a my dokážeme dodávat nové funkce v řádu dnů.
Změnil se způsob práce, způsoby doručování software, přibyly nové možnosti testování i řízení kvality. Nesvazuje nás tedy Scrum v něčem, co už dávno neplatí? Má Scrum v dnešní době ještě svoje místo?
Změna řízení projektů
Myslím, že Scrum nás v mnoha ohledech začíná brzdit, začíná nám překážet. Původně agilní metodika se stala neměnným rámcem, který často narušuje přirozený tok dění. Možná je načase revidovat naše požadavky na řízení projektů a navrhnout změny, které by pomohly lépe se přizpůsobit dnešní době.
Dynamické cykly namísto rigidních sprintů
I když je Scrum agilní metodika řízení, tak v tomto ohledu často selhává. Dvoutýdenní sprint je v dnešní době až moc tvrdě definovaný úsek. V mnoha případech se snažíme naši práci naporcovat tak, aby se tam vešla. Nebo se snažíme naopak menší dílky zařadit tak, aby měl každý dostatek naplánované práce.
Jenomže věci se mění rychle. Objevují se problémy a některé věci jsou naopak mnohem snadnější, než se zdálo.
Přesouváme potom úkoly ze sprintu na sprint, vývojáři začnou s prací o sprint dříve, protože nemají do čeho píchnout.
Na retrospektivě si potom vyčítáme, že jsme udělali špatný plán. To ale není naše chyba. Nejsme dokonalí a odhady jsou opravdu jenom odhady.
Na Scrumu jsem měl dříve rád to, že jsem na konci sprintu mohl “dokončit” svoji práci, pustit vše z hlavy a v dalším týdnu začít na něčem novém. Vývoj je ale kontinuální proces a většinou dokončíme jen nějakou část a pokračujeme v ní v následujících sprintech. Iluze dokončení se potom vytrácí.
Nevadí mi pracovat na nějaké feature dva měsíce, vadí mi, že se po každých dvou týdnech tváříme, že máme “hotovo”.
Prioritizace namísto plánování
Obzvláště v situacích, kdy spolupracuje více týmů, je plánování jako domeček postavený z karet. Stačí jedno škobrtnutí a vše se sesype. Každý tým se potýká s problémy a ovlivňuje práci dalších týmů. I týmy, které pracují samostatně, naráží na nečekané komplikace.
Prioritizace tak má často přednost před plánem – na projektech, kde spolupracuji, si toho všímám stále častěji.
V tomto ohledu nám tak Scrum často spíše překáží nebo nás brzdí.
Plovoucí kapacity
I zkušený Superman, kterého máme v týmu, může někdy narazit a dostat se do slepé uličky. Často je tak výhodnější přizvat do projektu odborníka. Tady asi není problém ani tak na straně Scrumu jako spíš na straně plánování kapacit. V týmech máme dané role, pevně dané FTE a s tím moc hýbat nejde.
Možnost upravit si tým dynamicky podle aktuálních potřeb vidím jako velký přínos – tým se naučí něco nového a příště už externího odborníka třeba nebude potřebovat. Současně nebude projekt blokován na věcech, se kterými si nevíme rady.
V mnoha případech jsme samozřejmě vázání smlouvami a není možné takto kapacity jednoduše přesouvat. To už je ale otázka, se kterou by si měl management umět poradit.
Chat nebo AI místo standupů
Když se podívám na svůj kalendář, dopadá na mě bezmoc. Tolik pravidelných meetingů, že často ani netuším, jestli budu v daný den schopen něco udělat. Mluvím především o denních stand-upech.
Nevím, jak to mají ostatní, ale věřím, že jsme na tom zhruba stejně. Ve třetině případů jsem duchem nepřítomen, protože myslím na věci, na kterých zrovna pracuji. V druhé třetině mě naopak standup od práce vyruší a já se potom musím „vrátit do správných kolejí“.
Přitom by stačila jedna věta v týmovém chatu. Nebo souhrn z dění v repozitářích a ticketech vygenerovaný pomocí AI.
Scrum nás také (víceméně) nutí oddělovat jednotlivé typy diskuzí. Grooming není plánování, daily scrum není pro řešení technických věcí. To se ale často nedodržuje, protože to prostě není vždy možné.
Naplánovat meeting na věci, které je skutečně potřeba řešit, mi přijde efektivnější než striktně dodržovat Scrumové ceremonie.
Nové staré metody
Možná už je opravdu čas Scrum opustit a podívat se po něčem novém. Po něčem, co je přizpůsobeno dnešní době. Při hledání informací jsem narazil na dvě poměrně nové metodiky a jednu poměrně starou.
- Shape Up – Zkušení vývojáři navrhnou jenom „tvar“ nebo možná spíše směr, kterým se bude projekt ubírat. Vše ostatní je potom na celém týmu a jednotlivcích. Nejsou zde plánovány žádné meetingy, tým se sejde, když je potřeba.
- Linear – Namísto sprintů se pracuje v cyklech. Není zde tlak na dodání „do konce sprintu“, spíše se zaměřuje na dodání konkrétních featur. Pokud se něco nestihne, nic se neděje, cyklus není pevně daný. Komunikace je zaměřovaná ke konkrétním úkolům namísto k celému týmu.
- Kanban – Kanban je takovou stálicí nejen ve světě vývoje softwaru. Zaměřuje se na prioritizaci a aktuální situaci. Jeho výhodou například je, že mnohem lépe umožňuje soustředit se na jednu věc.
Zodpovědnost a zkušenosti
Když píšu tyhle řádky, tak si uvědomuji, že nejdůležitějším prvkem je ale vždy zodpovědnost. A také zkušenosti. Týmy složené ze zkušených a zodpovědných vývojářů často žádné řízení ani nepotřebují. Scrum je pro mě jen formalitou, někdy i „nutným zlem“.
Jenomže takový tým je často utopie.
Možná tak není špatný nápad být i v tomto ohledu agilní. Nastartovat projekt se Scrumem a později ho přetransformovat na něco, co bude danému týmu více vyhovovat.
