Agilní vývoj

Osobně nerad říkám "vývoj", ale používám spíše výraz "přístup" nebo ještě více vypovídající "filosofie".

Learning Agile

Ve většině firem a u většiny lidí jde totiž o změnu myšlení. Bohužel hodně společností se snaží aplikovat tento přístup pouze na vývoj a nezahrnou do potřebných změn své zadavatele, ať je to běžný uživatel, platící zákazník nebo třeba interní business.

Principem agilního přístupu je zpracování požadavků inkrementálním a iterativním způsobem, tzn. postupné zpracování co nejmenších požadavků v co nejkratší době a následné předělání nebo vylepšení. To nám umožnuje rychlý vývoj nových věcí a možnost reagovat na jakoukoli změnu v průběhu vývoje. Základním pravidlem pak je, že vyřešení jakéhokoli požadavku přináší jeho zadavateli určitou hodnotu (jinak nemá smysl na požadavku pracovat). Tato všechna pravidla vychází z Agilního manifestu.

Agilní přístup také zahrnuje způsob zadávání požadavků, jejich prioritizaci, způsoby plánování vývoje, odhady pracnosti, principy fungování produktových týmů a jednotlivých rolí v týmu, jejich motivaci, komunikaci se zadavateli, prezentování výsledků, jejich akceptaci, způsoby uvolňování nových věcí do produkce, atd., atd... Je toho opravdu hodně, ale co je na tom všem pěkné je to, že vše nádherně do sebe zapadá.

Všimněte si, že jsem stále nepoužil pojmy "Scrum", "Kanban" a další agilní metodiky. Podle mne totiž nejde o to, jakou metodiku si vybereme nebo která nejvíce vyhovuje našim potřebám, ale důležitější je, jestli jsme schopni začít přemýšlet "agilně" a pochopit agilní principy.

Existuje mnoho mýtu kolem agilního vývoje. Většinou jsou zneužívány jako argument, proč agilně nefungovat ("Takto přeci nemůžeme vyvíjet, to by byl pěkný bordel."). Často se ale také podle nich řídí lidé, kteří toho o agilním vývoji moc nevědí, jen se něco doslechli a podle toho chtějí změnu implementovat. Zde uvádím několik z nich.

Neplánuje se

V porovnání s vodopádovým modelem se lidé domnívají, že se v agilním vývoji nic neplánuje, protože se pořád něco mění a jakékoli plány nemají smysl.

Naopak, v agilním přístupu se plánuje dokonce více. Rozdíl je, že se neplánuje jen v jedné úvodní fázi, ale plánuje se průběžně, plány se často upravují podle aktuálních potřeb a změna se upřednostňuje před dodržením původního plánu.

Nepíše se žádná dokumentace

Documentation

Pokud si pod dokumentací představíte obsáhlý dokument třeba ve wordu, kde je detailně popsána funkcionalita a technické řešení nějakého systému nebo aplikace, pak opravdu není moc vhodné takovou dokumentaci dělat. Důvodem jsou časté změny, které agilní vývoj podporuje. Taková dokumentace pak rychle zastarává, není v silách nikoho ji aktualizovat a původní náklady na její vytvoření jsou zbytečně vynaložené. Výjimkou je, pokud cílem požadavku je právě vytvoření obsáhlé dokumentace za nějakým účelem, který přináší zadavateli určitou hodnotu.

Není ale pravda, že se při agilním vývoji dokumentace nevytváří. Dokumentace se skládá hlavně s jednotlivých zadání ("user story") a z testovacích scénářů ("test case"). Na produkci se totiž nedostane nic, co nebylo zadáno a otestováno, takže veškeré informace můžete zpětně dohledat zde. Pokud potřebujete mít někde popsané návrhy řešení velkých systémů, pak je vhodné toto sepsat někam na wiki (pouze na high level úrovni) a z jednotlivých požadavků pro vývoj se odkazovat tam.

Obecně lze ale říct, že se při agilním vývoji dokumentuje méně. Jedním z důvodů je také to, že lidé mají snahu se za dokumentací "skrývat". Místo aby osobně prodiskutovali problém, tak ho radši písemně zdokumentují. A to zhoršuje celkovou komunikaci.

