Category: Agile

Vše co jste chtěli vědět o Agilních metodách

Definition of Done

Přestože Definition of Done (DoD) je velice jednoduchý artefakt Scrumu, spousta týmů s ním zápasí.  V podstatě je to definice toho, co musí splňovat úlohy, abyste je mohli nazvat “hotovými” – tedy “done”. Je to v podstatě takový checklist definující kvalitu, kterou musí všechny úlohy na konci Sprintu splňovat, abychom je mohli považovat za hotové a ukázat je v rámci Sprint Review. Nesplňují-li některé položky Backlogu všechny části Definition of Done, nejsou hotové a musí zpět do Product Backlogu. Primárním smyslem je konzistence. Aby bylo jasné, v jakém stavu dodaný produkt je. Definition of Done vzniká jako dohoda mezi development týmem a Product Ownerem a je stejná pro všechny položky Backlogu. Na rozdíl od Akceptačních kritérií, která jsou u každé položky Backlogu různá, protože jsou funkční specifikací, je Definition of Done stejná pro všechny položky Backlogu abychom věděli, co kvalitativně musí každá funkcionalita splňovat. V dlouhodobém horizontu můžete tuto dohodu mezi týmem a Product Ownerem změnit a Definition of Done rozšířit o další pravidla a celkovou kvalitu produktu tak zvednout, ale rozhodně by se neměla měnit ze Sprintu na Sprint.

Jak taková definition of Done může vypadat?

  • Napsaný kód
  • Otestováno
  • Review
  • Dokumentace
  • Běží na test serveru
  • Akceptováno Product Ownerem

Můžete jí samozřejmě udělat specifičtější:

  • Implementováno podle Product Backlog Item (User Story) definice
  • Automaticky otestováno (unit, functional tests)
  • Review (jiným členem týmu)
  • Dokumentace (interní)
  • Beží na test serveru
  • Akceptováno Product Ownerem

A jak již bylo zmíněno, Definition of Done se vyvíjí a časem zpřísňuje:

  • Napsaný kód
  • Otestováno
  • Review
  • Dokumentace
  • Uživatelská dokumentace
  • Přeloženo do čínštiny, francouzštiny a němčiny
  • Běží na produkci
  • Obsahuje businessové metriky
  • Akceptováno Product Ownerem

V takovém případě jsme v podstatě implementovali Continuous Delivery, neboť jednotlivé funkční celky jsou releasovány na produkci už v průběhu Sprintu kdykoliv je tým dokončí – tedy splní všechny části Definition od Done. Takhle přísnou definition of Done mají týmy, které potřebují získávat zpětnou vazbu od zákazníků v reálném čase a rychle na ni reagovat. Proto businessové metriky, které měří chování zákazníka a porovnávají je s očekáváním jsou nutnou součástí takového prostředí.

Čím Agilnější vaše organizace je, tím přísnější je obvykle Definition of Done. Nezapomeňte ale, že každá Definition of Done je vždy dohodou mezi businessem a týmem a musí tedy odpovídat potřebám vašeho businessu. Přísnější není vždy lepší. 🙂 Žádná nebo slabá Definition of Done na druhou stranu zase vede k chaosu a totální ztrátě předvídatelnosti. A to byste asi nechtěli. Jako vždy v Agilu a Scrumu hledáme balanc, a tak konkrétní podobu Definition of Done musíte sami najít pomocí krátkých experimentů a principu Inspect and Adapt – tedy být Agilní.

Jak na škálování Scrumu pro více týmů? Ideální je LeSS Large-Scale Scrum

Když zavádíte či ve firmě používáte Scrum, časem se dostanete do situace, kdy potřebujete aplikovat Scrum na něco většího, a nechat spolupracovat více týmů. Obecně to není nic složitého, ale abyste se v tom neztratili, je vhodné si trochu pomoct nějakým frameworkem. U menší produktové firmy je to pořád relativně snadné. Použijete Scrum ve větším, tedy Large-Scale Scrum (LeSS).

Large Scale Scrum - LeSS

LeSS je jednoduchý framework, který staví na principech Scrumu a dále je používá na více týmů. Tedy v kostce máte, jednoho Product Ownera, jeden Product Backlog, jeden produkt, který prezentujete zákazníkům, ale více týmů, kteří ho společně dodávají. Týmy jsou stejně jako v klasickém Scrumu stabilní, self-organized, a cross-functional – tedy každý tým dokáže vzít libovolnou položku z Backlogu a dokončit jí. Musí tedy mít všechny kompetence, které jsou potřeba aby mohli dodat end-to-end hodnotu zákazníkovi podle Definition of Done např. DB, backend, frontend, dokumentace, UX, architektura, automatické testy, uživatelská dokumentace apod.). Takhle jednoduchý koncept platí pro prostředí do osmi spolupracujících cross-functional týmů.

