A mai szoftvercsapatok, legalább a folyamatukban, agilisabbak! Hajlandóak gondolkodni kívül a meghatározott paramétereken, hogy kövessék, mi működik nekik. Alig várják, hogy megtanulják és alkalmazzák a projektmenedzsment és a projektfolyamatok új technikáit.
A Kanban elnevezésű projektmenedzsment módszer már évek óta megteszi a köröket a szoftveriparban, és az elmúlt öt évben pénznemre tett szert. Az Agile módszertanokkal együtt a Kanban-módszer alkalmazása sok eseményt adott a cégek számára.
De van egy kritika, miszerint Kanban nem más, mint egy dicsőséges feladatlista. Szóval miről szól? Találjuk ki.
Mi a Kanban?
Ha vállalkozása készen áll a tradicionális szoftverprojektmenedzsment megközelítésen való túllépésre, manapság nincs hiány a projektmenedzsment technikáknak.
Az egyik az Agile Project Management rendszer, amely a nemlineáris, iteratív szoftverfejlesztési módszerekre összpontosít. Az Agile módszerek alkalmazása nyilvánvaló a Scrumban, amely a projektmenedzsment rugalmasabb megközelítésére koncentrál.
Az Agile más projektek menedzsment keretrendszereihez is kapcsolódik, mint például a Kanban és az Extreme Programming. Ezek közül a Kanban nagy népszerűséget ért el. Végül is, ki nem akarja a japánok által kidolgozott folyamatot?
A Kanban egy olyan koncepció, amely a Toyota Gyárban fejlődött, hogy pontosan az időben (JIT) termeljen, amely csökkenti a költségeket és lehetővé teszi az erőforrások kevesebb felhasználását. Szívében a munka „húzza” elvét követi, vagyis a feladatokat vagy termékeket a követelmények és a követelmények „húzzák”, és nem „fentről lefelé” kell tolni. Úgy fejlesztették ki, hogy a kereslet alapján biztosítsák a gépjármű-alkatrészek jobb raktárkészletét a Toyota gyárakban. Ez azt jelentette, hogy a kereslet növekedésével a kérelmek kitöltésre kerültek.
A koncepciót a szoftveriparhoz igazították, néhány változtatással David Anderson, a Kanban című 2010. évi könyvében. Azóta különféle projektekben használják, nagy sikerrel. Óriási segítséget nyújthat olyan összetett projektekben, amelyekben a fejlesztési ciklus egyik oldalán túlterhelés szenvedhet.
Alapvetően a Kanban rendszer a szoftverprojekt folyamatát folyamatként kezeli. Tegyük fel, hogy a szoftverfolyamat háromféle típusú feladatot tartalmaz: elemzést, fejlesztést, tesztelést és végül telepítést. Tegyük fel, hogy húsz feladatot kell befejezni.
Hagyományos projektmenedzsment rendszer esetén például:
- Összesen 25 történet található
- Az elemzők hetente öt történetet tudnak kezelni
- A fejlesztők hetente öt történetet tudnak kezelni
- A tesztelőknek hetente három történet korlátozódik
Ebben a helyzetben a munka egyszerűen felhalmozódik a tesztelő végén. Az 1. hét végén a helyzet a következő lesz:
- Csak három történet ment tovább a telepítésre.
- A fejlesztők és elemzők három történeten dolgoznak, mivel a tesztelők nem képesek átvenni a fejlesztők outputját és ugyanazt tesztelni.
- A munka felhalmozódik, így a fejlesztők és elemzők és a projektmenedzser javításra kerül.
Az elemzők és a fejlesztők most egyszerűen csak hüvelykujját húzzák fel! Vagy a menedzserük észreveheti, hogy tétlen, és egy másik projekthez újraelosztják őket, ahol hasonló helyzet merülhet fel. Tehát két projekt van elakadva a tesztelési szakaszban!
Egy ilyen helyzetben a nehézségeket nem nehéz felismerni. Mi értelme tíz történet (vagy szoftver bit) kidolgozásának, ha ezeket nem hamarosan tesztelni fogják?
Most pedig a Kanban módszerrel.
A Kanban-módszer rendkívül egyszerű koncepció. Egy egyszerű logikát követ, a „pull módszer” használatával először a szűk keresztmetszeteket távolítja el, és a folyamatban lévő munkákat (WIP) korlátozza a jobb munkafolyamatok érdekében.
A legegyszerűbb formában Kanban, szó szerint, a „vizuális tábla” segít azáltal, hogy „elemeket” húz a teendők listájáról, és nem az ütemtervekkel dolgozik. A Kanban-módszer segíti a szűk keresztmetszetek azonosítását, hogy a folyamatáram jobban menedzselhető legyen.
A Kanban alaplapja tartalmazza a végrehajtandó feladatok, a folyamatban lévő és a végrehajtott feladatok listáját.
A szoftverkezelésben azonban a feladatok egy kicsit összetettebbek lehetnek. A legtöbb agilis projektnek hasonló testülete van. A Kanban táblában a telepítés szakaszai egyértelműen meg vannak jelölve, az egyes oszlopok számával együtt. Ez a szám jelenti a feladatok vagy történetek maximális számát, amelyeket egy adott lépés képes kezelni.
A példa egy Kanban táblán a második hét elején valamivel így néz ki. Ez azt jelenti, hogy a fejlesztők és elemzők nem fognak optimális számú történetet építeni azon a héten. Nyilvánvaló lenne, hogy a munka a tesztelő végén egyre felhalmozódik. És a szervezetek biztosíthatják, hogy a csapatok együttműködjenek a tesztelés elvégzésében. Alternatív megoldásként megvizsgálhatják a folyamatáramlás más modelljeit is, hogy ez ne történjen meg.
Ha a projekteket a Kanban rendszeren keresztül kezelik, akkor kevesebb lehetőség van a munka felhalmozására. A történeteket a rendelkezésre álló maximális sávszélességnek megfelelően veszik fel.
Egy tipikus Kanban-rendszerben a munkát a rendelkezésre álló sávszélességnek megfelelően veszik fel, és a munkát csapatok vonják be, hogy mindig a maximális kapacitással rendelkezzenek. A rendszer gyors megoldást is lehetővé tesz a sürgős feladatok elvégzéséhez, hogy minimális erőfeszítéssel mozoghassanak a táblán.
Vessen egy pillantást erre a Kanban táblára.
Nyilvánvaló, hogy minden lépés maximális hatékonysággal működik. És a „Gyors út” feladatát is figyelembe veszik.
A Kanban egyáltalán nem az egyetlen módszer a hatékonyság növelésére a WIP korlátozásával. Vannak más rendszerek is, amelyek ugyanazt az eredményt érik el - például a CONWIP (Constant Works in Progress) és a DBR (Dob-Buffer-Rope) rendszerek, amelyeket elsősorban a gyártóipar számára szántak.
A Kanban azonban a legjobban a szoftveripar számára átalakított rendszer.
Miben különbözik a Kanban az agilis módszertantól?
A szívében a Kanban olyan módszertan, amely az Agile Projektmenedzsment egyes elemeit használja. Az Agile keretrendszer számos projektének alapja a Lean megközelítés. A Kanban módszertan és az agilis projektmenedzsment közötti különbség nem olyan fekete-fehér, mint ahogyan a két módszer támogatói gondolnánk. Több közös, mint különbségük.
Az agilis keret nem abszolút. A kérdés nem az, hogy a csapatok agilisak-e vagy sem. A csapatok gyakran mutatnak mozgékonyságot különböző mértékben. A szoftverfejlesztési folyamat nagyobb mozgékonyságának egyik módja a Kanban használata.
Néhány különbség van a Kanban és az Agile módszertan között. A Kanban fejlesztésének néhány olyan jellemzője, amelyek kissé különböznek az Agile-től:
- Az idővonalak nem jelentős tényező . Ez egy nehéz koncepció, hogy körülvegyük a fejünket, mivel ez nagyon intuitívnak tűnik. „Hogyan dolgozol határidők nélkül?” Gyakran kérdezik az emberek. De ha a csapat minden tagja maximális hatékonysággal vesz részt, akkor az idő nem veszti figyelembe a tényezőt.
- A történetek (feladatok) nagyobbak, mint a tipikus agilis rendszereknél. A történetek általában hosszabb és összetettebb, mint egy tipikus Scrum-projektnél. Mivel a hangsúly nem az idő becslésére, hanem egyszerűen a folyamat előrehaladására irányul, Kanban megengedheti magának, hogy nagyobb történetekkel dolgozzon.
- A meglévő folyamatokban nincs jelentős változás. A Kanban szoftverfejlesztés alapelvei, amelyeket alapítója, David Anderson a blogjában fogalmazott meg, a következő alapelveket tartalmazzák:
-
- Kezdje azzal, amit most csinál
- Engedje meg, hogy fokozatos, evolúciós változást hajtson végre
- Tiszteld a jelenlegi folyamatot, szerepeket, felelősségeket és címeket
- Minden történetet ciklusidőben mérnek . A projektet nem a hagyományos, agilis sebességszámítás (egy adott időben befejezett történetek száma) alapján értékelik, hanem a ciklusidő. Ez azt jelenti, hogy Kanban hangsúlyt helyez arra, hogy mennyi ideig tartott egy feladat elvégzése. Számos Kanban táblán gyakran láthat egy kullancsot, amely megemlíti, hogy a csapat hány napot vesz igénybe egy történet befejezéséhez. Ez a becslés bekerül a következő ciklusba.
Kanban: Testület, de mi más?
Tehát a Kanban egy tábla, amely megmutatja nekünk, hogyan vannak elrendezve a történetek - hogy még ilyen nagy ügy is, sokan kérdezik. Valójában sok vita folyik arról, hogy mi a Kanban és mit tehet.
A Kanban csak egy módszer a munkafolyamat kezelésére? Vagy az agile módszerekkel együtt használható a maximális hatékonyság érdekében? Vagy lehet egy teljesen új módszer a munkafolyamat-kezeléshez?
Mindegyik csapat a saját helyzetéhez megfelelőnek tartja a Kanban-t. Függetlenül attól, hogy a Kanban az életmódja lehet a szoftverfejlesztésnek, ha az optimális szintre kerül.
Függetlenül attól, hogy a munkafolyamat kezelésére használják, vagy új paradigmának számít a szoftverfejlesztésben, nem tagadható, hogy elősegíti a WIP kezelését.
Annak érdekében, hogy a Kanban a legjobban működjön, fontos, hogy ez ne csak a WIP kezelése, hanem egy projekt menedzsment kerete legyen. Bizonyos alapvető iránymutatások elősegítik a folyamatot.
- Optimalizálja a csapatokat úgy, hogy egyetlen csapat sem kezdjen el olyasmit, amit nem tud befejezni. Ez elősegíti a folyamatot.
- Ne ellenálljon az eredeti Kanban-rendszerrel kapcsolatos változásoknak. Ha a projekt jól fog teljesíteni a határidőket és az ütemterveket, vegye be ugyanazt, mint te tenné. Ez egészségesebb és robusztusabb fejlesztési környezetet eredményez.
- Ne kerülje a csapatmunkát. A Kanban olyannak tűnik, de nem az, amely az elszigetelten dolgozó egyénekre épül. A csapatmunka a Kanban szoftverfejlesztésének szerves részét kell képeznie.
- Gondolkodj kreatívan. Gondoljon a munkafolyamat változásaira. Sok csapat most a teszt-vezérelt fejlesztést választja, az elfogadás-teszt-vezérelt fejlesztés mellett, ahol az elfogadási teszteket először használati esetekkel hajtják végre, amelyek azután meghatározzák a szükséges funkciókat és a fejlesztés természetét.
A hibridek
Mivel egyre több vállalat használja az adott helyzetéhez legjobban illeszkedő projektmenedzsment eszközöket, nem meglepő, hogy két legjobb projektmenedzsment módszertant: a Scrumot és a Kanbanot integrálják a nagy sikerhez.
A Scrumban elnevezésű hibrid sok projektet érint .
Ha egy szervezet már használja a Scrumot, de nehezen tudja a projektet együtt tartani, akár a sprint nem működik jól, a tesztelés nem légmentesen működik, ideje lehet Scrumban megfontolása.
Egyszerűen elmagyarázva Scrumban nagyítóval vett részt a sprintnél. Nem csak a sprintről szól, mint a projekt részéről, hanem arról, hogy mi történik a sprintben. Scrumban segít megvizsgálni, hogyan történik egy történet sprintben történő feldolgozása, és ez mindezt megváltoztathatja.
A Scrumban vagy annak bármely változata minimális változás a meglévő gyakorlatokhoz képest. A Kanban használatának szépsége az, hogy gyakorlatilag bármilyen projektmenedzsment-modellel használható: vízesés, agilis vagy bármi más között.
Az első lépések a Kanban-nal
Könnyű elindítani a Kanban rendszert. A Kanban minimális módon is megvalósítható próbaként a projekt egy bizonyos részén.
- Térképezze fel a szoftverfejlesztési folyamatot. Készítsen világos képet a teljes folyamatról. Hogyan működik a projekt - a kezdeti tervezéstől a fejlesztésig, a tesztelésig, a funkciók megváltoztatásáig, a valóságban?
- Sorolja fel azokat a lépéseket, ahol a Kanban felhasználásra kerül. Használja a teljesen az ellenőrzése alatt álló lépéseket. Ez jellemzően az elemzés, a fejlesztés, az áttekintés és a tesztelés szakaszát foglalja magában.
- Fontos kérdésekkel foglalkozzon, például:
- A folyamatban lévő munkák korlátozása minden lépésnél.
- A gyorsított / blokkolt munka folyamata
- A boríték hátralévő becslései a ciklusidőre vonatkozóan
- A Kanban fórum / folyamat / becslés felülvizsgálatának gyakorisága
- Vásároljon egy táblát és egy halom Post-It jegyzetet.
- Fogj neki
- Tekintse át szükség szerint.
- Ismétlés
Tehát, menj, és kezdd el a Kanban-t!
Ne félj, ha ez nem olyan, mint amire eredetileg terveztél. Az Agile módszertan mögött meghúzódó ötlet az emberekben és a folyamatokban bekövetkező változások figyelembevétele! Tudassa velünk a Kanban-módszerrel kapcsolatos tapasztalatait.
Ajánlott cikkek
- 6 legjobb segítő egy projektmenedzsment iroda (PMO)
- 8 hasznos lépés a kifinomult történettérképek elkészítéséhez a projekt számára
- Az extrém programozás 5 fontos értéke (nagy teljesítményű)