Author: zuzi

Studium MBA

K čemu je dobré MBA? Rozhodně nečekejte, že se Vám po absolvování zvýší plat na dvojnásobek a stane se z Vás ředitel. Tyto doby, kdy stačilo zamávat titulem, jsou už za námi. Takže proč jít ve 30+ ještě něco studovat? Po skončení university by mě to ani ve snu nenapadlo. Asi to bude pro každého jiné. Třeba se budete v práci nudit a nebude Vám už moc přinášet. Žádné náměty k zamyšlení, žádné challenge, jen rutina. Donekonečna dělat to samé. Vždyť jste se v tom osvědčili a jste v tom, co děláte, dobří.

Dalším motivem může být rozšíření obzorů, pro mě osobně vystoupení z IT světa a profilování se trochu bokem. A v neposlední řadě kontakty. Seznámení s lidmi z různých oborů. Možnost vidět svět i jejich očima. Zkušenost k nezaplacení.

Co se dá od studia čekat? Nečekejte čistou praxi, přeci jen, MBA je to vysokoškolský titul. Asi budete psát hodně prací v angličtině. Požadavky na práce budou záviset na tom, se kterou universitou (Británie/USA/…) bude Vaše škola spolupracovat a kde bude akreditovaná. Britové budou asi více formální. Hodně dají na formu. Co dál? Dostane se Vám kvalitní souhrn všemožných frameworků jak co řešit a analyzovat, obzvláště pan Porter je oblíben, když já osobně považuji jeho nástroje za těžko uchopitelné. Použijete je ve Vaší práci a nakonec v ideálním případě pochopíte a zužitkujete v jisté formě v praxi. Musím nakonec přiznat, že to funguje.

V neposlední řadě se můžete setkat se spoustou externistů z českých firem, a to jak na teoretičtěji zaměřených přednáškách tak na workshopech a diskuzích blízko praxi. Super. Myslím, že by to jedno bez druhého nemělo smysl. Ale asi to záleží na škole.

A nakonec, kterou školu vybrat? Záleží na Vašem rozpočtu a samozřejmě schopnostech. Asi je dobré se podívat u jaké zahraniční university je škola akreditovaná. A projít si žebříček Top 10 nebo Top 100 MBA škol na světě. Pěkné čtení. Chcete-li studovat dálkově v Čechách, zase na to zapomeňte. Ale to neznamená, že by byly špatné. Pracovat budete povětšinou třeba zase v Čechách, takže možná více nakonec využijete to, že škola je schopná zajistit na část přednášek i kvalitní lidi v české praxe. Přijímací proces na britskou MBA z Top 10 bude velmi náročný (GMAT, TOEFL, eseje, doporučení,…), studium bude denní a nebude možné ho kombinovat s prací.

Asi na závěr prozradím, že studuji na Masarykově ústavu, MBA program britské Sheffield Hallam University. A zatím můžu doporučit.

Kurzy o Agile a Scrum v Čechách?

Po přednášce na WebExpu – Agilní metody a Scrum jsem zaznamenala pár dotazů, jestli bych mohla doporučit nějaké kurzy Agile a Scrum v Čechách. Já osobně nemám s kurzy zkušenosti, nicméně zkusím tu iniciovat diskuzi na toto téma. Třeba si poradíte navzájem. Jediný kurz o Agile a Scrum co se mi podařilo najít, pořádá EDU Centrum společnosti Cleverlancerum. Co se týče certifikací, v Čechách nic. Obecně nejsem zastáncem všech možných certifikátů, takže mi to vlastně ani nechybí. Zkušenost z praxe je často cennější než stovky certifikátů.

Ostatně málo informací o Agile a Scrum v češtině bylo i důvodem k založení tohoto Blogu. No, a kdybyste měli pocit, že je to málo, tady najdete pár odkazů, kde se možná dozvíte více. Obecně doporučuji knihy či přednášky zakladatele Agile Alliance and Scrum Alliance jménem Ken Schwaber, tady múžete shlédnout jeho přednášku.

No a kdybyste chteli poradit v konkrétní situaci, neváhejte a ozvěte se, domluvíme se na přednášku či konzultaci. A na závěr, v poslední době mi vyšly o Agile a Scrum dva články (ICT Revue a Business World), které Vám tímto doporučuji.