Product Backlog
Pokud jste velká korporace (banka, pojišťovna, nebo prostě jen velká IT firma či firma s velkým IT oddělením), principiálně je to stejné. Jen implementace je výrazně komplexnější a změna náročnější. V takovém případě už si nevystačíte s jednoduchým LeSS frameworkem, ale musíte použít takzvaný LeSS Huge – tedy Large-Scale Scrum pro obrovská prostředí. Pořád máte stabilní, self-organized, a cross-functional týmy, které společně dodávají jeden produkt. Je dobré si uvědomit že produkt není projekt. Projekt je jen jednou položkou Product Backlogu. Více si o tom můžete přečíst tady. Produkt je tedy daleko dlouhodobější a umožňuje postavit stabilnější týmové prostředí.

Large Scale Scrum - LeSS HugeLeSS Huge není až tak odlišný od klasického Large-Scale Scrumu. Co je ale v LeSS Huge složitější je struktura Product Backlogu. Zbytek zůstává stejný. Překvapivě jednoduché, že? Abychom si zachovali takzvaný tah na branku, stále chceme mít jednoho Product Ownera a jeden Backlog. To ale už není tak snadné, a tak vzniká podpůrná struktura takzvaných Area Product Ownerů, kteří pomáhají výše zmíněnému Product Ownerovi s prioritizací. Arey nejsou fixní, ale dynamicky se mění podle potřeb businessu – ostatně stále platí, že týmy jsou cross-functional, takže mohou vzít z Backlogu jakoukoli položku a naplánovat ji do Sprintu. Co neumí, učí se. Obvykle ale nemusí umět vše a věnují se nějaké oblasti (Area). Nezapomeňte ale, že oblast není komponenta a týmy dodávají vždy end-to-end funkcionalitu. Product Backlog je stále jeden, a tak máme pořád focus na ty pro firmu businessově nejdůležitější věci.

Je to jednoduché, a hlavně to funguje. Ale stejně jako Scrum, ani Large-Scale Scrum tedy LeSS není žádná zázračná pilulka. Aby zafungoval vyžaduje změnu myšlení, přístupu a mindsetu. Ale na to jste si v Agilním světě jistě zvykli. 🙂

Agilní metody řízení projektů – 9. Agilní a Scrum certifikace.

V devátém díle mé video minisérie “Agilní metody řízeni projektů“ se podíváme na Agilní a Scrum certifikace. Na ty, do kterých se vyplatí investovat, pokud chcete na trhu práce zlepšit svojí pozici či plánujete práci v mezinárodním prostředí, anebo vědět, na které se ptát pokud najímáte spolupracovníky do svých Agile a Scrum týmů. Prostě jak říkám jde o Agile a Scrum certifikace, které mají opravdu hodnotu.

Další díl: 10. Zuzana ‘Zuzi’ Šochová.
Předchozí díl: 8. Jak na Agilní transformaci.

Agilní metody řízení projektů – 8. Jak na Agilní transformaci.

V osmém díle mé video minisérie “Agilní metody řízeni projektů“ se zaměřuji na organizaci jako celek. Nebo-li co si představit pod pojmem Agilní transformace, jaké jsou její fáze a jak se firmy transformují na moderní způsoby řízení.

Další díl: 9. Agilní a Scrum certifikace.
Předchozí díl: 7. Agile v marketingu.

Agilní metody řízení projektů – 7. Agile v marketingu.

Sedmý díl mé video minisérie “Agilní metody řízeni projektů“ míří zase jinam a konkrétně na marketing. Marketing je dnes také hodně projektově orientovaný a tak Agile zde má své místo. Dozvíte se tedy, že i marketing může být Agilní. Takže vzhůru na Agile v marketingu.

Další díl: 8. Jak na Agilní transformaci.
Předchozí díl: 6. Agile v HR.

Agilní metody řízení projektů – 6. Agile v HR.

Šestý díl mé video minisérie “Agilní metody řízeni projektů“ se věnuje modernímu HR (Human Resources). Zde se dozvíte, jak na moderní HR a personalistiku, což v mém pojetí znamená Agilní HR. Podíváme se, jak se mění přístup k pozicím, náborům nových zaměstnanců a performance review.

Další díl: 7. Agile v marketingu.
Předchozí díl: 5. Agile v IT.

Agilní metody řízení projektů – 5. Agile v IT.

Pátý díl mé video minisérie “Agilní metody řízeni projektů“ se věnuje IT. Překvapení? Možná trochu jo – Agilní přístup má většina lidí spojen s IT, ale to už dávno neplatí. Business Agility, jeden z buzzwordů co teď hýbe Agilním světem, je toho důkazem. Ale já se zde naopak vracím ke kořenům, kde Agile vznikl. Dozvíte se, jaké jsou praktiky Extreme Programmingu a jak zlepšit práci na IT projektech.

Další díl: 6. Agile v HR.
Předchozí díl: 4. Co je to Kanban?