Zdroj obrázka: pixabay.com

Dnešné softvérové ​​tímy sú prinajmenšom vo svojich procesoch agilnejšie! Sú ochotní myslieť mimo stanovené parametre, aby sledovali, čo pre nich funguje. Dychtivo sa učia a osvojujú si nové techniky projektového riadenia a projektových procesov.

Metóda projektového riadenia s názvom Kanban robí kolá v softvérovom priemysle už niekoľko rokov a za posledných päť rokov získala menu. Spolu s agilnými metodológiami prinieslo prijatie metódy Kanban spoločnostiam veľa osláv.

Existuje však aj kritika, že Kanban nie je nič iné ako oslávený zoznam úloh. O čo ide? Poďme zistiť.

Čo je liek Kanban?

Ak je vaša spoločnosť pripravená prekročiť tradičný prístup k riadeniu softvérových projektov, v súčasnosti neexistuje nedostatok techník riadenia projektov.

Pre jeden, existuje Agile Project Management systém, ktorý sa zameriava na nelineárne, iteračné metódy vývoja softvéru. Použitie agilných metód je zrejmé v Scrume, ktorý sa zameriava na flexibilnejší prístup k riadeniu projektov.

Agile má tiež prepojenia na iné rámce riadenia projektov, ako sú Kanban a Extreme Programming. Z nich Kanban získal veľkú popularitu. Koniec koncov, kto nechce postup, ktorý vyvinul Japonec?

Kanban je koncept, ktorý sa vyvinul vo výrobnom závode spoločnosti Toyota, aby sa dosiahla výroba v rovnakom čase (JIT), ktorá znižuje náklady a umožňuje menšie využitie zdrojov. Vo svojom jadre sa riadi princípom „ťahu“ práce, čo znamená, že úlohy alebo výrobky musia byť „ťahané“ podľa požiadaviek a dopytu a nie „tlačené“ zhora nadol. Bol vyvinutý s cieľom zabezpečiť lepšie skladovanie automobilových komponentov v závodoch Toyota na základe dopytu. To znamenalo, že so zvyšujúcim sa dopytom sa žiadosti vyplňovali.

Túto koncepciu prispôsobil softvérovému priemyslu s niekoľkými zmenami David Anderson vo svojej knihe z roku 2010 Kanban . Odvtedy sa používa na rôzne projekty s veľkým úspechom. Môže to byť nesmierne nápomocná v zložitých projektoch, ktoré majú potenciál trpieť preťažením na jednej strane vývojového cyklu.

Systém Kanban v zásade považuje proces projektovania softvéru za pipeline. Povedzme, že softvérový proces má tri typy úloh: analýza, vývoj, testovanie a nakoniec nasadenie. Povedzme, že je potrebné splniť dvadsať úloh.

V prípade tradičného systému riadenia projektu, ak napríklad

  • Celkom je 25 príbehov
  • Analytici dokážu zvládnuť päť príbehov týždenne
  • Vývojári dokážu zvládnuť päť príbehov týždenne
  • Testeri sú obmedzení na tri príbehy týždenne

V tejto situácii sa práca jednoducho hromadí na konci testerov. Na konci prvého týždňa bude situácia nasledujúca:

  • K nasadeniu sa presunuli iba tri príbehy.
  • Vývojári a analytici pracujú na troch príbehoch, pretože testeri nedokážu vziať výstupy vývojárov a otestovať to isté.
  • Práca sa hromadí a vývojári, analytici a projektový manažér nechávajú opravené.

Analytici a vývojári môžu teraz jednoducho hýbať palcami! Alebo ich manažér by si mohol uvedomiť, že sú nečinní a prerozdeliť ich na iný projekt, kde by mohla nastať podobná situácia. Takže sú tu dva projekty, ktoré sú teraz zaseknuté vo fáze testovania!

Problémy v takejto situácii nie je ťažké vidieť. Aký má zmysel vývoj desiatich príbehov (alebo kúskov softvéru), keď sa čoskoro nebudú testovať?

Teraz na metódu Kanban.

Metóda Kanban je veľmi jednoduchý koncept. Vychádza z jednoduchej logiky spočívajúcej v tom, že na odstránenie prekážok sa použije najskôr metóda „pull“ a na zlepšenie pracovných procesov sa obmedzí postup WIP (Works in Progress).

Vo svojej najjednoduchšej podobe Kanban doslova „vizuálna doska“ pomáha tým, že „vytiahne“ položky zo zoznamu úloh, skôr ako pracuje s časovými osami. Metóda Kanban pomáha pri identifikácii úzkych miest, aby bol tok procesov lepšie riadený.

Základná tabuľa Kanban obsahuje zoznam úloh, ktoré sa majú vykonať, prebiehajúcich úloh a dokončených úloh.

