Tipy z oblasti: Agilní řízení

Sdílení zkušeností: Jak přesvědčit zákazníky o agilním vývoji

Tyto zápisky vznikly ze sdílení zkušeností, které proběhlo 6.8. Zúčastnili se zástupci z firem: Morosystems, Brightify, Roger, Mathesio, Wandera, Blackboard, AURA, ALTEC, Faceup Technology, KROUPAHELÁN advokátní kancelář, Oracle, Flyingarchitecture, Notum Technologies

Oblasti k řešení

• Výběr dodavatele
• Smlouva o spolupráci
• Organizace vývoje
• Vývoj řešení 

Téma: Jak zapojit zákazníka?

•  Možnost dát si do smlouvy, že každé dva týdny budeme ukazovat, co jsme odpracovali a firma to musí odsouhlasit. Pokud se k tomu nevyjádří, bereme to jako souhlas.
• Firmu to potom více motivuje komunikovat na pravidelné bázi. 
• Pozitivní motivace: lepší cena za podmínky, že dodržují komunikaci, tak jak si stanovíme. Pokud ne, přejde se na vyšší cenu
• Jak se prezentovat zákazníkovi: ideálně od začátku komunikovat, že dodáváme agilně. Zákazník má možnost odmítnout, pokud mu to nevyhovuje.

 Use case Morosystems:

• Chceme přesvědčit klienty, že agile je ideální řešení.
• Představíme nejhorší scénáře co se může stát, když půjdeme waterfallem. Kde jsou rizika
• Stavíme to na empatickém příběhu
• Neuvádíme jednu cenu a jeden termín, uvádíme ohraničenou cenu. připouštíte, že cena se může měnit.
• Zákazník si u nás neobjednává dílo, ale kapacitu týmu, který je na to alokován
• Nastavujeme to na tým máte takový problém, takže potřebujete tolik a tolik lidí
• Co garantujeme našim zákazníkům
• Garance na sprint, co nadesignujeme na 14ti denní, to dodáme
• Garantujeme stabilitu týmu
• Pokud se dostane chyba až do produkce, tak garantujeme, že jim to opravíme zadarmo
• Time man material
• Agilní kontrakty
• Další možnost je zafixovat cenu: zákazník jaké je jeho finanční maximum a na základě toho jsme schopni odhadnout, co jsme schopni udělat
• U agilní spolupráce je důležité se setkat s člověkem, kdo je hierarchicky o jedno výš a zeptat se, jestli ví všechny informace
• Product owner by měl být interní, ne na straně zákazníka. potom se může stát, že je nekomptetentní.

Agilní role

Sdílení zkušeností: Jak na estimace v agilním řízení

Tyto zápisky vznikly ze Sdílení zkušeností, které proběhlo 4.6. Zúčastnili se zástupci firem Flowup, Flowmon, Safetica, Notum Technologies, Wereldo, Cleevio, Morosystems, COPS

• U scrum týmu je důležité mít artefakty: soubor transparentních pravidel, která jsou jasně zapsaná a všichni je chápou stejně (kdo odhaduje, potvrzuje, sprintový backlog)
• Rozlišujte mezi definiton of ready a definition of done
• Estimation flow: Je užitečné se vytvořit checklist: soubor otázek, na které se zeptat sám sebe. Checklist udržuje scrum master.
• Story points (v abstraktních velikostech) vs. manday. Každý odhaduje trochu jinak.
• Dobrá praxe (Flowup): Když uděláme nějaký projekt a víme kolik času jsme na něm strávili, tak potom určíme kolik to bylo story points. A jak se v budoucnu objeví podobný projekt, budu už schopen odhadnout, kolik story points mi zabere a může to fungovat jako měřítko
• Story points je spojené s agilním mindsetem: schopnost odprostit se od času a definování práce v mandays

 Téma: Jak nastavovat pricing v agilním prostředí?

• Zákazník chce často vědět kolik toho přesně bude vývoj stát. Je důležité vysvětlit zákazníkovi agilní mindset
• Dopředu nemůžeme vědět, co přesně bude zadání a neví to ani zákazník
• Je třeba jim všechno vysvětlit, provázet je procesem a bát transparentní
• Pozor na termín MVP: často se stává, že to zákazník často chápe a má pocit, že je to zcela funkční produkt za nejmenší cenu
• Dát zákazníkovi možnost ukončit spolupráci z jejich strany, ale od začátku komunikovat to, že vaší i jejich snahou je, aby to dávalo smysl
• Flowup: Pokud přijde zákazník s vágním zadáním a specifikací, organizuje pro zákazníky workshop. Výstupem je technická specifikace, user stories a flow. Workshop se organizuje za fixní cenu. Výsledkem workshopu není samotná estimace
• Když se bavíme se zákazníkem o pricingu je důležité zjistit, co zákazníkovi přináší z jeho pohledu největší hodnotu (Co je první věc, kterou očekává, že bude fungovat? )
• Často se stává, že to co zákazník vnímá jako hodnotu je z vašeho pohledu k ničemu: zkuste to zákazníkovi říct, být transparentní a upřímní, co si o tom myslíte
• Organizujte demo pro stakeholdery
• U menších firem může pomoct projít s nimi business model canvas: aby viděli bigger picture, mohli se zamyslet, co je jejich value proposition a to propsat do vývoje
• Pro některé zákazníky je všechno důležité. Může pomoct rozepsat jednoduše všechny featury pod sebe a říct zákazníkovi, aby jim přiřadili hodnotu A,B,C (A -největší priorita, C- nejnižší priorita). Praxe je taková, že se většinou stihnou udělat featury A a na další už se ani nedojde. 
• Pamatujte: nikdy nic nemá stejnou prioritu! (rozdíl mezi nice to have a must have)
• Podobné jako workshop je vytvoření prototypu pro zákazníka: vytvořit dvě verze a zákazník si vybere
• Další možnost naceňování je limitovat se cenou: Maximum, co je zákazník schopný zaplatit
• Soustřeďte se na velocitu týmu

