načítání...
nákupní košík
Košík

je prázdný
a
b

E-kniha: Agilní metody řízení projektů - Eduard Kunce; Zuzana Šochová

Agilní metody řízení projektů

Elektronická kniha: Agilní metody řízení projektů
Autor: ;

Pracujete jako vývojáři v týmu? Chcete pracovat efektivněji? Seznamte se s agilními metodami, pomocí nichž budete vyvíjet rychleji, efektivněji, s menším počtem chyb. Vaši ... (celý popis)
Titul je skladem - ke stažení ihned
Médium: e-kniha
Vaše cena s DPH:  149
+
-
5
bo za nákup

hodnoceni - 77.2%hodnoceni - 77.2%hodnoceni - 77.2%hodnoceni - 77.2%hodnoceni - 77.2% 90%   celkové hodnocení
3 hodnocení + 0 recenzí

Specifikace
Nakladatelství: » Computer press
Dostupné formáty
ke stažení:
PDF
Upozornění: většina e-knih je zabezpečena proti tisku
Médium: e-book
Počet stran: 175
Rozměr: 21 cm
Úprava: ilustrace , portréty
Vydání: 1. vyd.
Jazyk: česky
Téma: agilní metody
ADOBE DRM: bez
ISBN: 978-80-251-4194-6
Ukázka: » zobrazit ukázku
Popis

Pracujete jako vývojáři v týmu? Chcete pracovat efektivněji? Seznamte se s agilními metodami, pomocí nichž budete vyvíjet rychleji, efektivněji, s menším počtem chyb. Vaši zákazníci dostanou zakázku dříve a bude odpovídat tomu, co skutečně potřebují. Jejich spokojenost se pozitivně odrazí na případném doporučení.

Dvojice autorů, která se v oblasti agilních metod pohybuje řadu let a pracuje s nimi denně, vás seznámí nejen s tím, co agilní přístup znamená, ale i jak jej správně nasadit. Na řadě příkladů poznáte možná úskalí jejich nasazení a dozvíte se, jak z nich může váš tým profitovat. Kniha je zaměřena na širokou oblast profesí od vývojářů a testerů přes designéry, architekty a analytiky až po projektové a produktové manažery, vedoucí oddělení a manažery či ředitele celých společností.

Publikace vás mimo jiné naučí:
- Co představují agilní metody
- Jaké role participují na agilním přístupu
- Rozvrhnout projekt na dílčí celky
- Nastavit procesy v rámci týmu
- Správně implementovat agilní metody v organizaci


O autorech:

Zuzana Šochová se věnuje agilnímu koučování, školením a konzultacím. S agilními metodami a jejich nasazováním má dlouhodobé zkušenosti, v současné době spolupracuje s řadou softwarových firem.

Eduard Kunce je dlouholetým propagátorem agilních praktik nejen v tuzemsku, ale i v zahraničí. Specializuje se na jejich zavádění ve velkých společnostech, je Akreditovaným profesionálním koučem s několikaletou praxí.

Předmětná hesla
Zařazeno v kategoriích
Eduard Kunce; Zuzana Šochová - další tituly autora:
Recenze a komentáře k titulu
Zatím žádné recenze.


Ukázka / obsah
Přepis ukázky

Zuzana Šochová, Eduard Kunce

Agilní metody řízení projektů

Computer Press

Brno

2014


Agilní metody řízení projektů

Zuzana Šochová, Eduard Kunce

Obálka: Martin Sodomka

Odpovědný redaktor: Martin Herodek

Technický redaktor: Jiří Matoušek

Objednávky knih:

http://knihy.cpress.cz

www.albatrosmedia.cz

eshop@albatrosmedia.cz

bezplatná linka 800 555 513

ISBN 978-80-251-4194-6

Vydalo nakladatelství Computer Press v Brně roku 2014 ve společnosti Albatros Media

a. s. se sídlem Na Pankráci 30, Praha 4. Číslo publikace 18 468.

© Albatros Media a. s. Všechna práva vyhrazena. Žádná část této publikace nesmí

být kopírována a rozmnožována za účelem rozšiřování v jakékoli formě či jakýmkoli

způsobem bez písemného souhlasu vydavatele.

1. vydání


3

Obsah

Úvod 9

Zpětná vazba od čtenářů 10

Errata 10

ČÁST I

FILOZOFIE AGILNÍCH A LEAN METOD

KAPITOLA 1

Agilní a Lean metody 13

Co si představíte pod slovem „Agilní“? 13

Manifest Agilního vývoje software 14

Jednotlivci a interakce před procesy a nástroji 14

Fungující software před vyčerpávající dokumentací 15

Spolupráce se zákazníkem před vyjednáváním o smlouvě 16

Reagování na změny před dodržováním plánu 17

Co je to „lean“? 18

KAPITOLA 2

Transformace na agilní metody 21

Vývoj Software 21

Proč vůbec něco měnit 22

Jaké jsou nejčastější důvody pro přechod na agilní metody? 23

ČÁST II

POPIS METOD, PROCESŮ, PRAKTIK A ARTEFAKTŮ

KAPITOLA 3

Agilní slovníček 27

KAPITOLA 4

Role 31

Scrum Master 31

Product Owner 33

Self-organized tým 34

Scrum tým 35

Zákazník 37


4

Obsah

Product Owner Proxy 39

Role manažera 39

Role projektového manažera 41

KAPITOLA 5

Artefakty 43

Sprint 43

Product Backlog 45

Sprint Backlog 47

User Story 48

INVEST kritéria 50

Epic a Super User Story 52

Akceptační kritéria 53

Done kritéria 53

Dobrá vizualizace 54

Scrum tabule 55

Kanban Tabule 56

Kdy potřebujeme nástroj? 56

Ohodnocení 58

Relativní jednotky versus odhad času 60

Planning Poker 61

Rychlost 63

Burndown graf 64

KAPITOLA 6

Meetingy 67

Standup / Scrum Meeting 67

Retrospektiva 70

Jak začít? 71

Retrospektiva s lepítky 72

Časová osa 73

Další metody, jak retrospektivu občerstvit 75 Prioritya Prelanning 76 Plánování – Planning 79 Sprint Review 81 Backlog Grooming 83

KAPITOLA 7

Agilní programování – artefakty 85

Pair Programming 85

Review 86

Sdílený kód 86


Obsah

5

Coding Standard 87

Jednoduchý design 88

Continuous Integration 89

Test Driven Development – TDD 90

Refaktorování 90

Časté releasy 91

Žádné přesčasy 91

Společný cíl 92

Technický dluh 92

KAPITOLA 8

Scrum 1-1 a škálovatelnost Scrumu 95

Příprava Scrumu – Sprint 0 98

Scrum pro více týmů 98

Scrum of Scrums a další synchronizační meetingy 99

KAPITOLA 9

Extreme Programming 1-1 101

KAPITOLA 10

Kanban 1-1 105

KAPITOLA 11

Jak funguje tým 107

Tuckman’s Group Development Model 107

Pět důvodů proč týmy nefungují 110

Důvěra 111

Strach z konfl iktu 111

Nedostatek ochoty k závazku 111

