V oblasti vývoje softwaru do 90. let byly věci předvídatelné a přehledné: jasná posloupnost pracovních procesů, plánování krok za krokem, dokumentace, testování a implementace konečného produktu.
Projektové řízení bylo příliš rigidní a odchylky od přísného plánu narušily celý pracovní tok.
Model vodopádu (kaskádový model nebo "vodopádový" model) je nepružný model vývoje softwaru s jasnou posloupností akcí, kde není možné přejít na další etapu, dokud není předchozí zcela dokončena.
Vývoj ve vodopádu vypadá jako tok procesů, který se posouvá z etapy do etapy s jasnými požadavky. K žádnému přechodu na další etapu nedochází, dokud není aktuální etapa dokončena.
V 90. letech byla rigidní metodologie nahrazena rodinou flexibilních metod.
Odkazujeme samozřejmě na Agile (agilní vývoj softwaru). Tento nový přístup k metodologii projektového řízení vstoupil do světa IT a později se rozšířil do výroby, inženýrství, vývoje umělé inteligence a dalšího.
Mezi první flexibilní metody patřily:
- RAD (zaměřený na kvalitu s minimálním rozpočtem a časovým limitem)
- XP (extrémní programování s kolektivním vlastnictvím kódu)
- Scrum (kde každý člen týmu nese odpovědnost za výsledek)
- Kanban (vizualizace fází vývoje na tabuli), mimo jiné.
Čtyři Agile myšlenky, které byste měli znát:
- Lidé a interakce jsou důležitější než procesy.
- Spolupráce se zákazníkem je důležitější než vyjednávání o smlouvě.
- Funkční produkt má prioritu před dokumentací.
- Reakce na změnu je důležitější než dodržování plánu.
| Agile | Vodopád |
|---|---|
| Flexibilní pracovní procesy, které umožňují změny kdykoli | Kaskádový vývojový model s rigidní posloupností |
| Funkční produkt je důležitější než dokumentace | Dokumentace je důležitější než hotový produkt |
| Jednotlivá odpovědnost každého člena týmu za výsledek | Odpovědnost za celkový výsledek leží na týmu |
| Interakce se zákazníkem během vývoje | Zákazník není do procesu zapojen |
| Maximální zapojení vlastníka produktu do procesu | Minimální zapojení vlastníka produktu |
| Pracovní tok je rozdělen do krátkých sprintů, obvykle od 1 týdne do 1 měsíce | Každý pracovní tok je samostatná fáze trvající až do dokončení testování a schválení |
Populární systémy řízení projektů v Agile
Pojďme prozkoumat ty, které "zapustily kořeny" a jsou nejčastěji využívány ve vývoji softwaru.
Scrum
Flexibilní přístup k vývoji softwaru, kde jedna úloha odpovídá jednomu sprintu. Sprint v Scrumu může trvat od 1 týdne do 1 měsíce.
Pro koho je Scrum určen?
Pro malé firmy nebo oddělení, kde se může vlastník firmy nebo vedoucí oddělení fyzicky integrovat do pracovního procesu a aktivně se podílet. Tato metoda je také ideální pro startupy.
Používání Scrumu v projektovém řízení ztěžuje určení odpovědnosti za nedokončené úkoly. Každý člen týmu je zodpovědný za výsledek, přičemž dává přednost sebedisciplíně, aby utvářel pracovní toky.
Tým, který si vybere Scrum pro projektové řízení, musí být připraven na maximální flexibilitu. Například, pokud jeden člen týmu dočasně "vypadne" z procesu, musí jiný převzít jeho úkoly.
Scrum mistr – projektový manažer a klíčová postava v týmu, dohlíží na organizaci obchodních procesů, schůzky, motivaci týmu, rychlé reakce na změny a řešení problémů.
+ Výhody
Software se vyvíjí rychleji, s maximálním zapojením týmu, snižujícím náklady na vývoj rozdělením pracovního toku do krátkých sprintů.— Nevýhody
Scrum nemá žádná přísná pravidla nebo požadavky , ale umožňuje prostor pro experimentování, změny rozpočtů a časových plánů. Není vhodný pro klienty, kteří potřebují jasný plán a formální smlouvu.Například, pokud potřebujete vytvořit produkt pro státní organizaci, kde je prioritou podepsání smlouvy, Scrum je nevhodný. Nejvyšší prioritou je hotový produkt, následovaný dokumentací, pracovními zprávami atd.
Příklad projektového řízení pomocí Scrumu
Předpokládejme, že úkolem je vyvinout software v co nejkratším čase. Pracovní tok je rozdělen do sprintů, přičemž každý končí demonstrací dokončeného výsledku. Schůzky se konají za účelem přezkoumání mezivýsledků a přechodu na další sprint.
Monitorování rychlosti dokončení sprintu je v Scrumu klíčové.
Pro pochopení, jak dlouho bude sprint trvat, tým může na začátku spustit časovač. Sledování času stráveného na každém úkolu poskytuje poznatky o potřebné délce pro podobné úkoly.
Kanban
Vizualizace pracovního toku a postupného posunu úkolů z "V průběhu" do "Hotovo." Mezi těmito dvěma stavy může být několik dalších fází: "Vývoj," "Testování," "Optimalizace," atd. Kanban se objevuje jako tabule, na které se úkoly přesunují z úkolu na úkol. Když úkol dosáhne konečné stanice "Hotovo", je dokončen.
Scrum a Kanban jsou flexibilní přístupy k projektovému řízení. Nicméně, Kanban je ještě flexibilnější, protože:
- Umožňuje náhlé nové úkoly a "přepínání" mezi nimi.
- Kolektivní odpovědnost za výsledek zvyšuje efektivitu.
- Neplánované úkoly jdou do backlogu, což je úložný prostor pro všechny úkoly, které ještě nejsou v procesu. Backlog vypadá jako jakákoli jiná fáze pracovního procesu a obsahuje úkoly připravené k práci, když se jiné fáze dokončí dříve než očekáváno.
+ Výhody
Na rozdíl od Scrumu, Kanban nevyžaduje pravidelné schůzky, diskuse nebo revize sprintu, což šetří čas a zvyšuje efektivitu, protože všechny fáze jsou viditelné na tabuli.— Nevýhody
Kanban je náročný pro velké projekty, kde jsou mezivýsledky klíčové, rozdělení procesu na sprinty, a pre-schválení akčního plánu je potřebné. Kanban je vhodnější pro krátkodobé projekty a úkoly.Příklad projektového řízení pomocí Kanban
Úkolem je natočit instruktážní video pro klienta. To zahrnuje vytvoření několika úkolů: "Psaní scénáře," "Natáčení," "Hrubé editace," "Postprodukce." Každý úkol bude samostatným sloupcem na Kanban tabuli.
Kanban nebo Scrum? Který systém řízení projektů potřebujete?
Scrum poskytuje více kontroly a spravovatelnosti na začátku vývoje nového produktu. Pokud Kanban nabízí maximální flexibilitu, Scrum se více zaměřuje na kontrolu a řízení. Jakmile jsou procesy na místě, Kanban přichází na pomoc. Je ideální pro práci s opakujícími se úkoly.Jak vybrat nástroj pro projektové řízení?
správce úkolů je polovinou úspěchu. Jakmile si vyberete metodu projektového řízení, je klíčové přenést práci a úkoly do zvoleného systému.
6 znaků, že jste vybrali správného správce úkolů:
- Tým bez problémů migroval všechny pracovní toky do účtu.
- Funkčnost je intuitivní a využívána členy týmu.
- Tým snadno používá jednu z flexibilních metod řízení: Scrum nebo Kanban.
- Systematizace pracovního toku je zajištěna, což zvyšuje celkovou efektivitu.
- Komunikace v týmu se stává více koordinovanou: projekty, úkoly a komentáře nejsou ztraceny.
- Klient obdrží transparentní zprávy o úkolech a projektech a může sledovat pracovní toky, pokud si to přeje.