Netestuje se

TDD

V agilním vývoji, při rychlých iteracích není čas na testy, protože se neustále něco mění. Takto k tomu bohužel přistupuje hodně lidí.

V agilním vývoji se naopak klade velký důraz na kvalitu. Vývoj nikdy nesmí opustit cokoli, co není otestováno. Opakované testy se pokrývají automaty, menší dočasné testy se mohou dělat manuálně a QA je vždy součástí vývojového/produktového týmu.

Dokonce jeden z agilních přístupů je vyvíjet pomocí Test Driven Development (TDD), tzn. nejprve napsat test podle požadavku a pak teprve kód, který tímto testem projde. Tím se zajistí 100% pokrytí testy.

Nedělají se návrhy řešení(design)

Protože v agilním vývoji není žádná fáze analýzy, studie proveditelnosti apod. fáze, lidé se domnívají, že se v agilním vývoji žádné návrhy řešení nedělají.

Agilním vývoj možná využívá více návrhů řešení, než klasický přístup. Jen na to není vyčleněná některá fáze před vývojem, kde se vytvářejí velké designy systémů, které neplatí už pár minut po začátku vývoje. Design se řeší průběžně při vývoji a je založen spíše na refactoringu, kde vývojáři postupně zlepšují již navržené a naprogramované věci.

Při snaze přejít z klasického způsobu vývoje na agilní se lidé a firmy dopouštějí spousty chyb. A protože se jim pak díky tomu nepodaří začít fungovat lépe a efektivněji, jsou přesvědčeni, že buď je agilní přístup špatný nebo se prostě nehodí do jejich prostředí.

Zde popisuji nejčastěší chyby, kterých se různé týmy dopouštějí.

Nedostatek zkušeností

Bugfixing

Hodně lidí si myslí, že si stačí o agilním vývoji něco přečíst, zajít na nějakou konferenci nebo školení, udělat si certifikát "Certified ScrumMaster" a že pak mají dostatek znalostí na to, aby ve firmě zavedli agilní vývoj. Po zavedení nových technik, jako jsou sprinty, stand-upy, retrospektivy apod. si naivně myslí, že fungují agilně. Bez pochopení agilních principů ale po nějaké době zjistí, že jim to moc nefunguje a mají tendenci se vracet zpět ke starému způsobu vývoje.

Mám rád jedno přirovnání: Když si nastuduji, jak udělat sushi, budu ho schopný připravit a možná mi dokonce bude chutnat. Jak ale mohu vědět, že je to opravdu dobré, správně udělané sushi, když jsem ho nikdy před tím nejedl?

Co s tím? Spolupracujte s člověkem, který má reálnou zkušenost s úspěšným fungováním agilního vývoje, který si to "zažil" a který vám tuto zkušenost dokáže předat.

Implementace pouze v rámci IT vývoje (R&D)

Request

Bohužel velké množství společností se snaží aplikovat agilní vývoj pouze na Development a nezahrnou do potřebných změn své zadavatele, ať je to běžný uživatel, platící zákazník nebo Business. Pak ale naráží na to, že je omezuje okolí svým "jiným fungováním" a řeší problémy při styku "agilního světa" s "neagilním".

"Agilní vývoj" není jen o vývoji. Možná větší část potřebných změn ve firmách leží právě na zadavatelích, kteří musí fungovat také agilně. Jak se říká "rubbish in, rubbish out" neboli, když máte špatné zadání, nemůže z toho vzniknout nic kvalitního. I Business musí pochopit agilní principy a spolupracovat podle nich s produktovými týmy.

Produktové týmy nejsou "produktové"

Product

Jste si jisti, že víte, co je Váš "produkt"? Často se stává, že agilní vývoj se aplikuje na týmy, které nemohou fungovat ani trochu nezávisle, protože to co vyvíjejí, není produkt, který by měl nějakou hodnou pro uživatele/zákazníka. Jakýkoli požadavek na takový tým pak s sebou nese dopad do jiných týmů a ani jednoduchá funkcionalita nemůže být plně vyvinuta jedním týmem.

