Váš tým právě strávil šest měsíců tím, že vytvořil přesně to, co si klient vyžádal. Ukázka proběhla bezchybně. A pak to řekli: „Tohle už nepotřebujeme. Trh se změnil.“
Viděl jsem, jak tento scénář ničí projekty, rozpočty a morálku týmu, a to už nespočetněkrát.
Problémem není to, že se požadavky mění. To se děje vždy. Problémem je vytváření procesů, které předstírají, že se to nestane.
Softwarové týmy si v průběhu času uvědomily jednu důležitou věc: co kdybychom přestali bojovat proti změnám a místo toho je začali očekávat?
Zde se dozvíte, jak se stát projektovým manažerem s hlubokými znalostmi umělé inteligence →
V příručce pro projektové řízení založeném na umělé inteligenci získáte:
- 5 systémů umělé inteligence připravených k nasazení pro vaši týdenní práci na projektech
- 30 agentů zapojených od zahájení až po uzavření projektu
- Skutečné multiagentní pracovní postupy, které vám pomohou navrhnout si vlastní.
Tato změna v uvažování vedla ke vzniku agilního projektového řízení.
Hlavní poznatky
- Agilní řízení přináší přidanou hodnotu díky iterativním, krátkým vývojovým cyklům.
- Agilní projekty výrazně převyšují tradiční přístupy k řízení typu „vodopád“.
- Scrum, Kanban a XP jsou hlavní agilní projektové rámce.
- Úspěšné zavedení agilních metod vyžaduje skutečné změny v organizační kultuře.
Co je agilní řízení projektů?
Agilní řízení projektů je iterativní přístup, který přináší hodnotu prostřednictvím krátkých pracovních cyklů zvaných sprinty, které obvykle trvají dva až čtyři týdny a během nichž týmy průběžně plánují, realizují, vyhodnocují a přizpůsobují se, namísto toho, aby se řídily striktním sekvenčním plánem.
Místo toho, aby týmy strávily měsíce přípravou všeho před získáním zpětné vazby, vydávají funkční software každých několik týdnů a přizpůsobují ho na základě získaných poznatků.
To přímo řeší problém, s nímž se potýká většina týmů: dlouhé vývojové cykly, v jejichž rámci se vše dodává najednou, jen aby se pak zjistilo, že požadavky se změnily už před několika měsíci.
Tradiční vodopádový model řízení projektů stanoví požadavky na začátku a postupuje lineárními fázemi, přičemž každá fáze musí být dokončena, než může začít fáze následující.
Zapojení zákazníka probíhá především během počátečního sběru požadavků a při konečném předání, přičemž mezi tím není nic hmatatelného.
Agilní přístup to zcela obrací. Zákazníci se zapojují po celou dobu životního cyklu projektu a v každém sprintu vidí funkční software.
Týmy vítají změny požadavků i v pozdních fázích vývoje a považují je za konkurenční výhody, nikoli za nákladné problémy.
Tato metodika klade důraz na hodnotu pro zákazníka v rámci stanovených časových a nákladových omezení tím, že ze změn činí pravidlo, nikoli výjimku.
Proč je agilní řízení projektů důležité
Organizace, které úspěšně provedly agilní transformaci, uvádějí přibližně 30% nárůst efektivity, spokojenosti zákazníků a angažovanosti zaměstnanců.
Když přešli na dvoutýdenní sprinty, uvedli svou první funkční funkci na trh za čtyři týdny a upravili směr vývoje na základě skutečné zpětné vazby od zákazníků. Tato změna zachránila produktovou řadu.
Sledoval jsem, jak se jeden z klientů ze seznamu Fortune 500 devět měsíců potýkal s plánováním podle vodopádového modelu, než si uvědomil, že se jeho trh zcela změnil.
Když přešli na dvoutýdenní sprinty, uvedli svou první funkční funkci na trh za čtyři týdny a upravili směr vývoje na základě skutečné zpětné vazby od zákazníků. Tato změna zachránila produktovou řadu.
Výzkum společnosti Standish Group ukazuje, že agilní projekty dosahují 42% úspěšnosti, zatímco u projektů typu „waterfall“ je to pouze 13 %. Naopak projekty typu „waterfall“ selhávají v 59 % případů, zatímco u agilních projektů je to pouze 11 %.
Nejde o žádné drobné rozdíly. Představují zásadní zlepšení v tom, jak týmy zvládají nejistotu a přinášejí hodnotu i při změnách požadavků.
Hledáte snadný způsob, jak spravovat svůj agilní tým na jednom místě? Stáhněte si zdarma šablonu pro agilní řízení od ClickUp zde!
Základní principy agilního řízení projektů
Agilní manifest v roce 2001 stanovil čtyři hodnoty, kterými se moderní týmy řídí dodnes. Nejedná se o abstraktní filozofii, ale o praktické priority, které utvářejí každodenní rozhodnutí.
- Lidé a interakce mají přednost před procesy a nástroji: Týmy upřednostňují přímou komunikaci a spolupráci před striktním dodržováním procesů nebo složitých nástrojů.
- Fungující software před komplexní dokumentací: Důraz se přesouvá na dodávání funkčních inkrementů, které mohou uživatelé skutečně otestovat, namísto dokonalé dokumentace, která nemusí nikdy odrážet realitu.
- Spolupráce se zákazníkem nad vyjednáváním smluv: Neustálé zapojení zainteresovaných stran v průběhu celého vývoje je důležitější než striktní dodržování původních smluv, které byly sepsány ještě předtím, než kdokoli pochopil skutečné požadavky.
- Reagovat na změny místo dodržování plánu: Týmy přijímají měnící se požadavky a přizpůsobují se jim, jakmile se objeví nové informace, místo aby každou změnu považovaly za nákladný problém, kterému je třeba se vyhnout.
Tyto hodnoty neznamenají, že byste se měli zcela vzdát procesů, dokumentace, smluv nebo plánů. Jednoduše upřednostňují to, co přináší největší hodnotu, když jste nuceni si vybrat.
Jak funguje agilní přístup [krok za krokem]
Týmy uplatňují agilní přístup prostřednictvím opakujících se sprintových cyklů, které proměňují nápady ve funkční software.
Každý sprint probíhá ve stejném rytmu, obvykle trvá dva týdny, což zajišťuje předvídatelnost a zároveň zachovává flexibilitu v rámci této struktury.
1. Plánování sprintu
Cyklus začíná plánováním sprintu, při kterém tým vybírá položky z produktového backlogu, o kterých se domnívá, že je během sprintu dokáže dokončit.
Nejde však jen o náhodný výběr úkolů. Produktový vlastník vysvětlí, co je v danou chvíli nejcennější, a vývojáři posoudí, co je vzhledem k jejich aktuální kapacitě a dosavadní rychlosti realizovatelné.
Společně definují cíl sprintu, který dává práci smysl, který přesahuje pouhé splnění kontrolního seznamu.
Tým také rozčlení vybrané položky na menší úkoly a vytvoří plán, jak bude práce provedena.
2. Denní standupy
Každý den během sprintu pořádá tým patnáctiminutovou kontrolu, aby se všichni drželi v synchronizaci.
Nejedná se o zprávy o stavu pro manažera. Jsou to spíše pracovní schůzky, na nichž vývojáři hodnotí pokrok směrem k cíli sprintu a identifikují překážky bránící práci.
Každý se podělí o to, co včera dokončil, na čem dnes pracuje a co mu brání v pokroku.
Díky přísnému časovému limitu se všichni soustředí na podstatné věci a podrobnější diskuse se pak vedou až poté, a to pouze s příslušnými osobami.
3. Realizace sprintu
Mezi jednotlivými ceremoniály vytvářejí vývojáři funkční inkrementy, které splňují týmovou definici dokončení, sami řídí svou práci a každý den přizpůsobují plány na základě získaných poznatků.
Cíl sprintu zůstává neměnný, ale způsob, jakým ho tým dosáhne, se může měnit v závislosti na technických výzvách nebo při objevování lepších přístupů.
Neprovádějí se žádné změny, které by ohrozily cíl sprintu, i když se rozsah může upřesnit a znovu projednat s produktovým vlastníkem, jakmile tým získá více informací.
4. Revize sprintu
Na konci sprintu tým předvede dokončenou práci zainteresovaným stranám v rámci pracovní schůzky namísto formální prezentace, což umožňuje, aby zpětná vazba okamžitě ovlivnila stanovení dalších priorit.
Zainteresované strany vidí funkční software, který mohou skutečně otestovat, a mohou tak poskytnout zpětnou vazbu založenou na reálných zkušenostech, nikoli na teoretických požadavcích.
Produktový backlog se často upravuje přímo na místě na základě toho, co se všichni naučili z pozorování daného inkrementu.
5. Retrospektiva sprintu
Závěrečná ceremonie uzavírá každý sprint tím, že se zhodnotí, co se povedlo, jaké problémy se objevily a která vylepšení jsou pro příští sprint nejdůležitější.
Tým vyhodnocuje průběh sprintu z hlediska jednotlivců, interakcí, procesů a nástrojů.
Identifikují změny s největším dopadem na zlepšení efektivity a buď je okamžitě implementují, nebo je přidají do backlogu příštího sprintu.
Tento zabudovaný mechanismus zlepšování zabraňuje týmům opakovat stejné chyby sprint za sprintem.
Tento rytmus vytváří transparentnost, díky níž má každý přehled o práci, kontrolu, při které se pravidelně prověřuje pokrok, a přizpůsobení, při kterém se proces upravuje, pokud kontrola odhalí problémy.
Nejběžnější agilní přístupy
Agilní přístup není jedna metodika, ale celá skupina rámců. V moderní praxi dominují tři z nich a výběr mezi nimi závisí na typu práce, kterou váš tým vykonává, a na tom, jak předvídatelně se tato práce objevuje.
Scrum
Scrum je s 63 % mírou využití nejoblíbenějším rámcem, a to z dobrého důvodu.
Nabízejí strukturované role, včetně produktového vlastníka, scrum mastera a vývojářů, spolu s předepsanými rituály a jasnými artefakty, které týmům poskytují konkrétní výchozí bod.
Struktura sprintů s pevně stanovenou dobou vytváří rytmus a předvídatelnost, přičemž stále umožňuje přizpůsobení v rámci každého cyklu.
Tento rámec se nejlépe hodí pro vývoj složitých produktů v týmech o maximálně 10 členech, kde se měnící se požadavky dají nejlépe řešit pomocí adaptivního plánování.
Pokud vyvíjíte něco nového, u čeho se potřeby zákazníků mění s tím, jak získáváte nové poznatky, iterativní přístup Scrumu vám umožní každých několik týdnů upravit směr, místo abyste se vázali na rigidní dlouhodobý plán.
Kanban
Kanban volí odlišný přístup, když klade důraz spíše na plynulý tok než na pevně dané iterace.
Týmy vizualizují svou práci na tabulkách a stanovují limity rozpracovaných úkolů, které zabraňují přetížení a přepínání mezi úkoly.
Práce prochází systémem postupně, jakmile se uvolní kapacita, čímž vzniká plynulý a předvídatelný tok.
Tyto metody se skvěle hodí pro podporu výroby, údržbářské týmy s nepředvídatelnou nepřetržitou prací a provozní týmy zajišťující nepřetržité poskytování služeb, kde práce přichází neustále.
Pokud se váš tým zabývá řešením žádostí o podporu, opravami chyb nebo požadavky na infrastrukturu, které nemohou počkat na příští plánovací schůzku sprintu, je pro vás kontinuální model Kanbanu ideální volbou.
Extreme Programming (XP)
XP se intenzivně zaměřuje na technickou dokonalost prostřednictvím disciplinovaných inženýrských postupů. Při párovém programování pracují dva vývojáři na jedné pracovní stanici, aby mohli průběžně revidovat kód.
Při vývoji řízeném testy se nejprve napíší testy, které selžou, a teprve poté se píše kód. Kontinuální integrace kód ihned po přidání otestuje, aby se problémy odhalily co nejrychleji.
Tento přístup se nejlépe hodí v situacích, kdy je kvalita kódu prvořadá, týmy jsou malé a mohou pracovat na jednom místě, což umožňuje efektivní práci ve dvojicích, a požadavky se často mění.
XP poskytuje technické postupy, díky nimž zůstávají kódové základny udržovatelné i při změnách požadavků, což je obzvláště cenné u produktů s dlouhou životností, u nichž se technický dluh stává nákladným.
Kombinace rámců
Týmy často kombinují různé rámce, aby využily to nejlepší z každého přístupu.
Scrum plus XP představuje nejoblíbenější hybridní přístup, který využívá Scrum jako strukturu pro řízení projektů, zatímco XP zajišťuje technickou kvalitu prostřednictvím disciplinovaných inženýrských postupů.
Tato kombinace vám nabízí plánování založené na sprintech a zapojení zainteresovaných stran ze Scrumu spolu s postupy pro zajištění kvality kódu z XP, které zabraňují hromadění technického dluhu.
Kdy má agilní přístup největší smysl
Agilní přístup funguje nejlépe, pokud jsou splněny určité podmínky:
- Projekty s měnícími se nebo nejasnými požadavky, u nichž se potřeby zákazníků rychle mění
- Složité úkoly vyžadující flexibilitu a přizpůsobivost v průběhu učení se týmů
- Vývoj softwaru vyžadující častou zpětnou vazbu od zákazníků
- Situace, kdy týmy mohou dodávat funkční inkrementy každé dva až čtyři týdny
- Organizace, které jsou ochotné svěřit týmům pravomoc rozhodovat
Tyto scénáře mají jedno společné: nejistotu, kterou lze lépe zvládnout pomocí iterativního objevování než předem připraveným plánováním.
Stejně důležitá je i druhá strana mince. Pevně dané požadavky bez očekávaných změn plýtvají flexibilitou agilních metod, protože platíte náklady na přizpůsobení, aniž byste je potřebovali.
Naopak v přísně regulovaných odvětvích, jako je farmaceutický průmysl, vzniká jiný problém, protože vyžadují rozsáhlou dokumentaci, kterou agilní přístup se svou jednoduchostí přirozeně neposkytuje.
Některé projekty se také potýkají s omezeními, kvůli kterým je iterativní přístup nepraktický. Stavební projekty mají přísné závislosti, u nichž má sekvenční přístup prostě větší smysl.
A pokud smlouvy obsahují pevně stanovené ceny s předem danými výsledky a přísnými sankcemi, jsou v zásadním rozporu s agilním přístupem, který počítá s měnícím se rozsahem projektu.
Než se rozhodnete, zvažte tři předpoklady, které určují proveditelnost:
- Dokážete vydávat nové funkce každý měsíc bez nadměrných nákladů na testování?
- Je k dispozici někdo, kdo je oprávněn jako produktový vlastník rozhodovat o denních výdajích?
- Ještě nevíte, jak by takové řešení mělo vypadat?
Pokud na některou z otázek odpovíte „ne“, často dává větší smysl zvolit hybridní přístupy, které kombinují agilní postupy s tradiční projektovou strukturou, než se snažit za každou cenu prosadit metodiku, která neodpovídá vašim omezením.
Jak začít s agilním řízením projektů
Zavedení agilních metod vyžaduje promyšlený postup, nikoli pokus o okamžitou transformaci. Zde je návod, jak přejít od plánování k prvnímu úspěšnému sprintu.
Než se pustíme do podrobností, toto video vám poskytne pevný základ pro pochopení toho, jak agilní přístup ve skutečnosti vypadá v praxi:
- Krok 1: Posuďte svou připravenost Než oznámíte agilní transformaci, zhodnoťte, zda ji vaše prostředí skutečně dokáže podpořit. Nejprve se podívejte na typ vašeho projektu a ujistěte se, že má měnící se požadavky a vyžaduje častou zpětnou vazbu. Poté zvažte, zda jsou členové týmu ochotni změnit svůj způsob práce, nebo zda budete čelit zakořeněnému odporu. Nakonec se ujistěte, že zainteresované strany a vedení chápou, že se budou muset aktivně podílet na celém procesu, a ne jen přijímat zprávy o stavu na konci. Pokud některý z těchto prvků chybí, vyřešte tyto mezery, než budete pokračovat. Agilní transformace selhávají mnohem častěji kvůli nedostatku organizační podpory než kvůli problémům s technickou realizací.
- Krok 2: Vyberte si rámec Jakmile si ověříte, že jste připraveni, vyberte si jeden rámec a držte se ho alespoň tři měsíce. Scrum poskytuje strukturu, která se dobře hodí pro týmy zabývající se vývojem produktů, zatímco Kanban je vhodný pro práci s plynulým tokem, jako je podpora a údržba. Pokud je vaší hlavní prioritou technická kvalita, XP se zaměřuje na inženýrské postupy, jako je párové programování a vývoj řízený testy. Klíčem je nejprve dokonale zvládnout jeden přístup, než začnete rámce kombinovat, protože musíte pochopit, proč každý prvek existuje, než ho začnete přizpůsobovat své situaci.
- Krok 3: Spusťte pilotní projekt Po výběru rámce si vyberte jeden projekt, který je pro firmu důležitý, ale jehož případné problémy firmu nezničí. To vám dá prostor k učení bez katastrofálních následků. Jako hodnotící období naplánujte dva až tři sprinty (čtyři až dvanáct týdnů) a udržujte tým v malém počtu čtyř až pěti lidí, aby koordinační náklady nezastínily to, zda agilní přístup sám o sobě funguje. Zajistěte, aby se členové týmu mohli pilotnímu projektu věnovat na plný úvazek, místo aby rozdělovali svou pozornost mezi více projektů.
- Krok 4: Stanovte jasné role Váš pilotní projekt potřebuje tři klíčové role, které budou správně fungovat od prvního dne. Produktový vlastník musí mít pravomoc činit každodenní rozhodnutí o výdajích, aniž by musel žádat o schválení nadřízenými, a musí být k dispozici týmu, místo aby na několik dní zmizel. Váš scrum master by měl usnadňovat proces a odstraňovat překážky, místo aby řídil lidi v tradičním smyslu. Nakonec sestavte mezifunkční vývojový tým, který disponuje všemi dovednostmi potřebnými k dokončení práce, aniž by ho zpomalovaly vnější závislosti. Tyto role nejsou volitelnými doplňky, které můžete vynechat. Jsou to strukturální požadavky, aby agilní přístup fungoval tak, jak byl navržen.
- Krok 5: Zahajte svůj první sprint Plánování sprintu začněte tím, že produktový vlastník vysvětlí aktuální priority, zatímco tým vybere práci, kterou podle svého názoru dokáže dokončit. Společně definujte, co pro váš tým vlastně znamená „hotovo“, aby všichni sdíleli stejný standard, poté naplánujte všechny opakující se ceremonie, jako jsou denní standupy, revize sprintu a retrospektiva, a chraňte tento čas před jinými schůzkami. Poté začněte pracovat a počítejte s tím, že první sprint bude trochu nepříjemný, protože to tak vždy bývá. Týmy obvykle potřebují tři až pět sprintů, než najdou svůj rytmus a nastaví spolehlivou rychlost.
Než oznámíte agilní transformaci, zhodnoťte, zda ji vaše prostředí skutečně dokáže podpořit. Nejprve se podívejte na typ vašeho projektu a ověřte, zda má měnící se požadavky a vyžaduje častou zpětnou vazbu. Poté zvažte, zda jsou členové týmu ochotni změnit svůj způsob práce, nebo zda budete čelit zakořeněnému odporu. Nakonec se ujistěte, že zainteresované strany a vedení chápou, že se budou muset aktivně podílet na celém procesu, a ne jen přijímat zprávy o stavu na konci. Pokud některý z těchto prvků chybí, vyřešte tyto mezery, než budete pokračovat. Agilní transformace selhávají mnohem častěji kvůli nedostatku organizační podpory než kvůli problémům s technickou realizací.
Jakmile si ověříte, že jste připraveni, vyberte si jeden rámec a držte se ho alespoň tři měsíce. Scrum poskytuje strukturu, která se dobře hodí pro týmy zabývající se vývojem produktů, zatímco Kanban je vhodný pro práci s plynulým tokem, jako je podpora a údržba. Pokud je vaší hlavní prioritou technická kvalita, XP se zaměřuje na inženýrské postupy, jako je párové programování a vývoj řízený testy. Klíčem je nejprve dokonale zvládnout jeden přístup, než začnete rámce kombinovat, protože musíte pochopit, proč každý prvek existuje, než ho začnete přizpůsobovat své situaci.
Po výběru rámce si vyberte jeden projekt, který je pro firmu důležitý, ale jehož případné potíže firmu nezničí. To vám dá prostor k učení bez katastrofálních následků. Jako hodnotící období naplánujte dva až tři sprinty (čtyři až dvanáct týdnů) a udržujte tým malý, o velikosti čtyř až pěti lidí, aby koordinační náklady nezastínily to, zda agilní přístup sám o sobě funguje. Zajistěte, aby se členové týmu mohli pilotnímu projektu věnovat na plný úvazek, místo aby rozdělovali svou pozornost mezi více projektů.
Váš pilotní projekt potřebuje tři klíčové role, které budou správně fungovat od prvního dne. Produktový vlastník musí mít pravomoc činit každodenní rozhodnutí o výdajích, aniž by musel žádat o schválení nadřízenými, a musí být k dispozici týmu, místo aby na několik dní zmizel. Váš scrum master by měl usnadňovat proces a odstraňovat překážky, místo aby řídil lidi v tradičním smyslu. A konečně sestavte mezifunkční vývojový tým, který disponuje všemi dovednostmi potřebnými k dokončení práce, aniž by ho zpomalovaly vnější závislosti. Tyto role nejsou volitelnými doplňky, které můžete vynechat. Jsou to strukturální požadavky, aby agilní přístup fungoval tak, jak byl navržen.
Začněte plánování sprintu tím, že produktový vlastník vysvětlí aktuální priority, zatímco tým vybere práci, kterou podle svého názoru dokáže dokončit. Společně definujte, co pro váš tým vlastně znamená „hotovo“, aby všichni sdíleli stejný standard, poté naplánujte všechny opakující se ceremonie, jako jsou denní standupy, revize sprintu a retrospektivy, a chraňte tento čas před jinými schůzkami. Poté začněte s vývojem a počítejte s tím, že první sprint bude trochu nepříjemný, protože to tak vždy bývá. Týmy obvykle potřebují tři až pět sprintů, než najdou svůj rytmus a nastaví spolehlivou rychlost.
Často kladené otázky
Za jak dlouho uvidíme výsledky agilního přístupu?
Okamžité zlepšení komunikace v týmu se projeví již během prvního sprintu. Transformace společnosti John Deere přinesla 79% zkrácení doby cyklu během šesti měsíců. Střednědobé přínosy dosahují 165% nárůstu produktivity. Dlouhodobá zralost po dvanácti až dvaceti čtyřech měsících vytváří soběstačnou kulturu s maximální návratností investic (ROI).
Jaký je rozdíl mezi agilním přístupem a metodou Scrum?
Agilita je filozofie vycházející z Agilního manifestu, která obsahuje hodnoty a principy. Scrum je jeden z rámců pro implementaci agility s definovanými rolemi, událostmi a artefakty. Agilitu si můžete představit jako filozofii zdravého životního stylu, zatímco Scrum je konkrétní plán stravy a cvičení.
Mohou malé týmy o dvou až třech lidech efektivně využívat agilní metody?
Ano, často i efektivněji. Průvodce Scrumem doporučuje tři členy jako minimum, ale i menší týmy se dobře přizpůsobí. Neustále spolu komunikují, čímž eliminují formální standupy. Větší týmy jsou třikrát až čtyřikrát dražší a vykazují více chyb. Udržujte retrospektivy a zvažte zavedení postupů Kanbanu nebo XP.
Závěr
Není žádným tajemstvím, že agilní řízení projektů patří k nejoblíbenějším metodikám řízení projektů na světě.
Je to jednoduché a rychlé – pomůže to vašemu týmu hravě zvládnout úkoly a projekty v rekordním čase!
Navíc, jelikož tyto metody kladou důraz na změny v reakci na zpětnou vazbu od zákazníků, můžete si být jisti, že uvedete na trh produkt, který si vaši zákazníci zamilují.
Pokud uvažujete o zavedení agilních metod řízení projektů, proč nevyzkoušet software jako ClickUp?
Najdete zde vše, co potřebujete k snadnému řízení svých projektů a sprintů! Zaregistrujte se ještě dnes a získejte navždy bezplatnou verzi ClickUp