Jak funguje zodpovědnost 112

Neochota převzít odpovědnost 113

KAPITOLA 12

Smlouvy a formy spolupráce 115

Fixed Time, Fixed Price 116

Agilní smlouva 117

KAPITOLA 13

Otázky na závěr 119

Jsou agilní metody a Scrum vhodné pouze pro malé fi rmy? 119

Má Scrum smysl jen na projektech, kde se často mění zadání? 119

Je vhodné zavádět jednotlivé metody postupně? 120


6

Obsah

Pro které fi rmy agilní přístup není vhodný? 120

Musí tým sedět společně v jedné místnosti? 120

Musí být jednotliví členové v týmu alokovaní na plný úvazek? 121

Jak moc nám agilní metody můžou pomoct? 121

ČÁST III

IMPLEMENTACE, TRANSFORMACE, ZMĚNA

KAPITOLA 14

Průvodce agilní změnou 125

Proč agilně 125

Bude to Zig-Zag 127

KAPITOLA 15

Co mám dělat, když... 129

Co mám dělat, když jsem malá fi rma? 129

Co mám dělat, když jsem středně velká fi rma? 130

Co mám dělat, když jsem velká fi rma? 131

Top-down 131

Bottom-up 132

Co mám dělat, když děláme jen migraci? 134

Co mám dělat, když jsme projektově organizovaná fi rma? 135

Co mám dělat, když máme distribuovaný tým? 136

KAPITOLA 16

Jak stavět Product Backlog 139

Product Discovery 139

Story Mapping a Project Chartering 141

KAPITOLA 17

„Best Practices“ Scrumu 147

KAPITOLA 18

Agilní organizace a Tulming metoda 151

Tulming metodika 153

KAPITOLA 19

Ohodnocování a metriky 155


Obsah

7

ČÁST IV

PŘÍKLADY

KAPITOLA 20

Průvodce agilní transformací –

co budete při zavádění Scrumu potřebovat 159

Role 159

Artefakty 160

Praktiky 161

KAPITOLA 21

Ukázka Backlogu 163

Závěr 165

O Autorech 167

Zuzana Šochová 167

Eduard Kunce 168

Ostatní kontakty: 168

Agilní Asociace 168

Agile Prague Conference 169

Rejstřík 171



9

Úvod

Dostává se vám do ruky publikace o agilních metodách. Snažili jsme se čtivoufor

mou popsat všechna možná zákoutí a nástrahy, které vás při přechodu na agilníme

tody mohou potkat. Kniha nepopisuje pouze to, co to agilní metody jsou, jak funguje

Scrum a Kanban a jak by jednotlivé artefakty těchto procesů měly správně vypadat,

ale primárně se snaží vysvětlit fi lozofi i agilního přístupu a zaměřit se na vysvětlení,

proč jednotlivé metody fungují. Součástí textu jsou praktické příklady a doporučení,

co dělat a čeho se naopak vyvarovat.

Kniha se zabývá agilními metodikami vývoje soft waru v různých typechspolečnos

tí, od malých fi rem až po nadnárodní korporace. V první části knihy jsou popsány

základní stavební prvky agilního vývoje, od vlastní defi nice procesu až po ukázky

z praxe. Čtenář se dozví všechny potřebné informace k adopci agilních metodik,kul

turní odlišnosti agilních fi rem a další základní stavební kameny nutné pro úspěšnou

adopci agilních principů. Kniha dále obsahuje podrobný popis rolí, které se typicky

vyskytují v agilně řízených fi rmách. Vedle těchto popisů obsahuje kniha i „kuchařky“,

resp. doporučené postupy adopce agilního řízení pro různé velikosti a typy fi rem.

V posledních 10 letech se agilní metody staly ve světě velmi populární. Používají je

velké nadnárodní korporace jako Amazon, Salesforce, Oracle či Google, najdete je na

univerzitách, v telekomunikacích, v bankách a pojišťovnách, v armádě, aerolinkách,

automobilovém průmyslu, medicínských fi rmách a samozřejmě i v mnoha malých či

středních fi rmách. V České republice se dostávají do povědomí fi rem až v posledních

několika letech, ale být agilní a používat Scrum či Kanban již dávno není výjimkou,

a agilní metody se tak stávají na českém trhu běžnou metodikou.

Kniha je primárně určena pro lidi pracující v ICT, a to ja k pro soft warové vývojáře,

testery, designéry, architekty a analytiky, tak i projektové a produktové manažery,ve

doucí oddělení, manažery i ředitele či vlastníky takových organizací. Přestože agilní

metody byly primárně defi nované pro zlepšení a zefektivnění vývoje soft waru,pou

žívají se v podstatě kdekoli, kde je třeba řídit projekty, organizovat týmy lidí a kde je

výsledný produkt komplexní a pro jeho úspěch je vyžadována kreativita, fl exibilita,

schopnost reagovat na změny (např. v  marketingových či re klamních agenturách,

konzultantských společnostech nebo hardwarových fi rmách). Máte-li na starostině

jaký projekt nebo tým lidí, určitě je tato kniha pro vás.


10

Úvod

A kladete si hned v začátku otázku, co můžete spolu se zavedením agilních metod

očekávat? Určitě vyšší fl exibilitu a schopnost reagovat na změny, vyšší efektivitu,kvalitnější produkt, větší předvídatelnost termínu dodání a vyšší spokojenost zákazníka

s vaším produktem či službou a v neposlední řadě motivovaný tým, který sespoluodílí na produktu a jeho inovacích. Tedy jednoduše řečeno: být úspěšnější.

Autoři vycházejí z vlastní zkušenosti s nasazováním agilních metodik v různýchprostředích fi rem, od malých startupů až po mezinárodní korporace. Ze svých bohatých

zkušeností autoři vybrali vše podstatné a srozumitelnou formou předkládají čtenáři

návod, jak postupovat, od prvních krůčků až po kompletní agilní transformaci celé

společnosti.

Zpětná vazba od čtenářů

Nakladatelství a vydavatelství Computer Press, které pro vás tuto knihu připravilo,

stojí o zpětnou vazbu a bude na vaše podněty a dotazy reagovat. Můžete se obrátit

na následující adresy:

Computer Press

Albatros Media a.s., pobočka Brno

IBC

Příkop 4

602 00 Brno nebo

sefredaktor.pc@albatrosmedia.cz Computer Press neposkytuje rady ani jakýkoli servis pro aplikace třetích stran. Pokud budete mít dotaz k programu, obraťte se prosím na jeho tvůrce. Errata Přestože jsme udělali maximum pro to, abychom zajistili přesnost a  správnost obsahu, chybám se úplně vyhnout nelze. Pokud v některé z našich knih najdete chybu, budeme rádi, pokud nám ji oznámíte. Ostatní uživatel e tak můžete ušetřit frustrace a pomoci nám zlepšit následující vydání této knihy. Veškerá existující errata zobraz íte na adrese http://knihy.cpress.cz/K2140 po klepnutí na odkaz Soubory ke stažení.


11

ČÁST I

FILOZOFIE AGILNÍCH

