Ismeri Scrumot, igaz? Azt hiszem, igen, figyelembe véve, hogy a Scrum Szövetségnek több mint 400 000 tagja van, és ezek közül a legtöbb sikeresen használja szervezetében.
De nem ez az egyetlen mód a szoftver gyors és gyors fejlesztésére - komolyan! Hallottál már Kanbanról?
Kicsit háttérinformációként eredetileg a lean gyártásban alkalmazták, hogy a munka bemenete és outputja ábrázolódjon egy gyárban. Ezt a megjelenítést egy olyan táblán mutatták be, amelyet „várd meg” Kanban néven. Az utóbbi időben és relevánsabb az ön számára, ezt a szoftveres fejlesztési irányítási módszerként alkalmazták.
Elsőként David J. Anderson neurológus körvonalazta a szoftverfejlesztés és a tervezés szervezésének egyik módját, amely lehetővé teszi a folyamatproblémák felfedését és a termék folyamatos értékes fejlesztéseinek folyamatos végrehajtását - amelyről tudom, hogy ideálisnak tűnik. Egyszerűen fogalmazva, bármikor megnézheti, hol van a munka (kártyákkal ábrázolva) a fejlesztés folyamatában.
Hogyan működik
A Kanban alaplapja hat oszlopot használ, amelyek megmutatják, hogy az egyes munkák hol vannak a termékfejlesztési ciklusban. Az alábbiakban egy durva mintát néz ki, hogy hogyan néz ki.
Tekintse meg ezt a Kanban tábla példát a Trello-n.
1. oszlop: Lemaradás
A Hátralék oszlopnak tartalmaznia kell az ötletek, hibák vagy üzleti igények prioritási sorrendjét. A kártyanak még nem kell egy csomó részletet tartalmaznia, de elegendő információnak kell lennie, hogy a csapat tagjai megértsék, miért fontos.
2. oszlop: Tervezés
Ebben az oszlopban egy termékmenedzser kitölti a szolgáltatás specifikációját, üzleti találkozókkal, mérnökökkel és tervezőkkel megbeszélve. Amikor készen áll, áthelyezi a „Készen áll a tervezésre” oszlopba.
3. oszlop: Készen áll a tervezésre
Ebben a szakaszban minden kártyának részletes specifikációval kell rendelkeznie. Noha továbbra is kérdése lehet a műszaki részletekkel kapcsolatban, az üzleti követelményeknek egyértelműeknek kell lenniük.
4. oszlop: Folyamatban van
Bármikor áthelyezheti a kártyát a „Folyamatban” elemre. Ez az önvezérelt „húzórendszer” a személyes elszámoltathatóság és a kíváncsiság kultúráját építi fel.
5. oszlop: Vizsgálat
Miután befejezte a kártyán végzett munkát, vigye a „Testing” -be, ahol egy másik mérnök (vagy valaki a QA-csapatban) felveszi azt.
6. oszlop: Telepített
Egy másik meghatározó tulajdonság az, hogy a munkát folyamatosan át kell adni egy átmeneti vagy produkciós környezetbe. Ez az oszlop lehetővé teszi a csapat tagjai számára, hogy megtekintsék a nemrégiben kiadott munkát.
Az előnyök és a kompromisszumok
Amikor a Kanban és a szokásosabb módszertan, például a Scrum vagy a vízesés között döntesz, tartsa szem előtt ezeket az előnyöket és kihívásokat:
Előny: Javítja az együttműködést
Néhány fejlesztői csoportban, ahol dolgoztam, a mérnökök szakemberek voltak. Mindegyik csapatnak lenne pár frontend mérnöke és backend mérnöke. Ez azt jelentette, hogy a munkát gyakran blokkolták, mert egy mérnök valami másval volt elfoglalva.
A Kanban viszont korlátozza a folyamatban lévő munkát és visszatartja az akadályokat. Minden csapattag egyszerre csak egy tárgyon dolgozhat, és bárki, aki nincs elfoglalva, húzza a munkát a „Készen áll a tervezésre” oszlop tetejéről. Ez ösztönzi a mérnöki generálokat és a csapat tagjai közötti együttműködést.
Növelje az előnyt: Ne hagyja, hogy a dolgok elhaladjanak, még mielőtt készen állnának
A Kanban csak akkor működik, ha arra vár, hogy a kártyákat a következő oszlopba mozgatja, amíg azok teljesen el nem készülnek. (Bónusz: Ez nagymértékben minimalizálja a hibákat.)
Kihívás: csökkenti a reflexió idejét
Alapértelmezés szerint nincsenek egyértelmű célokkal, dátumcélokkal és kiadási ciklusokkal ellátott időzített sprint. Ehelyett gondoljon minden kártyára mint önálló munkadarabra, amelyet bármikor el lehet készíteni és kiadni.
Ennek a folyamatos munkafolyamatnak köszönhetően nincs „várjon a következő sprintre” opció. Folyamatosan ellenőrizze a táblát, húzza a következő elemet, és a kész elemeket mozgassa lefelé. Ha nem állít be időben a visszamenőleges lehetőségeket és az átállásokat, akkor a csapat tagjai számára nehéz lehet, hogy lépést tartsanak azzal, ahogy vannak.
Kerülje körül: Hitelt, ami működik a Scrum-ból
Napi standupekat és retrospektívákat használtam a Kanbannal, és megállapítottam, hogy ezek hozzáadott értéket jelentenek. Ha vannak rendszeres találkozók vagy minták, amelyek a csapatod számára működnek, ne változtassa meg úgy, hogy dogmatikusan tartsák be a Kanban-t. Költségvetési idő, hogy beszéljünk a prioritásokról és azok megváltozásáról, hogy mindenki tudja, mi történik a termékfejlesztési ciklusban.
Előny: Növeli az átláthatóságot
Minden fejlesztőnek kezdeményeznie kell a kártya áthelyezését a „Folyamatban” oszlopba. Ez azt jelenti, hogy a csapat menedzsere bármikor átnézheti, ki van elfoglalva, ki nincs elfoglalva, és hogy mennyi ideig folytatták a munkát.
Amikor a termelés lelassul vagy leáll, a Kanban lehetővé teszi, hogy pontosan megtudja, miért. Akár azért, mert az üzleti csapat nem priorizálta a lemaradásban szereplő tételeket, a termékcsapat még nem fejezte be a specifikációt, a dev-csapat a vártnál lassabban halad, vagy a minőségbiztosítási csapat nem tudott tesztelni valamit; a szűk keresztmetszetek nyilvánvalók.
Növelje az előnyt: hagyja, hogy a haladás nyilvános legyen
Az egyik előnye az, hogy a Kanban nagyon vizuális. Még a nem technikai csoport tagjai is megnézhetik a Kanban fórumot, és megmondhatják, hol vannak a munkák. Használja ki ezt előnyei érdekében, és hagyja, hogy a csapat teljesítménye ragyogjon azáltal, hogy nyilvános helyre állítja a táblát.
Kihívás: Nem engedélyezi a hosszú távú tervezést
A határidőkkel és a becslésekkel való aggódás nem az idő leghatékonyabb felhasználása, ezért felmérheti, hogy a Kanban inkább a napi teljesítményről szól. Ugyanakkor önmagában nem nyújt rendszert egy hosszú távú terv felépítéséhez. Ez azt okozhatja, hogy a projekteknél szórványosan dolgozik, ahelyett, hogy sokáig összpontosítana egy dologra. Nehéz egy napot eltölteni az A projekten, majd egy napot a B projekten, majd visszatérni az A projektbe.
Kerülje körül: használja, amikor a prioritások valószínűleg megváltoznak
A táblában minden oszlop független a többitől, így a csapat tagjai bármikor mozgathatják a dolgokat. Ez bosszanthatja a fejlesztőket egy Scrum beállításban (ahol a sprintre előre becsülik), de Kanban ilyen gyorsan változó környezetben él.
Mindenki szeretne inkább termékeny lenni, de nehéz lehet kipróbálni valami újat, ha nem is biztos abban, hogy hol kezdje. Úgy találtam, hogy a Kanban hasznos, és remélem, hogy hasznos lesz a személyes munkafolyamatához (vagy akár az egész csapatához!).
Küldje el nekem, ha úgy dönt, hogy felveszi!