V softvérovom manažmente však môžu byť úlohy o niečo zložitejšie. Väčšina agilných projektov má podobnú radu. Na karte Kanban sú fázy nasadenia zreteľne označené spolu s číslom pre každý stĺpec. Toto číslo predstavuje maximálny počet úloh alebo príbehov, ktoré môže konkrétny krok zvládnuť.

Náš príklad na doske Kanban by na začiatku druhého týždňa vyzeral niečo také. To znamená, že vývojári a analytici nebudú v tomto týždni pracovať na optimálnom počte príbehov. Je zrejmé, že na konci testera sa hromadí práca. Organizácie môžu zabezpečiť, aby tímy spolupracovali na dokončení testovania. Alternatívne sa môžu pozrieť na ďalšie modely toku procesov, aby sa tak nestalo.

Ak sa projekty riešia prostredníctvom systému Kanban, existuje menší priestor pre hromadenie práce. Príbehy sa prijímajú podľa maximálnej dostupnej šírky pásma.

V typickom usporiadaní Kanban sa bude práca vykonávať podľa dostupnej šírky pásma a práca bude ťahaná tímami, aby boli vždy na maximálnej kapacite. Systém tiež umožňuje zrýchlený postup pre naliehavé úlohy tak, aby sa pohybovali po tabuli s minimálnym úsilím.

Pozrite sa na túto tabuľu Kanban.

Je zrejmé, že všetky kroky pracujú s maximálnou účinnosťou. Úloha, ktorá je na „Fast Track“, sa tiež započítava.

Kanban nie je v žiadnom prípade jedinou metódou používanou na zvýšenie efektívnosti obmedzením WIP. Existujú aj iné systémy, ktoré dosahujú rovnaký výsledok - napríklad systémy CONWIP (Constant Works in Progress) a DBR (Drum-Buffer-Rope), ktoré sú určené predovšetkým pre výrobné odvetvia.

Kanban je však systém, ktorý bol najlepšie upravený tak, aby vyhovoval odvetviu softvéru.

Ako sa Kanban líši od agilných metodík?

Vo svojom jadre je Kanban metodikou, ktorá využíva niektoré prvky agilného riadenia projektov. Mnoho projektov v agilnom rámci má korene v štíhlych prístupoch. Rozdiel medzi Kanbanskou metodológiou a agilným projektovým riadením nie je taký čiernobiely, ako by sme podľa názoru navrhovateľov týchto dvoch metód dokázali. Majú spoločné viac ako rozdiely.

Agilný rámec nie je absolútny. Otázkou nie je, či sú tímy agilné alebo nie. Tímy majú často pohyblivosť v rôznej miere. Jednou z metód na zvýšenie obratnosti procesu vývoja softvéru je použitie produktu Kanban.

Medzi metodikami Kanban a Agile existuje niekoľko rozdielov. Niektoré črty vývoja Kanban, ktoré sa trochu líšia od agility, sú:

  • Časové rady nie sú významným faktorom . Je to tvrdý koncept obtočiť naše hlavy okolo, pretože sa zdá byť veľmi intuitívny. „Ako pracujete bez termínov?“ Ľudia sa často pýtajú. Ale ak je každý člen tímu zapojený do svojej maximálnej efektívnosti, čas prestáva byť faktorom.
  • Príbehy (úlohy) sú väčšie ako v typických agilných systémoch. Dĺžka a zložitosť príbehov sú zvyčajne dlhšie ako pri typickom projekte Scrum. Keďže sa nesústredí na odhad času, ale iba na to, aby sa proces pohol ďalej, Kanban si môže dovoliť pracovať na väčších príbehoch.
  • Existujúce procesy sa nijako významne nezmenili. Princípy Kanban pre vývoj softvéru, ako ich uvádza jeho zakladateľ David Anderson, vo svojom blogu zahŕňajú nasledujúce základné princípy:
    • Začnite tým, čo robíte teraz
    • Dohodnite sa na postupných, evolučných zmenách
    • Rešpektujte súčasný proces, úlohy, zodpovednosti a tituly
  • Každý príbeh sa meria v čase cyklu . Projekt nie je hodnotený tradičným agilným výpočtom rýchlosti (počet príbehov dokončených v danom čase), ale podľa času cyklu. To znamená, že Kanban kladie dôraz na to, ako dlho trvalo dokončenie úlohy. Na mnohých doskách spoločnosti Kanban môžete často vidieť ticker, ktorý uvádza, koľko dní tím potrebuje, aby dokončil príbeh. Tento odhad sa premieta do nasledujúceho cyklu.

Kanban: Rada, ale čo iného?

Kanban je tabuľa, ktorá nám ukazuje, ako sú usporiadané príbehy - je to také veľké množstvo, že sa mnohí pýtajú. V skutočnosti sa skutočne diskutuje o tom, čo Kanban je a čo môže robiť.

