跑看板要不要把 Story 拆解成 Task?
我不是看板專家，可是有一位看板專家 Ruddy 老師當我的同事，所以今天被指正了一個錯誤，我有點嚇到原來我之前的認知是錯的，但很爽。
這題很吃 Context
原本的團隊運作看板方法是：我們有一個產品，有一個
PO，有一個團隊。PO 很棒棒的把他想做的東西寫成了 User Story 的形式，所以大小也很不錯，是可以在一個 iteration
內(兩個禮拜)完成好幾個 Story 的大小。PO 會把這些 Story 排序在看板的 ToDo 欄位上，團隊就一個一個拿過來做。
第一個
column 是 Analysis，拿過來的 Story 會先在這邊待一陣子，跟這個 Story 相關的人會討論這個 Story
該怎麼施工。這件事通常在 standup meeting 之後發生，然後隨時互相更新進度，隔天的 standup meeting
再一起看一下這個 Story 的狀況，隨時都可以去移動 Story 的 post it。
這個團隊開始跑看板半年以來，沒什麼問題，我也覺得這樣還蠻敏捷的呀。
可是，某一天有一個
Story 有點卡了久了一點，PO 一片好意地想幫忙，就問說這件 Story 現在狀況怎樣。可是在看板上他看不到，他只能看到這個 Story
在這個欄位停了很久，所以他請團隊能不能把 Story 拆成 Task，這樣其他人、或是 PO
自己都可以想辦法幫忙，然後團隊就回說：那個頭髮捲捲又沒什麼下巴的王泰瑞說「請相信團隊的自我管理」，「跑看板不用拆 task」
(對，我真的這樣說過)。
然後就有這題了，我們就跑去問 Ruddy 老師，老師就說拆啊。
原因大概是因為，把 task 拆出來，團隊的其他 member 才有機會去幫那個人的忙、才能透明的呈現現狀，要追蹤也比較好追蹤。
正確。
PO 進步了。
以前啊，PO
還叫做 PM 的時候，他會 assign 事情給 team member：「你去做 UI」、「你去開 API」、「你你你去設計
DB」等等，PM 都在關注 task level 的事情，然後整個事情就變成很糟的
micro-manage，團隊就變得了無生氣了。
我們導入敏捷以後，把 PM 改名為 PO
(其實只是改個名字，沒什麼意義，但做就做了)，然後用各種方法，請 PO 去關注產品的價值；而不是每個人在忙什麼，也不是把團隊看成 CPU，一直去看
utilization。 PO 應該做的是關注 Story 有什麼價值，而不是 task 層面的事情。
所以我這樣安排團隊，在看板上只看得到 Story，而沒有 task，這樣 PO 就不會一直來煩團隊，什麼什麼 API 開了沒，APP 那邊接得怎麼樣了。他可以把注意力放在 Story 的流動上。
這個 PO 在經過一段時間後，他做到了，而且做得很好。
所以，他發現某一個 Story 推進得很慢，他想要幫忙，他希望能關心一下團隊。他的做法不是像以前，說「乾～我不管喔，我們X月X號前這個就是要做完，你們不做完，我就去 escalate 給你們主管喔～」。他的做法是提醒開發團隊，他主動地伸出了支援的手。
開發團隊傻傻的
可是，開發團隊卻跟他說「跑看板不用拆 task」，就…傻傻的。
任何事情跟做法，只要能夠幫助提升透明度，幫忙團隊開發，幫助交付，就應該做啊！假如把
task 拆一下，有機會能從卡關的狀態中盡快跑出來，就做了啊！不應該是因為：泰瑞教官說，標準答案是「跑看板不用拆
task」。囧，你拆了我也不會說，前方大樹看到沒有？30 秒左去右回，稍息以後開始動作，稍息！
以後還是拆一下好了
看板本來就有很大的彈性，要不要拆 task，我覺得都可以，需要就拆，不需要就不用拆。
但站在提升透明度的角度上，還是應該要拆的，有被說服。
要誠實面對自己的錯誤，才能更進步。
…
好吧，我寫這篇只是替自己辯解。XDDD
留言
張貼留言