Je potřeba si ujasnit co je Vaším produktem, jakou část můžete relativně nezávisle poskytovat uživatelům/zákazníkům a podle toho sestavte týmy tak, aby v nich byli lidé se všemi potřebnými znalostmi. Nestavte týmy podle znalostí a nezkoušejte následně na ně ohnout produkt, dělejte to opačně.

QA není součástí vývoje

Ve vodopádovém modelu je jasně oddělený vývoj od testů. Při přechodu na agilní vývoj, např. Scrum, pak ve firmě tento zvyk přetrvá (co taky se zavedeným QA týmem). Výstupem sprintů je tak neotestovaná změna nebo nová funkcionalita a přitom je tento požadavek prezentován jako dokončený (vždyť hlavní práci, tedy vývoj, jsme dokončili a už to stačí "jen" přetestovat). Víte, kolik věcí se vám vrací z testů zpět k vývojářům v různých fázích projektu?

Principem agilního vývoje je rychlá změna, rychlá zpětná vazba a rychlá reakce na zpětnou vazbu. Jednou z důležitých zpětných vazeb je i výstup z testů. Aby vývojář tento výstup dostal co nejdříve, je potřeba začlenit testy přímo do vývoje a sprintu. Výstupem ze sprintu nesmí být nic neotestovaného. Takže pokud si vývojáři nedokáží svůj výtvor správně otestovat, pak musí být QA součástí produktového týmu. Za kvalitu má být zodpovědný hlavně vývojář, tester pouze ověřuje, jestli developer neudělal někde chybu.

Nedostatek automatických testů

Automatizované testování je základem pro dosáhnutí požadované kvality produktu při krátkých cyklech vývoje. Kdykoli vývojář něco dodělá, je potřeba spustit test, na základě kterého co nejrychleji vývojář zjistí, zda neudělal někde chybu. I při implementaci malé změny je potřeba přetestovat celou aplikaci, protože i nepatrná změna může mít zásadní dopad do jiné části aplikace. Není v lidských silách, aby takto rychlá zpětná vazba pro vývojáře byla zajištěna manuálním testem.

Automat není potřeba psát na každou změnu (pokud tedy neděláte Test Driven Development), jestliže předpokládáme, že se nová věc bude ještě měnit. Novinky je možné dočasně testovat manuálně. V případě, že se změna stane standardní součástí aplikace, pak je potřeba ji pokrýt automatickým testem.

Tvorba automatických testů často padá na názoru, že je to zbytečně nákladná činnost. V dobře nastaveném agilním vývoji se ale dostanete k potřebě testovat každý den nebo i dokonce vícekrát za den. Při takto častém testování se investice určitě vyplatí a bez automatů nejste schopni správně testy jinak pokrýt.

Odhady pracnosti nezahrnují všechny činnosti

Často se stává, že při odhadech pracnosti jednotlivých požadavků týmy zapomínají začlenit do odhadu všechny činnosti, které na požadavku dělají. Nejčastěji to jsou testy. Možná kvůli tomu, že cíleně nebo podvědomě pořád oddělují vývoj a testy, viz odstavec výše. I malá změna může znamenat obsáhlé testy, takže pokud nedáte do odhadů pracnosti i náročnost testů, pak začne docházet k tomu, že např. nejste schopni dokončovat požadavky v rámci sprintů. Náklady na testy musí být součástí odhadů pracnosti a zadavatel musí znát celkovou náročnost na základě které se rozhoduje, jestli do implementace jít nebo ne.

Estimation

Jedna z nejtěžších dovedností vývojáře je provést správný odhad pracnosti určitého požadavku. Většinou dochází k podhodnocení, což vede k nestíhání termínů, což zpětně vede k tomu, že všechny odhady se násobí "magickou" konstantou, aby se finální odhad přiblížil realitě, což ale také většinou moc nefunguje.

