Preklad Agile Manifesto do slovenčiny

Hľadáte slovenské znenie Agile Manifesta?

Neoficálnych prekladov existuje viacero. Oficiálny preklad uznávaný Agile Allianciou však má byť vytvorený komunitou.

Aj preto sme sa v Agile@Slovakia rozhodli, že zorganizujeme stretnutia komunity v dôležitých centrách agility Slovenska:

  • Košice, 28.1.2013
  • Žilina, 27.2.2013
  • Banská Bystrica, TBD
  • Bratislava, 28.2.2013

Ako budeme postupovať?

  1. Prídete na stretnutie do daného mesta.
  2. Vytvoríme malé tímy.
  3. Každý tím preloží časť manifesta.
  4. Po preložení posunie preklad vedľajšiemu tímu.
  5. Takto preložíme všetky časti manifesta a princípy.

Po preložení Agile@Slovakia skontaktujeme Agile Alliance, odošleme výsledné znenie a požiadame o oficiálne publikovanie znenia.

Chcete sa stať signatárom slovenského znenia? Príďte na meetup!

Košice 28.1.2013

40 výhod agilných prístupov

Minulý rok sa ma viacerí pýtali na výhody Agile v porovnaní s tradičnými prístupmi k tvorbe produktov, resp. riadeniu projektov.  Spravili sme teda vo firme krátky brainstorming a tu je náš zoznam.

  1. Zákazník dostáva hodnotu priebežne už v prvých týždňoch vývoja
  2. Produkt použiteľný po prvých dvoch týždňoch
  3. Priebežná redukcia rizika od začiatku projektu
  4. Rýchlejšie dostupné výsledky
  5. Vysoká angažovanosť klienta
  6. Jednoduché prispôsobenie produktu trhu
  7. Vyššia konkurencieschopnosť
  8. Vysoká angažovanosť tímov
  9. Tímy poznajú a chápu biznis model
  10. Prioritizácia úloh podľa biznis hodnoty a rizika
  11. Vyššia produktivita
  12. Vyššia kvalita
  13. Väčšia znalosť o produkte v tíme
  14. Manažment viac vedie, menej riadi
  15. Odstránenie mikromanažmentu
  16. Veľká viditeľnosť do stavu produktu
  17. Neustály proces zlepšovania procesov a technik
  18. Neustále prehodnocovanie vízie a stratégie produktu
  19. Jednoduché metriky umožňujúce operatívne validovať stav produktu a meniť jeho smerovanie podľa potrieb
  20. Vyššia rýchlosť dodania na trh
  21. Vyššia dôvera zákazníka
  22. 3* úspešnejšie projekty (podľa Chaos Manifesto)
  23. Motivácia výsledkom
  24. Stmelenejšie tímy
  25. Priebežné opravy chýb
  26. Zintenzívnenie spolupráce a komunikácie v tíme a aj so zákazníkom
  27. Pravidelný rytmus synchronizácie tímov
  28. Lepšia predvídateľnosť dodávok
  29. Vyššia spokojnosť klienta
  30. Vyrovnanejšie náklady vývoja
  31. Zameranie tímu na výsledok
  32. Efektívne riadenie projektov aj napriek častým zmenám
  33. Vyššia morálka a disciplína tímov
  34. Zlepšené inžinierske praktiky
  35. Jednoduchší a efektívnejší proces vývoja
  36. Dobré prispôsobenie procesu firemnej kultúre
  37. Lepší ROI
  38. Holistický prístup k vývoju, od techník vývoja, nástrojov, cez budovanie tímov až po procesy a firemnú kultúru
  39. Výrazné zlepšenie prezentačných schopností
  40. Nemotivovaní jedinci sa často sami rozhodnú zmeniť pôsobenie.

Článok bol pôvodne uverejnený na http://scrum.sk/index.php/vyhody-agilnych-pristupov/

Vodopád, Agile a ten tretí

