July 22 15:48~16:58
一位朋友告訴Teddy，他們的團隊採用Kanban來分配工作，老闆對於這種模式非常滿意。有一次Teddy去參觀他們的Daily Standup Meeting（每日站立會議，雖然Kanban沒有要求，但是朋友的團隊還是有採行此做法），嚇了一大跳。原來朋友的Kanban，只是PM（專案經理）分派工作的一種工具而已，請參考下圖。
PM從老闆口中「接下聖旨」之後，接著「揣摩聖意」一番，將聖意切割成一個個「工作」，朋友將其稱為之Ticket。因此，切割工作的動作就叫做「切票」，把工作發派給開發人員的動作，就稱為「領票」或「派票」。每一位開發人員，都有一個工作佇列代表這個人被分派的所有代辦事項。PM切好票並確定指派對象之後，這張票就跑到被指派對象的工作佇列中。
Teddy：ㄟ…你們的value stream（workflow）怎麼沒有畫出來？
朋友：喔，我們不管那些細節啦。反正我們的票是交給個別開發人員獨力完成，領到票的人決定怎麼完成都可以，我們不管，所以不需要畫出視覺化工作流程。
Teddy：那…你們的WIP要怎麼定？
朋友：很簡單啊，WIP就訂在每個人身上。一個人同時間最多可以做三件工作，所以每個人的WIP=3。
Teddy：Lead Time怎麼算？
朋友：票進入工作佇列到票被做完的這段時間，就是Lead Time。
Teddy：工作佇列大小有限制嗎？
朋友：有啊，大小和WIP一樣，也是3。只要工作佇列一空下來，PM就可以丟入一張新的票。
Teddy：如果你們的系統出現瓶頸怎麼辦？
朋友：這就是我們聰明的地方，我們的Kanban所對應的工作流程，直接綁定在個人身上。所以如果工作有瓶頸，一定是個人的問題。我們可以藉由「紅蘿蔔與棍子」策略，來激勵員工突破瓶頸。
Teddy：這樣有用嗎？
朋友：效果還不錯，但有時候員工會對這招麻痺。反正新鮮的肝那麼多，用壞掉再換一副就好了。
Teddy：原來你們消除瓶頸的方法就是…直接讓造成瓶頸的那個人消失
Teddy：你們有沒有想過讓開發人員組成一個團隊，彼此互相合作嗎？
朋友：拜託，精實開發就是要消除浪費，難道你不知道溝通就是一種浪費？藉由消除溝通的浪費，我們只要專注在每位員工的績效就好了。
Teddy：你們的員工，好像一顆CPU或是一個Thread喔。
朋友：好了，不跟你聊了，我要去切票了。
***
不斷地切票、領票，小心最後跳票。
***
友藏內心獨白：以上純屬虛構。
那該怎模用？
回覆刪除如果我看Teddy的書，沒有理解錯誤的話。
刪除Daily Standup Meeting是用來報告今天預計進度、昨天實際進度，昨天的進度「預計與實際誤差」的問題。
而文中的「領票」是sprint plan時在做的，領task，在sprint週期中完成task的部份(吧？)
Kanban，是在沒有sprint週期限定時，視覺化task進度的工具。
刪除至於Kanban如何派task，就沒有心神領悟到了。 ^^a
用Daily Standup Meeting溝通，如果還嫌成本太高，而不溝通(也太極端)。
刪除也許他們的PM喜歡工程師幫他做書面報告。(到底是要工程師做ppt還是寫程式呀？)
感謝回覆，Teddy的書我也看過，可能看的不夠深入。
刪除對於這篇文章，我特別感到疑惑的是：
Teddy：你們有沒有想過讓開發人員組成一個團隊，彼此互相合作嗎？
朋友：拜託，精實開發就是要消除浪費，難道你不知道溝通就是一種浪費？藉由消除溝通的浪費，我們只要專注在每位員工的績效就好了。
這樣的缺點在哪裡？那應該怎模做會更好呢？
看板方法藉由限制WIP（降低批量規模）與視覺化價值流（value stream）來觀察工作瓶頸（流動不順暢的關卡）或是造成阻塞的工作流。理想上，造成瓶頸或是阻塞的關卡，可藉由團隊成員（自發性地）互相幫助而排除阻塞。在這種合作與溝通的活動中，形成組織與成員逐步改善的文化。如果把溝通看成浪費，不鼓勵甚至是禁止團隊成員互動，而把工作成敗全部歸咎於個人能力。這樣一來，不但無助於排除阻塞與瓶頸，更會讓開發人員承受過大壓力，長期以往會降低工作士氣。
刪除有人覺得Kanban很好，因為可以在不用改變現況之下，便開始實施，但忽略Kanban的目的之一是要養成團隊持續改善的能力。如果只是把Kanban當成視覺化派工與進度跟催工具，就失去了原先的目的。
感謝Teddy指導，
刪除回饋寫下目前我的理解，再請各位先進指導：
kanban上所有的卡片作是屬於整個團隊要合力完成的。kanban上的每張卡片細到以task/單一團隊成員負責為單位是允許的。當大家看到kanban有某張卡片卡關的時候，所有團隊成員即可自發性地投入該卡片的task，以度過難關。