Update 2011:
Doporučené kurzy a workshopy zaměřené na Agilní metody, Scrum proces a Kanban:
– sochova.cz – kurzy, školení, konzultace, koučing, audit procesů
– Gopas – pravidelné veřejné kurzy zaměřené na agilní metody a Scrum proces

Burndown graf

Burndown graf je výborným pomocníkem při vizualizaci výsledků. Na internetu najdete spoustu odkazů jak takový burndown může vypadat, spousta aplikací pro Scrum proces vám je budou přímo generovat. Nicméně obyčejný Microsoft Excel vám udělá stejně dobrou a možná i lepší službu. Výhodou je že se data zpracujete a zobrazíte sami, tedy máte výstup plně pod kontrolou. V tom úplně nejjednodušším případě kdy máte backlog definovaný v Excelu spolu s výsledky jednotlivých Sprintů (třeba takto) je již vcelku snadné data zobrazit.

Důležité jsou v podstatě dva grafy. Jedním je tzv. Velocity plan, tedy plán jak rychle bude tým postupovat. Obvykle vezmete v úvahu, že na začátku se tým učí a pak už pracuje konstantní rychlostí. Je dobré zahrnout do plánu i masivní dovolené (např. Vánoce) a plán tomu pro daný Sprint uzpůsobit.

velocity plan

Druhým grafem je Projekt Burndown graf, který kombinuje aktuální stav s odhady a vizualizuje předpokládaný konec projektu.

Vytiskněte každý sprint tyto dva grafy a vystavte je na veřejné místo, ať všichni na první pohled vidí jak se projektu a týmům daří.

Podívejte se na příklad toho, jak by takový burndown mohl vypadat.

Kdy je úloha dokončená?

Jedním z nejčastějších problémů na které narazíte, budou diskuze kdy je úloha dokončená a co dělat když z nějakých procesních důvodů dokončit v rámci Sprintu nejde (např. čeká se na review konkrétní osoby). Samozřejmě že ‘tým za to přeci nemůže‘ a tedy si přeci musí vzít body z dané úlohy. A že dokončení je již jen formalita a není na tom žádná práce. Obecně byste měli trvat na striktním dodržování pravidel, a tedy připsání si bodů až když je úloha opravdu hotová. A to včetně testování, dokumentace a review. Podíváme-li se ale na reálnou situaci, je to vlastně tak trochu jedno. V případě že si tým připíše body za úlohu, která není zcela hotová, vrátí se z review na přepracování, či nebyla dostatečně otestovaná, pomůže si jen na velmi limitovanou dobu jednoho Sprintu. A Sprint jak již bylo zmíněno, musí být přiměřeně krátký. Takže odložení potencionálního problému o max. jeden sprint není nijak kritické.

Nám se nejvíce osvědčilo umožnit ke konci Sprintu rozdělení úloh na menší části: tedy např. z úlohy Tisk seznamu zaměstnanců – 6 bodů, udělat dvě úlohy: Tisk seznamu zaměstnanců: Implementace, dokumentace, testování – 5bodů která se stihne a tedy i dokončí v rámci Sprintu a Tisk seznamu zaměstnanců: Review – 1 bod , která se přeplánuje na další Sprint. O tuto část úlohy bude samozřejmě výsledek týmu menší oproti plánu. Samozřejmě cílem bude takto dělit minimum úloh a vytvářet tlak na plné dokončení v rámci Sprintu. Nicméně občas úloha objektivně čeká, nepracuje se na ní, a tedy tým může začít práci na jiné úloze a nakonec i získat plánovaný počet bodů. Pak je rozdělení úlohy v podstatě i blíže realitě, než striktní dodržování pravidla nepřipsat si bod za úlohu která není hotová.

Dělení úloh je poměrně mocný nástroj, který samozřejmě svádí ke zneužívání. Když tým nebude stíhat plán na Sprint, rozdělí úlohy ve prospěch běžícího Sprintu bez ohledu na aktuální stav. To týmu pomůže jen krátkodobě, tak po dobu jednoho Sprintu. Dlouhodobě je to neudržitelné. Ale to je asi více o firemní kultuře, důvěře a férovosti konkrétních lidí…

