Kanban a Sysadmin munkakörben?

Vélemény

Igen, nálunk bevált
13% (18 szavazat)
Nem sysadmin körbe tartozik
10% (15 szavazat)
Csak az eredmény érdekel
35% (51 szavazat)
Nem tudom
42% (60 szavazat)
Egyéb, leírom
0% (0 szavazat)
Összes szavazat: 144

( sj | 2017. 03. 15., sze – 13:09 )

akar pro, akar kontra lehet ervelni a kanban vs. sysadmin relacioban, felteve, hogy ertelmesen csinaljak...

Milyen érvek lennének ellene?

A Kanban az 3 szabály:
1) legyen látható, hogy mi történik. (Pl. két helyen, ahol dolgoztam (nem Kanban volt), whiteboardra írta fel reggel a főnök, hogy mik az aznapi feladatok, aztán ahogy haladt a nap, áthúzták azt, ami kész volt). Ez szerintem jó. Van valami hátránya?

2) korlátozni kell a Work In Progress-t. Ennek megvan a maga elmélete. Onnan jön, hogy ha az ember mindent félbehagy ha nehézséggel találkozik, és valami újba kezd, akkor soha semmi nem lesz kész. Az, hogy idővel a dolgokat csak be kéne fejezni, az szerintem jó ötlet. Nem feltétlenül WIP limittel (de persze WIP limit nélkül már nem Kanban). Van olyan szituáció, ahol ez gondot okoz? (Mondjuk azon kívül, hogy a ticketek nagy részét valami külső dolog blokkolja)

3) egy kis adminisztráció: mérjük, hogy mennyi a várakozási idő, mennyi az átlagos feldolgozási idő. Ennek az a célja, hogy ötleteket ad, hogy mit lehetne/kéne javítani, hogy nagyobb legyen az áteresztőképessége a rendszernek. Itt megint nem nagyon látom, mi lehet kontra érv. Van egy nagyon kicsi extra adminisztráció, pl. amikor az ember felvesz egy új kérést, rögzíteni kell, melyik napon érkezett. Ez lenne a gond?

A 2est egyébként lehet alkalmazni a bejövő oldalon is (nyilván akkor nem wip limitnek hívjuk, de az mindegy), amivel rá lehet kényszeríteni a mindenféle stakeholdereket, hogy prioritizáljanak, és ne a teamnek kelljen. Van olyan szitu, amikor ez kifejezetten hasznos tud lenni.

(Külső blokkra meg épp lehet külön statust csinálni, ha nagyon olyan a szitu).

---

Szóval csatlakoznék, szerintem a kanban jó, csak arra kell figyelni, hogy a szokásos agile megmondóemberek formához való ragaszkodását helyén kell kezelni. Mindig jól elmondják, hogy mert az fontos, hogy vizuális, meg izé, meg tábla, holott maga a processz szerintem sokkal fontosabb, az, hogy szintes cetliket tologatunk balrú jobbra, ezeket esetleg fennrű le, ne adj isten egyszerűen csak használunk random ticketinget így, az szerintem tök másodlagos. Értsd, nem teljesen lényegtelen, van olyan banda, ahol segít a klasszikus board, van, ahol tök mindegy, és van, ahol konkrétan zavaró, mert az emberek jobban átlátják egy klasszikus listás dologban.

Meg egyébként is józan ésszel kell, értsd, hogy mi mért van, és kell-e az neked úgy. Ha nem, akkor teljes lelki nyugalommal le lehet fosni, hogy valami megmondó ember veri az asztalt, hogy de annak muszáj úgy lennie.

Igen, ha a külső blokk egy olyan probléma, amin az ember nem tud segíteni (pl. várni kell, hogy a user válaszoljon, vagy teszteljen, vagy akármi), akkor én ezt külön venném egy Blokkolt pool-ba, hogy ne egye meg a WIP limitet.

Ahogy én értelmezem, a WIP limit igazából mindenképp a bejövő oldalon limitál: pull rendszer van, és nem húzhatsz be újat a bejövő oldalról.
Vagy milyen más lehetőség van még?

A priorizálás szerintem ezektől mindtől független, és hát nélküle teljesen mindegy, hogy kanbant használnak vagy bármi mást, nem lesz túl jó.

Ha nagyon sok az elvégzendő, akkor tud segíteni egy előszűrés abban, hogy mi legyen a következő. Azt a problémát tudja orvosolni, hogy mikor valaki eljut oda, hogy behúz egy újat, akkor ne 30 taskból kelljen neki választani valamit, és aztán hallgatni a többi 29 ownerét picsogni, hanem kikényszeríti, hogy a management értelmesen előkészítse a dolgokat. Ezt természetesen lehet másképp is kezelni (mondjuk ha elve normálisan van a backlog), és nyilván, nem oldja meg azt a problémát, ha folyamatosan több a (valódi) fóka, mint az eszkimó, amiért jó, az az, hogy ezzel a csapat mint olyan tudja kikényszeríteni, hogy ne rajtuk csattogjon, hogy ez nincs meg, és ehhez nem kell folyamatos személyes konfrontációt tartani. (Illetve azt a helyén tartja, anyázzanak csak a stakeholderek róla egymás közt)

/Egyébként ez a másik tök zárójeles, de én abban sem feltétlen hiszek, hogy majd a user pullolja. Kanbanozni lehet úgy is, hogy valaki dispatchel./

( hnsz2002 v | 2017. 03. 16., cs – 08:43 )

Rágugliztam, hogy miaz...
--
"Sose a gép a hülye."