http://kanbanlean.blogspot.com/

Van pl. WIP-korlát, és emiatt pl. a fejlesztők rendszerint besegítenek a tesztelőknek, ha a tesztelőknél tornyosul a sok feladat. Ez jó.

Több oszlop is van a falon, mint a hagyományos Scrum-táblán.

De megmaradtak pl. az iterációk, és nem mérik az átfutási időt sem, ami szerintem óriási probléma. (Ehelyett a sprintek során teljesített sztoripontok szolgálnak a mérés alapjául.) Az átfutási idő mérésének hiánya miatt (szerintem) nem alakul ki a folyamatos tanulásra való kényszer, és ezért nem hívnám igazából kanbannak. Azt hiszem, ezt hívják Scrumban-nak (sic!).

Hallottam másokat is, akik használják (startupok). Általában tetszeni szokott nekik.

Olyat viszont nem láttam, hogy vki kapásból azzal kezdte volna, hogy az átfutási idő mennyit javult (Pedig azt hiszem, ez az egyik kulcsa a dolognak )

Visszatérve a Kanbanra, egy kérdés: van arról tapasztalatod, hogy valaki/valamilyen cég már ezt (is) alkalmazná? Mennyire terjed ez a módszer és vannak-e eredmények a teljesítmény javulásáról? Egyáltalán, mekkora lehet ennek a “háttere” Mo-on?

Azért nyomozom ezeket, mert mi kipróbáltuk (persze vegyesen a scrummal) és nagyon jól működött! 1-2 scrum elemet feleslegessé tett, pl burn down chart.

Ne haragudj, de nekem a Scrumban nincs projekt menedzser szerepkör. Van ScrumMaster meg Product Owner meg van csapat. Azt meg, hogy helyi szinten ki hogy (nem) tudja összeegyeztetni a menedzsmenttel az agilitást, azzal inkább nem foglalkoznék

A ScrumMaster feladata, hogy segítsen a csapatoknak, ha problémát jeleznek vagy ő maga problémát lát.

Amúgy meg egyetértek, ott a tábla meg a burndown chart, különösebb egyéb adminisztráció nélkül láható, hogy hogy áll a csapat. Bármikor oda lehet menni megnézni, ahogy írtad is.

Jó ez a toyotás történet!

A 2. ponthoz: nem is írtam, hogy a manager (bár nem tisztáztuk, milyen manager, de én a project managerre gondoltam) turkáljon bele a napi munkába, csak azt, hogy ha akarja, simán tudja összesíteni és rögzíteni akár napi szinten is a haladást, elég csak körbenézni a Scrum (vagy akár Kanban – ez a téma is megérne 1-2 misét) táblákat. Ezzel nem zavarja a munkát, egyáltalán nem szól bele és elkerülhető, hogy a Scrum csapat mindenféle tool-okban vezesse, hogy mit csinált, mennyit dolgozott és éppen mennyi az agynyomása. Ugyanakkor gyorsabb a feedback a PM számára, mintha csak sprintenként látna valamit. A gyors feedback mindig jó. A még gyorsabb még jobb.

De az scrum témából az egyik legjobb, hogy mindig fejlődni kell és persze lehet is. Magát a scrumot is meg lehet reformálni, ha bizonyos problémákba ütközik az ember adott projectben.

Nemrég olvastam, hogy a Toyotánál látogatást tett 1-2 nyugati fejes, és csodálkoztak, hogy semmit nem látnak abból, amit a LEAN-ről és a SCRUM-ról leírtak a különböző könyvekben. A japók meg nem értették, mi a probléma, hiszen a kaizen elv szerint (continuous improvement) egyszer minden elavul és lekerül a napirendről…;)

Egyelőre még nem gondolkoztunk azon Csutival, hogy belekezdjünk egy újabb fordításba, de ha úgy alakul, akkor megkereslek!

1. Abszolút igazad van, ez szerintem is a leghelyesebb attitűd, amivel hozzá lehet állni a problémához.

2. Ha már Scrumot csinálunk, akkor a menedzser (alaphelyzetben) ne kotnyeleskedjen bele napi szinten, hogy áll a csapat. A csapat a sprintre kötelezte el magát. Minden sprint végén látható, hogy mennyi teljesült és mennyi van még hátra a product backlogból. Látható, mennyi a csapat sebessége. Ehhez nem kell a falat elektronikus formában vezetni.

3. Itt is igazad van. De erről a részről most nem írhatok részletesen. Az a szennyes kiteregetése lenne, ami nem illik

1. a logokat lehet egyrészt rendbetenni (írtad, hogy általában katyvasz), másrészt deploy (install, telepítés) után elemezni valami szkripttel, hogy minden oké-e és ha nem, akkor az a build (verzió) mehet a kukába (nem szabad publikálni), a villogót meg bekapcsolni a lava lamp-on szép pirosra, hogy valamelyik managernek (jobb esetben az egész csapatnak) kiégesse a retináját és azonnal javítsa – máris meg van oldva az automatikus deploy hiba ellenőrzés, se fejlesztő, se tesztelő nem kell hozzá
2. a feladatok nyilvántartása elektronyos formában azért lenne jó sokak szerint, mert akkor könnyebb őket összegeznie a roppant elfoglalt vezetőségnek és még feljebb reportálni, hogy ennyit és ennyit haladtunk – más kérdés, hogy ezt egy élelmes manager úgy is megteheti, ha napi szinten (vagy kétnaponta) körbesétál az egyes csapatok tábláihoz és 10 perc alatt összeszedi ezeket az infókat, ráadásul még mozog is egy kicsit (go and see!)
3. sztem ha vki olyannal találkozunk, aki ragaszkodik a rossz megoldáshoz, le kell vele ülni és bevonni a megoldásba – azaz, átrántani a másik oldalra és érdekeltté, motiválttá tenni. Hogy ez kinek a dolga nálatok, azt persze nem tudhatom…:)

Vannak további fordítási tervek? Pl:

http://www.infoq.com/minibooks/priming-kanban-jesper-boeg

Akár még segítenék is.

A könyvön nagy nehezen átrágtam magam. Nagyon sok ismétlődés van benne és hosszú, de nagyon jók benne az elvek és a gondolatok. Sok eszközt is megemlít. Egyfajta referenciakönyvként használható. Szerintem alapmű lesz, de jó lenne belőle egy max. százoldalas változat, amit mindenki el bír olvasni.