Transformace starších IT systémů: Jak začít a jaké kroky podniknout
PŘEČÍST ČLÁNEK
V Etneteře se aktivně zabýváme agilním řízením a máme velkou chuť se v tom zlepšovat. Můžeme společně. Rozhodli jsme se pro cestu sdílených informací pomocí rozhovorů se zajímavými hosty. Pro všeobecný úvod do Agilního světa jsme si vybrali Zuzku Šochovou.
S agilními metodami jsme si v Etneteře (konkrétně v týmu Synergy) začali pohrávat v roce 2011. Nebylo nám to nařízeno shora, sami jsme si k tomto přístupu řízení projektů našli cestu. Z mé zkušenosti mohu ale říct, že nadšení a odhodlání v týmu je půl cesty.
Druhou velmi důležitou částí zavádění agilních metod, technik a přístupů je okolí. Ať už jde o top management nebo lidi na klientské straně: projektové manažery, produktové manažery nebo dokonce ostatní podpůrné týmy ve firmě. Úspěch zavedení je závislý i na nich všech, pokud oni nebudou hrát podle stejných pravidel, bohužel to nebude fungovat tak, jak by mělo. Osvěta, nebo jak se dneska moderně v angličtině říká evangelizace, je nedílnou součástí zavádění agilu.
Osvěta je nedílnou součástí zavádění agilu.Zuzka Šochová
V květnu se v Praze zastavili podebatovat představitelé celosvětové organizace Agile Alliance. Měl jsem to štěstí tam být a velmi se mi líbil výrok Lindy M. Cook (USA): “ Scrum is training wheels to adopt agile mindset”. Metafora je podle mě natolik trefná, že si dovolím na ní navázat obrázkem. Je potřeba si uvědomit, že na takovém kole se neučí jezdit jen agilní tým, ale i jeho okolí.
Jak Simon Sinek rád říká “Začněte s proč” nebo technika na zjištění důvodu 5x Proč, i tady je potřeba nejprve převzít smysl. Neboli dostat odpověď na otázky:
Nejedná se o střelhbité zavedení alá pravidlo “Potom co doplňuješ poslední balík kafe do kafomatu, dáš vědět relevantní osobě”. Tady není potřeba vysvětlovat smysl. U agilu je to běh na delší trať, protože je potřeba si zažít způsob myšlení.
Pro zajímavost: Nejdále s agilním přístupem jsme podle mě u klienta Fortuna - sázková společnost. Aktuálně bychom metodu mohli nazvat vyladěným Scrumbanem (kombinace Scrumu a Kanbanu). K tomu, jak přesně fungujeme se dostanu v některém z dalších článků.
Čím hlouběji se o agilní přístupy zajímám, tím více si všímám nejrůznějších obav před zavedením. A protože v agilu vidím opravu velký přínos, rozhodl jsem se natočit sérii několika rozhovorů, kde se podíváme na agile podrobněji. Vždy se budu snažit dostat z hosta jeho pohled na věc s tím, že každé video bude mít hlavní nosné téma.
Pro všeobecný úvod do Agilního světa jsem si vybral Zuzku Šochovou. Agilní koučku, spoluzakladatelku Agilní Asociace a pořadatelku konference Agile Prague.
Jak to celé vzniklo? Japonsko bylo po 2. světové válce výrazně neefektivní. Podle čísel cca 6x méně efektivnější než Němci a až 9x méně než-li Američané. V 50. letech přichází společnost Toyota s tzv. štíhlou výrobou (Lean). I přesto, že se jedná o strojírenství, je to považováno za start tak trošku jiného - agilního - smýšlení.
V únoru 1986 publikují Hirotaka Takeuchi a Ikujiro Nonaka svůj odborný článek v Harvard Business Review s názvem “The new new product development game”. Ten je brát jako první oficiální výkop agilních myšlenek do sektoru IT.
Nejznámější událost v agilním světe se ale konala v roce 2001 v Utahu hluboko v horách. Sedmnáct zkušených a uznávaných softwarových vývojářů a architektů se sešlo za jediným účelem - sjednotit a jasně popsat agilní principy. Sestavili agilní manifest a ve dvanácti bodech popsali to stěžejní.
Inkrementální vývoj s krátkými iteracemi
Při pohledu na dnešní turbulentní trh je možnost okamžitě reagovat dle aktuální situace rozhodující pro konkurenceschopnost. Pokud například přímá konkurence přijde s novou vlastností svého produktu, adekvátní reakce je podle mého nutnost. Sledovat to ale z pohledu byznysu a v takový okamžik začít tlačit na vývoj je sice cesta, ale ne příliš efektivní. Lepší je mít celý vývojový proces nastavený tak, že tyto turbulence nejenom zvládá dobře, ale on je přímo očekává. Pro produkt to v samotném důsledku znamená časté nové verze se zapracovanými nejprioritnějšími požadavky a tím i rychlejší návratnost.
Co je efektivnější?
A) sepsat detailní specifikaci a podle ní nechat vývojáře programovat
B) představit vizi, zadat nejprioritnější požadavky, verbálně prodiskutovat jakékoliv nejasnosti a začít programovat
U varianty A) dostanete první výstup s mnohem větším zpožděním než u B). Navíc sepsaná a následně čtená specifikace dává větší prostor ke komunikačnímu šumu. Ve chvíli, kdy zatáhnete zadavatele požadavků do vývojového procesu, tak rapidně naroste efektivita vývoje. Tým generuje nové a nové verze a zadavatel má pod kontrolou výstupy tím, že je na blízku a dává zpětnou vazbu. Obecně se dá říct, že feedback je velmi důležitý aspekt celého agilního vývoje.
Vždy a za všech okolností se hraje na přidanou hodnotu. Opakovaně si byznys i agilní tým pokládají otázku “Přináší tato věc přidanou hodnotu uživateli nebo našemu byznysu?”. Pokud je odpověď negativní, zjevně to nemá takovou prioritu. Jednoduchý princip, přesto spousta lidí pracuje na věcech, které hodnotu nemají a plýtvají tak svým časem, penězi i energií. Druhý úhel pohledu je dosahovat maximální hodnoty s minimálním úsilím. Přímo v agilním manifestu se píše: “Jednoduchost - umění maximalizovat množství nevykonané práce - je klíčová”. Zní to pěkně, prostě některé věci neuděláme, že? Bohužel to v našich hlavách není tak snadné, jak se může zdát. Nejde jenom o to vynechat některé méně důležité věci. Jde o to najít minimální vlastnost, který přináší hodnotu. Například chceme se do práce dostat rychleji než pěšky. Spousta lidí asi začne přemýšlet nad autem či motorkou. Ano, je to asi nejideálnější řešení. Ale pravda je taková, že kolo vyrobíme snáz a levněji a splní taky svůj účel. Můžeme jít ale ještě dál, co udělat jenom koloběžku. Člověk se více nadře, ale do práce se dostane rychleji než pěšky. To znamená i tohle přináší hodnotu. Co jít ještě dál a udělat jakýsi pseudo-skateboard z prkna a pár koleček. Taky urychlí přesun do práce, přinese určitou úroveň hodnoty a zároveň jej sestavíte s minimálním úsilím. Porovnání skateboardu a auta - cítíte ten výrazný rozdíl? Američané tomu říkají good-enough.. Hledáme tedy poměr maximální hodnoty a minimálního úsilí.
Aby tým mohl rychle a bez technického dluhu vyslyšet přání zadavatele, musí s tím při návrhu i vývoji počítat. Existuje spousty technik a nástrojů, jak držet programátory spokojené a jejich řešení připravené na změny a turbulentní rozvoj. Na téma boje proti technickému dluhu si budu povídat v dalším rozhovoru s Karlem Smutným. Zatím namátkou:
Metod, technik i přístupů je spousta. Všechny mají ale společný základ a ten je popsaný v agilním manifestu. Pokud chcete vědět více, koukněte na některé z následujících odkazů.
.png)
.jpg)
