3 Úskalí Scrumu a jak je opravit

Zbavme se hrozných schůzek stand-up, pekla odhadů a poskytujeme uživatelskou hodnotu a místo toho budujeme skvělé produkty.

Foto: Randy Fath na Unsplash

Kdykoli procházíte volná místa pro softwarové inženýry, existuje téměř vždy jedna univerzální dovednost, kterou by měl potenciální kandidát zvládnout. Tato dovednost je „Scrum“. Bez ohledu na to, zda Scrum je vlastně dovednost stejným způsobem, jako je tesařství nebo psaní kódu, vždy mi připadalo zajímavé, že drtivá většina společností učinila Scrum de facto způsobem práce.

Výhody pracovní agility - což téměř vždy znamená určitou implementaci Scrumu - jsou zřejmé z manažerského hlediska. Můžete se rozhodnout, co je cenná práce v pravidelných intervalech, spíše než se zapadat do čtvrtletních plánů, a práce je rozdělena takovým způsobem, že by ji teoreticky každý měl být schopen provést.

V roce 2018 jsem napsal článek, v němž jsem uvedl, co v té době považuji za cenu používání Scrumu pro softwarové inženýrství. Tento článek obdržel spoustu chválu od frustrovaných vývojářů a také velké množství kritiky od těch, kteří trvají na tom, co jsem popsal, byl faux Scrum.

Od té doby jsem šel na cestu, abych zjistil, co tvoří tento „špatný“ Scrum. Spíše než odpisovat Scrum úplně jako něco, co nemůže fungovat pro vývoj softwaru, zaměřil jsem se na určení špatných prvků a pokusil jsem se formulovat způsoby, jak je transformovat do smysluplných, produktivních prvků.

V tomto článku se zabývám tím, co jsem se od psaní předchozího článku naučil, a jak si myslím, že by Scrum mohl pomoci vám a vašemu týmu vytvořit lepší software.

Provádějte užitečné denní pohotovostní schůzky

Toto je zajímavé téma. Stand-up setkání jsou jedním ze základních kamenů Scrumu. Myšlenka je taková, že projektový tým se schází brzy ráno, vstává a informuje se o svém pokroku a jakýchkoli překážkách, s nimiž by mohl pomoci s pomocí. Tato setkání jsou teoreticky skvělá. Dostane každého na stejnou stránku a protože se vyskytuje na začátku dne, každý může trávit své dny produktivně.

Zjistil jsem však, že tato setkání jsou manažery často zneužívána k tomu, aby určili, zda všichni dobře pracují a zda je projekt stále v plánu. Pokud si nejste jisti, zda se jedná o váš případ, nebo ne, je dobré naznačit, zda mluvící osoba navazuje oční kontakt se svým nadřízeným nebo s některým z jejich kolegů. Pokud primárně řídí svůj rozhovor u svého manažera, je pravděpodobné, že se jedná o reportážní schůzku v přestrojení.

Pokud je stand-up orientovaný na manažera, má tendence stát se cvičením, když mluvím, nikdo neposlouchá. Všichni jen zírají do dálky, nudí se ze své mysli a čekají na setkání. Je ironií, že tento typ stand-up také inklinuje zahrnovat zbytečné podrobnosti, jen aby podal zprávu manažerovi, takže to trvá mnohem déle, než by ve skutečnosti mělo.

Naštěstí může být oprava tohoto druhu stand-up jednoduchá. Nejprve vyjměte manažera ze stand-up. Síla funguje, ale pravděpodobně je můžete přesvědčit, aby tak učinili pouhým mluvením s nimi. Za předpokladu, že každý, kdo zůstane na schůzce, pracuje na stejném projektu, tón schůzky se po chvíli změní.

Místo toho, aby se schůzka týkala dokazování, že jste včera provedli smysluplnou práci, a bude to i nadále dělat, bude mít schůzka více charakter řešení problémů. Na místě se rozhodnete, jaký úkol řešit, a pokud vám něco blokuje cestu, můžete to hned a tam vyřešit.

PS Pokud jste manažerem tohoto příběhu, vím, že je těžké se od schůzky odříznout. Je ještě obtížnější pro členy týmu požádat o vaši nepřítomnost. Možná, že o tom budete hovořit se svým týmem a zkusit krátké schůzky bez manažerů, může být dobrý způsob, jak změřit, zda se schůzka stane bez vás produktivnější.

Foto Rob Hampson na Unsplash

Neposlouchejte uživatelskou hodnotu

Jedním z důvodů, proč společnosti implementují rámce, jako je Scrum, je to, že chtějí rychle přinést hodnotu svým koncovým uživatelům. Pěkně se to spáruje s krátkým trváním jednotlivých sprintu a také se schopností mezi nimi upravit zaostření.

Největší chybou, kterou zde můžete udělat, je posedlost přinášet hodnotu pouze vašim koncovým uživatelům. Stejně jako nemá smysl přidávat do budovy další podlahu s hnijícími podpůrnými paprsky, nemá smysl přidávat prvky do projektu, který se rozpadá podle své vlastní váhy.