A LEAN METOD  KAPITOLA 1 – Agilní a Lean metody  KAPITOLA 2 – Transformace na Agilní metody



13

KAPITOLA 1

Agilní a Lean

metody

Co si představíte pod slovem „agilní“?

Agilní je dynamický, rychlý, interaktivní, přizpůsobivý, iterativní, zábavný, hravý,

rychle reagující na změnu... a  jistě vymyslíte spoustu dalších synonym. Je to jiný

způsob života, upřednostňující jiné hodnoty: reálný výsledek před striktními procesy,

změnu před předem naplánovaným. Být agilní znamená žít agilní fi losofi í. Přináší to

odlišnou fi remní kulturu a náladu. Ale jestli čekáte kuchařku, jak se stát agilní,budete zklamaní. A jestli očekáváte nějaký model či framework s několika stupni agility,

nebo dokonce checklist, tak vás bohužel zklameme. Nic takového nehledejte, protože

to ani neexistuje, ač mnoho certifi kovaných hlav tvrdí pravý opak. Žádný certifi kát

agility vám v pochopení nepomůže, maximálně může nastartovat proces přeměny.

Ale agilní musíte být, agilně musíte myslet, agilně se chovat.

Ale nebojte se, není to zas tak neuchopitelné, jak se na první pohled zdá. Agile je

o  spolupráci a  komunikaci a  připravenosti na změnu. Děláme zásadně to, co má

v danou chvíli smysl, a děláme to tak, jak nejlépe umíme. Nejde sice o žádný striktní

proces, ale není to ani žádný chaos. Má svá jasná pravidla. Dalo by se říct, že defi nuje

hranice a vytyčuje menší hřiště, v jejichž rámci si týmy mohou stanovovat svá vlastní

pravidla hry, tak aby se jim dobře pracovalo a byly co nejvíce produktivní, efektivní

a dodali kvalitní produkt v co nejkratším čase. Takový tým je zaměřený na business

value, tedy hodnotu pro zákazníka. Na to, jak optimalizovat funkcionalitu tak, aby

zákazník byl maximálně spokojený a dostal za vynaložené prostředky to, co opravdu

potřebuje a může používat.

V této kapitole:

 Co si představíte pod

slovem „agilní“?

 Manifest agilního

vývoje softwaru

 Co je to „lean“?


14

ČÁST I FiloZofi e Agilních a Lean metod

Základním stavebním kamenem je – jak jinak – manifest; v  tomto případě přímo

agilní manifest, který shrnuje ve čtyřech bodech, co to vlastně znamená být agilní.

Manifest agilního vývoje softwaru

http://agilemanifesto.org

Objevujeme lepší způsoby vývoje soft waru tím, že jej tvoříme a pomáháme při jeho

tvorbě ostatním. Při této práci jsme dospěli k těmto hodnotám:

 Jednotlivci a interakce před procesy a nástroji

 Fungující soft ware 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 Jakkoliv jsou body napravo hodnotné, bodů nalevo si ceníme více. Pojďme sespolečně chvíli zamyslet nad tím, co nám vlastně manifest říká. Jednotlivci a interakce před procesy a nástroji Je známým faktem, že spolupracující týmy mají lepší výsledky než skupinyindividuálně pracujících jednotlivců. Procesy a nástroje jim pomáhají dosáhnout výsledků, ale nejsou pro jejich úspěch nijak klíčové. Pojďme se podívat na dva odlišné týmy. V prvním máme 10 profesionálů, kteří si vytvořili vlastní nástroje a pracují v silně kolaborativním prostředí, ve druhém máme 10 vývojářů, kteří pracují v přesně defi - novaném procesním prostředí s nejlepšími nakoupenými nástroji, ale bez interakcí a spolupráce. Co myslíte, který z těchto týmů vytvoří lepší soft ware v kratším čase? Myslím, že se shodneme na tom, že první tým má větší šanci uspět, protože vzájemná spolupráce a komunikace mnohokrát převáží přesně defi nované procesy a nástroje. Ostatněpodívejme se na úspěšné startupy, kde moc procesů nenajdeme, zato všichni překypují spoluprací a komunikací. Hlupák i s nejlepším nástrojem je zkrátka pořád hlupák. Na druhou stranu, manifest neříká nic o tom, že procesy a dohody my neměly existovat ani že by týmy měly pracovat zcela bez nástrojů. Jen by měly mít možnost si nástroje vybrat a používat jen ty, které jim opravdu pomáhají v dosažení kvalitního výsledku.


KAPITOLA 1 Agilní a Lean metody

15

Fungující software před vyčerpávající dokumentací

Když se zeptáte zákazníků, zda by si koupili dokument popisující váš popisplánova

ného produktu s architektonickou dokumentací, nebo ten samý produkts minimál

ní dokumentací, co si vyberou? Nebo praktičtější příklad: Když si jdete koupit nový

mobilní telefon, vyberete si pouze podle technické specifi kace na papíře, nebo bude

pro vás důležité si vyzkoušet i vlastní telefon před tím, než si ho koupíte? A když si

koupíte nový televizor, přečtete si nejdříve manuál, nebo chcete vyzkoušet, jakfun

guje, a manuál čtete až na posledním místě? Lidé (ano, i zákazníci jsou lidé) zkrátka

preferují praktické seznamování s produktem.

Mnoho soft warových fi rem na toto zapomíná a chce ohromit zákazníka množstvím

dokumentace, ale když dojde na vlastní demo, výsledek často dokumentaci odporuje

a zákazník je z „funkčního“ soft waru poněkud překvapený. Dokumentace je důležitá,

ale neměla by převážit nad vlastním produktem; měla by primárně sloužit jakorefe

rence pro oblasti, které nejsou intuitivní a snadno pochopitelné. A takových oblastí

by mělo být minimum.

Interní dokumentace se často píše pro budoucí týmy, aby se znalost architekturypro

duktu neztratila. To samo o sobě není nijak špatný nápad, ale už jste někdyzkouše

li něco dohledat v deseti úrovních dokumentů, z nich každý má aspoň 1 000 stran?

Vyčerpávající. A když už si dáte tu práci a prohledáte tu kupu slov, v devíti z deseti

případů zjistíte, že daná věc v dokumentaci chybí či je v poslední verzi již zcela jinak.

Interní dokumentace by měla být stručná a postihnout klíčové informace. Ostatní je

obvykle efektivnější dokumentovat přímo v kódu.


16

ČÁST I FiloZofi e Agilních a Lean metod

Poslední případ je dokumentace funkcionalit v průběhu vývoje, kterou můžetev pod

statě úplně odstranit a nahradit dobrou komunikací mezi analytiky, testery a vývojáři.

Ti se pak sami domluví, co je třeba zdokumentovat pro „budoucí generace“ vývojářů

a testerů a v jaké podobě. Na závěr připomeneme, že nedoporučujeme přestatdo

kumentovat, ale jen dokumentaci omezit na minimum, aby poměr mezi námahou

a časem, který investujete do psaní dokumentace, odpovídal hodnotě, kterou jejízá

kazníci, tedy všichni, kteří ji kdy čtou, z takovéto dokumentace načerpají.

