Agilní metody řízení projektů

Proč jsem si vybrala tuto knihu?

Knížku agilní metody řízení projektů jsem četla z doporučení od našeho kouče Jonáše, z důvodu mého projektu na weby. Po přečtení zadní strany knihy jsem si řekla, že to pravděpodobně moc nevyužiji. Opak je pravdou, kniha je naplněná mnoha, pro mě novými pojmy, rolemi a metodami a už se nemůžu dočkat až vše vyzkouším v našem projektu. 

Úvod

Kniha hned ze začátku popisuje celou metodologii agilní metody, co je to "lean", scrum, kanban a další. Samotná knížka je rozdělena na pět částí. Nejdůležitější myšlenka na začátek je asi ta, že být "agilní" znamená žít agilní filosofií a tudíž v knize není žádný přesný postup jak dosáhnout toho, aby tým byl agilní.

Výtažky z knihy: 

• MANIFEST AGILNÍHO VÝVOJE SOFTWARU - hodnoty
• 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

Tyto hodnoty hned, jak jsem si přečetla moc dobře chápu a souhlasím s nimi. Rozhodně v projektu hodlám dbát spíše na to, aby web, či aplikace byla v nějakém fungujícím stavu, než-li aby byla uživatelská dokumentace skvěle sepsaná. S čím dále plně souhlasím, tak s reagováním na změny před dodržováním plánu. Nejsem zrovna takový typ, co by musel jet vyloženě podle plánu a když se změní, neví co dělat. Tudíž přizpůsobovat se novým událostem a věcem mi nedělá problém a jsem ráda, že je to v agilní metodě řízení naopak vyhledáváno.

• "LEAN" 
• Hlavní princip procesu lean je - JUST IN TIME - což znamená, dělejte věci, jen když jsou potřeba
• Principy:
• Odstraňte vše, co nepřináší hodnotu - pracovat na něčem co se potom vyhodí, nemá cenu
• Zlepšujte se a učte se již v průběhu - je důležitá ZPĚTNÁ VAZBA!
• Rozhodujte se co nejpozději - čím déle rozhodnutí padne, tím více máme informací
• Dodávejte práci, jak nejrychleji to jde - čím dříve dokončíme úkol, tím dříve dostaneme zpětnou vazbu
• Dejte týmu důvěru a zodpovědnost - větší motivace v týmu
• Zaměřte se na celkový výsledek - "Think big, act small, fail fast, learn rapidly!"

Zde jsem měla největší uvědomění pravděpodobně v bodě - Zlepšujte se a učte se již v průběhu - je důležitá ZPĚTNÁ VAZBA! Že je zpětná vazba důležitá vím, ale nevěnovala bych tomu v projektu bez této knihy takovou pozornost si myslím. Proto je to hlavní věc, kterou chci v projektech zavést.

• DŮVODY PRO PŘECHOD NA AGILNÍ METODY 
• Flexibilita - v dnešní rychlé době všichni chtějí všechno nejlépe hned a proto dostávají díky agilní metodě výsledky po kouscích hned, jak jsou části hotové. Zákazník si poté sám vybere, kdy je pro něj práce dostačující.
• Efektivita - je mnohem více efektivní pracovat ve dvou a nebo v celém týmu. Proto je tato metoda je efektivnější, kvalitnější a rychlejší, než když každý pracuje sám.
• Předvídatelnost - odhady jak dlouho nám jaká práce zabere se zde odhaduje v relativních jednotkách a celkovou náročnost odhaduje spolu celý tým.
• Kvalita - do produktu zapojíme zákazníka a tým děláme zodpovědné za kvalitu výsledku.
• Zábava - všichni vidí smysl v tom, proč to dělají a rozumí produktu a zákazníkovi. Díky tomu je tým více namotivovaný a chce spolu spolupracovat a to přináší onu zábavu.

Nejvíce mě v této část zaujala efektivita a hned na druhé schůzce našeho projektu jsem to vyzkoušela a jsem zvědavá na výsledky. K jednomu zkušenějšímu členovi týmu jsem přiřadila nadšeného nováčka, co se teprve zaučuje a budou pracovat spolu na jedné věci. Spolupráce by měla probíhat tím způsobem, že většinu času nováček vše vytváří a zaběhnutý člen týmu mu říká co dělat a vysvětluje proč.

• Organizace je tak dobrá, jak dobré má leadery.
• Odpovědnost se z jednotlivce přenáší na tým.
• Organizace potřebují tvořit adaptivní sítě, které jsou inovativní a kreativní a rychle reagují na změnu prostředí.
• Decentralizujte, tvořte sítě a komunity.
• Umožněte autonomní rozhodování v rámci dobře definovaného prostoru.

• SCRUM MASTER 
• Kouč, facilitátor, servant leader.
• Jeho cíl - vytvořit samostatný, efektivní a spokojený self-organized tým
• Pomáhá týmu aby dobře fungoval.
• Dobrou facilitiací pomáhá týmu odstraňovat problémy
• Motivuje tým k lepším výsledkům
• Koučuje tým a stará se o jeho rozvoj
• Musí být empatický, komunikativní, dobrý facilitátor, kouč a agilní nadšenec
• Technicky nejzkušenější člen týmu obvykle není dobrým Scrum Masterem