Jeden z důvodů proč je obtížné odhadnout správně čas potřebný k dodělání příslušného požadavku je ten, že vývojář dopředu neví, jakým způsobem tento vymezený čas stráví. Úkol, na který standardně vývojář potřebuje např. 8 hodin čistého času, mu zabere 2-3 dny, když je stále vyrušován jinými věcmi nebo dokonce déle, pokud dělá na více věcech najednou. Dalším z důvodu je, že dokud vývojář nezačne reálně na požadavku pracovat, tak neví, s čím se bude muset potýkat a je to stále jen nepřesný odhad na základě nějaké předešlé zkušenosti s jinými, i když podobnými, požadavky.

Klíčem k úspěchu jak dělat správné odhady, je dělat opravdu "odhad pracnosti". Pojďme si nejprve rozklíčovat tato slova pomocí Slovníku spisovného jazyka českého:

  • Odhad = přibližné určení, stanovení něj. rozměru, počtu, hodnoty, ceny něčeho úsudkem, bez měření, počítání ap.
  • Pracnost = množství práce potřebné k zhotovení výrobku n. vynaložené na výrobní postup.
Storypoints Z toho vyplývá, že děláme pouze odhady, které nemohou být z podstaty věci přesné a takto s nimi dále musíme pracovat. Dále, že neodhadujeme časovou náročnost, ale množství práce, které musíme vynaložit.

K takovým odhadům se používají bodové hodnoty (např. Story points), které říkají pouze to, jak je určitý požadavek "složitý" v poměru k jinému již odhadnutému požadavku (jestli požadavek B je menší nebo větší než požadavek A a zhruba o kolik) viz Wiki - Planning poker.
Některé týmy používají tzv. T-shirt sizing, kde ohodnocují požadavky pomocí písmen S,M,L,XL. Já osobně tento způsob estimace nedoporučuji ze dvou důvodu. Za prvé nejste schopni tyto hodnoty sčítat a jednoduše říct, kolik požadavků se vejde do iterace. Za druhé není jasné jaký je poměr těchto hodnot mezi sebou (je XL 2x vetší než L nebo je jen o 50% větší?). Pokud použijeme číselné hodnoty, tyto problémy odpadají, protože každý umí sečíst a porovnat čísla mezi sebou.

Složitost problému není jen v tom, jestli mám vytvořit jedno pole na formuláři nebo udělat celou novou aplikaci. Složitost také ovlivňuje např. stav kódu formuláře, do kterého mám jedno pole přidat, jestli vše dokáže udělat vývojář sám nebo se musí zkoordinovat více lidí nebo jestli nám tato malá úprava nenaruší některé věci okolo, které se musí také upravit.

Na odhady pracnosti mají vliv 3 věci: riziko, komplexnost a úsilí. Součtem těchto hodnot dostaneme celkovou pracnost/složitost problému.

  • Riziko - může vzniknout na základě špatného a nečitelného kódu, nejasných závislostí, neznalosti problému, potřebě použít novou technologii apod.
  • Komplexnost - zdrojem může být složitost algoritmu, struktury dat apod. viz Wiki - Complexity.
  • Úsilí - jaké úsilí musíme vyvinout, abychom něco dokončili. Kolik kroků musíme udělat, kolik různých věcí musíme změnit, jaké jsou interní procesy (např. potřeba schvalovaní kritických věcí), s kolika lidmi je potřeba spolupracovat apod.

Použití této metody nevede k přesným odhadům jednotlivých požadavků, ale ke správnému rozdělení požadavků mezi sebou. Pak nevadí, když tým podhodnocuje své odhady o X procent, protože takto podhodnocené jsou v průměru všechny požadavky. A jak je možné, že to nevadí? Důvodem je měření a používaní Velocity týmu.

Almost done

Velocity týmu je hodnota, která udává kolik bodů je tým schopen dokončit v průběhu jedné iterace (např. sprintu). A ačkoliv např. v každé iteraci jsou jednotliví vývojáři jinak vyrušováni, množství takto stráveného času má tendenci být konstantní v porovnání s ostatními iteracemi. Takže velocity se pouze sníží, ale je dále také konstantní. Díky velocity pak má tým a jeho okolí jasnou zpětnou vazbu o tom, kolik se toho dokončilo v minulých iteracích a kolik se toho dokončí s největší pravděpodobností v iteraci následující.