Spolupráce se zákazníkem před

vyjednáváním o smlouvě

Proč vlastně vytváříme nějaký produkt? Chceme ho prodat, že? Když stavíme produkty

pro zákazníky, je dobrý nápad se jich zeptat, co vlastně chtějí koupit. Jistě, zákazník

mnohdy neví, co vlastně chce, a často mění názor, ale dlouhodobou spolupracímů

žeme zákazníka „vychovat“ a společně vytvořit spolupracující tým, který zajistí jak

úspěch náš, tak úspěch zákazníka. Je lepší se se zákazníkem dohodnouta spolupra

covat než se potkávat pouze u soudu a komunikovat přes právní zástupce.

Smlouvy jsou důležité, ale neměly by být prostředkem nahrazujícím spoluprácia ko

munikaci. Je důležité se už při jejím podpisu zamyslet nad tím, co se při spolupráci

může stát. Je třeba si uvědomit, že zákazník možná ne vždy ví přesně, co přesně chce,

a že se stejně bude měnit rozsah a smlouvu se pokusit přiblížit realitě.


KAPITOLA 1 Agilní a Lean metody

17

Spokojený zákazník, který dostal to, co potřebuje, vás doporučí dalším fi rmám,za

tímco zákazník, který sice má to, co si objednal a ve smlouvě podepsal, ale nijak mu

to v jeho misi nepomohlo, se příště podívá po jiném dodavateli. Smlouvy určitěpiš

te, ale ani sebelepší smlouva vás neochrání před změnami, které přijdou. Obvykle to

stejně bez ohledu na smlouvu skončí kompromisem, kdy po měsících hádek o chyby

a požadavky na změny jich dodavatel polovinu dodělá jako opravu na vlastní náklady

a polovinu jako novou funkčnost za extra peníze od zákazníka. Vzájemnéspokoje

nosti a dobrým vztahům to nijak nepomůže.

Reagování na změny před dodržováním plánu

Svět se pořád hýbe kupředu a technologie se neustále mění a spolu s nimi se mění

i požadavky a problémy našich zákazníků. Ti, jako všichni ostatní, se musípřizpů

sobovat trendům na trhu a  konkurenci. A  my, jako jejich dodavatel, je nemůžeme

v těchto změnách brzdit – tedy pokud chceme dále spolupracovat. Představte si, že

zákazník přijd e se změnou v posledních fázích projektu a ta změna bude důležitá pro

jeho přežití na trhu.

Řeknete mu, že se budete držet plánu a kontraktu a změny přijdou až po doručení

první verze. A opravdu si myslíte, že další změny budou? Odvážím se tvrdit, že pokud

se my nepřizpůsobíme, náš zákazník už si nic dalšího nekoupí, zkrátka proto, že ho

konkurence převálcuje. Podobně je to i v méně vyhraněných případech, kdy zákazník

prostě jen zjistí, že to, co původně tolik chtěl, vlastně vůbec neřeší jeho problémy a že

by naopak potřeboval něco úplně jiného, o čem se předtím vůbec nemluvilo.


18

ČÁST I FiloZofi e Agilních a Lean metod

Projektové plány jsou důležité jako vodítko, ale neměly by řídit životyspolupracují

cích fi rem. Každé plány se mění a dogmatické dodržování původních plánů mnohdy

vede k větší katastrofě než jejich postupné přizpůsobování dané situaci.

Co je to „lean“?

Lean na druhou stranu je proces převzatý z tovární výroby. Štíhlý. Dělejte věci, jen když

jsou potřeba. Just in time. Často se používá i výraz „systém tahu“. Stejně tak jako „agile“

je i „lean“ spíše o přístupu než striktním procesu. Navíc jsou si oba principy v mnohém

podobné a vzájemně se prolínají. Je to takový pěkný moderní buzzword. Lean fi rma.

Spousty velkých fi rem lean principy implementují, obvykle bez většího porozumění

jejich zaměstnanci. Často to končí tím, že si udělají nějaké lístečky a jsou dostatečně

„lean“, tedy štíhlí. Jenže na to, aby to přineslo nějaké výsledky, je stejně jako u agilních

metod třeba porozumět fi lozofi i. A ne jen slepě vykonávat nějaké rituály. O co tedy

jde? Jednoduše řečeno o omezení práce na tom, co by nemuselo přinášet hodnotu,

a tedy v konečném důsledku mohlo přijít nazmar.

Nejznámější lean fi rma je určitě Toyota. Tam vyvinuli proces řízení výroby odlišný

od běžných procesů, kdy vyrábíme kdykoli a cokoli na sklad. Řídí výrobu systémem

tahu, kde vyrábíme příslušný díl, až když je opravdu potřeba.

Jak takový princip použít ve fi rmách, kde žádné fyzické díly nevyrábíme? Tak setře

ba podívejme na standardní vývojový proces – waterfall. Nejprve uděláme na sklad

analýzu, pak kód a pak testy. A čekáme, že to je tak v pořádku a že všechny díly jsou

kvalitní (tedy že design už se nezmění, v kódu se nenajde chyba a že zákazník to tak

opravdu chce). A stejně jako ve výrobě musíme jednotlivé věci předělat, opravit,za


KAPITOLA 1 Agilní a Lean metody

19

hodit – někdy i celou krabici dílů se stejnou chybou (někdy i celou rozsáhloufunkcionalitu našeho soft waru).

Jak na to? V kostce: Omezte rozdělanou práci („work in progress“) a soustřeďte se na

to, abyste jednotlivé požadavky dokončili co nejrychleji. Implementujte „systém tahu“

a nezačínejte s analýzou, dokud nemáte prioritní požadavek od zákazníka. A dokud

nemáte zpětnou vazbu, že předchozí požadavek byl akceptován.

Aby to bylo celé více uchopitelné, Lean Soft ware Development je založen nanásledujících principech:

 Odstraňte vše, co nepřináší hodnotu – tedy zbavte se odpadu. Pracovat naněčem, co se ve fi nále vyhodí, je škoda času. Když se vám podaří tento časinvestovat do věcí, které mají smysl, budete jistě efektivnější.

 Zlepšujte se a učte se již v průběhu práce – když jen slepě vykonávátepředpisy a sledujete procesy, může se stát, že stejnou chybu opakujete pořád dokola,

a „odpad“ se vám tedy na konci projektu nahromadí víc, než byste si přáli.Pravidelná zpětná vazba vám pomůže se soustředit jen na to, na čem opravdu záleží.

 Rozhodujte se co nejpozději – čím později rozhodnutí padne, tím více máte

informací. Takže jsme zase zpět u myšlenky, že nemá smysl vyrábět zásoby na

sklad jen proto, že zrovna máte volnou linku nebo programátory.

 Dodávejte práci, jak nejrychleji to jde – čím dříve něco dokončíte, tím dříve

dostanete zpětnou vazbu, kterou můžete hned v další iteraci zohlednit.

 Dejte týmu důvěru a zodpovědnost – a budete mít mnohem motivovanější tým,

než když se budete držet tradičních top-down struktur.

 Zaměřte se na celkový výsledek – jednotlivé chyby a selhání nejsou podstatné,