dfsakldfja25Ak ste súčasťou vývoja softvéru, asi ste počuli o vodopádovom modeli. Je to pomenovanie pre metódu riadenia pozostávajúcu z jednotlivých za sebou nasledujúcich krokov vývoja (zber požiadaviek, analýza, návrh atď.). Je dosť možné, že ste už tiež počuli o agile. O tých divných metódach, kde za jedným počítačom môžu sedieť dvaja a každý deň sa stojí na porade. A to by mohlo byť o riadení projektov všetko. Ale nie je. Je tam ešte tretia metóda. Má mnoho foriem a žiadne oficiálne meno, ale ja jej budem hovoriť chaos. Toto je príbeh o troch svetoch, v ktorých môže žiť softvérový projekt.

Vývojári a zákazník môžu mať v určitom smere protichodné záujmy. Hlavne čo sa týka pružnosti vývoja softvéru. Prvý svet je svet vodopádu a zmrazených, nehybných požiadaviek. Je to svet vývojárov, kde sa všetky zmeny pekne rozanalyzujú a zapracujú. Všetko má svoj prísny poriadok, vždy je jasné, čo bude nasledovať na celej dĺžke plánu. Je to svet, kde zákazník ledva prežije. Najprv je nútený pomerne presne odhadnúť pol roka alebo rok dopredu, čo bude chcieť a potom začne byť jeho hlas ignorovaný alebo potláčaný. A niekedy až po roku zistí, čo si to dal vlastne vyrobiť (a že chcel niečo tak trochu iné)

Na druhej strane tejto pomyselnej planéty projektov je svet plný ohňa, výbuchov a neustálej zmeny. Je to svet, kde kríza strieda krízu, kde sa požiadavky menia z hodiny na hodinu. Je to svet, kde je softvér samá záplata a hack, až vyzerá ako narýchlo zbitá búda. Je to svet zákazníka a meniaceho sa trhu, kde jeden ASAP strieda druhý. Je to svet, kde vývojár ledva prežije. Neexistuje žiaden pevný systém, ktorého by sa mal držať. Nemôže uvažovať strategicky, lebo nikdy nevie, čo bude zajtra, a už vôbec nie o týždeň, mesiac. Je nútený robiť len nevyhnutné zmeny v kóde, len toľko, aby to fungovalo a môžeme ísť ďalej. Takto vzniká technologický dlh, ktorý spôsobuje, že riešenia sú čím ďalej tým viac skratkovité, kód sa len viac a viac zauzľuje, tie isté problémy sa na rôznych miestach riešia rôzne a kódom sa ako nepríjemný smog rozlieza duplicita.

Ak by ste si nakreslili na mapu tieto dve svety a spojili ich priamkou, niekde uprostred by ste našli agile. Agile je krok od vodopádu smerom k zákazníkovi a krok od chaosu smerom k vývojárovi. Je to kompromis. Zatiaľ čo svet vodopádu je nehostinný pre zákazníka a svet chaosu pre vývojára, je agile prostredie, v ktorom dokážu prežiť obaja. Na jednej strane poskytuje vývojárovi systém, v rámci ktorého vie fungovať, plánovať zmeny a mať aspoň čiastočne stabilné požiadavky. Na druhej strane umožňuje zákazníkovi meniť priority pre krátkodobé cykly, získavať prehľad, čo sa vyrába a môcť to pripomienkovať. Aj preto je svet agile tak trochu divný. Je to hybrid. Kompromis. Nie je úplne prirodzený ani pre vývojára ani pre zákazníka. Je to ale niečo, s čím sa dá dlhodobo prežiť na obidvoch stranách.vodopad.agile.chaosKeď sa rozhodnete prejsť na agile, čaká vás zodpovedanie niekoľkých otázok. Viem určite o dvoch otázkach, ktorým sa nevyhnete. Jednej ľahkej a jednej ťažkej. Tá ľahká znie: Kam sa chcem dostať? Je ľahká preto, lebo informácií o tom, ako by mal vyzerať agile, je už dnes obrovské množstvo. Detaily sa nemusia s vaším prípadom zhodovať, ale ak správne zavediete základnú štruktúru, doplnia sa sami. A teraz tá ťažká: Kde vlastne som? Toto je ozajstný oriešok. Žiadna kniha, návod alebo prezentácia vám s ňou pomôže. Jediným človekom, ktorý na to vie odpovedať, ste vy. Nedarí sa vášmu obchodu? Asi žijete vo svete polárneho ľadu a mali by ste sa vydať smerom k rovníku. Obchod je fajn, ale vývojári sú nejakí zničení a stále hasíte nejaký požiar? Asi žijete vo svete horúceho trhu a mali by sa ste zamieriť do miernejších pásiem.

Ujasnenie týchto otázok je pre úspešnú transformáciu na agile kritické. Keď viete kde ste a kam chcete ísť máte body dva s ich vzájomnou polohou a teda mapu! A s mapou sa vždy cestuje ľahšie…

Vyhrajte vstup na Agile Prague

SDlogorobime_it-logo

ScrumDesk s.r.o. v spolupráci s robime.it a organizátormi konferencie Agile Prague ponúkajú nielen členom Agile@Slovakia  vstup zdarma na konferenciu Agile Prague v hodnote 5.000 CZK!

Čo potrebujete spraviť aby ste tento vstup získali?  Stačí zodpovedať pár jednoduchých otázok o Agile na stránkach robime.it.

Zúčastniť sa súťaže na stránkach robime.it!

logo_apc-250x70

Prečo ísť do Prahy 3.-4. septembra 2012:

  • pretože je to Praha :),
  • pretože stretnete viac ako 100 ďalších ľudí, ktorí aplikujú Agile alebo sa snažia dozvedieť viac,
  • pretože budú predstavené prípadové štúdie z Barclays, CA, IBM, Kerio, Seznam.cz,
  • po každej prednáške bude rečník dostupný v open space zóne. Preberte svoje problémy s expertmi.

Viete kto prezentuje?

a ďalších 24 rečníkov. Mimochodom, poznáte rečníkov na fotografiách? Stretnete ich na konferenciách nielen v Prahe.

Tak a teraz klikni na linku a pokús sa vyhrať!

Fyzický vs. elektronický Scrum

fdsafdsf4564Scrum, ako aj iné metódy riadenia (či už pre tím alebo osobné), vyžaduje určité nástroje na realizáciu. Zoznam, grafy a iné artefakty, ktoré sú pre beh metódy nevyhnutné. Tieto nástroje môžu existovať vo forme elektronickej alebo fyzickej. Elektronická forma predstavuje rôzne špecializované softvéry alebo prispôsobené všeobecnejšie nástroje (Calc, Excel..), zatiaľ čo pri papierovej je to najčastejšie samotný papier alebo tabuľa (magnetická, korková …). Diskusia o tom, ktorá z týchto foriem je vhodnejšia, je prakticky nekonečná a to z jednoduchého dôvodu: univerzálna odpoveď na túto otázku neexistuje. Respektíve existuje odpoveď, ktorá ale nepomáha problém riešiť, a to je: pre každý projekt je vhodná iná forma. Keď už ale príde na lámanie chleba, musíte si vybrať…

To, čo pomáha sa dostať z tohto bludného kruhu otázky a odpovede je fakt, že každá z týchto foriem má svoje výhody a nevýhody. Práve tento zoznam bonusov a potenciálnych rizík by mal byť prostriedok, ktorý umožní zvládať túto dilemu. Je potrebné len zvážiť, ktoré vlastnosti sú pre váš projekt najdôležitejšie a vybrať. Poďme sa teraz bližšie pozrieť na jednotlivé výhody a nevýhody.

Elektronika

Ak sa rozhodnete použivať elektronický nástroj, je výber taký široký, až to začína byť nepríjemné. Vybrať si môžete buď nástroj, ktorý je šitý priamo na vašu metódu, ktorý vám dá presne to, čo potrebujete, ale na druhej strane vás môže obmedzovať, ak potrebujete niečo naviac. Alebo si môžete siahnuť po univerzálnejšom nástroji, ktorý si budete musieť najprv prispôsobiť. Teraz mám na mysli vyššie spomínané nástroje ako Calc alebo Excel, s ktorými viete robiť naozaj veľa, ale chce to vedomosti a čas. Rozdiel medzi týmito dvoma kategóriami je hlavne v tom, že s tým prvým si kupujete aj metódu, s tým druhým nie. Prečo ale po softvérovom nástroji siahnuť:

  1. prístup z rôznych miest – toto je asi najdôležitejšia výhoda. Pre distribuovaný tím je elektronická forma prakticky nevyhnutná. Ale členovia tímu nie sú jediní, ktorých stav projektu môže zaujímať. Riadiaci pracovníci, obchodné oddelenie alebo zákazník. Alebo hoci aj ten monitor vo vstupnej hale, ktorý vysiela Sprint Burnd Down Chart náhodným okoloidúcim.

  2. vyhľadávanie – jednoznačne jednoduchšie ako pri fyzickej forme.

  3. prenositeľnosť – kopírovanie, zálohovanie, dlhodobá archivácia.

  4. ľahký prechod na papier – rôzne grafy a zoznamy je často možno jednoducho vytlačiť a získať tak ich fyzickú formu.

  5. automatizácia – systém dokáže automaticky za vás vykonávať niektoré práce. Kreslí graf, počíta priemery, posiela e-maily…

Fyzické nástroje

Pod pojmom fyzické nástroje si môžete predstaviť akékoľvek jednoduché prostriedky, pomocou ktorých viete v reálnom svete zobrazovať stav projektu. Tabuľa, papier, fixa, pero, nálepka, magnet, lepiaca páska, špagát, žiarovka, siréna atď. S hotovými fyzickými sadami pre Scrum som sa zatiaľ príliš nestretol, ale ak prehľadáte internet, určite nájdete dostatok inšpirácie. Prečo ale siahnuť po fyzickej forme:

  1. sloboda – jednoduché nástroje vám umožnia vytvárať ľubovoľné zložité objekty. Obyčajná popisovacia tabuľa s fixou a sadou lepiacich papierikov poskytuje neuveriteľné množstvo možností kombinácií toho, ako ich dokopy použijete. Niečo nefunguje, tak ako potrebujete? Zahodíte a nahradíte iným riešením. Ak nefunguje ani to, skúsite niečo iné. Takáto sloboda ohnúť nástroj do požadovaného tvaru môže byť pri softvéry problém. A že by mali mať ľudia navrch oproti nástrojom hovorí už aj samotné Agile Manifesto.

  2. hmatateľnosť – svet softvéru alebo poskytovania služieb má oproti klasickej priemyselnej výrobe jednu nevýhodu – to, čo firma vyrába, s čím sa každý deň pracuje, nie je hmatateľné. Na prvý pohľad to nemusí vyzerať až tak podstatne, ale je dôležité si uvedomiť, že spoločnosť za posledné desaťročia prešla revolúciou, zatiaľ čo my ľudia sme skôr evolučná záležitosť. Hmatateľné predmety je možné si podávať, rozostavovať ich v priestore, ukladať na kopy alebo hoci aj hádzať do koša. Všetko toto sú pre ľudí prirodzené činnosti, preto aj práca s fyzickými nástrojmi je prirodzenejšia.

  3. jednoduchšia viditeľnosť – ak sa nerozhodnete pre nejaké komplikovanejšie riešenie ako je zapnutý projektor, alebo každodenné tlačenie stavu na papier má elektronická verzia jednu nevýhodu – je uzamknutá do vášho monitoru. Oproti tomu je fyzická často umiestnená na nejakom viditeľnom mieste, a teda je omnoho ťažšie ju prehliadnuť (pre vás, manažment alebo kohokoľvek, koho by to mohlo zaujať). Stačí len otočiť hlavu.