• PRODUCT OWNER - VLASTNÍK PRODUKTU
• Definuje produktovou vizi a její následnou komunikaci týmu, zákazníkům a firmě.
• Má na starosti business hodnotu a návratnost investice celého projektu.
• Jeho čas se dělí na 80% u zákazníka, 20% v týmu
• Musí vyvážit obě funkce své role - znát zákazníka a být s ním v kontaktu a zároveň být k dispozici týmu.
• Komunikativní člověk se silnými znalostmi produktu

Tuto roli se pokusím v našem projektu zastávat já, jako projektový manažer tohoto projektu. Nějakou takovouto představu jsem o tom měla již předtím, ale teď se mi to alespoň pojmenovalo a více definovalo a ukázalo směr, kterým se mohu vydat a vést tým.

• MANAŽER 
• Odpovědnost vytvořit prostředí, ve kterém agilní týmy můžou dobře fungovat a zlepšovat se.
• Pomáhá řešit Scrum masterovi problémy, na které už nestačí jako kouč.
• Role manažera se v agilním světě mění směrem k agilnímu leadershipu, a je tak ještě důležitější než v klasickém světě.
• Agilní organizace od manažerů potřebují jiný styl leadershipu, který podporuje rozvoj leadershipu v rámci organizace.

• PROJEKTOVÝ MANAŽER 
• V agilních firmách je tato role nepotřebná a vše zastane Product owner a backlog.
• Tito lidé se většinou stávají product ownery nebo scrum mastery, nebo stakeholdery.

• PRIORITIZACE
• Základní vlastnost product ownera, je prioritizace.
• Je to schopnost, rozhodnout se které položky na backlogu má tým následující sprint pracovat.
• Spravný product owner by měl být schopný se rozhodnout a dokázat prioritizovat, protože on je zodpovědný za výslednou úspěšnost projektu.
• 80% business hodnoty je skryto v 20% funkčnosti
• 65% úspěšně dodaného produktu se nikdy nepoužije.
• Product Owner musí umět identifikovat potřebu, ne dělat vše, co zákazníci chtějí

Pro mě je zde klíčová poslední věta a to umět identifikovat potřebu, ne dělat vše, co zákazníci chtějí. Je to myšlenka nad kterou budu přemýšlet vždy při rozdávání úkolů, co kdo má udělat. Dále se zde zase potvrdilo Paretovo pravidlo.

• SPRINT 
• Pravidelně se opakující věci jsou pro lidi z psychologického hlediska příjemné a snadno si na ně zvyknou. Proto Scrum, rozděluje celkový proces na pravidelné sprinty, které tým plní. 
• Cílem sprintu není dodat všechny položky sprint backlogu, ale dosáhnout cíle sprintu. 

• Jak nastavit sprinty: 
• Když nevíme jak žačít - začněme 2 týdny - delší sprinty nemají smysl, vůči zpětné vazbě 
• Pokud nestíháme dokončit úkoly do konce sprintu, neprodlužujme sprint ale rozložme úkoly na jednodušší úkony
• Cíl sprintu by se neměl během sprintu měnit a je na týmu aby se zorganizoval a pro splnění cíle udělal maximum 

Sprinty jsme si zavedli v takové "demo" verzi již u nás na náš první projekt, na kterém již pracujeme. Bohužel ale nikdo kromě mě zatím tuto knihu nečetl a tak neví jak funguje tato metoda a tudíž, za krátký čas nevysvětlím co po nich chci, natož aby si sami určili co stihnou za sprint udělat, když se tam půlka teprve učí základy. Ale máme nastavený časový úsek a rozdělené co kdo děla, s tím že si můžou navzájem kdykoli pomoci a plán co zvládneme za tu dobu - který jsem nyní nastavila já. 

• INVEST kritéria 
• I - Independent - nezávislý - user strories musí být na sobě nezávislé. Jedna funkcionalita vede k druhé. 
• N - Negotiable - otevřený diskusi - Product Owner musí umět vyprávět příběhy, funkcionalitou žít. Díky tomu tým bude chápat pohled zákazníka a dodá kvalitní řešení problému. 
• V - Valuable - musí mít hodnotu - Zákazník musí vidět hodnotu toho co děláme. 
• E - Estimable - ohodnotitelný - User stories hodnotí tým a aby mohl funkcionalitu ohonotit, musí jí rozumět. 
• S - Small - malá - tým by měl být schopen práci určenou na celý sprint dokončit ideálně za nejdéle půlku sprintu. 
• T - Testable - otestovatelná - "Jak poznáme, že jsme dosáhli požadovaného výsledku?"

Každá User Story by měla být nezávislá, otevřená diskusi, mít hodnotu pro zákazníka, být ohodnotitelná týmem, malá a testovatelná. 

• PLANNING POKER - hra
• Cílem hry a týmu je se domluvit. Není to o kompromisu, ale shodě týmu. 
• Každý má karty s čísly od 0 po nekonečno a také s kafem a s otazníkem. 
• Každý s týmu hodnotí danou funkcionalitu jednou kartou a poté se Product owner zeptá na nejvyšší a nejnižší hodnocení a poté tým vede diskusi a shodne se na nějakém řešení