6.兩者都是以經驗為依據的 (1)
source: Kanban and Scrum making the most of both, Henrik Kniberg & Mattias Skarin
http://www.infoq.com/minibooks/kanban-scrum-minibook
想像一下, 如果有這樣的儀器, 並且上面有些旋轉鈕, 可以讓你簡單地藉由調整這些旋轉鈕, 就可以調整你的流程. "我要高性能, 低前置時間, 高品質, 和高度可預測性. 所以我將各自地調整它們到 10, 1, 10, 10."
那不是很好嗎? 很遺憾的是, 沒有這樣這麼直接的控制. 這並不是我知道的少, 如果你有發現, 請讓我也知道.
相反地, 我們有一堆間接的控制.
Scrum和看板都是以經驗為依據的, 這個意思就是當你去實驗這流程時, 你會被期待要去客製化它, 以適應你的狀況. 事實上, 你必須要去體驗, 因為不論scrum或是看板, 都不會提供所有的答案 - 它們只是給你一些限制, 以迫使你自己流程的改進.
* Scrum說你應該要組成跨功能的團隊. 所以那誰應該在什麼團隊呢? 不知道, 要實驗看看.
* Scrum說團隊要自行選擇在一個sprint要做多少工作. 所以那應該有多少工作被放進去呢? 不知道, 要實驗看看.
* 看板說你應該限制WIP. 所以那這個限制應該是多少呢? 不知道, 要實驗看看.
正如我前面提到的, 看板是比scrum有著較少的限制. 這意味著你會得到更多的參數來思考, 及更多的旋轉鈕去調整. 這既可以是缺點, 也可以是優點, 但要視你的狀況而定. 當你打開一個軟體工具的建構對話盒, 你會喜歡有3個選項去選, 還是有100個選項去調整? 也許介於兩者之間. 這將取決於有多少狀況你需要調整, 或者你有多了解這個工具.
因此, 如果我們減少WIP的值, 根據假設, 這將會改進我們的流程. 然後我們觀察一下一些事情, 像是效能, 前置時間, 品質和可預測性的變化. 我們可以從這些結果得出結論, 然後改變一些事情, 持續不斷地改善我們的流程.
這裡有很多名稱來形容這件事情. Kaizen(日本話的"改善", 在Lean的行話是持續改進), 檢視 & 調適 (以scrum的行話來說), 務實的流程控制, 或是為什麼不是科學方法
這件事情最關鍵的元素是回饋迴路. 也就是改變一些 => 檢查一下它會怎樣 => 從中學到什麼 => 再改變一些事情. 一般來說, 你會想辦法盡量縮短回饋迴路, 所以你才能很快調適你的流程.
在scrum中, 基本的回饋迴路是sprint. 然而, 如果你結合XP(eXtreme programming, 極致編程)那會有更多的回饋:
當事情被做的正確時, Scrum + XP 會給你一堆很有價值的回饋迴路
最內圈的回饋迴路, 搭檔編程, 它是在幾秒鐘發生的回饋迴路. 錯誤可以在幾秒鐘內被發現以及被修復("嘿, 這變數不是應該是3嗎?"). 這是一個"我們是否把這東西做對?"的回饋迴路.
最外圈的回饋迴路, sprint, 它是一個幾週的回饋週期. 這是一個"我們是否做對的東西"的回饋迴路.
那看板怎麼樣呢? 嗯, 不論你是否使用看板, 首先你可以(也可能應該)把上述所有回饋迴路放進你的流程. 然後看板會給你一些非常有用的即時衡量.
* 平均所需的前置時間. 每次有項目被"做完"時, 會更新這個數值. (或者每當你宣稱已經放到最右邊那個欄位)
* 瓶頸. 典型的症狀是某個欄位X擠滿了工作項目, 而第X+1欄位則是空著的. 尋找出白板上的"氣泡(air bubbles)"
有關於即時衡量最棒的事是, 根據你多久願意分析衡量的結果和作出改變, 你可以選擇你回饋迴路的長度. 太長的回饋迴路, 意味著你的流程改進會十分緩慢. 太短的回饋迴路, 意味著在每次改變之間, 你的流程可能還沒有足夠的時間去穩定下來, 這將會導致不斷的抖動.
事實上, 回饋迴路的長度本身是一件你能實驗的事情, 有點像分析回饋迴路的回饋迴路(meta-feedback loop). 好吧! 我就講到這裡為止.
留言列表