Vyhodnocení Sprintu

Posledním krokem Sprint cyklu je vyhodnocení výsledků. Příslušný počet bodů za dokončené úlohy se odečte z produkt backlogu a ze zbývajícího počtu bodů a rychlosti týmu se upraví očekávaný konec projektu. V ideálním případě by tým měl dokončit všechny úlohy, které v rámci plánovacího meetingu naplánoval a které se zavázal splnit. To ovšem v reálu není vždy pravidlem a obzvláště na začátku, než tým dostatečně vstřebá hodnotu bodu a naučí se plánovat, se skutečnost bude od původního záměru odlišovat. Nezapomeňte, že hlavním cílem je naučit tým dobře plánovat a odhadovat svoji práci. Takže po každém Sprintu by měl tým dostatečně dobře vidět, nakolik se od plánu odlišuje, a uvědomit si proč to je. A při příštím plánováni se případných chyb vyvarovat.

Obecně je dobré udělat krátkou prezentaci, kde se porovná plánování a výsledky jednotlivých týmů za končící Sprint. Jednou z oblíbených Agile metod vizualizace jsou Burndown grafy (o tom více v dalším příspěvku). Současně je dobré ukázat progres celého projektu a jeho milestonů, aby týmy přímo viděli, jak se projekt posouvá jako celek a jestli je na tom dobře (Critical Chain úlohy, Concerto graf). Zhodnocení sprintu může pak přímo přejít do plánovacího meetingu, kde jednotlivé týmy připraví plán na další Sprint. Tyto dílčí plánovací meetingy je lepší mít odděleně pro jednotlivé týmy, výsledné plány na nový Sprint by ale týmy měly v rychlosti prezentovat zase veřejně, aby vzniklo povědomí o tom, co dělají jednotlivé skupiny, kolik bodů plánují a jak se jim následně daří plán plnit.

Zapojení zákazníka – Customer demo

Softwarové projekty často neodpovídají očekáváním zákazníka. A to i tehdy když jsou napsané podle specifikace. Ruku na srdce, určitě jste už někdy chtěli nějaký výrobek, popis přesně odpovídal, a když jste to nakonec získali či koupili, nějak to nebylo ono. Často to byly drobnosti, co výrobku chyběli k dokonalosti a praktičnosti. Stejná situace je i s vývojem a specifikací softwaru. Zákazníci očima vývojářů často nevědí, co chtějí. Vývojáři zase většinou nemají potřebný kontext či doménovou znalost prostředí a potřeb zákazníka.

Na to odpovídá Scrum proces zapojením zástupce zákazníků do procesu plánování. Zástupce zákazníka by měli být přítomni plánování na pre-planning meetingu, aby byli zapojeni do procesu a spolupodíleli se na určování priorit. Zákazník je pak ten kdo říká, co a kdy chce. Agile k tomu dodává praktiku zvanou customer demo, kde zákazník na prezentaci uvidí výsledek zadané práce. Customer demo je vhodné zorganizovat pravidelně na konci každého Sprintu. Zajistí se tak zpětná vazba a úlohy se mohou případně upravit podle potřeb zákazníka hned a předejde se složitému redesignu. Na zákazníka to neklade časově nijak velké nároky, navíc pravidelně, vždy na konci sprintu vidí výsledek, což je často k nezaplacení.

Proces plánování – Sprint planning

Podíváte-li se na běžné softwarové projekty, většina z nich končí daleko po naplánovaném konci. To je samozřejmě způsobeno několika faktory. Tím kdo plán dělá, nakolik je zkušený, nakolik umí odhadnout, co všechno bude potřeba naimplementovat, nakolik je obeznámen s procesem vývoje a samozřejmě kvalitou a spolehlivostí vstupní specifikace. Zkusme ale začít u jednotlivých vývojářů. Kolik z nich umí dobře odhadnout, kdy svoji úlohu dokončí. Kolik z těch úspěšných udělá dobrý odhad high-level oblasti – Story? Kolik z nich odhadne délku celého projektu a s jakou přesností? Asi tušíte, kam mířím. Vývojáři často neodhadnou ani úlohu na týden, natož cokoliv abstraktnějšího. Sprint Backlog Vám zajistí příslušnou granularitu úloh, Sprint pre-planning nastaví priority pro jednotlivé Story a přiřadí je týmům jako vstup na Sprint planning.

