Tomáš Beneda
27.9.2013

Postřehy z AgilePrague 2013

Po roce jsem zavítal na již třetí ročník konference věnované agilním metodikám a souvisejícím  oblastem softwarového vývoje – Agile Prague 2013. V tomto článku vás rád seznámím s několika osobními postřehy, které jsem si z této akce odnesl.

Na konferenci, konanou 16.-17. září, jsem přišel s otázkami typu: máme iterativní vývoj, standupy, plánujeme, děláme retrospektivy,… jsme ale opravdu agilní? Proč náš vývoj stále skřípe? Odpověď jsem částečně našel už v úvodní keynote od Davida Hussmana. Po úvodní fázi hledání a zkoušení agilních metodik je důležité začít být produktivní a produktivitu si následně udržet. Nestačí jen převzít agilní proces vývoje a tupě ho následovat. Je potřeba ho neustále validovat. Přinášejí nám standupy nějakou hodnotu, anebo je to jen povinná týmová čtvrthodinka? S produktivitou jako takovou je navíc potřeba být opratrný. Roste-li nám počet implementovaných vlastností, není to na úkor kvality? Nezačínají nám naskakovat úroky technologického dluhu? David zde radí sledovat ani ne tak čísla (prodeje) jako výslednou hodnotu práce, jak se výsledek používá a zda zároveň nepřibývá i procesů.

Kritický tón se objevil i v přednášce Pata Guariglia, který odhalil takzvaný paradox scrumu. Ten spočívá ve všeobecném pozitivním vnímání scrumu, které pak zastiňuje jeho správné použití a může vést až k nezdaru. Mezi časté chyby patří zejména záměna scrumu za agile jako takový a jeho aplikování na izolované týmy bez vazeb na zákazníka a zbytek firmy. Pat připomněl, že scrum je především nástroj pro vývoj a plánování, nikoliv celkové řešení pro celou firmu. Kdo používá scrum ještě není nutně agilní.

Z oblasti scrumu se dále ve velmi emotivním a svižném tempu Angelo Medinilla věnoval osobě scrum mastera. Vysvětlil, že jeho hlavní rolí je pomáhat samoorganizujícímu se týmu a že je potřeba se vyvinout od „ScrumTýpka“, co plánuje a řídí, přes „ScrumMatku“, která pečuje a chrání ke skutečnému „ScrumMistrovi“, který koučuje a motivuje. Jen tak může přinést týmu nějakou hodnotu, stejně jako to dělá trenér fotbalového mužstva.

Z tábora kanbanu jsem si prostřednictvím Mikea Lebera odnesl to, že se dá narozdíl od scrumu nenásilně zavést, neboť se nejedná o plnohodnotnou metodiku, ale o sadu několika principů a doporučení, které si můžeme přizpůsobit svým potřebám. Klíčové je nepospíchat, zohlednit současnou situaci ve firmě a vyvarovat se překvapení (a usnutí na vavřínech). Zaujala mě i prezentovaná podstata kanbanu, tedy rovnováha mezi potřebami trhu a možnostmi týmu, nikoliv jen zvyšování efektivity a udržování workflow, jak jsem kanban doteď vnímal.

Pro mě jako vývojáře bylo velkým tématem testování a QA obecně. Pro Uriva Nativa je QA přežitek a doporučuje, aby testovali sami vývojáři. Varuje před komunikační zdí v podobě samostatných oddělení a zůrazňuje, že klíčem k vysoké kvalitě je zrychlení kolečka vývoj-test-chyba-oprava a důrazné dodržování pravidla “nejdříve oprava chyb, pak vývoj nových vlastností”. Nový kód doporučuje uvolňovat do produkce postupně, tak jak to dělá například Facebook. Tedy nejprve k užití samotným vývojářům, pak interním zaměstnancům a postupně malé části uživatelů.

Nad vývojem a testováním se zamýšlel i Scott Barber, když porovnával vývoj v softwaru a v průmyslu. Jako největší problém vnímá, že se k vývoji software často přistupuje jako k manufaktuře, ačkoliv má blíže k R&D (Research and development). V něm je přirozené, že vývojáři sami testují, neboť výsledkem jejich práce je funkční specifikace či prototyp. Zadáním pro R&D není seznam požadavků, ale vize a cíle, a o pokračování či zastavení vývoje se rozhoduje na základě výsledků. Průmyslová R&D tak jdou v mnohém vývoji softwaru příkladem, ačkoliv se v jejich případě nemluví o agile, i když agilními jsou.

Zajímavých myšlenek a témat bylo na konferenci samozřejmě daleko více, namátkou ještě zmíním psaní user stories, zohlednění nahraditelnosti v softwarovém vývoji, být statečný, mít sny a o realných zkušenostech týmů z praxe ani nemluvě. Pro mě osobně byla konference především připomenutím, že být agilní není stav, ale nekončící běh. Že všechny ty metodiky, role, hezké obrázky a grafy jsou jen podpůrnými nástroji a že jejich dogmatickým dodržováním se člověk agilním principům spíše vzdaluje. Beru je ale jako dobrý začátek, odrazový můstek, protože něčím se začít musí, a bez nich, jak zkušenosti ukazují, je vývoj nepříjemná otrava.

Vaše emailová adresa nebude zveřejněna

Komentáře

Děkujeme za váš komentář
Další
  • Softwarové inženýrství bez testerů, tj. vývojáři kteří testují, je utopie, viz článek Top Five (Wrong) Reasons You Don't Have Testers http://www.joelonsoftware.com/articles/fog0000000067.html

  • Tomáš Beneda

    Nemyslím si, že je to utopie. Na testerech ocenuji, pokud si umí sami zautomatizovat test (např. selenium) - nejsou pak už taky vývojáři? Na vývojářích na druhou stranu ocenuji, když svůj výsledek vyzkouší a pokryjí unit testy. Nejsou pak testery? Nemluvě o tom, jak často vývojáři vyvíjejí testováním, který framework či copy-paste z internetu vyřeší jejich aktuální problém. Ta hlavní myšlenka je podle mě ta, že testování je nedílnou součástí vývoje a čím blíže mu je, tím lépe.

  • Já v tom vidím prostou dělbu práce. Samozřejmě, vývojář zvládne práci analytika, programátora, projekťáka, obchodníka atd., ale když je větší tým, je lepší aby to dělal specialista. S testery je to stejné. Jistě, testování je nedílnou součástí vývoje, ale stejně nedílnou součástí vývoje by měla být i analýza, obchod atd. Tomu všemu by měl vývojář perfektně rozumět. Ale myslím si, že by to nemusel nutně sám dělat.