jestliže se z nich poučíte. „Th ink big, act small, fail fast; learn rapidly“ – tedy:Přemýšlejte dopředu, začněte u malých věcí, ty vyhodnoťte a rychle se z nich poučte.

Jen tak zajistíte, že výsledný produkt bude úspěšný. Produkt není jen výsledný

soft ware, zaměřte se na celkový dojem, který produkt vyvolává. Dbejte na kvalitu

a celkovou udržitelnost systému, nevytvářejte technický dluh. Metoda, která aplikuje na soft warový vývoj myšlenky „leanu“, se jmenuje Kanban a  stojí někde na pomezí agilních metod a  „leanu“. Ostatně obě metodiky staví na stejném fi lozofi ckém základu a  je často těžké je oddělit. Tato kniha není primárně o lean principech, ale o agilních metodikách. Takže i když se o „lean“ občas otřeme, do detailu se tím dále zabývat nebudeme.



21

KAPITOLA 2

Transformace

na agilní

metody

Vývoj softwaru

Čím se vlastně vývoj soft waru liší od standardní továrny? A proč klasické metodyřízení projektů právě tady selhávají? Předně je vývoj soft waru komplexní a empirický

problém. Nejde jen tak něco naplánovat a podle plánu vytvořit. Problém je v tom, že

jakákoliv empirická činnost se velmi špatně odhaduje a ještě hůř se plánuje.

Soft warové společnosti s tím zápasí odjakživa. 70 % projektů končí pozdě, jsou mimo

rozpočet (budget) a velmi často dodají něco úplně jiného, než zákazník potřeboval.

Poté následuje nekonečné dohadování o jednotlivých požadavcích, které ovšem končí

vždy stejně – část zaplatí zákazník jako změnu, část dodavatel jako opravu.A o spokojeném zákazníkovi si můžeme nechat zdát.

Prvním problémem je, že zákazník často neví, co chce. Tedy vždy si myslí, že vínarosto přesně, co chce, ale nedokáže to efektivně předat svému dodavateli. Aplikaci si

neumí představit, má jen hrubou představu o tom, jak by mu měla pomoci a urychlit

či jinak zlepšit práci. A typický zákazník už vůbec nerozumí počítačům, neví, proč by

měl použít knihovnu X nebo technologii Y. Bohužel stále většina soft warových fi rem

své zákazníky nutí říct dopředu přesné požadavky s představou, že oni to pak podle

nich jen vyrobí, stejně jako na tovární lince.

Typicky požadavky rozmyslí tým analytiků, popíše, navrhne technologii, architekturu,

design, cosi zdokumentuje a předá vývojářům. Ti interpretují specifi kaci podle svého

V této kapitole:

 Vývoj softwaru

 Proč vůbec něco měnit

 Jaké jsou nejčastější důvody

pro přechod na agilní metody?


22

ČÁST I FiloZofi e Agilních a Lean metod

a něco nakódují. A když zbude čas, hodí to ještě testerům na otestování. Na závěr to

předáme zákazníkovi a o problém je postaráno; s překvapením sledujeme upřímné

zděšení zákazníka následované slovy, že očekával něco jiného. Že pracuje jinak, než

jsme si mysleli, a že naše geniální funkcionality ani nepochopil. A hlavně – vůbecne

ní spokojený. Přitom my jsme napsali přesně to, co si objednal. Výsledek? V mnoha

fi rmách to skončí tak, že „příště si musíme dát pozor a sepsat ještě detailnějšíspeci

fi kaci, aby se nám to nestalo.“ A bludný kruh se uzavírá ... anebo ne?

Proč vůbec něco měnit

Hned na začátku vás musíme upozornit, že vás čeká spousta nelehké práce. Totižza

vádění agilních metodik neznamená jen změnu procesu nebo kolonek naformulá

řích. Iniciátorem celé změny je obvykle palčivý a zdánlivě neřešitelný problém, který

vás pálí natolik, že se vám přechod na agilní metody vyplatí. Každá změna je těžká

a změna kultury rozhodně nejtěžší.

Čeká vás změna fi rmy z hierarchicky řízené na fi rmu orientovanou na problém.Bu

dete chtít dosáhnout něčeho, čemu se říká samoorganizovaný tým. Najednou vaše

práce nebude založená na práci jednotlivců řízených odněkud shora, ale na spolupráci

lidí v týmu, na jejich schopnosti se domluvit, rozhodnout a nést za svá rozhodnutí

odpovědnost. Pro některé fi rmy to zní jako utopie, pro jiné je to blízké tomu, jak již

dnes fungují. V obou případech se ale změní hodně, a to nejen u vývojářů a testerů.


KAPITOLA 2 Transformace na agilní metody

23

Jaké jsou nejčastější důvody pro

přechod na agilní metody?

Flexibilita – donedávna to šlo. Dělali jste releasy jednou za 6–12 měsíců, zákazníci na

to byli zvyklí a fi rma také. Když chtěli nějakou změnu, protáhli jste jí vaší soft warovou

výrobní linkou a při troše štěstí zákazník svou změnu dostal už za několik měsíců. Ale

doba se změnila a najednou všichni chtějí všechno hned. Chtějí dostávat výsledky po

malých kouscích, ideálně ihned, jak jsou hotové. Bohužel toto v současném procesu

není možné. Analytici musí požadavek popsat, vývojáři nakódovat, testeři otestovat

a to není jen tak. Navíc nemůžete releasovat kdykoli. Tím byste ohrozili plán releasu

a celá snaha by skončila chaosem.

Efektivita – máte pocit, že by toho šlo stihnout víc, kdybychom šli všichni za jedním

cílem? Studie ukazují, že spolupráce více lidí je výrazně efektivnější než prácejednot

livců. Co se frameworků týče, máte v podstatě dvě možnosti. Zkusit párovéprogramo

vání, kde máte na všechny činnosti dva lidi, tedy i dva soft warové vývojáře u jednoho

počítače. Zkušenosti ukazují, že tato metodika je efektivnější, kvalitnější a rychlejší,

než když každý z  nich pracuje samostatně. Anebo postavit spolupracující tým, jak

doporučuje Scrum, kdy jednotliví členové spolupracují na jednom výsledku, pomáhají

si a sami se organizují. Chvíli trvá, než si tým na sebe zvykne, ale funguje to skvěle.

Ještě na jeden aspekt se můžete zaměřit. Podívejte se na to, jak řídíte funkcionalitu.

Kdo je zodpovědný za produkt a kdo za konkrétní funkčnost. Dělejte jenom na tom, co

opravdu je potřeba, co zákazník potřebuje a použije. Na tom, co mu přinese v daném

čase co nejvyšší hodnotu. Systémy jsou plné funkcionalit „co kdyby“. Budete-li dobře

řídit funkcionalitu, a i v tom vám agilní metody pomůžou, můžete ušetřit až 80 % času.

Předvídatelnost – jestli vaše projekty končí včas a bez přesčasů před koncemrelea

su, asi vám váš proces funguje dobře. Pokud to tak není, agilní metody vám mohou