Toto nám dává jednoduchý, ale sofistikovaný nástroj. Pokud tým požadavky podhodnocuje, vede to k tomu, že v průběhu iterace nestihne vše, co si naplánoval. To způsobí, že se velocity sníží a do další iterace se podle této velocity naplánuje méně požadavků, které už tým stihne dokončit. Naopak pokud tým požadavky nadhodnocuje, v průběhu iterace stihne více věcí, než si původně naplánoval, což velocity zvýší. Postupně se tak velocity ustálí na reálné kapacitě týmu.

Velocity je založena na striktních pravidlech. Nikdy do velocity nezapočítávejte hodnoty nedokončených požadavků. Nikdy nedovolte, aby se konec iterace posouval i jen třeba o pár hodin. Tyto věci princip zpětné vazby založený na velocity narušují a dostanete se do stavu, kdy nejste schopni velocity správně vyhodnocovat, plánovat a dokončovat další požadavky. Velocity má tendenci být na začátku projektu nebo při vytvoření nového týmu nestabilní. Počkejte 2-3 iterace v průběhu kterých se velocity stabilizuje. Po tomto čase byste měli být schopni dosahovat stejné velocity ve všech dalších iteracích.

Jak se vypořádat s chybami v agilním vývoji při metodě Scrum? Odhadujeme jejich pracnost? Dáváme je do extra backlogu? Přiřazujeme je jinému týmu, který funguje metodou Kanban?

Nejprve bych rozdělil chyby do dvou množin.

Do more

První množina jsou chyby, které vznikly a našly se v průběhu sprintu nebo těsně po něm, ale ještě se nedostaly na produkční prostředí a neovlivňují uživatele. Tyto chyby nijak neodhadujte, jednoduše je opravte v aktuálním sprintu. Znalost vyvíjené funkcionality je čerstvá a cena potřebné opravy bude nízká. Může to sice trochu ovlivnit velocity týmu, ale na druhou stranu máte velocity, která odpovídá dodávání "bezchybného" kódu. Základním pravidlem v tomto případě je, že chybný kód nebo neotestovaný požadavek se nesmí dostat ze sprintu.

Druhá množina jsou chyby, které jsou již na produkci a které tam ani nemusel zanést aktuální tým. Některé společnosti tento typ bugfixingu řeší pomocí dalšího nezávislého týmu, který opravuje pouze chyby a který funguje pomocí Kanbanu. Tento způsob má ale svá úskalí:

  • Nemusí být efektivní, aby chybu opravoval jiný člověk/tým než ten, který příslušnou funkcionalitu vyvinul a má tedy nejlepší znalost problému.
  • Nemusí být lehké najít vývojáře, který by chtěl dělat pouze bugfixing.
  • Je finančně a kapacitně náročné mít dva nezávislé týmy pro jeden produkt a z toho jeden, který nevyvíjí nic nového.

Bugfixing

Co tedy dělat v případě, že máme jeden tým, který se kompletně stará o produkt?

  • Pokud je chyba jednoduchá, lehce opravitelná (změna jednoho řádku kódu, překlep v textu apod.), tak ji prostě opravte. Neřešte nic zbytečně kolem.
  • Pokud chyba není triviální a zároveň to není blocker (chyba blukující používání produtu na produkci), dejte ji do produktového backlogu.
  • Pokud je chyba blocker, pak ji dejte do aktuálně probíhajícího sprintu. Pak ale musíte něco jiného z aktuálního sprintu vyndat.

K chybě v backlogu se chovejte stejně jako k novému požadavku. Dělejte odhad pracnosti a prioritizaci. Product manager má pak možnost upřednostnit opravu chyby oproti nějaké nové funkcionalitě nebo naopak říct, že nový požadavek je důležitější než oprava méně závažné chyby.

Jak ale odhadnout náročnost opravy chyby, když pro správný odhad pracnosti potřebujeme vědět původ chyby, což ale může znamenat vynaložení většiny potřebného úsilí k opravě chyby?