Pár zásad na začátek. Tým je ten kdo plánuje konkrétní úlohy na Sprint. Tým je ten kdo je přiřazuje úlohy jednotlivým lidem. Tým je ten kdo zajišťuje změny v přiřazení lidí na úlohy. A konečně tým je ten, kdo je zodpovědný za výslednou kvalitu a dokončení včas v rámci Sprintu. Z čistě psychologického hlediska tým se tím, že plán sám vytvoří, také zaváže k jeho splnění, tedy slíbí, že ho splní. K takovému cíli je samozřejmě psychologicky více vázán než k jakémukoliv direktivnímu nařízení, které nemůže ovlivnit.

Jak probíhá samotné plánování. Tým dostane jako vstup Story z pre-planning meetingu. Každá taková Story obsahuje jednotlivé úlohy v backlogu spolu s ohodnocením. V případě že granularita není dostatečná je čistě v pravomocích týmu úlohy rozdělit tak, aby bylo možné je dokončit v rámci jednoho Sprintu a naplánovat jen to, co věří, že dokončí. Je to jednoduché, ale na začátku se to tak nemusí zdát. Po každém Sprintu by mělo proběhnout vyhodnocení plánu, realita by se neměla moc lišit. V případě že s Agile začínáte, první Sprinty pravděpodobně nebudou naplánované zrovna ideálně. Důležité ale je tým učit a dát mu zpětnou vazbu. Za cca 3 Sprinty by plán měl být už dostatečně věrohodný a kvalitní.

Proces plánování – Sprint pre-planning

Je načase trochu popsat jak probíhá podle Agile a SCRUM plánování. Produkt backlog už máme definovaný, Story či jednotlivé úlohy jsou ohodnoceny body. Před každým začátkem Sprintu sezvěte tzv. expert-tým složený z klíčových lidí. Obecně budete chtít sezvat zástupce jednotlivých týmů, někoho z managementu, hlavního architekta, zástupce zákazníka/zákazníků a to včetně interních zákazníků v rámci firmy. Interním zákazníkem je každá skupina závislá na Vašem výstupu (takže třeba nezávislá skupina zajišťující formální testování). Cílem je zastoupit všechny skupiny jakkoliv zainteresované na výsledku projektu. Ti by pak měli na pre-planning meetingu společně vybrat oblasti, na kterých budou po následující sprint týmy pracovat.

Není úkolem přidělovat jednotlivé úlohy ani konkrétním lidem ani týmům, ale předvybrat pro každý tým příslušné high-level Story. Na konci každého Sprintu se v Burndownu vyhodnotí výsledky a nedokončené úlohy se vrátí zpět to produkt Backlogu. Před začátkem nového Sprintu se svolá další pre-planning meeting a znovu určí priority pro jednotlivé týmy.

Hlavním úkolem pre-planningu je umožnit komunikaci jednotlivých zájmových skupin (zákazník, management, architekt, …), koordinovat a pokud možno uspokojit jejich rozdílné zájmy a nastavit priority práce pro týmy.

Konstantní rychlost práce

Dalším z klíčových prvků plánování je rychlost, kterou tým pracuje. Měří se samozřejmě na body, které si tým započítává za dokončené úlohy. Na začátku každého projektu budete mít pozvolný náběh, kdy se tým seznamuje s úkolem, specifikací, technologií a architekturou. A učí se. Učící křivka bude stoupat po dobu cca 1-3 sprintů v závislosti na projektu. Pak tým najede na svůj limit a pracuje konstantní rychlostí až do konce projektu.