pomoci i s tímto aspektem. Tyto metody zavádějí zcela odlišný způsob odhadování.

Odhadují v relativních jednotkách a do odhadování zapojují celý tým. Zprvu to zní

hodně zvláštně, ale přesnost vašich odhadů se časem výrazně zlepší. Rozdělit projekt

na malé kousky je druhou důležitou metodou, jak zlepšit předvídatelnost. Na krátkém

úseku se méně projevuje tzv. studentský syndrom a  úsilí (eff ort), které tým investuje,

je stabilnější, bez výkyvů a stresu na konci.

Kv a l it a – tady cílíme na dvě oblasti. Za prvé zapojíme do produktu zákazníka.Zeptá

me se ho, co chce a proč a také na to, kdo a jak bude produkt používat. Ukazujeme

mu výsledky po malých kouscích a tím řídíme jeho očekávání. Nestává se pak, že by


24

ČÁST I FiloZofi e Agilních a Lean metod

zákazník produkt odmítl jako nepoužitelný a trval na jeho přepsání. Na druhé straně

tím, že uděláte celý tým zodpovědný za kvalitu výsledku, se sníží počet chyb a vzroste

dlouhodobá udržitelnost kódu. Tým se sám stará o to, že jim neroste technický dluh.

Pro oba směry zavádějí agilní metody spoustu praktik.

Zábava – a  v  neposlední řadě práce bude zase zábava. I  jednotliví členové budou

vědět, co a proč píšou. Budou chápat smysl produktu a rozumět zákazníkovi. Navíc

spolupráce s ostatními nakonec také přináší zábavu. A motivovaný člen týmu je jistě

efektivnější než znuděný vývojář sedící sám za svým počítačem.

Poznámka: Než se pustíte do nasazování agilních metod, udělejte si jasno vočekáváních, zejména týkajících se fl exibility, efektivity, předvídatelnosti, kvality a zábavy. Jak jsme již říkali, nic není zadarmo. Jestli jste v  některé kategorii našli dostatečně velký potenciál, pusťte se dál do čtení. Jestli ne, možná vám současné projekty fungují dobře a na změnu ještě nenastal čas. Nasazovat agilní metody jen proto, že je toněco nového, nemá smysl. Je to náročný a trnitý proces, na jehož konci vás musí čekat dostatečně velká odměna. Jinak to vzdáte ještě dřív, než se změny stihnou projevit. Zkusit si to můžete na jednoduchém cvičení. Výše zmíněné důvody pro změnu si nakreslete do grafu a ohodnoťte jednotlivé kategorie na stupnici 1–10, kde 1 ješpatné, 10 je super. Hodnotíte váš tým, projekt, produkt, fi rmu. Ideální je tzv. pavučinu nakreslit ve dvou barvách. První odpovídá realitě, tedy současnému stavu, a druhá odráží vaše očekávání za, řekněme, rok. Oblasti, ve kterých je největší rozdíl hodnot, indikují důvody pro změnu. Jste-li naopak se vším spokojeni, pak nejlepší strategií bude zůstat u současných procesů a nic neměnit.

Poznámka: Než se pustíte do nasazování agilních metod, udělejte si jasno vočekáváních, zejména týkajících sefl exibility, efektivity, předvídatelnosti, kvalitya zábavy.


25

ČÁST II

POPIS METOD,

PROCESŮ, PRAKTIK

A ARTEFAKTŮ  KAPITOLA 3 – Agilní slovníček  KAPITOLA 4 – Role  KAPITOLA 5 – Artefakty  KAPITOLA 6 – Meetingy  KAPITOLA 7 – Agilní programování – Artefakty  KAPITOLA 8 – Scrum 1-1 a škálovatelnost Scrumu  KAPITOLA 9 – Extreme Programming 1-1  KAPITOLA 10 – Kanban 1-1  KAPITOLA 11 – Jak funguje tým  KAPITOLA 12 – Smlouvy a formy spolupráce  KAPITOLA 13 – Otázky na závěr


26

Ve druhé části popíšeme jednotlivé artefakty, procesy a techniky. A protože jednosou

visí s druhým, na úvod dáváme krátký slovníček agilních pojmů. Detailní vysvětlení,

jak konkrétní praktiku implementovat, co od ní očekávat, jak začít a čeho se naopak

vyvarovat, najdete v následujících sekcích. Teorie je vždy doplněná doporučeními, jak

ji v praxi aplikovat. Každá kapitola končí sekcí souvislosti, ve které najdete praktiky,

které s popsanou kapitolou úzce souvisejí a které budete potřebovat zavést, aby daná

praktika fungovala a přinesla očekávaný efekt.


27

KAPITOLA 3

Agilní slovníček

Praktiky procesy a artefakty Vysvětlení

Akceptační kritéria Doplňuje základní popis User Story o další kritéria defi nující, jak se

pozná, že je User Story hotová. Backlog Grooming Pravidelný meeting, na kterém tým probírá s Product Ownerem

prioritní User Story z Backlogu tak, aby jim porozuměl a byl jeschoen ohodnotit. Burndown graf Graf zobrazující rychlost „spalování“ funkcionality v Product Backlogu. V závislosti na rychlosti týmu vizualizuje predikci dokončení. Done kritéria Domluvená pravidla pro předání, defi nující hotovou User Story. Epic Větší funkční celek, který se následně rozpadá na User Stories. Extreme Prgramming – XP Metoda agilní spolupráce postavená na spolupráci a programovacích praktikách jako review, continuous integration, Test Driven

Development (TDD), pair programming,... INVEST Kritéria dobře napsané User Story: Independent, Negotiable,Valuable, Estimable, Small, Testable. Kanban Metodika na pomezí Agile a Lean fungující na principechvizualizace procesu, omezení rozpracované práce a minimalizace času

potřebného na dokončení jednotlivých celků. Planning Ve Scrumu plánuje tým, vybírá z prioritních User Stories do Sprint

Backlogu ty, které je schopen dokončit v příštím Sprintu. Planning Poker Metoda pro odhadování velikosti User Stories v relativníchjednotkách, tzv. bodech. Obvykle se hraje ve formě herních karet s tzv.

Fibonacciho řadou pro určení velikosti (komplexnosti) User Story.Prelanning Příprava pro planning, kde Product Owner identifi kuje priority ze

kterých následně tým při planningu vybírá. Product Backlog Prioritizovaný seznam funkcionality (user stories), kterou chceme

dodat zákazníkovi. Backlog je vytvářený a udržovaný ProductOwnerem. Vždy přístupný celému týmu před začátkem, ale i běhempráce na produktu.


28

ČÁST II Popis metod, procesů, praktik a artefaktů

Praktiky procesy a artefakty Vysvětlení

Product Owner Vlastník vize produktu. Má na starosti Product Backlog a jezodpovědný za ROI a celkovou úspěšnost Produktu. Je součástí týmu.Defi nuje, co je potřeba v daném produktu či oblasti udělat. Na základě

kontaktu a diskuzí se zákazníky určuje prioritu úkolů. Product Owner Proxy Pomocná role Product Ownera u větších produktových týmů,tyicky v různých geo-lokacích a časových zónách Retrospektiva Týmový meeting, kde jednotliví členové zhodnotí, co se jim vposlední iteraci dařilo, v čem chtějí pokračovat a co naopak chtějí