Je Kanban iba spôsob riadenia pracovného toku? Alebo je to niečo, čo sa dá použiť spolu s agilnými metodikami pre maximálnu účinnosť? Alebo to môže byť úplne nový spôsob riadenia pracovných postupov?

Každý tím používa Kanban podľa vlastného uváženia pre svoju konkrétnu situáciu. Bez ohľadu na to má Kanban potenciál pracovať ako spôsob života pri vývoji softvéru, ak sa použije na optimálnu úroveň.

Či už sa používa na riadenie pracovného toku alebo ako nové paradigma vo vývoji softvéru, nemožno poprieť, že pomáha spravovať WIP.

Aby Kanban čo najlepšie fungoval, je dôležité myslieť naň nielen ako na správu WIP, ale aj na rámec riadenia projektov. Tento proces vám pomôžu niektoré základné usmernenia.

  1. Optimalizujte tímy tak, aby žiadny tím nezačal niečo, čo nemôže dokončiť. Toto pomáha procesu spolu.
  2. Neodolajte zmenám z pôvodného systému Kanban. Ak sa vášmu projektu podarí dodržať termíny a termíny, začleňte to isté, ako by ste chceli. To prispieva k zdravšiemu a robustnejšiemu vývojovému prostrediu.
  3. Nevyhýbajte sa tímovej práci. Kanban sa môže zdať ako, ale nie je, modelom založeným na jednotlivcoch, ktorí pracujú izolovane. Tímová práca musí byť neoddeliteľnou súčasťou vývoja softvéru Kanban.
  4. Mysli mimo krabičky. Zamyslite sa nad zmenami v pracovnom postupe. Mnoho tímov sa teraz rozhodlo pre vývoj riadený testami, s akceptačným testom riadeným vývojom, kde akceptačné testy sa vykonávajú najskôr s prípadmi použitia, ktoré potom riadia požadované vlastnosti a povahu vývoja.

hybridy

Keďže stále viac spoločností používa nástroje projektového riadenia, ktoré sú najvhodnejšie pre ich konkrétnu situáciu, nie je prekvapujúce, že dve z najlepších metodológií projektového riadenia: Scrum a Kanban boli s veľkým úspechom integrované.

Hybrid, ktorý sa volá Scrumban, zasahuje do mnohých projektov.

Ak organizácia už používa Scrum, ale zistí, že je ťažké udržať projekt pohromade, buď s sprinty, ktoré nefungujú dobre, aby testovanie nebolo nepriepustné, môže nastať čas zvážiť Scrumbana.

Aby sme to vysvetlili jednoducho, Scrumban si vzal do sprintu lupu. Nejde iba o sprinty ako súčasť projektu, ale o to, čo sa deje v sprintoch. Scrumban pomáha skúmať, ako sa príbeh spracúva v sprinte, a to by mohlo priniesť celý rozdiel.

Scrumban alebo ktorákoľvek z jeho variantov je minimálnou zmenou oproti existujúcim postupom. Krása použitia Kanban je v tom, že sa dá použiť prakticky s akýmkoľvek modelom riadenia projektu: vodopád, agilnosť alebo čokoľvek medzi tým.

Začíname s Kanbanom

Začať so systémom Kanban je ľahké. Kanban je tiež možné implementovať minimálnym spôsobom ako pokus pre konkrétnu časť projektu.

  1. Zmapujte proces vývoja softvéru. Vytvorte jasnú mapu celého procesu. Ako funguje projekt - od počiatočného návrhu, po vývoj, testovanie, zmeny funkcií, v skutočnosti?
  2. Uveďte kroky, v ktorých sa Kanban použije. Použite kroky, ktoré sú úplne pod vašou kontrolou. Spravidla to zahŕňa fázy analýzy, vývoja, preskúmania a testovania.
  3. Práca na dôležitých bodoch, ako napríklad:
    1. Limity prebiehajúcich prác pre každý krok.
    2. Procesy pre urýchlenú / zablokovanú prácu
    3. Odhady zadnej časti obalu s ohľadom na čas cyklu
    4. Frekvencia preskúmania tabuľky / procesu / odhadu Kanban
  4. Kúpte si tabuľu a stoh poznámok Post-It.
  5. Začať
  6. Skontrolujte podľa potreby.
  7. opakovať

Tak choďte do toho a začnite s Kanbanom!

Neboj sa, ak to nevyjde tak, ako ste pôvodne zamýšľali. Celá myšlienka agilných metodológií je prispôsobiť sa zmenám v ľuďoch a procesoch! Dajte nám vedieť o svojich skúsenostiach s metódou Kanban.

Odporúčané články

  1. 6 najužitočnejšia kancelária pre riadenie projektov (PMO)
  2. 8 užitočných krokov na vytvorenie sofistikovaných príbehových máp pre váš projekt
  3. 5 dôležitých hodnôt extrémneho programovania (výkonné)

Kategórie: