Proč jsem si knihu vybral?
Dlouho jsem se potýkal s nevědomostí, jak efektivně využívat agilitu/agilní řízení a co tu vůbec je. Proto když se tato kniha objevila na mém jídelním stole, okamžitě mě zaujala a okamžitě jsem si ji „ukradl“ k přečtení.
Co dělá agilní firma?
Agilní firma (tým, projekt, vývoj) dokáže dobře reagovat na vnější a vnitřní změny, hrozby, příležitosti a podněty.
Co je CYNEFIN?
a) Jasné a jednoduché
Tato doména představuje dobře známé problémy s jasným očekávaným výsledkem a postupem řešení (označujeme jako „známé známé“). Známe pravidla či nejlepší praxe, prostředí je stabilní a je jasná posloupnost „když A, pak B“. Doporučené chování v této doméně je „porozumět, zařadit, zareagovat.“ Jakmile pochopíme situaci, je třeba ji správně zařadit – a pak už jen konat podle daných pravidel pro danou situaci. Bohužel někdy se stává, že manažeři mají tendenci některé problémy a situace příliš zlehčovat a tlačit je právě do této domény.
Např. Pracovník, ke kterému objednávka dorazí, ji zařadí podle předem daných kategorií a poté aplikuje příslušný postup – například předání na příslušné oddělení k vyřízení a vystavení faktury.
b) Komplikované
Druhá doména sestává ze „známých neznámých“. Pro správnou reakci (a posouzení vztahu „jestliže – pak“) je potřebná analýza situace a výběr z možných správných řešení.
Např. Příkladem problému z této domény může být například stavba mostu. Neexistuje jeden typ čí návrh mostu, který by byl vhodný do všech prostředí. Pro návrh a stavbu mostu však existují normy a standardizované postupy, materiály atd.
c) Kompletní
Doporučení pro tuto doménu zní: „prozkoumat, porozumět, zareagovat“. Tedy zkusit něco udělat (prototyp, experiment), pochopit, co se stalo, a následně na to reagovat.
d) Chaos
Doporučení pro tuto doménu zní: „jednat, porozumět, zareagovat.“ Začít něco dělat, porozumět tomu, co je a není stabilní, a následně reagovat se snahou změnit chaos v komplexní situaci.
e) Zmatek
Tuto doménu bychom mohli pojmenovat jako „nikdo nic neví“. Není jasné, do jaké z úvodních čtyř domén problém patří, lidé se hádají mezi sebou a celkově se jedná o jistou katastrofu
Kořen agility – Lean
Co je to „lean“? Je to filozofie zaměřená na člověka, která má dva hlavní pilíře: respekt k lidem a neustále zlepšování. „Manažer“ v lean prostředí se snaží svým lidem ukázat, jak se učit, autonomně přemýšlet, přicházet s nápady a samostatně řešit problémy. Neříká jim, co mají dělat, a neřídí každý jejich krok, jak bylo tehdy všude jinde zaběhnutým postupem.
V kostce se lean filozofie snaží dělat jen to, za co je zákazník ochoten platit (tedy to, co má hodnotu), a minimalizovat věci, ze které nikdo platit nechce (plýtvání).
Zájem o vysokou efektivitu práce (individuální, na bázi KPI) nahrazuje zájem o výsledný efekt, hodnotu (efektivnost). Proto mívají agilní organizace velmi plochou organizační strukturu, založenou na stabilních sebeorganizovaných týmech (což je jeden aspekt z mnoha a důvodem je redukce plýtvání.
Snažíte se průběžně zlepšovat? Máte k sobě navzájem respekt? Učíte své lidi učit sebe i ostatní? Učíte je dělat rozhodnutí? Přijímat zodpovědnost? Redukovat plýtvání? V tom spočívá jádro lean myšlení, tohle je důležité. Ostatní s tím přijde samo.
Ve chvíli, kdy se podaří, aby zodpovědnost a aktivitu převzali lidé v týmech, už prostě nebude potřeba, aby je někdo pouze koordinoval, úkoloval a kontroloval. Taková činnost přestane mít jakoukoliv hodnotu.
Lean v tomto kontextu definuje pět základních kroků:
1. Identify value – urči hodnotu. V čem spočívá hodnota z pohledu zákazníka? CO vlastně je potřeba vytvářet, abychom způsobili reálný dopad, efekt, naplnění potřeby zákazníka? Někdy je velmi těžké tuto otázku zodpovědět. Každopádně se vyplácí jít do hloubky a zkoumat jakési „prvotní potřeby“.
2. Map the value stream – prozkoumej tok hodnoty. Pokud vezmeme definovanou hodnotu jako výchozí bod, které aktivity a kroky přispívají k jejímu vytvoření? Veškeré činnosti, které nepřispívají k hodnotě, se chápou jako plýtvání, odpad. Ten může být z nějakého důvodu nezbytný a snažíme se jej redukovat na minimum, nebo může být i zcela zbytečný.
3. Create flow – vytvoř tok. Když je odstraněn odpad, snažíme se o to, aby hodnoty vytvářející aktivity plynuly hladce, bez zdržení nebo přerušení. Může to zahrnovat přeskládání procesů, jiné rozložení pracovní síly, tvorbu multifunkčních pracovišť a týmů.
4. Establish pull – stabilizuj tah. Systém založený na tahu minimalizuje skladové zásoby a množství rozdělané práce. Věci a prvky se v tomto kontextu vytvářejí až ve chvíli, kdy jsou potřeba, a v množství, které je potřeba.
5. Pursue perfection – usiluj o dokonalost. Každý pracovník by měl usilovat o zdokonalování sebe sama a prováděné práce. Vidím, že by šlo něco dělat lépe? Nebo že by šlo daný proces nějak vylepšit? Sem s tím! Neustále zlepšování je možná nejdůležitější součástí lean kultury.
Které tři věci nejvíce brání konceptu lean?
1. Muda – plýtvání marnost, zbytečnost
1.1. Transport –zbytečné posílání dokumentů/mailů (oproti využití sdíleného uložiště), složité schvalovací smyčky
1.2. Zbytečné pohyby – nevhodné uspořádání pracovišť, hledání dokumentů a přepisování dat z aplikace do aplikace
1.3. Čekání – např. na dokumenty nebo kolegy na poradě
1.4. Nadbytečné zpracování – identifikujte zbytečné kroky v procesu a odstraňte je, zbytečné schůzky, dělání zbytečné práce
1.5. Vady a opakování – lepší udělat na poprvé pořádně a neplýtvat následně časem za špatně odvedenou práci
1.6. Nadprodukce – na co vyrábět, když to nikdo nepoužije
2. Mura – nerovnoměrnost, nevyváženost, nedostatek jednotnosti
Patří sem například nerovnoměrné rozložení pracovní zátěže, nepravidelný pracovní rytmus, nerovnoměrná kvalita. Pokud je například termín ještě daleko, je obvykle úplně jiná úroveň nasazení a stresu, než když je deadline za dva týdny.
Mura je také „zlo“ v podobě práce postupem, který lidem nevyhovuje, je pro něj nepřirozený (nejde jim pod ruku). Lidé se soustředí na to, jak se věci provádějí, kterým nástrojem, podle jakého podrobného procesu. Proto jsou týmy v agilní organizaci velmi často tzv. sebeorganizované. Soustředíte se na výsledky, hodnotu, dopad jejich činnosti a necháváte jim volnost v tom, jak toho bude dosaženo.
3. Muri – přetěžování zdrojů, nepřiměřenost
Toto „zlo“ se projevuje především jako přesčasová práce, rutina (která může být mentálně unavená), nadměrný stres, nedostatečný spánek a tedy předpoklady vedoucí k vyhoření. Lze zde vidět i věci jako neudržitelné tempo vývoje, příliš ambiciózní KPI, nereálné termíny, nezájem o názor atd.
Co je motivace 3.0. a proč sedí k agilnímu řízení?
Motivace 1.0. – Ve velmi dávné historii byli lidé poháněni svými pudy a potřebou přežít.
Motivace 2.0. – Jádrem je princip, že kromě potřeby přežít pohání lidi ještě potřeba vyhnout se trestu nebo naopak hledat odměnu. U nás se vžilo označení „cukr a bič“.
Motivace 3.0. – Hlavním hybačem je zde právě vnitřní chuť dělat něco smysluplného, co nás baví, dělat si to po svém a být v tom dobří. Jste ve stavu flow. Když však za vámi někdo přijde s tím, že pokud splníte ty a ty výkonnostní cíle, dostanete odměnu. Různé studie prokázaly, že když na to přistoupíte, v drtivé většině případů, se vytratí „ten“ pocit, který jste měli před tím. Už to není zábava, už je to práce. Přitom se jedná stále o stejnou činnost. Jen už nejste tak svobodní, zužují vám pohled nějaké cíle zadané někým jiným… vnitřní potěšení se vytratí.
Pokud tedy chceme angažované a motivované jednotlivce a týmy, je třeba vytvářet prostředí, v němž si dotyční budou moci do značné míry sami volit způsob řešení, ve kterém porostou a které jim dávat celkový smysl. Podmínky pro vznik angažovanosti a výkonu fungují jako důsledky stylu vedení managmentu, kultury společnosti a stavu klimatu na pracovištích. Nevyžadují žádné náklady ani materiální odměny. Netýkají se peněz, bonusů ani poskytování organizačních či ekonomických odměn. Snad jen příležitosti učit se by mohly představovat náklady.
Co na to vývojové fáze týmu?
V roce 1965 popsal Bruce Tuckman vývojové fáze týmu, které probíhají (řízeně či samovolně) v de facto každém prostředí, kde má skupina lidí dosáhnout nějakého společného výsledku.
Ve většině organizacích je cílem vytvořit co nejvíce samostatný, angažovaný a úspěšný tým. Kdo by takový nechtěl, že? Ale moc takových není… proč? Protože vývoj týmu většinou nikdo neřídí.
Fáze 1: Forming
První fáze, ve které tým ještě není týmem. Většina lidí na takovém setkání není moc aktivní, chtějí si hlavně poslechnout, o co jde, jak by se jich to mělo týkat, a případně si „ochránit to svoje“. Naší úlohou je v této fázi především informovat, a tak trochu i velet. V tuto chvíli je prostě potřeba udat jasný směr. Musíte vysvětlit základní smysl a cíl projektu, vizi produktu apod. Naučit lidi případné nové koncepty a nástroje pro spolupráci.
Fáze 2: Storming
Jakmile si tým nastaví kurz a základní pravidla spolupráce, začíná reálně spolupracovat. Teď začnete zjišťovat, co jste při nastavování pravidel spolupráce nedořešili, co lidé nepochopili nebo nevnímali. Tato fáze je plná konfliktů, napětí a někdy i hádek. Je pro všechny zúčastněné velmi nepříjemná. Bohužel, pokud není vývoj týmu řízen, u velké části projektů je i fází konečnou. Abyste se z ní dostali v rozumném čase, tedy před konečným termínem projektu, musíte změnit přístup.
Jak zvládnout storming správně? Facilitovat!! A přestat řešit vše osobně (Karel přijde za mnou, že Alice něco nedělá, já jdu za Alicí a vyřídím odpověď Karlovi. Mnohem lepší je pozvat si Karla s Alicí společně a pomoci jim k tomu, aby sami našli řešení svého problému. Protože když jim řeknu, co mají dělat a bude to špatně, oni jsou v klidu. Jen dělají, co jsem jim řekl. Pokud to bude jejich řešení, jsou jeho vlastníci oni. Je jejich vzájemná zodpovědnost, že řešení funguje. Takto nastíněným přístupem můžete tým naučit starat se o své problémy a o své členy.
Fáze 3: Norming
Pokud se Vám podaří dostat do této fáze vývoje týmu, vypadá to, že máte vyhráno. Většina konfliktů se vyřešila, hrany se obrousily, vše si tak nějak sedlo. Lidé se už nehádají, spolupráce funguje, aniž byste ji museli vy nebo tým řešit. A členové týmu se cítí dobře. Proto se jim nebude chtít z této fáze dál. většinou budou mít obavy z dalších změn, protože by v jejich očích mohly vést zpátky k pádu do stormingu.
Chtěný norming vypadá tak, že si věci sice sedly, ale nikoliv následkem rezignace a odevzdané apatie. Lidé v týmu si prostě byli schopni domluvit pravidla tak, aby jim vyhovovala, byla podle nich.
Fáze 4: Performing
Zde chcete tým mít. Spolupráce je velmi efektivní, a i když vznikají díky vysokému tempu a experimentování nějaké konflikty, tým je umí sám účinně řešit. Mimo jiné jste členy naučili přemýšlet nejen o tom, co dělají, ale také jak to dělají. Atmosféra v týmu je plná energie, přitom ale klidná a vyrovnaná. Konflikty nejsou osobní, ale v zájmu týmu a zlepšení výsledků a výkonu.
Co je to ta slavná sebeorganizace?
Sebeorganizace samozřejmě neznamená to, že by si každý dělal, co se mu zrovna zachce, že by najednou místo práce ve výrobě šel třeba vyrábět domácí keramiku nebo zpívat. Sebeorganizace má své mantinely dané vizí příslušné organizace, stanovenými cíli atd. Určení těchto hranic je úkol managmentu organizace, byť je faktem, že je to spíše otázka během vzniku a utváření.
Jak agilně z vize vytvořit produkt?
Na začátku by se měla odehrát dobře provedená product development fáze, která nám dá smysluplnou vizi produktu, pojmenuje hlavní zákazníky a jejich potřeby a identifikuje hlavní směry vývoje (respektive co by asi tak náš produkt měl zhruba dělat a umět).
Po základní definici produktu začíná fáze product discovery. Týmy se většinou snaží identifikovat konkrétní zástupce svých zákazníků a diskutovat s nimi o jejich problémech a potřebách, pochopitelně především v kontextu zamyšleného produktu. Někdy dochází k tomu, že tým stráví s reprezentanty zákazníků nějakou dobu a prostě pozoruje, co a jak dělají. Pokud máte reálného člověka, který by měl používat váš produkt, je to ideální a snažte se mu co nejvíce přiblížit. Nejzazší variantou je v tomto kontextu tvorba vymyšlených person a snaha vcítit se do věcí z jejich úhlu pohledu.
Výsledkem této fáze by měla být tzv. story map. Popis toho, jakým způsobem daný konkrétní zákazník používá náš nový produkt, aby dostal hodnotu nějak jinak, respektive lepším způsobem než nyní: v takové podobě, aby za to byl ochoten a chtěl zaplatit.
Všechny tyto konverzace a diskuse by v této fázi měly vést ke zvýšení vzájemného porozumění mezi zákazníky a týme, mezí členy týmu navzájem atd. Jde o pochopení zákazníka a jeho kontextu.
SCRUM
Scrum je přímo založen na sebeřízeném, kompletním týmu, která získává co nejčastěji a co nejvíce napřímo zpětnou vazbu od zákazníka a upravuje tak ve spolupráci s product ownerem svůj další postup – co možná nejvíce transparentně, formou sprintů. Je dobré si uvědomit, že scrum není cílem, ale prostředkem. Je to cesta například ke spokojenějším zákazníkům, kvalitnějšímu produktu a motivovanějšímu týmu.
Vítáme zde změny i v pokročilé fázi vývoje, protože cílem není dodat původně psanou funkcionalitu, ale co největší hodnotu pro zákazníka. Místo individuálních KPI se zaměřujeme na výkonnost týmu jako celku (měřenou dodanou hodnotou pro zákazníka, tedy efektivností, nikoliv efektivitou).
Scrum se skládá z:
1. Transparentnost
Proces a vznikající práce musí být viditelné jak pro osoby provádějící práci, tak pro ty, kteří práci přijímají, nebo se jich nějakým způsobem týká. Je třeba, aby bylo zřejmé, na čem se pracuje, v jakém to je stavu, na čem se zřejmě bude pracovat v nejbližší době atd.
2. Pozorování
Ve velmi krátkých intervalech je potřeba provádět pozorování všech důležitých aspektů – jestli se pracuje na tom, co má hodnotu, jak se daří v průběhu sprintu, zda tým pracuje efektivně atd.
3. Přizpůsobení
Pokud se některé aspekty procesu odchylují mimo přijatelné limity nebo je-li výsledný produkt nepřijatelný, musí být aplikovaný proces nebo vyráběné výsledky upraveny. Proto je potřeba, aby měli zúčastnění lidé dostatek pravomocí a kompetencí k provádění potřebných změn, tedy k sebeřízení. Scrum předpokládá, že se scrum tým přizpůsobí v okamžiku, kdy se prostřednictvím pozorování naučí něco nového.
Scrum tým
Členové scrum týmu mají všechny znalosti a dovednosti potřebné k vytvoření hodnoty každého sprintu. Neznamená to, že ve scrum týmu jsou ti největší odborníci na všechny činnosti. Ale je tam někdo, kdo je schopen je dostatečně dobře pokrýt. Tyto týmy jsou sebeřízené, což znamená, že interně rozhodují, kdo co dělá, kdy a jak to dělá, jaké se používají podpůrné nástroje atd. Obvykle ho tvoří deset nebo méně lidí.
Scrum tým se skládá z následujících rolí:
- scrum master (jedna osoba)
- prodcut owner (jedna osoba)
- vývojáři (více osob)
Scrum master
- Zodpovídá za efektivitu sebeorganizovaného scrum týmu. Dělá to především prostřednictvím reflexe průběhu sprintů při retrospektivách, koučováním členů týmu, facilitací událostí scrumu apod.
- Způsobuje odstraňování překážek v pokroku scrum týmu.
- Vede tým k přijímání zodpovědnosti, samostatnosti a sebeorganizaci. Dokonce pokud dojde k přesvědčení, že chování některého člena týmu narušuje výkon týmu jako celku a že dostupná řešení selhala, je oprávněn takového člena z týmu vyřadit.
Product owner
- rozvoj a otevřenou komunikaci cíle produktu
- prioritizace položek produktového backlogu
- ujišťování se, že je produktový backlog transparentní, viditelný a pochopený
- aby uspěl, musí celá organizace respektovat jeho rozhodnutí. Toto rozhodnutí se odrážejí v obsahu a prioritizaci položek z produktového backlogu
- pouze on přidává, odebírá nebo prioritizuje produktový backlog. Nedělá to jako vykonavatel rozhodnutí někoho jiného, ale na základě svých vlastních rozhodnutí a své vůle. Pokud někdo chce provést změnu produktového backlogu, může to udělat tak, že se o tom pokusí přesvědčit product ownera
Vývojáří
- pomáhá vytvořit plán pro sprint/backlog sprintu
- zajištění kvality dodržováním definice, kdy je hotovo DoD
- přizpůsobuje svůj plán směrem k cíli sprintu
- vzájemná odpovědnost jako profesionál
Co je to product backlog? Soupis položek, které by měly vést k naplnění cíle vývoje našeho produktu.
Co je CoS (Conditions of Satisfaction)? Je to úvaha, za jakých podmínek bude daný konkrétní uživatel spokojen. Platí, že v rámci CoS se používají spíše kvalitativní kritéria a parametry než „tvrdé“ číselné hodnoty.
Co je přírustek produktu? Je to konkrétní krok k dosažení cíle produktu. Znamená to, že se jedná o použitelný kousek funkcionality, který si lze vyzkoušet a lze k němu dostat zpětnou vazbu. Souhrn přírůstků je prezentován na review sprintu, čímž se podporuje zpětná vazba.
Co je DoD (Definition of Done)? Přírůstek vznikne v okamžiku, kdy položka produktového backlogu splňuje DoD. DoD vytváří transparentnost tím, že poskytuje každému sdílené porozumění tomu, která práce byla v rámci přírůstků dokončena. Minimální DoD bude zřejmě zahrnovat požadavky jako: vytvořeno – otestováno a opraveno – schváleno vlastníkem produktu – otestována a opravena integrace s ostatními přírůstky – vytvořena dokumentace úrovně XYZ – prošlo sprint review bez připomínek.
Co je to sprint a jak ho Scrum využívá?
Sprinty udávají ve scrumu rytmus a mají tak pevně danou délku. Je to jeden měsíc nebo méně (méně je lépe). Nový sprint začíná okamžitě po skončení přechozího sprintu. Oprávnění zrušit už domluvený sprint má pouze product owner.
1. Plánování sprintu
Sprint je zahájen plánováním sprintu, jehož smyslem je stanovit a rozvrhnout práci, která má být ve sprintu provedena. Tento výsledný plán je vytvořen spoluprací celého scrum týmu. Product owner zajišťuje, že účastníci jsou připraveni diskutovat o nejdůležitějších položkách produktového backlogu a o tom, jak souvisí s cílem produktu (že jim tedy všichni rozumí a chápou je a že byly prodiskutovány).
Točit bychom se měli kolem následujících třech témat:
1.1. Proč je tento sprint hodnotný? Prodcut owner navrhuje, jak by produkt mohl v aktuálním sprintu zvýšit svou hodnotu a přínos. Cíl sprintu musí být definován před koncem plánování sprintu.
1.2. Co lze v tomto sprintu dokončit? Na základě diskuse s product ownerem vybírají vývojáři z produktového backlogu položky, které budou zahrnuty do aktuálního sprintu.
1.3. Jak bude vybraná práce dodána? Vývojáři naplánují pro každou vybranou položku produktového backlogu práci nezbytnou k vytvoření přírůstku, který splňuje DoD. Způsob, jak se to provede, závisí čistě na úsudku vývojářů. Nikdo jiný jim neříká, jak proměnit položky produktového backlogu na přírůstky hodnoty.
2. Denní scrum
Účelem denního scrumu je prozkoumat pokrok směrem k cíli sprintu a podle potřeby upravit sprint backlog úpravou další plánované práce. Denní scrum je maximálně na 15minutová událost pro vývojáře scrum týmu. Pro zjednodušení se koná ve stejný čas a na stejném místě každý pracovní den sprintu. Pokud product owner nebo scrum master aktivně pracují na položkách ve sprint backlogu, účastní se také.
3. Review sprintu
Účelem review sprintu je prozkoumat výsledkem sprintu a určit budoucí přizpůsobení. Během review získává tým ZV o tom, co se během sprintu dotáhlo do stavu „hotovo“. Toto je také obvykle kritériem, jestli daná věc může nebo nemůže jít na review. Obvykle platí zásada, že co není hotovo (nesplňuje DoD), není hotovo a nemůže jít na review. Review sprintu je pracovní setkání a scrum tým by se měl vyhnout tomu, aby se toto setkání omezilo pouze na prezentaci. Té by koneckonců mělo být co nejméně. V podstatě ideální je, když vývojáři nějakým vhodným způsobem „dají na stůl“ všechno, co se podařilo dokončit, a zadavatelé si to v klidu prozkoumají. A následuje diskuse.
4. Retrospektiva sprintu
Identifikují se mylné domněnky a předpoklady z končícího sprintu a je snaha zjistit i jejich příčiny. Scrum tým diskutuje o tom, co šlo během sprintu dobře, na jaké problémy a narazil a jak byly (nebo nebyly) tyto problémy vyřešeny.
Co je to kanban?
Tento přístup si klade za cíl řídit práci vyvážením požadavků s dostupnou kapacitou a zlepšením řešení úzkých míst na úrovni systému. Pracovní položky se vizualizují, aby účastníkům poskytly pohled na postup a proces od začátku do konce – obvykle prostřednictvím „nástěnky“, tedy kanbanu. práce je tzv. „tažena“ podle priority a nikoliv „tlačena“ do procesu. Cílem struktury kanban je objasnit obecný pracovní postup a tok jednotlivých položek účastníkům a zúčastněným stranám.
Škálovací rámec LeSS (Large Scale Scrum)
Jedná se o to, jak lze co nejjednodušeji aplikovat zásady, prvky a eleganci scrumu ve velkém měřítku. Máme jeden product backlog, jedno DoD a jednoho product ownera. Rámec LeSS je od 2 do 8 týmů (o velikosti do 8 lidí).
Scrum of Scrums (SoS)
SoS je technika pro podporu provozování scrumu ve větším měřítku, kdy na stejném produktu pracuje více týmů. Platforma SoS jim umožňuje diskutovat o postupu a vzájemných závislotech se zaměřením na koordinaci dodávání softwaru. Zvláštní pozornost je přitom věnována, různým překryvům a následné integraci. Princip spočívá v tom, že po denním scrumu dílčích týmů je určen jeden člen týmu jako ambasador, který se následně účastní scrumu scrumů s ambasadory z jiných týmů. V závislosti na kontextu mohou být ambasadoři vývojáři, nebo scrum masteři.
Co je temný scrum?
Temný scrum je pojem, který vznikl v souvislosti s neúspěšnými pokusy o agilní transformaci. Ve zkratce jde o chybné pojetí agilního přístupu.
- Předepíšeme lidem, že musí dodávat ve sprintech, že musí být na denním scrumu. A že tento konkrétní rozsah (WBS) musí být tímto způsobem dodán za 4 měsíce v předepsané podobě s danými akceptačními kritérii.
- Na review nechodí nikdo z přímých uživatelů či jejich reprezentantů, protože je to: nezajímá; nemají čas; koná se příliš často; nevědí, proč tam mají být; vše se přece vyřešilo při zadání…
- Tým skutečného zákazníka nikdy neviděl, protože managment se děsí představy, že by zákazník viděl tu bandu hipíků, kteří nedej bože měli i mluvit. Na review tedy chodí obchodník nebo manažer projektu nebo jiný zprostředkovatel myšlení zákazníka.
ATP
Tak tohle jsem nečekal!!! Na to, že jsem před čtením knihy ani nevěděl, co je agilní řízení, tak jsem byl naprosto nadšen z knihy. Přelouskal jsem jí za pár dní. Poznatky o scrumu jsem si pečlivě zapsal a jako majitel své budoucí firmy se k poznámkám vrátím. My jsme už takový jeden velký scrum tady v Tiimi a je zajímavé si o tom přečíst i z jiného pohledu. Do projektu Seznamovák nevím, jak bych agilní v současné chvíli zahrnu. V projektu C+ nutrition se teprve nacházíme ve fázi plánování a nemám tedy, kde agilní přístup zkusit. Pravidelně si jej však zkouším v rámci BG na pozici „vývojáře“. Zkusím agilně třeba přispívat pro plánování práce týmu. Třeba jej využiji příští semestr jako „zlý pan“ learning manager.