vylepšit či změnit. Review Meeting Po skončení každého Sprintu tým v rámci Review prezentuje zákazníkovi dokončené User Stories. Rychlost (Velocity) Rychlost měříme vždy za tým a Sprint v relativních jednotkách, tzv.

bodech. Slouží k lepšímu odhadu práce pro příští Sprinty a je též

ukazatelem efektivity týmu. Rychlost má smysl pouze v danémtýmu, a jelikož používáme relativní jednotky, nelze rychlost vzájemně

porovnávat mezi týmy. Scrum Proces postavený na týmové spolupráci, zapojení zákazníka apravidelné zpětné vazbě v krátkých Sprintech. Scrum je v součastnosti

jedna z nejčastěji využívaných agilních metodik. Scrum Master Kouč a moderátor týmu. Odstraňuje překážky, stará se o rozvoj

a fungování týmu. Udržuje Scrum v chodu. Není manažerem týmu. Scrum Tabule Zobrazuje stav aktuálního Sprintu. Obvykle pomocí papírových

lístečků s jednotlivými User Stories a tasky. Self-organized tým Tým, který se v rámci mantinelů projektu organizuje a sámrozhoduje, na čem a jakým způsobem bude pracovat, bez vnějšího vlivu

tak, aby maximalizoval efektivitu, fl exibilitu a motivaci jeho členů.

Pozor, nezaměňovat s anarchií, i v self-organized týmech vždyplatí, že změnit lze pouze něco = existují hranice a procesy, které ani

tento tým nemůže změnit. Sprint Krátká fi xně dlouhá iterace, ve které se tým zaváže dodatfunkcionalitu, která má pro zákazníka hodnotu. Sprint Backlog Vybraná funkcionalita z Product Backlogu pro daný Sprint. Standup / Scrum Meeting Krátký týmový meeting, pravidelně každý den, obvykle ráno.Jednotliví členové sdílí mezi sebou aktuální stav a identifi kují případné

problémy. Je moderován Scrum Masterem. Story point (Bod) Relativní jednotka velikosti User Story. Nedá se převádět na čas a má

smysl pouze v jednom daném týmu, tedy nemůžeme porovnávat

Story Pointy mezi jednotlivými týmy.


KAPITOLA 3 Agilní slovníček

29

Praktiky procesy a artefakty Vysvětlení

User Story Funkcionalita popsaná v tzv. kanonické formě: Jako uživatel, chci

funkcionalitu, abych dostal hodnotu. User Story má přesně defi novaná akceptační kritéria a je dostatečně malá, aby ji tým rozuměl

a mohl odhadnout její velikost.

Obecné pojmy:

Výraz Vysvětlení

Budget Rozpočet projektu.

Demo Předvedení produktu, ať již interně nebo zákazníkům.

Checklist Seznam bodů se „zaškrtávátky“. Nejčastěji slouží jako postupnýseznam úkolů či náležitostí nějaké činnosti, které můžemezkontrolovat a odškrtnout. Change request Požadavek na změnu oproti původnímu zadání. KPI – Key Performance Indicator Klíčový ukazatel výkonnosti. Jedná se o stanovenou či měřenou

hodnotu, proti které porovnáváme skutečný stav efektivity nebo

výkonu organizace. Waterfall Tradiční metodika vývoje softwaru a jiných projektů spočívající

v řetězení činností za sebe, tzn. dokud se nedokončí předchozí

fáze, další nemůže začít.



31

KAPITOLA 4

Role

Scrum Master

Takže jak vlastně Scrum funguje? Je založen na principu self-organized týmu,transarentní komunikaci a otevřené kultuře, která podporuje spolupráci a sdíleníinformací. Aby to celé fungovalo, zavádí některé specifi cké role, které tradiční metody

managementu neměly – a to Scrum Mastera a Product Ownera.

Scrum Master není teamleader v klasickém slova smyslu, ale pracuje jako mezičlánek

mezi týmem a jakýmkoliv rušivým elementem zvenku. Jeho hlavním cílem je vytvořit

samostatný, efektivní a spokojený self-organized tým. Detailnější cíle a povinnosti by

se daly shrnout do následujících bodů:

 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 defi novaném cíli

Dále se stará se o to, aby Scrum byl efektivní a fungoval, má na starosti jehododržování, ale zároveň i možnost iniciovat změnu, je-li to třeba. Scrum Master by měl

upřednostňovat koučovací principy, podporovat tým a  jednotlivce v  jejich rozvoji,

být komunikativní, vnímavý a  utlumovat případné konfl ikty v rámci týmu. Scrum

Master by neměl být direktivní.

V této kapitole:

 Scrum Master

 Product Owner

 Self-organized tým

 Scrum tým

 Zákazník

 Product Owner Proxy

 Role Manažera

 Role Project Manažera


32

ČÁST II Popis metod, procesů, praktik a artefaktů

Scrum Master je ten, kdo „zametá cestičku“, aby se týmu dobře pracovalo. Když dobře

fungující tým přirovnáme ke stroji, stará se, aby se „kola týmu točila“ jak nejrychleji

to jde a nikde to nedrhlo, nevrzalo, neskřípalo. Scrum Master je součástí týmu a měl

by být týmu kdykoli k dispozici. Měl by proto sedět v jedné místnosti s týmem.

Funguje-li Scrum Master dobře, nedá se jeho pozice chápat jako náklad navíc. Tím,

že rozpohybuje tým a  zajistí tak vyšší efektivitu, kvalitu a  motivaci, ušetří v celkovém rozsahu více peněz, než kolik Scrum Master jako nákladová položka fi rmu stojí.

Není vhodné roli Scrum Mastera kombinovat s Product Ownerem. Obvykle nefunguje

ani kombinace role s vývojářem či testerem, kde vývojáři či testeři často upřednostní

svou technickou práci před prací Scrum Mastera, a nechají tak tým v kritickýchokamžicích de facto bez Scrum Mastera.

Poznámka: Technicky nejzkušenější člen týmu obvykle není ideálním Scrum Masterem.

Scrum Master musí být vnímavý, klást otázky a podporovat schopnost týmu si na řešení

problémů přijít sám i za cenu lokální neefektivity.

Expert je naopak člověk, který dokáže poradit a zná obvykle odpověď na otázky lépe