Zkuste chyby odhadnout podobným způsobem jako ostatní požadavky pomocí parametrů riziko, komplexnost a úsilí viz Odhady pracnosti. Možná se budete divit, kolik chyb takto nakonec zvládnete odhadnout.

U chyb, které opravdu nedokážete odhadnout nebo analýza potřebná k odhadu pracnosti by de facto chybu opravila, zkuste alespoň snížit míru nejistoty např. takto: pokud používáte Story pointy (0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40), kde hodnota 40 je nejvyšší hodnota kterou přidělujete novým požadavků, přidělte chybám hodnoty 13 nebo 20. Tím pokryjete riziko, že neznámý bug může být složitý.

Pokud je odhad pracnosti opravy chyby velký a nejste si jisti, zda se vám vejde do sprintu, pak je možné opravu rozdělit na 2 úkoly - zjištění důvodu chyby a samotnou opravu chyby. Samotný úkol zjištění důvodu chyby může mít vlastní akceptační kriteria a výstup se dá prezentovat (Customer demo).

Když si jako firma potřebujete něco nechat vyvinout u externího dodavatele, začnete narážet na různé překážky. Hlavní rozdíl oproti "klasickému" agilnímu vývoji je ten, že nemáte jeden tým, který může produkt vyspecifikovat, vyvinout, otestovat a dodat koncovému uživateli. Spolupráce týmů zákazníka a dodavatele může mít různé formy. Od striktně nezávislých týmů, fungujících pouze na základě smluv, specifikací apod. až po blízkou spolupráci na denní bázi. Velké korporátní firmy mají navíc nastaven různý způsob interní komunikace, odlišnou kulturu, různé bezpečností politiky jak a kde sdílet informace. Z toho vyplývá, že jednoduchá domluva na konkrétních věcech mezi těmito společnostmi může být problém.

Příklad:

Zákazník je velká firma, která nemá žádný nástroj pro týmovou spolupráci, soubory (včetně velkých specifikací) interně sdílí pomocí adresářové struktury na sdíleném disku, nemá nástroj pro management požadavků a používá specializovaný nástroj na správu chyb (např. ALM). Nástroje jsou přístupné pouze z interní sítě nebo přes VPN.
Dodavatel používá úplně jiný systém pro správu požadavků, týmovou spolupráci a management chyb (např. TFS - Team Foundation Server). Tento systém si ale maximálně chrání, protože tam má veškeré své know-how a neumožní zákazníkovi jakýkoli přistup.

Takže existují dva úplně odlišné světy, které technicky spolu nekomunikují. Aby byla možná alespoň nějaká výměna informací, komunikace se nastaví např. následovně:

  • Týmová spolupráce - běžné krátké informace nebo malé soubory se posílají přes maily. Výsledkem je kupa mailů s různým obsahem, s různou verzí příloh a informací. Při diskuzích se pak lidé odvolávají na nějaký zaslaný mail, který byl ale mezitím již několikrát aktualizován. Navíc v průběhu mailové komunikace se různě mění adresáti, takže není jistota, že všichni mají tutéž informaci.
  • Sdílení souborů - větší soubory se se posílají přes FTP a ještě zašifrovaně kvůli bezpečnosti. Tím se dost zesložiťuje práce a ne všichni chtějí s takovými dokumenty pracovat. Proto se zvolí člověk, který sleduje, jestli přes FTP nepřišlo něco nové, tyto soubory rozšifruje a nakopíruje na interní úložiště.
  • Management požadavků - zákazník určitým způsobem (většinou formou specifikace) dodá zadání dodavateli. Dodavatel zadání rozpadne na menší kousky podle potřeb svého týmu a ty eviduje ve svém systému. Za nějakou dobu (iterace) pak dodavatel dodá vše co pochopil ze zadání. V průběhu iterace se aktuální stav požadavků nikde nesdílí. Zákazník zjišťuje reálný obsah a stav dodávek až při předání.
  • Management chyb - obě strany si evidují chyby ve vlastních systémech, které nejsou nijak propojené. Proto je nutné tyto systémy synchronizovat manuálně. K tomu je na každé straně určen člověk, který zpracovává různé notifikace, svůj systém aktualizuje a čas od času pošle souhrnný report pro kontrolu, že obě strany mají sjednocený aktuální stav.

