Odborná snídaně 20.9. - Agile@DevOps - 1. část
•Download as PPTX, PDF•
1 like•333 views
Jak (ne)pohřbít agile v 7 krocích Agile v T-Mobile CZ Agile FTFP
Recommended
More Related Content
Similar to Odborná snídaně 20.9. - Agile@DevOps - 1. část
Similar to Odborná snídaně 20.9. - Agile@DevOps - 1. část (20)
More from Profinit
More from Profinit (20)
Odborná snídaně 20.9. - Agile@DevOps - 1. část
- 1. Jak (ne)pohřbít agile v 7 krocích Pavel Krayzel, Delivery Manager 20. 9. 2016
- 3. 3 O čem mluvit nechceme
- 4. 4 ???
- 5. 5 Proč agile? › Možnost reagovat na změny › Možnost pracovat s vizí místo pevného zadání › Možnost průběžně si osahávat nápady i řešení Incrementally Instead of all at once
- 6. 7 kroků, jak (ne)pohřbít agile
- 7. 7 1. Business + IT › Business je součástí procesu tvorby software › Není to nákup auta
- 8. 8 2. Silný product owner › Má vizi produktu › Má čas se tomu věnovat › Je schopný přijímat rozhodnutí
- 9. 9 3. Omluva pro absenci procesu › Neznamená to… – nemít žádný plán a žádný proces – nedodržovat termíny – nepsat dokumentaci
- 10. 10 4. Doing agile vs being agile › Koncentrace na praktiky místo na podstatu › Cílem je dodávat funkční software, ne dodržovat metodiku › Napodobování věcí co fungují jinde…, ale víme proč?
- 11. 11 4. Doing agile vs being agile
- 12. 12 5. Agile jako silver-bullet › Nepomůže vyřešit všechny problémy, které organizace má › Může rovněž skončit neúspěchem › Nepomůže pokud není známá vize › Nehodí se pro všechny situace
- 13. 13 7 častých problémů 1. Business + IT 2. Silný product owner 3. Omluva pro absenci procesu 4. Doing agile vs being agile 5. Agile jako silver-bullet 6. Marketing do firmy 7. Agile a fixování rozsahu
- 14. Jak z toho ven?
- 15. 15 Jak z toho ven? › Víme, proč to vlastně chceme? › Máme na to business parťáka? › A co zbytek organizace?
- 16. 16 JAK USPĚT S AGILE VE FIRMĚ Marek Endlicher, T-Mobile CZ 20.9.2016
- 17. PROČ ZAČÍT DĚLAT AGILE? 17 Naše důvody v T-Mobile:
- 18. CO POTŘEBUJETE PRO ÚSPĚCH AGILE? 18 Motivaci Důvody, proč dělat Agile Správné lidi Agile je změna a není pro všechny Know-how Nebojte se si nechat poradit Podporu ve firmě Kombinace přístupů Bottom-up & Top-down
- 19. JAK JSME ZAVEDLI AGILE V T-MOBILE 19
- 20. VÝZVY AGILNÍ TRANSFORMACE 20 Kulturní změna Kulturní změnu nelze nařídit – lidé se musí chtít změnit Podpora vedení Bez podpory vedení narazíte na hranice, které jen těžko překonáte Škálování V prostředí s komplexním IT se časem neobejdete bez škálování „Svatá válka s waterfallem“ Rezistence waterfall světa dokáže být veliká, buďte připraveni na dlouhý a tuhý boj
- 21. DALŠÍ KROK - DEVOPS 21
- 22. 2222 DÍKY ZA VAŠÍ POZORNOST „Agile development will not solve any of your problems - it will just make them so painfully visible that ignoring them is harder.“ Ken Schwaber Father of Scrum THE INEVITABLE TRUTH
- 23. Agile FTFP Richard Michalský, Solution Architect 20. 9. 2016
- 24. 24 Agile & FTFP?
- 25. 25
- 27. 27 Project pipeline › Jak tohle celé dodat FTFP?
- 28. 28 Fixed Time, Fixed Price › S rozsahem se bude pracovat! › User stories › 80 % … 300 % › Minimum Viable Product , Variable Scope
- 29. 29 Zákazník a dodavatel na jedné lodi › Silný Product Owner… › … závislý na dokončení projektu
- 30. 30 Faktory úspěchu › Interní vývoj › Nebo team-lease… › ... se zapojením interních lidí › On-site › Prostředí kontrolované důvěry
- 31. 31 Dokumentace › Analytické sprinty › Koncepce a architektura › User stories a backlog › Specifikace během vývoje
- 32. 32 Agile & FTFP done right
- 33. Profinit, s.r.o. Tychonova 2, 160 00 Praha 6 Telefon + 420 224 316 016 Web www.profinit.eu LinkedIn linkedin.com/company/profinit Twitter twitter.com/Profinit_EU Děkujeme za pozornost
Editor's Notes
- neni to obchodni prezentace Mluvit tady budou prevazne technicti lide, pripadne lide co vedou projekty chceme diskutovat co jsme zazili, co jsme videli… nase zkusenosti… Zajimaji nas ale i Vase zkusenosti a radi bychom aby tady vznikla diskuze
- Nebudeme mluvit o zakladech, co je v agilnim manifestu, zakladni principy a hodnoty Nechceme dnes mluvit o konkretnich praktikach a metodach Nechceme Vas presvedcovat ze jedna je lepsi nez druha… chceme se podelit o nase zkusenosti s ruznych projektu, kde co jak vidime ze nefunguje jak by mohlo chceme i rozproudit debatu co funguje / nefunguje
- Nase zkusenost je, ze temer kazdy se s tim nejak setkal; nicmene malokomu to funguje nebo tomu veri - schvalne kdo z Vas uz se s tim ve sve organizaci nejak setkal (bud primo na projektu, nebo ve vedlejsim oddeleni / projektu), pripadne kdo na to ma alespon nazor? - kdo z Vas s tim ma pozitivnu zkusenost (v jakem smyslu - projekt splnil svoji vizi, dodal efektivne co mel atp - neni to moc fuzzy otazka?) - pokud bude odpoved dle ocekavani malo lidi; pak otocit na druhou stranu - kdo z Vas s tim ma naopak negativni zkusenost (videl projekt selhat, nedodat, byt zastaven atp)? TODO ? - zde se mozna jeste zeptat X lidi na hlavni problemy zda dokazou rici - probrat jak bude pusobit, zda to nenaboura kostru, jak pak budem schopni reagovat a drivovat to dale? - pokud bude odpoved prekvapive hodne lidi; pak z toho vybruslit stylem ze si radi popovidame / podeli o zkusenosti zda maji nejaky lek na nektere z problemu o kterych budeme mluvit
- Proč vlastně agile? Co je v tom pro nás? agile vyvojem dostava zakaznik to co potrebuje v dobe kdy to dodava, ne v době moznost pracovat s vizi a ne s presnym zadanim - ma moznost si to osahavat jak to vznika Reakce na změny (TODO obrázek / příběh) Vágní zadání Možnost osahat si nápady i řešení Na konci dne by mel vzniknout ten spravny software / produkt , idealne jednodussi a levnejsi
- Naše zkušenost z toho co vidíme se dá shrnout do cca X problémů
- Pokud prinosy z predchoziho slajdu budete prezentovat nekomu z obchodu… dost často ho pro věc nadchnete. Co ale často nefunguje / nezazni – není to jen věci IT – pro business to není „zadarmo“. Timto se business stava primym ucastnikem procesu tvorby software. Toto není nakup auta, kdy z katalogu vyberete jakou chcete karoserii, jakou chcete mimoradnou vybavu… dohodnete si jakou chcete slevu a cekate kdy Vam auto dodaji. Je potreba si uvedomit ze je potreba zcela zmenit tento zazity zpusob uvazovani… Business a IT musí fungovat spolu, nestaci jen jeden z nich… business si nenakupuju IT sluzbu, ale je uvnitr procesu… a spolurozhoduje o tom co se dodava atp… Zaroven tam musí byt urcita duvera v IT…
- K tomu aby to fungovalo je naprosto klicova role product ownera… clovek který by mel mit vizi produktu (není nutne mit presne zadani, do puntiku sepsane a vymyslene)… ale směr kudy produkt smerovat… nemusi vedet detaily jak to bude fungovat, ale vi proc se to buduje, jaky problem to resi… a pro koho! Tento clovek musí mit cas se tomu venovat… pokud to je jeho 8. projekt v rade a vidite se s nim jednou tydne / jednou za 14 dni hodinu… pak to nikam nepovede. Tento clovek musí byt zaroven dostatecne silny v organizaci aby si umel od stolu delat rozhodnuti a prijimal za ne odpovednost (pripadne je v kratkych otockach – jednotky hodin) umel ziskat z tech spravnych lidi… Pokud se po mesici ukaze ze rozhodnuti nebylo optimalni a musí se to predelat, neda se nic delat ale je to lepsi nez mesic stat a cekat na optimalni reseni které se stejne od stolu (bez te zkusenosti slepe ulicky / nespravneho rozhodnuti) udelat neda Tento clovek musí byt schopny mluvit a spolupracovat i s lidmi z IT světa… ne s analytiky kteří mluvi jeho jazykem, ale agile je o spolupraci mezi lidmi…
- Agile vzniknul protože stavajici proces byl rigidni… nebyl vyhovujici a nebylo mozne v nem rychle reagovat na zmenu… Neznamena to ale ze zadny proces není potreba… TODO: nejaky prakticky priklad kdy se agile schovava za no process Napr: ? u jednoho z nasich zakazniku rozvijime velky a hodne pouzivany systém, kde se jede klasickym waterfallem… vznika spousta dokumentace (dve / tri urovne analyticke, designerske – technicke, testovaci, …) proces je hodne rigidni a vhodny pro vetsi pozadavky / integracni projekty kde není snadne něco predelavat a je potreba to udelat dobře… jak se tym zajel tak je toto zbytecne rigidni pro drobny rozvoj… neznamena to ze pro drobny rozvoj nebude zadny proces… proces bude jednodussi… seskrta se o kroky které jsou zbytecne a zjednodussi se počet zapojenych lidi atp… Priklad – měli jsme se integrovat s jednim systemem, byla to klicova integrace z hlediska fungovani funkcnosti smerem k uzivateli… Při snaze o domluvu terminu kdy zacneme spolecne integrovat a testovat, jsme se dozvedeli ze druhy tym jede agilne, tze nam nedokazou rici uplne presne kdy to budou mit… ale az to bude tak se nam ozvou… jak to zapada do release managementu cele organizace? Neustale presouvani funkcnosti z jedne iterace do další, neustale nedodrzovani toho co bylo v jedne iteraci naplanovane a co bylo skutecne dodane – pokud se toto stane jednou a podle toho se preplanuje, pak OK… pokud se takto deje opakovane a nikdo to neresi – tak toto není agile. Timto davate jasne najevo ze je jedno jestli jsou věci dokoncene poslední den jedne iterace, nebo v prvnich dnech te druhé… Fungujici software je preci primarni a nejdulezitejsi meritko progressu – spousta tymu si neuvedomila ze je jejich projekt v potizich az do doby nez měli nasazovat a dodavat. Pritom všechny predchozi casti byly vcas (sber pozadavku, design, vyvoj, … protahlo se to az při testovani a integraci). As Chet Hendrickson, coauthor of Extreme Programming Installed (Addison-Wesley, 2000), remarks, "If a project is going to fail, I'd rather know that after one month than after 15." Stejne tak agile neznamena ze nemá vznikat zadna dokumentace… Specifikace – dokumentace na konci dne musí vzniknout, trosku jina nez je std. a muze vznikat soubezne s vyvojem… ale rozhodne při formovani agile manifesto nebylo mysleno to, ze budete jen programovat a nikde nebudete mit zdokumentovano jak to funguje (třeba formou test casu) nebo proc bylo něco rozhodnuto tak ci tak… o tomto bude vice mluvit Richard Michalsky v posledním agile prispevku
- Jednim z nejcastejcich problemu kterou vidime je velka koncentrace na praktiky, misto na principy. Jeden az dva priklady z praxe: Videli jsme „agilni“ tym, který mel každý den standup meeting, který trval 40 az 50 minut, pulka tymu u nej sedela… byla to vicemene analyticka schuzka o casti aplikace tykajici se tri lidi z deseti… k tomu asi standup není ne? Proc ho tedy delat? Ze delam standupy, neznamena ze jsem agilni Ze pouzivam backlog neznamena ze jsem agilni… Není dulezite zda odhadujete ve story pointech, hodinach nebo v minutach… Není dulezite zda mate scrumboard, nastenku pouzivate nejaky nastroj typu Jira… Mistaking scrum for agile Stand-ups that don’t end No retros Dulezite je zda dodavat funkcni software! Cilem agile ma byt dodavat funkcni software, nikoliv dodrzovani metodiky. Co funguje jednomu tymu nemusi nutne fungovat tymu jinemu, každý tym by si toto mel ladit a kontinualne na tom pracovat (k tomu jsou ty ruzne retrospektivy a feedbacky). Další castym problemem je slepe kopirovani praktik jednoho tymu k druhemu – Cargo cult viz další slajd
- Co funguje jednomu tymu nemusi nutne fungovat tymu jinemu, Jeden absurdni priklad z historie, trosku z jineho oboru. Po druhe svetove valce melanezske kmeny napodobovali to co predtim videli u spojencu – staveli improvizovane letistni budovy, pristavaci drahy, pristavaci veze… Dokonce pry měli i operatory kteří nosili na usich pulky kokosu jako sluchatka… no a doufali ze prileti ti velci ptaci a budou z nebe zase schazovat ty velke krabice se zasobama jidla… jako to videli behem valky :) kupodivu to nefungovalo…
- Agile není zázračný recept na všechny problémy které Vaše organizace má. Mimo to spousta dalších problémů (o některých bude mluvit Marek Endlicher) může přinést… Pokud v organizaci určitá oddělení nespolupracují (např. kvůli nastavení KPI atp), tak jen tím že si řeknete pojedeme agilně se to nevyřeší…. Projekt může zfailovat naprosto stejně při použití agile jako při použití tradičních metod… výhodou je že při agile zfailuje rychleji (díky transparentnosti a viditelnosti kterou přináší). Není to ale silver bullet nebo dogma a výmluva pro to aby se přestalo uvažovat… Agile is not the answer to all IT problems. There is no single answer to all IT problems, rather it’s about integrating different frameworks each of which provides part of the answer. The implementation of delivery and management frameworks such as agile must be pragmatic. It must recognise the real-world environment in which a system will be implemented and used, and consider the best integration of agile and non-agile frameworks that will work in that real-world environment. There is no single silver bullet framework. Na začátku jsme mluvili o tom že není potřeba mít přesné zadání ale stačí vize. Agile ovšem nevyřeší problém, kdy chybí vize… proč se vlastně projekt dělá a co má přinést… pokud tohle není jasné pak je lepší projekt zastavit než jej dělat agilně. Nehodí se pro všechny situace: Zde se názory pro co se hodí a pro co se nehodí dost rozchází Moje vnímání je pokud je něco složité a drahé na předělání, pak je lepší to dopředu více zanalyzovat a popsat - např. integrační projekty kde je hodně stran (MW, FE, BE) - nicméně v dnešní době kdy i architektura systémů se mění a přizpůsobuje tomu, aby tyto věci takto dělat šly to úplně nemusí platit (microservices, …) - dále je to otázka rizikovosti a kritičnosti - např. life critical systémy, řízení letového provozu, software pro letadla… Např. ani spolu s Richardem Michalským se na toto téma neshodneme a asi je to potřeba brát s rezervou pro každou situaci. Někde je možné se dočíst definici Acceptable cost of failure is a prerequisite for agile
- Krátká rekapitulace… pro správné pojetí je klíčová Spolupráce business a IT Existence silného product ownera Pragmatický přístup jak uchopit, na co použít a jak řídit… Pokud jste počítali správně… tak jsme doposud mluvili o 6 nejčastějších problémech… zde na slajdu jich je sedm… Poslednímu velmi důležitému bodu se dnes bude věnovat Richard Michalský – pokud si kladete otázku lze dělat agile na FTFP? Pak prosím chvilku počkejte – Richard Michalský o tomto bude mluvit.
- Co máme dělat pokud těmito problémy trpíme? Co s tím?
- Je potřeba se v uvažování vrátit na začátek… víme proč to vlastně chceme? Co od agile přístupu čekáme? Jsou to tři přínosy které jsme si dnes zmiňovali? Jak to vnímá business? Je na organizační změnu připraven? Jakým způsobem se to do naší organizace dostalo? Nařídil to někdo shora? Jak to vnímá zbytek organizace? Všechna oddělení která jsou klíčová pro dodávku software (procurement, architektura, …) Marketing do organizace… v této části už přelézáme hranice IT… proto si dovolím předat slovo našemu hostovi Markovi Enderlichovi… který bude mluvit mimo jiné o transformaci v Tmobile…
- Dobrý den, mé jméno je … a v Profinitu dělám …?
- V této části bych se rád vrátil z kontextu celé firmy zpátky do IT. Možná nejsložitější a zároveň nejčastější problém, se kterým se v tomhle kontextu potkáváme je práce s rozsahem projektu, v nejčistší podobě s častým požadavkem na to, že projekt musí být agilní a zároveň FTFP. Má to ještě dvě trochu odlišné roviny: rozsah, který se přímo netýká funkčnosti software – to může být cokoliv od formálních, procesně daných dokumentů, až po prezentace, které prodávají projekt dovnitř organizace. To je opět organizační záležitost, kterou si musíte odehrát uvnitř firmy, jak o tom mluvil kolega v předchozí části (a ano, agilní projekt může mít mnohem stručnější analýzu a specifikaci než tradiční waterfall, o tom více později) Skutečné vlastnosti software, kde zadavatel chce pochopitelně vědět, co za své peníze dostane.
- Tj. v reálném světě / s obvyklým zadavatelem nějaký kontrakt (obecně, psaný, nepsaný, nebo dokonce jen implicitně očekávaný, nemyslím nutně smlouvu o dílo) vznikne. Agilní manifest také neříká, že žádný kontrakt být nemá, jenom, že je důležitější spolupráce než smlouva. Jak tedy nastavit podmínky tak, aby spolupráce mohla fungovat i s poměrně volným nastavením a obě strany se cítily komfortně?
- Bohužel / samozřejmě, obvyklý problém jsou rozdílná očekávání. Tolik proklínaný up-front design, změnové řízení a kontrakt ve waterfall modelu, proti kterým se agilní manifest zásadně vymezuje, slouží právě k řízení a nastavení očekávání tak, aby obě strany měly maximálně sdílenou myšlenku o finálním produktu ještě dříve, než se začnou peníze do projektu házet lopatou – před implementací. Jak z toho ven?
- Jak už řekl Pavel přede mnou, stříbrná kulka nepomůže ani zde. Z toho, co zaznělo je celkem jasné, že agile přístup je vhodný spíše pro „software factory“, ne pro pořízení krabice - „be agile“ místo „do agile“, „it’s not like buying a car” Je to dlouhodobá „procesní“, ne projektová aktivita, nastavení kultury, týmu, „velocity“, … se vyplatí hlavně v dlouhodobém měřítku Tady si dovolím malou odbočku, z výše uvedeného podle mě na rozdíl od obvykého vnímání vyplývá, že agilní model se hodí daleko více pro velké a dlouhodobé projekty než pro malé, resp. Tam přináší největší výhody. Jak do toho zapadá požadavek na FTFP? buying a „car building kit“
- Rozsah projektu je jen rámec (na úrovni user-stories) „Predictability vs. Guarantee“ 80-90%, tj. tolik % user stories dokáže tým odhadnout obvykle přesně, zbytek může divoce fluktuovat TODO rozebrat Aby vůbec mohlo fungovat, je podle mých zkušeností potřeba jednak se neustále vracet k výhodám, které agile přináší, jednak nastavit následující 3 oblasti. TODO přeformulovat
- Zadavatel musí na řešení životně záviset Jedině tak je schopen pracovat s rozsahem („myslel jsem, že toho stihnete více“) a akceptovat řešení podle user-stories (ne ve stylu „já jsem si představoval něco jiného“) Viz zkušenost z Online DPS a Business360.
- Nastavení dlouhodobé spolupráce (TODO přeformulovat, vyčpělé) Ne „buying a car“, ale „buying a car factory“ Důvěra je nezbytná (TODO přeformulovat nebo zlehčit) Team-lease Možno více týmů, jeden tým od jednoho dodavatele Zároveň na dodavatele vytváří větší tlak dodávat (přišel by o více než o pár BS, které dá snadno jinam) Se zapojením interních lidí Předávání know-how Interní pohled na rozsah, odhady, velocity, … On-site vývoj Product owner věří vývoji více, když vidí, že skutečně v práci jsou a neflákají se „collaboration over contract“ Dá se částečně nahradit velmi častými iteracemi s PO Dohromady tomu říkám „Ovzduší „kontrolované důvěry“ (https://www.youtube.com/watch?v=As6y5eI01XE)“
- Vlastní příběh – vývojáři si sami vyžádali a začali psát specifikaci. Zvlášť u delšího projektu je nutné strukturovaně dokumentovat průběžná rozhodnutí. U jednoduchých aplikací paralelně během vývoje Strukturovaná dokumentace průběžných rozhodnutí Složitější řešení vyžadují na začátku analytické sprinty Specifikace je odlišná od waterfallu, plní odlišné úkoly Není důležité předat informaci členům týmu, ti ji v reálném čase mají z interakce s PO Místo toho dokumentuje důvody jednotlivých rozhodnutí a dopady Obvykle mnohem stručnější než u waterfallu
- Co se dá z tak širokého tématu prakticky odnést? Je to těžké, … Pamatovat si, proč to děláme – přínosy agile Nastavení podmínek: Být na jedné lodi Důvěra Dokumentace … ale stojí to za to POZOR! umět uzavřít i rozplizlou debatu
- Otevíráme diskuzi. Děkujeme za posouzení Profinit nabídky a zájem.