Téma: Jak odhadovat estimace releasů?

• Stává se, že odhady dělá úzká skupina seniorních lidí. To vede k tomu, že se nafukuje scope a nedodá se včas. -.> je důležité, aby odhady dělal celý tým. Pozor na to, když si svou práci estimuje developer sám. 
• Když máte plně kompetentní tým a práci doručují pomalu, je to problém komplexity
• Je velmi důležité mít dobře nastavené ceremoniály (standupy a retrospektivu po každém sprintu), ceremoniály musí být dobře odfacilitovány, aby přinesly to, co mají
• Je důležité mít průběžné testování, netestovat až na konci
• Jaké role je třeba pokrýt: delivery manager (zákazník ví, za kým má jít), QA, solution architect, team lead. (má znalosti a autoritu, vede tým) 

Užitečné nástroje

• Cynefin network: pomoc při rozhodování 

• Scrum team
• 

Sdílení zkušeností: Agilní řízení #6 (11.6.2019)

Škálované metodiky = jak agilně pracovat s velkými týmy ve větších firmách

• Možnost rozdělení na týmy, které dokážou produkt vyvinout od začátku do konce (tzv. tribe) tzn. není zvlášť front-end, back-end a mobilní vývoj, ale vznikne tribe, kde lidé z těchto týmu vytvoří tým nový
• Snazší pro komunikaci, časové plánování
• Inspirace: Spotfiy: model, jak funguje jejich engineering tým najdete zde: https://www.youtube.com/watch?v=R2o-Xm3UVjs
• Riziko zatížení product ownera

Jak nastavit smlouvu pro agilní vývoj?

• Jedna z možností je smlouva o dílo a potom účtovat za odpracované hodiny
• Může být zafixovaná částka a aspoň rámcově odhadnout kolik to bude stát. Cena se vypočítá podle z toho kolik je alokovanych lidí
• Další možnost je stanovovat výši odměny podle spotřebovaného času. Například když vývoj trvá o týden dýl, odměna může být jen poloviční.
• Subscription model: budeme pro vás vyvíjet řekněme 50 MD
• Periodicka platba po sprintech
• Model slovenské firmy: success fee: motivace, že to dotáhnou, periodická platba je nízká: pokryjí náklady a odměna za success fee je vysoká
• Prototyping: dá se použít interně - interně vyhodnotíme, jestli to má smysl, můžeme zákazníkům nabídnout varianty, ale je to dost drahé
• Příklad STRV: náš tým je součást vaší firmy, sám se řídí a vy ho platíte
• Cinefyn framework

Práce na roadmapě

• Nástroj: Agile wheel
• Možnost iterovat na verze
• Portfolio: nástavba Jiry
• Program výměny scrum masterů

Sdílení zkušeností: Agilní řízení #7

Tyto zápisky vznikly ze Sdílení zkušeností na téma Agilní, které proběhlo 13.8. Zúčastnili se zástupci z firem: T-mapy, Mathesio, COPS, Greycortex, IBM, Blackboard

Agilní řízení mimo vývoj software

• Agilní řízení mimo vývoj software
• Agilní přístupy se mohou prolínat do celé firmy (obchod, HR)
• Ceremoniály (srpinty, retrosektiva) se dají  zahrnout do jiných oblastí firmy.
• Cynefin framework: definuje komplexitu problému.
• Když jde o rutinní úlohu, je zbytečné používat scrum. 
• Příklad implementace agile v právnické kanceláři: jak reagovat na nečekané události, vytvořil se backlog, agilní board, zavedli ranní standup
• Ideální velikost scrum týmu: cca 7 lidí
• Restrukturalizace firmy do scrumu: vyplatí se konzultant. vymezit doménové oblasti, nové izolované doménové týmy. Pak řešit jak spolu jednotlivé domény fungují
• Domain driven design: metodika, event storming
• Crossfunctioing: každý umí všechno, důležité podporovat  týmu, vzájemně se vzdělávat
• Produktová rada: ostatní týmy zasahují do vývoje: marketing, obchod
• Zvát ostatní na demo sesions
• Tip: Česká cesta” pomůže pochopit jiná oddělení

Neplánovaná maintanence v rámci sprintu

• Vývojáři dělají zároveň víc projektů najednou, vpadne do toho hodně incidentů, jak na to?
• Všechny projekty na jednom boardu, domluvit se s product ownerem, že nějaká část kapacity bude vyhrazena na opravy bugů.
• Naplánovat méně kapacity (80%), mít buffer
• Technika fantom: v jednom sprintu určím dva lidi, kteří se budou starat o maintenance 
• Technika: plánovat na 60 procent, dle historických dat můžeme zhruba určit kolik bude incidentů.
• Jak řešit nenadálé věci: máme několik úrovní podle priorit (1,2,3) to s nejvyšší prioritou řešíme na daily meetingu, tam je i product owner. Priorita dva: musíme řešit v dalším sprintu, priorita 3: budeme na tom pracovat třeba za 2 měsíce
• Na denní bázi revidujeme, buď se to vleze do bufferu, nebo se holt posune sprint
• Scrum master a product owner nemá být jedna osoba
• Scrum master má ochránit tým od vnějších vlivů

Agilní nástroje (jak naložit s časem)

• Qizlet
• Todoist