Tento styl je běžný pro vodopádový model vývoje, kdy stačilo si nesdílet různé informace pouze v určitých fázích projektu a mezi těmito fázemi se víceméně nekomunikovalo. K přímému, rychlému a jednoduchému sdílení informací to má daleko.

Pozn. Proč je VPN problém?
Mohlo by se zdát, že připojení do interní sítě přes VPN, je elegantní řešení bezpečnosti. Kdokoli se zvenku připojí a může využívat všechny nástroje jako by byl v kanceláři na interní síti. Problém je ale v tom, když např. vývojář od externího dodavatele už VPN používá k připojení do své vlastní sítě. A protože nemůže být najednou připojen do dvou sítí, pak si musí vybrat. Nemůže např. programovat a zároveň číst zadání. Což opět zásadně omezuje a znesnadňuje komunikaci.

Jak toto ale změnit, když chcete fungovat agilně a komunikace na denní bázi je zásadní?

Obecné řešení:

  • Používejte nové platformy k tomu určené. Zabezpečte si ji proti okolnímu světu, ale co nejvíce usnadněte použití lidmi na projektu. Ano, budete bohužel muset občas obejít různá interní nařízení, ale ty tu většinou jsou spíše z historických důvodu než proto, aby něco opravdu řešili natož, aby Vám usnadnili práci.
  • Dohodněte se s dodavatelem na použití konkrétních nástrojů, které budou jednoduše přístupné a použitelné pro všechny členy týmu. Využívejte "cloudové" služby. I sebelepší systémy, které jsou v interní síti, jsou složitě přístupné z okolního světa a tím pádem i problematicky použitelné druhou stranou (zákazník/dodavatel).
  • Eliminujte mailovou komunikaci pomocí různých kolaboračních platforem, které slouží pro efektivní týmovou spolupráci.
  • Vyhněte se zasílání dokumentů mailem, nasdílejte příslušný dokument online. Elegantně tím vyřešíte verzování, rychlou editaci více lidmi najednou. Stačí pak znát odkaz na příslušný dokument a všichni mají přístupnou poslední verzi.
  • Požadavky a evidenci chyb řešte v jednom, tomu určeném, nástroji, který je přístupný všem online. Všichni členové týmu budou mít lepší přehled o aktuálním stavu projektu a stávajících/budoucích požadavcích. Je dobré mít pouze jeden systém na požadavky i evidenci chyb. Pak lze prioritizovat oboje najednou a dodavatel přesně ví, kdy co má dodat, zda upřednostňujete opravu chyb proti dodání nové funkčnosti nebo naopak.
  • Vyhněte se manuálnímu kopírování čehokoli kamkoli.

Konkrétní řešení:

  • Confluence - kolaborační platforma, která zásadně zlepší komunikaci a spolupráci uvnitř týmu. Lze tu online sdílet různé informace, ukládat zápisy ze schůzek, zadávat úkoly a sledovat jejich plnění. Výborně se také hodí na komunikaci kolem požadavků, tvorby design apod. Mnoho diskuzí lze vést v tomto nástroji a tedy ne přes mail.
  • JIRA / ALM - systém pro správu požadavků a chyb. Požadavky lze jednoduše zadávat, spravovat, kategorizovat a prioritizovat. Pokud nelze sloučit správu nových požadavků (JIRA) a správu chyb (ALM), pak je potřeba tyto dva systémy propojit a automaticky synchronizovat (existují k tomu různé nástroje).
  • Google Drive - jednoduchá platforma pro sdílení dokumentů. Jednoduše nasdílíte složky nebo soubory, online vidíte provedené změny, všechny soubory se verzují, změny lze doplnit komentáři.

O mně

Od roku 2006 se věnuji projektovému řízení v oblasti vývoje SW. Za tuto dobu jsem řídil projekty pro velké firmy (finanční instituce), střední i malé firmy. Spolupracoval jsem i na projektech v zahraničí (USA).