Konstantní rychlost a pravidelnost odevzdávání dílčích výsledků je jedním z klíčových prvků Agile metod, takže jen shrnu, co chceme docílit. Pravidelnost jde spolu s předvídatelností. Jen tak že tým odevzdá každý sprint konstantní počet bodů, bude datum dokončení projektu dostatečně důvěryhodné číslo. Z pohledu týmu je účelem udělat plánování jednodušší, když se to tak na začátku nezdá a oprostit jednotlivé členy týmu od stresu, ale zároveň je na výsledku motivovat. Tým naplánuje jen to, co věří, že stihne udělat. Ostatně úlohy jsou obodovány a tým ví, že je schopen udělat 20 bodů za sprint, a tedy že stihne zase 20 bodů. Samozřejmě může se stát, že se to ve vyjímečných případech nepodaří, ale troufám si říct, že je pak pravděpodobné, že něco nefunguje úplně ideálně a stálo by to za Vaši pozornost. Pracuje tým opravdu týmově? Jak probíhá plánování? Rozumí pojmu bod? …

Zavádíte-li s Vašimi lidmi první Agile projekt, je velmi pravděpodobné že se to budete nějakou dobu učit. Můj odhad je tak 5-8 sprintů. Tým se musí naučit chápat a vnímat co je to bod, jak dělat plán a jak spolupracovat opravdu týmově. Na začátku bylo obvyklé, že tým vykazoval naprosto nerovnoměrné výsledky v rozmezí od 0 do 2.5 násobku plánovaných bodů. Jedním z velmi důležitých pravidel je tým nechat samostatně pracovat po dobu sprintu, a neorganizovat ho zvenku, ale na konci sprintu věnovat čas na reflexi a vysvětlení.

Na závěr ještě jednu radu. Vaším cílem je být efektivní. A platí, že dobrý tým je vždy efektivnější než samostatní jedinci. Proto neporovnávejte a nehodnoťte jednotlivé lidi podle toho, kolik dokončili úloh a za kolik bodů ty úlohy byly, ale hodnoťte vždy jen tým jako celek. Motivujete tím tým na výsledku a tedy i jeho jednotlivé členy na vzájemné spolupráci. Navíc máte-li týmy dva a více, vzbudíte tím zdravou soutěživost, a vytvoříte dobrou referenční soustavu.

Krátké vývojové cykly – Sprinty

Podíváte-li se na software development projekty, dost část se Vám stane, že nejsou dostatečně dobře časově odhadnuty. Samozřejmě částečně je to dáno špatnými odhady vývojářů. Často je ale hlavním problémem nejasná specifikace na začátku, která se v průběhu stále upravuje a designe a architektura se pak neustále předělává. V tom úplně nejhorším případě na konci máte něco úplně jiného, než se zpočátku myslelo.

V této sekci se zaměřím na to jak včas odhalit, že vám vůbec hrozí problém nedokončení v daném termínu. Začneme kvalitním produkt backlogem. Ten zdaleka nemusí být rozpracován do detailů, ale musí obsahovat všechny aktivity – Story – které musí být hotovy, aby byl se projekt mohl odevzdat. Např. pro implementaci nějaké funkcionality asi musíte udělat návrh, designe testu, implementaci, integraci, otestování a napsat dokumentaci. Tyto highlevel Story ohodnotíte body a v průběhu projektu detailněji rozpracujete.

Tým nechte pracovat v pravidelných cyklech – Sprintech. Na konci každého Sprintu jednoduše odečtete body za již hotové úlohy z celkového backlogu. Porovnáním hodnoty s plánem velice rychle vidíte, jestli je vše v pořádku či ne. Použijete-li pro vizualizaci burndown graf, automaticky víte, jak jste na tom a to pravidelně každý sprint. Úkolem sprintu je naučit tým naplánovat to co opravdu zvládne a odevzdávat pravidelně stále stejný objem práce a tak zvýšit důvěryhodnost odhadů a spolehlivost data dokončení.

Sprint by měl být krátký, obecně by asi neměl být delší než měsíc. Při zavádění Agile a sprintů se nebojte na začátku změnit délku sprintu, když se ukáže pro váš projekt nevhodná. Nám se nakonec osvědčily 14 denní sprinty. Začínali jsme s týdnem, ale to se ukázala být moc krátká doba. Dobrá pomůcka je že musíte být za sprint schopni ukončit běžnou úlohu. Ale úlohy se dají vcelku neomezeně dělit, takže jde spíš o to si to vyzkoušet přímo ve Vašem prostředí.