Myslím, že rozhodnutie o forme by malo padnúť pre každý projekt zvlášť a dokonca, že by malo byť možné ho zmeniť, ak sa ukáže, že druhá forma je vhodnejšia. Každopádne je možné tieto formy udržiavať aj obe naraz – synchronizovať. To si ale vyžaduje viac úsilia, a teda je otázne či to naozaj stojí za to. Takto sa síce dajú získať výhody obidvoch foriem, ale zaplatíte za to monotónnou každodennou prácou a rizikom, že sa synchronizácia rozíde.

Projektový manažér == Scrum Master?

V posledných dňoch mám čoraz väčší dojem, že niektoré veci musíme ako komunita dôraznejšie ozrejmovať,  vysvetľovať a trvať na správnom použití.

V tomto príspevku sa chcem viac zamerať na význam roly Scrum Master. Prečo? Pretože počas posledného týždňa som našiel päť článkov (jeden dokonca publikovaný na nemenovanej unverzite), ktoré nesprávne vysvetľujú kto je Scrum Master, čo má robiť a ako to má robiť.

Dôvodom je možno slovenčina, do ktorej sa tento pojem Scrum Master veľmi ťažko prekladá. Majster Scrumu? Hmm, v profesionálnom prostredí to znie zvláštne. Ja osobne tento pojem práve preto takto neprekladám. No významovo je tento preklad vynikajúci.

Projektový manažér (v terminológii Scrum-u „ScrumMaster“)

Chcel by som sa venovať asi najväčšiemu nepochopeniu, ktoré som objavil.

Nie, nesprávne. Toto sú dve roly, ktoré majú za úlohu riešiť iné aspekty. Áno, často je to ten istý človek. No tento človek má na vešiaku dva kabáty. Raz môže byt projektovým manažérom, inokedy scrum mastrom. Dokonca z praxe poznám mnohých projektových manažérov, ktorý sa radšej stali Scrum Mastrom.

Prečo? Pretože  Projektový manažer <> Scrum Master.

Pretože projektový manažér sa má zaoberať časom, rozpočtom, zdrojmi a kvalitou. To sú atribúty akéhokoľvek projektu. A projektový manažér ich má držať pokope tak, aby výsledok projektu bol dodaný načas, v rozpočte s danou kvalitou, vyvinutý vybraným tímom.

Projektový manažér je na svete kvôli PROJEKTU.

No Scrum Master sa týmto primárne vôbec nemá zaoberať. Scrum Master sa zaoberá:

  • Vyrovnávaním cesty, po ktorej kráča tím.
  • Snaží sa skoro rozpoznať prekážky, snaží sa ich odstrániť aj za pomoci organizácie.
  • Snaží sa tímu pomôcť, aby bol efektívnym.
  • Robí denne prácu, ktorá by iných blokovala.
  • Prináša a udržuje viditeľnosť stavu projektu tým, že komunikuje s tímom a inými tímami
  • Synchronizuje tím s inými tímami
  • Pripravuje a moderuje (pozor, nevedie!) porady a diskusie.
  • Komunikuje s organizáciou – produktovým aj projektovým manažérom.
  • Zaoberá sa procesom vývoja.
  • Koučuje (vyučuje) agilné techniky v tíme. Také aké práve tímu pomôžu. Musí mať prehľad o tejto problematike a mal by vždy vedieť trochu o tom viac ako členovia tímu.

Scrum Master je na svete kvôli TÍMU.

Máte na tento zoznam ako projektový manažér v dnešnej dobe čas?

Fedexday