než jiní členové. Když už uvažujete o kombinaci s nějakou jinou rolí, snažte se, aby role Scrum Mastera byla vždy prioritní. Některé fi rmy nechávají Scrum Mastera koučovat dva týmynajednou, ale ani to není ideálním řešením, protože problémy často chodí spolu. Velmi tedy záleží na prostředí a týmu a konkrétní osobnosti Scrum Mastera. Ani kombinaci rolí Scrum Mastera a  manažera rozhodně nemůžeme doporučit. Scrum Master by tým neměl nijak přímo řídít ani organizovat, ani za tým rozhodovat. Role Scrum Mastera je pro úspěch produktu klíčová, vyžaduje vnímavého člověka se schopností dobře komunikovat, koučovat, moderovat. Prostě někoho, kdo jeschoen tým posunout dál a udělat jeho členy ještě úspěšnější. Navíc dobrý ScrumMaster problémům předchází, tedy se po čase může zdát, že tým už je plně funkční sám a  Scrum Mastera nepotřebuje. Když ovšem takového Scrum Mastera přesunete na jinou práci, po čase se v týmu začnou množit problémy a přestane fungovat. Není to hned – a o to méně si na konci vzpomenete, že by to mohlo mít souvislosts neexistujícím Scrum Masterem. Říkali jsme, že Scrum Master nemá být direktivní, není to manažer týmu. Na druhou stranu, nemůže být ale ani nevýrazný a nechat vše plynout. Role Scrum Mastera se mění v závislosti na zkušenostech a schopnostech týmu se sám organizovat.

Poznámka: Technicky nejzkušenější člen týmu obvykle není ideálním Scrum Masterem.

Scrum Master musí být vnímavý, klást otázky a podporovat schopnost týmu si na řešení

problémů přijít sám i za cenu lokální neefektivity.

Expert je naopak člověk, který dokáže poradit a zná obvykle odpověď na otázky lépe

než jiní členové.


KAPITOLA 4 Role

33

Ze začátku může Scrum Master více radit a  určovat, co se bude dít, více všechno

organizuje a svým způsobem řídí. Jste-li ale v takovéto roli i po několika měsících,

pravděpodobně jste zapomněli, že cílem Scrum Mastera je vybudovat self-organized

tým, který si bude schopen sám najít řešení na své problémy a sám se organizovat

tak, aby jeho práce byla co nejvíce efektivní. Nebuďte jako starostlivá maminka, která

ani v 10 letech dítě nepustí samotné přes ulici na nákup. Nechte týmu prostor, nechte

z nich vyrůst sebevědomé a zodpovědné jedince, pravý Scrum tým.

Upozornění: Kombinace rolí vždy přináší rizika a je velmi náročná. Když už jste si jisti,

že je nutné role kombinovat, dejte si pozor, abyste rozuměli dobře konfl iktům cílů apriorit těchto rolí.

(Co budete ještě potřebovat zavést)

Self-organized tým: Cílem každého Scrum Mastera je dosáhnout toho, že se tým sám

organizuje, rozhoduje a nese za svá rozhodnutí odpovědnost.

Product Owner: I když se Scrum Master stará o správně fungující tým, bez Product

Ownera, který udává týmu směr a priority, se nikdy nedosáhne správného výsledku.

Role Manažera: V agilním světě se vzdaluje každodenní operativě, alokování zdrojů,

a organizaci času jednotlivých lidí. To má na starosti tým. Manažer je odpovědný za

vytvoření prostředí, ve kterém tým může efektivně pracovat, a podílí se více nastrategických rozhodnutích než na řešení každodenních problémů, které si může tým vyřešit

spolu se Scrum Masterem sám. Product Owner Další z rolí, které Scrum zavádí, je role Product Ownera. Product Owner jevlastníkem produktu. Má na starosti defi nování vize projektu a její transparentníkomunikaci týmu, zákazníkům, fi rmě. Product Owner defi nuje priority, rozhoduje, na které funkcionalitě se bude pracovat dříve, na které později a na které vůbec. Má na starosti Business Value a také ROI celého produktu. Product Owner je tedy zodpovědný za celý Product Backlog. Není na takovou práci sám, ale obvykle mu pomáhá tým lidí. Kdo by v takovém product týmu mohl být? To záleží hodně na kontextu vašeho produktu. Obvykle tam je někdo z následující skupiny: zástupce zákazníka, uživatelů, soft warový architekt, User Experience, jiní Product Owneři.

Upozornění: Kombinace rolí vždy přináší rizika a je velmi náročná. Když už jste si jisti,

že je nutné role kombinovat, dejte si pozor, abyste rozuměli dobře konfl iktům cílů apriorit těchto rolí.

Souvislosti:


34

ČÁST II Popis metod, procesů, praktik a artefaktů

Product Owner je týmu pravidelně podle potřeby k dispozici, ale na rozdíl od Scrum

Mastera už s týmem ne vždy sedí v jedné místnosti. Tráví dostatek času sezákazníky, aby vstřebal jejich prostředí a dokázal se vždy správně rozhodnout, kde je pravá

hodnota pro zákazníka. Product Owner neřídí jednotlivé členy týmu ani tým, nemá

možnost jim přikazovat, co musí dokončit, jen stanovuje, co se má dělat a v jakém

pořadí – tedy defi nuje priority.

Primárním cílem Product Ownera je porozumění produktu. Tento cíl následněkomunikuje tak, aby všichni věděli, kam jdeme, proč a jak. A to jak v rámci týmu, tak

managementu a zákazníků. Cíl musí být pro všechny stejný, i když jazyk, kterým ho

do jednotlivých skupin komunikuje, bude pravděpodobně odlišný.

Role Product Ownera by neměla být kombinována s rolí Scrum Mastera. Role je pro

úspěch celého procesu klíčová, vyžaduje komunikativního člověka se silnými znalostmi produktu.

Poznámka: Product Owner musí vhodně vyvážit obě funkce své role – znát zákazníka

a být s ním v kontaktu a zároveň být týmu k dispozici.

Obvykle se čas Product Ownera dělí tak, že je 80 % času u zákazníka a 20 % v týmu.

Konkrétní čísla se ale můžou lišit v závislosti na typu produktu.

(Co budete ještě potřebovat zavést)

Tým: Spolupráce v týmu je lepší než práce jednotlivců. Správný tým zná zákazníka a je

partnerem Product Ownera při tvorbě Product Backlogu.

Product Backlog: Product Owner by měl mít jasno v tom, na čem tým bude pracovat,

a být schopen určit priority. Self-organized tým Agilní metody jsou postavené nejen na časté zpětné vazbě a komunikaci, ale i natýmové spolupráci. A vývoj soft waru je komplexní problém, který není snadnénaplánovat dopředu. Každá fi rma je jiná, každý produkt je jiný, každý tým je jiný. Nikdo zvenku neumí dosáhnout optimální efektivity ani workfl ow. Proto agilní týmy často spoléhají na své jednotlivé členy a nastavují adaptivní proces, který jeho členové sami můžou ovlivnit a změnit.

Poznámka: Product Owner musí vhodně vyvážit obě funkce své role – znát zákazníka

a být s ním v kontaktu a zároveň být týmu k dispozici.

Obvykle se čas Product Ownera dělí tak, že je80 % času u zákazníkaa20 % v týmu.

Konkrétní čísla se ale můžou lišit v závislosti na typu produktu.

Souvislosti:


Toto je pouze náhled elektronické knihy. Zakoupení její plné

verze je možné v elektronickém obchodě společnosti eReading.




       
Knihkupectví Knihy.ABZ.cz - online prodej | ABZ Knihy, a.s.
ABZ knihy, a.s.
 
 
 

Knihy.ABZ.cz - knihkupectví online -  © 2004-2018 - ABZ ABZ knihy, a.s. TOPlist