Za tuto dobu jsem si prošel různými způsoby softwarového vývoje a naučil se různé metodiky projektového řízení. Jsem certifikován na projektovou metodologii PRINCE2, řídil jsem projekty a nastavoval firemní projektovou metodiku podle PMI, zaváděl jsem IT procesy podle ITIL apod.

Ale až když jsem se začal věnovat agilnímu vývoji a začal tyto principy zavádět do praxe, konečně mi do sebe zapadlo mnoho věcí a uvědomil jsem si, že pomocí tohoto přístupu, se dají dělat opravdu zajímavé a kvalitní produkty. A tak se postupem času ze mne stal "Agilní Evangelista".

Pojem "Evangelista" se někdy překládá jako "nadšený přívrženec" a to jsem přesně já. Hledám způsoby jak co nejlépe aplikovat tento přístup, jak pomoci lidem, aby pracovali lépe, ve větší pohodě a aby vytvářeli lepší produkty, které budou mít úspěch u zákazníků.

Co Vám mohu nabídnout

Vysvětlení

Potřebujete vysvětlit principy agilního vývoje?

Metodiky

Chcete rozjet Scrum nebo Kanban, ale nevíte co je pro Vás vhodnější?

Školení

Chcete proškolit vývojáře, testery, analytiky, produktové manažery a další role, případně management?

Analýza

Vyžaduje Váš management, abyste fungovali agilně, nebo naopak tlak na změny jde přímo od vývojářů, ale nejste si jisti, jak by to mohlo fungovat ve Vaší organizaci?

Nastartování

Rádi byste začali pracovat agilně, ale nevíte jak na to?

JIRA

Používáte JIRA tracking system a potřebujete pomoct ho nastavit tak, aby byl užitečný pro Váš způsob práce?

Zlepšní

Už si myslíte, že agilně fungujete, ale stále to není ono?

Integrace

Nevíte jak provázat projektový management s agilním řízením a produktovým managementem?

Potřebujete cokoli z výše uvedeného nebo Vás napadá něco dalšího?

Rád Vám v tom pomůžu.

Reference

Leveris

Leveris

Jako Agile Coach & Scrum Master jsem zde pomohl zavést full stack týmy, které mohou nezávisle dodávat funkčnosti do jedné aplikace. Dále pomohl zrychlit celý cyklus time to market, posunul dodávání nových funkčností z týdnů na dny a hodiny, atd. Díky tomu jsme např. úspěšně dodali peer-to-business investiční platformu Bondster.
Česká spořitelna

Největší banka v ČR

Zde jsem měl roli Agile Coach & Scrum Master na projektu vývoje nového bankomatového softwaru. Pomáhal jsem internímu týmu vypořádat se s agilním přístupem a zahraničním dodavatelem.
Českomoravská stavební spořitelna

Českomoravská stavební spořitelna

Dvoudenní workshop na míru.
AVAST

Jeden z nejlepších a nejrozšířenější antivir na světě.

Firma, ve které jsem pomáhal rozjet a rozvíjet agilní vývoj ve několika týmech. Zavedli jsme SCRUM nebo KANBAN, měli jsme lokální i distribuované týmy, spolupracovali s externími dodavateli, používali Atlassian produkty.
Nubium

Výhradní dodavatel technologií pro Ulož.to, největší české online datové uložiště.

V této firmě jsem provedl audit agilního vývoje, doporučil a pomohl zavést potřebné změny, které vedly ke zlepšení vývoje pomocí metodiky Scrum.
LMC

Pracovními portály jobs.cz, prace.cz a HR aplikace G2.

Byl jsem zodpovědný za celý program implementace agilního vývoje do všech částí společnosti - restrukturalizace R&D, rozjetí automatických testů pro QA, sestavení nových produktových týmů, zavedení UX, změna pravidelných releasů z půlročních na 14ti denní.
2n

Vývoj HW a SW v oblasti telekomunikací.

Pomáhal jsem nastavit agilní vývoj, včetně zlepšení používání různých nástrojů, jako např. JIRA nebo Confluence.

Kontakt

  • cerveny.ladislav@gmail.com
  • +420 602 298 867
  • IČO: 04517661
  • DIČ: CZ8104083229
  • LinkedIn