124f54gNáklady firiem na vytváranie motivácie u zamestnancov nie sú malé. Obľubené sú teambuildingové akcie, výlety, finančné prémie a pod. To všetko stojí peniaze. A pritom čínnosť ako je vývoj softvéru (a vývoj všeobecne) môže byť sama o sebe natoľko zaujímavá, že sa stáva motiváciou. Ak neveríte, dá sa to jednoducho overiť. Môžete si skúsiť Fedexday.

Pre zamestnancov je Fedexday zážitok, pre zamestnávateľa sa to nedá nazvať inak ako veľa muziky za málo peňazí. Fedexday je súťaž, kedy za 24 hodín (preto ten Fedex v názve) musíte vyvinúť a dodať (t.j. musí to byť funkčné) nejaký výsledok. Pre softvérové firmy to znamená hlavne dodanie softvéru. To, na čom budete pracovať, akú technológiu použijete a s kým na tom budete pracovať, je na vás. Práve táto sloboda venovať sa niečomu, na čo ste si už možno dlho brúsili zuby, je hlavným motorom akcie. Je to síce súťaž a na konci je vyhlásenie víťaza, ale žiadne reálne vecné ceny nečakajte. Tie by len poškodili hlavnú motiváciu a tou je zvedavosť a snaha niečo dokázať. Fedexday neznamená len, že môžete robiť, na čom chcete, ale aj to, že máte na to 24 hodín a nie viac. Za ten čas musíte byť schopný dodať to, čo ste si predsavzali.

Pred určitým časom som sa takejto akcie zúčastnil a myslím si, že je to niečo, čo je prospešné pre firmu aj zamestnanca naraz. Zamestnanec môže zažiť nevšednú akciu, pri ktorej si otestuje novinku alebo vytvorí niečo, po čom už dávno túžil. Firma zase za malý obnos (poskytnutie priestorov, pizza) u ľudí zvýši motiváciu k práci. Začať pracovať na obed jedného dňa, pracovať 24 hodín bez oddychu a na ďalší deň opäť na obed to prezentovať je zážitok, ktorý možno nie je až taký adrenalinový ako skok s bungee lanom, ale má svoju osobitosť. Jedna z vecí, ktorú vás to naučí je, že ste schopný dodať hotovú vec za kratší čas, ako ste mysleli. Pritom prostredie ani nástroje sa nemenia. Len vaša motivácia.

Fedexday vie byť pre firmu pomerne silným impulzom. Je podľa mňa lepší ako štandardná teambuldingová akcia, pretože ľudia si vyberajú, čomu sa budú venovať, a teda sú do toho viac zapojení ako do nejakých súťaží, ktoré niekto pripravil. Tímy sa formujú sami, myšlienky sa realizujú v krátkom čase a učiaca krivka je prudká. Po 24 hodínach máte dosť. Ste zrelý na sprchu a do postele. Ale kombinácia toho, že ste sa za tak krátky čas prehrýzli problémom a dodali niečo čo funguje, že ste pochopili, ako to máte celé postaviť a potom to postavili … to jednoducho stojí za to.

Agile Estimation and Planning

978d4fCítiť istotu je určite nepohodlné, ale byť si istý, to je na smiech.“ -čínske príslovie

Agilné metódy pomerne výrazne nabúravajú zažité postupy metód tradičných. Nielen že radia preniesť riadenie a zodpovednosť na ľudí, nepísať dokumentáciu (aspoň nie toľko ako predtým) a nerobiť analýzu (aspoň nie príliš dopredu), ale dokonca hovoria o tom, že dlhodobé a presné plány sú na nič. Odhadovanie a na ňom závislé plánovanie by sa malo robiť nepresne alebo krátkodobo. Odhady by mali tvoriť ľudia a zákazník by mal akceptovať neistotu v tom, čo bude dodané. To sú veci, ktoré sú niekedy (a v niektorých situáciach) len ťažko predstaviteľné. Ak vás zmáhajú pochybnosti ako to má celé fungovať, možno by ste mali siahnuť po knihe Agile Estimation and Planning od Mike Cohna.

