Zuzana Šochová, Eduard Kunce
Proč tuto knihu?
Knihu jsem vybrala jako jednu ze dvou knih a směrů k předmětu Projektové řízení v podnikání.
O knize
Kniha se snaží vysvětlit filosofii agilního přístupu a zaměřit se na vysvětlení, proč jednotlivé metody fungují. Popisuje stavební prvky agilního vývoje, od vlastní definice procesu až po ukázky z praxe. Obsahuje popis rolí, které se typicky vyskytují v agilně řízených firmách. Zabývá se agilními metodikami vývoje softwaru v různých typech společností.
Základní pojmy a teorie z knihy
Co znamená „agilní“? – dynamický, rychlý, interaktivní, přizpůsobivý, zábavný, hravý, rychle reagující na změnu
Základním stavebním kamenem je manifest – agilní manifest. Co to je? Ve čtyřech bodech co to vlastně znamená být agilní:
-jednotlivci a interakce před procesy a nástroji
-fungující software před vyčerpávající dokumentací
-spolupráce se zákazníkem před vyjednáváním o smlouvě
-reagování na změny před dodržováním plánu
Agilní firma je firma orientovaná na problém.
Princip „lean“ – štíhlý, just in time, „systém tahu“ - je v mnohém podobný agile a vzájemně se prolínají. Jako u agile jde o přístup, nikoli o striktní proces – pro výsledky je třeba porozumět filosofii. Je to omezení práce na tom, co by nemuselo přinášet hodnotu a přišlo by nazmar. Příkladem je Toyota, která řídí výrobu systémem tahu, kde vyrábíme příslušný díl, až když je opravdu potřeba.
Metoda, která aplikuje na softwarový vývoj „leanu“ se jmenuje Kanban a stojí někde na pomezí agilních metod a „leanu“.
Nejčastější důvody pro přechod na agilní metody:
-flexibilita – všichni chtějí všechno hned, výsledky po malých kouscích, ideálně hned a vědět jak jsou hotové
-efektivita – spolupráce ve více lidech je výrazně efektivnější než práce jednotlivce, v týmu si pomáhají, sami se organizují, řídit funkcionalitu – možné ušetřit až 80% času
-předvídatelnost – odhadování v relativních jednotkách a to v celém týmu, rozdělení projektu na malé kousky, na malém úseku se méně projevuje tzv. studentský syndrom a úsilí, které tým investuje, je stabilnější, bez výkyvů a stresu na konci
-kvalita – zapojení do produktu zákazníka, ukazování výsledků po malých kouscích, tím řídíme jeho očekávání, celý tým je zodpovědný za kvalitu výsledku, tím se sníží počet chyb a vzroste dlouhodobá udržitelnost
Popis metod, procesů, praktik a artefaktů
Scrum – proces postavený na týmové spolupráci, zapojení zákazníka a pravidelné zpětné vazby v krátkých sprintech, Scrum je v současnosti jedna z nejčastěji využívaných agilních metod, je založen na principu self-organized týmu, transparentní komunikaci a otevřené kultuře, která podporuje spolupráci a sdílení informací
-role:
Scrum Master – pomáhá týmu dosáhnout jeho cílů, odstraňuje problémy, motivuje tým k lepším výsledkům, chrání tým před vnějšími vlivy, které by ho mohly odvádět od soustředěné práce na definovaném cíli, neměl by být direktivní
Product Owner – udává týmu směr a priority, je vlastníkem produktu, definuje vize projektu transparentní komunikaci týmu, zákazníkům, firmě, zodpovědný za celý Product Backlog, má na starosti Business Value a ROI celého podniku
Self-organised tým
Retrospektiva je velice důležitá pro konec sprintu a je jedním ze základních prostředků, jak týmu umožnit získat sám na sebe zpětnou vazbu a ovlivňovat to, jak pracujeme, jak se bude pokračovat co zlepšit anebo změnit
Sprint – Scrum celý vývojový proces rozděluje na pravidelné cykly/sprinty, ve kterých tým dodává hotovou funkcionalitu, délka – vždy trochu jiná, musí být ale dostatečně dlouhý, abychom stihli jako tým něco dokončit a prezentovali tak hotovou funkcionalitu.
Sprint je fixní časový úsek, ve kterém tým zpracovává funkcionality ze Sprint Backlogu a na jehož konci tyto funkcionality prezentuje na zákaznickém demu v rámci Sprint Review. Obecně se doporučuje mít Sprint 1-4 týdny dlouhý (ideální většinou dva týdny).
Kanban je metodika na pomezí Agile a Lean fungující na principech vizualizace procesu, omezení rozpracované práce a minimalizace času potřebného na dokončení jednotlivých celků.
Product Backlog je prioritizovaný seznam funkcionality (user stories), kterou chceme dodat zákazníkovi. Je vytvářený a udržovaný Product Ownerem, vždy přístupný celému týmu před začátkem, ale i během práce na produktu.
ATP
Na Agile jsme měli TS, kde jsme probrali a zopakovali teorii Agilního řízení. Měli jsme zákaznickou schůzku v Tmobile, kde jsme mohli slyšet i příklady z praxe a z reálného fungování ve firmě a v týmech. Toto řízení se dá použít u řízení našich BG, kde bychom si mohli dělat pravidelně checkpointy se zadavatelem. Do určité míry to děláme, ale checkujeme si jen, jestli dobře rozumíme zadání, ale ne už sdílení našich výstupů a jeho představy, zdali jsou sjednocené.