Stejně jako to, že schopnost řídit auto neznamená, že člověk ví, jak postavit auto, člověk, který „řídí“ vývojový tým, nemusí nutně znát nejlepší způsob vytváření softwaru. Pokud vám mechanik vašeho vozidla řekne, že vaše vozidlo již není bezpečné řídit, víte, že příště budete mít dovolenou, riskujete obrovské riziko. Stejné opatření bychom měli přijmout, když nám zkušený technik řekne, že přidání něčeho, co uživatel zoufale chce, má velký dopad na kvalitu naší kódové základny.

Softwaroví inženýři, kteří pracují každý den na kódové bázi, jsou také jeho nejintenzivnějšími uživateli. Na rozdíl od běžných uživatelů nesledují jen šťastnou cestu; sledují každou cestu. Pokud bude implementace produktu spletena, bude pro inženýry postupně obtížnější provést nějakou smysluplnou práci. Tráví velkou část svých dní spíše prací na věcech než na věcech.

Při vytváření funkcí pro naše koncové uživatele má nepochybně význam, ale mít produkt, který si po dlouhou dobu uchová jak koncové uživatele, tak vývojáře, bude s větší pravděpodobností dlouhodobě úspěšný. To znamená, že někdy může být dobrý nápad naplánovat rozsáhlé refaktorské práce nebo obecné úklidové práce ve sprintech. Ne jako prvotřídní práce, ale jako prvotřídní - považujte to za práci, která je stejně důležitá jako vytváření nových funkcí.

Neužívejte odhady pro evangelium

Aby bylo možné určit množství práce, kterou lze ve sprintu udělat, je každému jednotlivému úkolu v nevyřízeném pořadí stanovena priorita a jeho práce je odhadnuta. Někdy se to provádí odhadem skutečných hodin potřebných k dokončení úkolu, jindy více vágních náhradníků, jako jsou body nebo dokonce velikosti trička.

Nutnost odhadnout práci, kterou lze provést během sprintu, je pravděpodobně jednou z nejsložitějších částí Scrumu. Zdá se, že vývojáři nikdy nesouhlasí s množstvím úsilí, které konkrétní úkol vyžaduje, a to je za předpokladu, že je dokonce zřejmé, s čím se podle odhadů začne. Existuje mnoho důvodů, proč jsou odhady téměř vždy přesné.

Jedním z těchto důvodů je předchozí zkušenost. Může to být předchozí zkušenost jednotlivce nebo tým, ale nikdy to neplatí pro každého jednotlivce v týmu. Řekněme, že člen týmu má rozsáhlé zkušenosti s implementací mechanismů autentizace podle určitého standardu. Mohou mít sklon odhadnout implementaci autentizace jako mnohem méně „úsilí“ než někdo, kdo má o dané problematice méně znalostí. Odhad však musí být přesný pro každého v týmu, bez ohledu na to, kdo ve skutečnosti skončí.

Dalším důvodem je to, že odhadovaná práce je stěží jasná. U pekárny je poměrně snadné odhadnout, jak dlouho jim bude trvat, než upečou sto chlebů. Vědí, jak dlouho člověk trvá, kolik jich může péct najednou, a pak prostě uděláte nějakou jednoduchou matematiku.

Jak každý softwarový inženýr bude vědět, nefunguje to tak, pokud jde o kód. Pokaždé, když se ponoříte do určitého kódu, musíte jej nejen analyzovat a porozumět, ale také porozumět a analyzovat změny, které se chystáte provést, a také jejich možné důsledky. To je nesmírně náročné, natož odhad.

Pravděpodobně můžete přijít s několika dalšími důvody, proč je odhad práce obtížný, ale jde o to, že byste neměli brát žádný odhad jako evangelium. Předpokládejme, že tým dělá v nejlepším případě vzdělaný odhad, s lidmi, které v tom okamžiku mají.

I když týmy dokážou lépe odhadnout práci v průběhu času, vždy mějte na paměti, že nejmenší z věcí může odhad zcela odhazovat. Skutečná hodnota je ve skutečné práci, ne v tom, zda byl odhad správný.

Závěr

Je zřejmé, že Scrum je víc než jen součet jeho částí. Chirurgické provádění obřadů a jejich nazývání Scrum vám prostě nechá spoustu obřadů, které lidé najednou musí absolvovat, ale nemusí nutně zefektivnit váš vývojový proces nebo dokonce agilnější.

Implementace Scrumu musí být předmětem neustálého zlepšování. Pokud pro váš tým něco nefunguje; přizpůsobit to. Scrum by neměl být neměnnou sadou obřadů a setkání - měla by to být tekutá věc, která roste ve vašem týmu a dává vám soubor pokynů, které vám pomohou stát se produktivnějšími a efektivnějšími.

V žádném případě nejsem vášnivým agilním nadšencem a pravděpodobně nikdy nebudu. Ale na rozdíl od článku, který jsem napsal v roce 2018, na který jsem se možná zmiňoval, nemyslím si, že Scrum jako instituce je pro týmy pro vývoj softwaru neodmyslitelně špatnou věcí.

Pokud se Scrum necítí jako tým, který je pro váš tým vhodný, otevřete konverzaci. Zjistěte, zda se ostatní lidé ve vašem týmu cítí stejně, a pokud ano, zkuste přesně určit, co se cítí neproduktivní, a společně provádějte postupné změny.

Nejlepší způsob vývoje softwaru je způsob, který pracuje pro váš tým. Soustřeďte se na to. Zapomeň na zbytek.