Kniha je (prekvapivo) o plánovaní a odhadoch. Neobsahuje prakticky žiadne vysvetľovanie agilných metód, a preto nie je vhodná pre úplného začiatočníka. Kniha nie je len popisom postupov a artefaktov plánovania, ale je tiež značnou mierou obhajoba toho, prečo je tento postup správnejší ako tradičný. Ak teda potrebujete nazbierať argumenty v prospech agilného prístupu, v knihe určite nejaké nájdete.

Čo všetko tam vlastne môžete nájsť? Kniha je rozdelená do šiestich častí: 1. Problém a cieľ; 2. Odhad veľkosti; 3. Plánovanie pre hodnotu; 4. Sledovanie a komunikácia; 5. Prečo agilné metódy fungujú a 6. Prípadová štúdia.

Prvá časť skúma plánovanie ako také. Snaží sa identifikovať princípy a ciele plánovania všeobecne. Ďalej postupne vysvetľuje filozofiu agilného plánovania, porovnáva ho s klasickým plánovaním a poukazuje na rozdiely. Ako napríklad vyzerá dobrý plán? Je to plán, na základe ktorého môže zákazník robiť svoje vlastné rozhodnutia. To v preklade znamená, že robíte plán, ktorý je dostatočne presný, aby sa zákazník napríklad vedel rozhodnúť, kedy začať marketingovú kampaň, ale zároveň v sebe obsahuje dostatok priestoru na prispôsobovanie zmenám v budúcnosti.

Druhá časť sa plne venuje procesu odhadovania. Snaží sa objasniť, čo je to story point a prečo je lepší ako reálny človekodeň alebo ideálny človekodeň. Nájdete v nej tiež rôzne techniky na odhadovanie.

Tretia časť sa už zaoberá praktickým postupom plánovania agilného projektu. Ako zostaviť backlog (a čo to vôbec backlog je), ako naplánovať release a ako iteráciu. Prioritizácia backlogu je téma sama o sebe a je jej venované niekoľko kapitol. Prioritizovať sa dá na základe rizika a hodnoty, alebo na základe ROI či Kanov-ho modelu. Táto kniha je jednou z mála, v ktorej nájdete agilné metódy a seriózne tabuľky s prepočtom investovanej a navrátenej hodnoty. Autor sa tiež venuje téme dobrých User Story, ale o nich už existuje samostatná kniha, ktorá ich rozoberá dopodrobna (moju recenziu na ňu môžete nájsť tu: http://agile.sk/?p=568). V knihe sa dá nájsť aj kapitola o zahrnutí neistoty (teda vytvorenia buffera) pre plán alebo plánovania pre viactímový projekt.

V štvrtej časti nasleduje pasáž o vizualizácii a komunikácii plánov a to hlavne smerom k zákazníkovi. Mike ukazuje rôzne typy grafov pre zobrazovanie aktuálneho stavu releasu a iterácie a vysvetľuje, ako s nimi pracovať a ako odkomunikovať taký parameter, ako je rýchlosť (velocity) tímu.

Piata časť je pomerne krátka a obsahuje v skratke argumenty, prečo agilné plánovanie funguje a šiesta záverečná časť obsahuje prípadovú štúdiu plánovania vývoja softvérového projektu – počítačovej hry. Posledná kapitola je obzvlášť dobrá, ak si všetku tú teóriu z predchádzajúcich kapitol neviete predstaviť v praxi.

Kniha Agile Estimation and Planning podáva vysvetlenia v oblasti, ktorá je pre projekt jedna z kľúčových. Ak už máte predstavu o agilných metódach alebo ich už nejakým spôsobom používate, ale to plánovanie sa akosi stále deje po starom, pretože ten nový spôsob pôsobí príliš exoticky, môže byť táto kniha dobrý sprievodcom ako ďalej. Každopádne to, že sa na približne 300 stranách venuje len tejto téme, je dostatočný priestor na to, aby bola rozpytvaná pre potreby ľubovoľne odborného publika.