Dnešní softwarové týmy jsou přinejmenším ve svých procesech agilní! Jsou ochotni myslet mimo nastavené parametry a sledovat, co pro ně funguje. Dychtí se učit a osvojit si nové techniky projektového řízení a projektových procesů.
Metoda projektového řízení s názvem Kanban se již několik let věnuje kolům v softwarovém průmyslu a za posledních pět let získala měnu. Společně s agilní metodologií, přijetí metody Kanban dalo společnostem mnoho oslav.
Existuje však také kritika, že Kanban není ničím jiným než oslaveným seznamem úkolů. Takže o co jde? Pojďme to zjistit.
Co je Kanban?
Pokud je vaše společnost připravena překročit tradiční přístup k řízení softwarových projektů, dnes již neexistuje technika technik projektového řízení.
Jedním z nich je systém Agile Project Management, který se zaměřuje na nelineární, iterační metody vývoje softwaru. Použití agilních metod je zřejmé v Scrumu, který se zaměřuje na flexibilnější přístup k řízení projektů.
Agile má také odkazy na jiné rámce řízení projektů, jako jsou Kanban a Extreme Programming. Z nich Kanban získal velkou popularitu. Koneckonců, kdo nechce postup vyvinutý Japonci?
Kanban je koncept, který se vyvinul ve výrobním závodě Toyota, aby se dosáhlo výroby v reálném čase (JIT), která snižuje náklady a umožňuje menší využití zdrojů. Ve svém středu se řídí principem „tahání“ práce, což znamená, že úkoly nebo produkty musí být „taženy“ podle požadavků a poptávky a nikoli „tlačeny“ shora dolů. Byl vyvinut za účelem zajištění lepšího zásobování automobilovými součástmi v závodech Toyota na základě poptávky. To znamenalo, že se zvyšující se poptávkou byly žádosti vyplněny.
Koncept byl přizpůsoben softwarovému průmyslu s několika změnami Davidem Andersonem ve své knize Kanban z roku 2010. Od té doby je využíván pro různé projekty s velkým úspěchem. Může to být nesmírně nápomocná v komplexních projektech, které mají potenciál trpět přetížením na jedné straně vývojového cyklu.
Systém Kanban v zásadě považuje proces softwarového projektu za potrubí. Řekněme, že softwarový proces má tři typy úkolů: analýza, vývoj, testování a konečně nasazení. Řekněme, že je třeba splnit dvacet úkolů.
V případě tradičního systému řízení projektů, pokud
- Celkem je 25 příběhů
- Analytici dokážou zvládnout pět příběhů týdně
- Vývojáři dokážou zvládnout pět příběhů týdně
- Testery jsou omezeny na tři příběhy týdně
V této situaci se práce jednoduše hromadí na konci testerů. Na konci 1. týdne bude situace následující:
- Pouze tři příběhy se přesunuly k nasazení.
- Vývojáři a analytici pracují na třech příbězích, protože testeři nemohou vzít výstupy vývojářů a otestovat to samé.
- Práce se hromadí a vývojáři a analytici a vedoucí projektů zůstanou v opravě.
Analytici a vývojáři nyní mohou jednoduše otáčet palci! Nebo by si jejich manažer mohl uvědomit, že jsou nečinní, a přerozdělit je do jiného projektu, kde by mohla nastat podobná situace. Takže ve fázi testování jsou nyní zaseknuty dva projekty!
Problémy v takové situaci není těžké vidět. Jaký je smysl vyvinout deset příběhů (nebo bitů softwaru), když se v brzké době nebudou testovat?
Nyní na metodu Kanban.
Metoda Kanban je velmi jednoduchý koncept. Vyplývá to z jednoduché logiky spočívající v použití „metody tahu“ k odstranění nejprve úzkých míst a omezení WIP (Works in Progress) pro lepší pracovní procesy.
Ve své nejjednodušší podobě Kanban doslova „vizuální deska“ pomáhá tím, že „vytáhne“ položky ze seznamu úkolů, než aby pracovala s časovými osami. Metoda Kanban pomáhá identifikovat úzká místa tak, aby byl tok procesů lépe řízen.
Základní deska Kanban obsahuje seznam úkolů, které mají být provedeny, probíhající úkoly a dokončené úkoly.
Ve správě softwaru však mohou být úkoly trochu složitější. Většina agilních projektů má podobnou radu. Na desce Kanban jsou fáze nasazení jasně označeny spolu s číslem pro každý sloupec. Toto číslo představuje maximální počet úkolů nebo příběhů, které určitý krok zvládne.
Náš příklad na desce Kanban by vypadal něco takového na začátku druhého týdne. To znamená, že vývojáři a analytici nebudou v tomto týdnu pracovat na optimálním počtu příběhů. Bylo by zřejmé, že práce se na konci testera hromadí. Organizace mohou zajistit, aby týmy spolupracovaly na dokončení testování. Alternativně se mohou podívat na jiné modely toku procesů, aby k tomu nedošlo.
Když se projekty řeší prostřednictvím systému Kanban, existuje menší prostor pro hromadění práce. Příběhy jsou přijímány podle maximální dostupné šířky pásma.
V typickém uspořádání Kanban bude práce zahájena podle dostupné šířky pásma a práce bude tažena týmy, takže budou vždy na maximální kapacitě. Systém také umožňuje rychlejší sledování úkolů, které jsou naléhavé, takže se pohybují po desce s minimálním úsilím.
Podívejte se na tuto tabulku Kanban.
Je zřejmé, že všechny kroky pracují s maximální účinností. Úkol, který je na „Fast Track“, se také započítává.
Kanban není v žádném případě jedinou metodou používanou ke zvýšení účinnosti omezením WIP. Existují i jiné systémy, které dosahují stejného výsledku - například systémy CONWIP (Constant Works in Progress) a DBR (Drum-Buffer-Rope), které jsou primárně určeny pro zpracovatelský průmysl.
Kanban je však systém, který byl nejlépe upraven tak, aby vyhovoval softwarovému průmyslu.
Jak se Kanban liší od agilních metodik?
Ve svém středu je Kanban metodologií, která využívá některé prvky Agilního řízení projektů. Mnoho projektů v rámci Agile má kořeny v Lean přístupech. Rozdíl mezi metodikou Kanban a agilním projektovým řízením není tak černobílý, jak by nám navrhovatelé těchto dvou metod věřili. Mají více společného než rozdíly.
Agilní rámec není absolutní. Otázkou není, zda jsou týmy agilní nebo ne. Týmy mají často pohyblivost v různé míře. Jednou z metod, jak v procesu vývoje softwaru dosáhnout vyšší pohyblivosti, je použití Kanban.
Existuje několik rozdílů mezi metodami Kanban a Agile. Některé rysy vývoje Kanban, které se trochu liší od Agile, jsou:
- Časové linie nejsou významným faktorem . Je to těžký koncept obepínat naše hlavy, protože se zdá velmi neintuitivní. „Jak pracujete bez termínů?“ Lidé se často ptají. Pokud se však každý člen týmu věnuje maximální efektivitě, přestává být čas faktorem.
- Příběhy (úkoly) jsou větší než v typických agilních systémech. Délka a složitost příběhů je obvykle delší než u typického projektu Scrum. Protože se nezaměřuje na odhad času, ale pouze na to, aby se tento proces pohyboval, Kanban si může dovolit pracovat na větších příbězích.
- Ve stávajících procesech nedošlo k žádné významné změně. Principy Kanban pro vývoj softwaru, jak uvádí jeho zakladatel David Anderson ve svém blogu, zahrnují následující základní principy:
-
- Začněte tím, co děláte nyní
- Souhlasíte s tím, že budete provádět přírůstkové, evoluční změny
- Respektujte současný proces, role, odpovědnosti a tituly
- Každý příběh se měří v čase cyklu . Projekt není hodnocen tradičním agilním výpočtem rychlosti (počet příběhů dokončených v daném čase), ale časem cyklu. To znamená, že Kanban klade důraz na to, jak dlouho trvalo dokončení úkolu. Na mnoha kanbanských tabulích často vidíte tikátko, které uvádí, kolik dní trvá tým, než dokončí příběh. Tento odhad vstupuje do dalšího cyklu.
Kanban: Rada, ale co jiného?
Kanban je deska, která nám ukazuje, jak jsou příběhy uspořádány - je to, že i tak velká část se jich mnozí ptají. Ve skutečnosti se hodně diskutuje o tom, co je Kanban a co může dělat.
Je Kanban pouze metodou řízení pracovního postupu? Nebo je to něco, co lze použít společně s agilními metodikami pro maximální účinnost? Nebo to může být úplně nový způsob řízení pracovního postupu?
Každý tým používá Kanban tak, jak uzná za vhodný, pro svou konkrétní situaci. Bez ohledu na to má Kanban potenciál pracovat jako způsob života pro vývoj softwaru, pokud bude použit na optimální úroveň.
Ať už se používá ke správě pracovního postupu nebo jako nové paradigma ve vývoji softwaru, nelze popřít, že to pomáhá spravovat WIP.
Aby Kanban fungoval co nejlépe, je důležité myslet na něj nejen jako na správu WIP, ale také na rámec řízení projektů. Tento proces vám pomohou některé základní pokyny.
- Optimalizujte týmy tak, aby žádný tým nezačal něco, co nemohou dokončit. To pomáhá procesu spolu.
- Neodolávejte změnám původního systému Kanban. Pokud se vášmu projektu podaří termíny a časové lhůty, začleňte to samé jako byste. To přispívá ke zdravějšímu a robustnějšímu vývojovému prostředí.
- Nevyhýbejte se týmové práci. Kanban může vypadat jako, ale není, model založený na jednotlivcích pracujících izolovaně. Týmová práce musí být nedílnou součástí vývoje softwaru Kanban.
- Myslet mimo krabici. Přemýšlejte o změnách v pracovním postupu. Mnoho týmů se nyní rozhodlo pro vývoj řízený testem, s akceptačním testem řízeným vývojem, kde akceptační testy jsou prováděny nejprve s případy použití, které pak řídí požadované vlastnosti a povahu vývoje.
Hybridy
Protože stále více společností používá nástroje pro řízení projektů, které nejlépe vyhovují jejich konkrétní situaci, není divu, že dvě z nejlepších metodik řízení projektů: Scrum a Kanban byly integrovány k velkému úspěchu.
Hybrid, nazývaný Scrumban, se vrací do mnoha projektů.
Pokud organizace již používá Scrum, ale je pro něj obtížné udržet projekt pohromadě, ať už sprinty nefungují dobře, aby testování nebylo neprodyšné, může být čas zvážit Scrumbana.
Abych to vysvětlil jednoduše, Scrumban zahrnoval, aby do sprintu vzal lupu. Nejde jen o sprinty jako součást projektu, nýbrž o to, co se děje uvnitř sprintu. Scrumban pomáhá prozkoumat, jak se příběh zpracovává v sprintu, a to by mohlo změnit všechno.
Scrumban nebo jakákoli jeho varianta je minimální změnou oproti stávajícím praktikám. Krása použití Kanban je v tom, že může být použit s prakticky jakýmkoli modelem modelu řízení projektů: vodopádem, agilitou nebo něčím mezi tím.
Začínáme s Kanbanem
Začít se systémem Kanban je snadné. Je také možné implementovat Kanban minimálním způsobem jako pokus pro konkrétní část projektu.
- Namapujte proces vývoje softwaru. Vytvořte jasnou mapu celého procesu. Jak funguje projekt - od počátečního návrhu, přes vývoj, testování, změny funkcí, realitu?
- Seznam kroků, ve kterých bude Kanban použit. Použijte kroky, které jsou zcela pod vaší kontrolou. To obvykle zahrnuje fázi analýzy, vývoje, kontroly a testování.
- Práce na důležitých bodech, jako jsou:
- Limity pro probíhající práce pro každý krok.
- Procesy pro urychlenou / zablokovanou práci
- Odhady zadní obálky s ohledem na dobu cyklu
- Frekvence kontroly desky / procesu / odhadu Kanban
- Kupte si tabuli a hromadu poznámek Post-It.
- Začít
- Zkontrolujte podle potřeby.
- Opakovat
Tak jděte do toho a začněte s Kanbanem!
Nebojte se, pokud to nevyjde tak, jak jste původně zamýšleli. Celá myšlenka metodik Agile spočívá v přizpůsobení se změnám lidí a procesů! Dejte nám vědět o svých zkušenostech s metodou Kanban.
Doporučené články
- 6 Nejužitečnější kancelář pro řízení projektů (PMO)
- 8 užitečných kroků k vytvoření sofistikovaných map příběhů pro váš projekt
- 5 důležitých hodnot extrémního programování (výkonné)