source: Kanban and Scrum making the most of both, Henrik Kniberg & Mattias Skarin
http://www.infoq.com/minibooks/kanban-scrum-minibook

 

Kanban 的本質是一個很簡單的想法: 同時進行的工作 (Work In Progress, WIP) 必須被限制; 當目前手上工作被完成, 或是下游的工作被拉動, 新的工作才可以開始. 看板(或是訊號卡) 會產生視覺化的訊號, 是因為目前工作量沒到達限額, 所以新的工作可以被拉進來. 這聽起來不是革命性的改變, 似乎也不會影響團隊或組織的績效, 文化, 能力或成熟度. 但很神奇地看板做到了!看板看起來只是小的變化, 但是卻改變商業中的一切.

 

我們意識到, 看板是一個關於變革管理的方法, 它不是軟體開發方法, 也不是專案管理的生命週期或過程. 看板是給現有軟體開發週期或專案管理方法, 引入改變的做法. 看板的原則, 是從你現在做的開始, 藉由分析價值流程來了解你目前的工作流程. 然後在工作流程上的每個階段, 對限制同時工作的量達成共識. 當看板訊號產生時, 藉由拉動工作, 開始讓流程運作.

 

看板對實施敏捷開發的團隊非常有用, 但對於只是傳統做法的團隊也能吸引他們的目光. 在組織文化中要進行精益改造, 和鼓勵持續改進, 看板往往會被導入其中.

 

因為 WIP 在看板中是被限制的, 不管因為什麼原因, 任何被阻礙的任務, 都會對系統造成影響. 如果有足夠多的任務被阻礙, 整個流程將會被停止. 這將會迫使整個團隊, 甚至大到整個組織, 聚焦在此來解決問題, 好讓被阻礙的任務再度流動.

 

看板使用視覺化控制的機制, 追蹤工作流經價值流程的每個階段. 一般來說, 實體白板加上便利貼, 或者是電子看板 是最常被使用. 最好的方式是兩者都用. 它所帶來的透明度將會促使文化的轉變. 敏捷方法某些方面已經提供了不錯的透明度, 像是 WIP, 完成的工作, 以及有關速度的度量報告(也就是每個迭代中完成的工作數量). 然而, 看板更近一步, 提供了流程和工作流動的透明度. 看板會曝露瓶頸, 堆積在每個階段的工作, 變化, 以及浪費. 所有這些因素都會影響組織的績效, 包含所交付的有價值的工作的數量, 以及這些交付工作的交付週期. 團隊成員和外面的利害關係人, 都可以從看板中自己行動(或不做什麼)所帶來的影響. 因此, 早期的研究顯示, 看板可以改變行為, 並且促進在工作場所有更緊密的協作. 當人們看到瓶頸, 浪費, 和變化所造成的影響, 將會促使他們討論如何改進, 並且很快地把改進方案落實到他們的流程當中.

 

因此, 看板鼓勵現有流程以漸進的方式演進, 逐漸地向敏捷和精益靠攏. 看板不要求徹底改變人們的習慣, 而是鼓勵逐步改善. 它的改變是工作者以及和他一起合作的人都達成共識的.

 

由於拉式系統的特色, 看板鼓勵延遲承諾, 不管是新工作優先順序的排序, 或者是現有工作的交付. 一般來說, 團隊同意和上游利害關係人定期開會, 來決定接下來要做什麼. 這類型的會議因為時間短, 所以會經常召開. 在會議上通常要回答一個很簡單的問題. 例如 目前從上次以來我們有兩個空位, 我們交付的週期時間是 6 週, 你最希望在 6 週之後要交付哪2個項目?這個問題有兩個含義: 一個問題可以得到快速且明確的答案, 並且也讓會議很短. 另外, 也意味到了最後時候, 才承諾接下來要做什麼. 透過期待管理, 縮短從承諾到交付的週期時間, 來改善敏捷性. 而且由於優先順序變化的狀況變少了, 所以也減少重工的機會.

 

關於看板我想說的最後一件事, 是限制 WIP 可以讓週期時間變得更容易預測, 並且交付更加可靠. 當出現障礙或錯誤後的停線機制, 也確保高品質的水準, 並讓重工的狀況急劇下降.

 

儘管從書中精彩且清楚的解釋可以證明這些好處, 但是如何做到這樣卻看不出來. 看板並不是在一個下午的時間裡, 忽然間就奇蹟般的頓悟, 它需要幾年才能夠漸漸成型. 許多深層的心理和社會的影響, 對組織文化, 能力, 成熟度的程度所帶來的改變, 是無法想像的, 但是它就是發生了. 許多看板所造成的結果是反直覺的. 看起來很機器化的作法–限制 WIP 和以拉式方法運作–卻對人與人之間的互動和協作的方式, 產生深遠的影響. 不管是我, 或是其他人, 在開始使用看板時, 都沒有預想到這一點.

 

我追求一種最小阻力的變革方法, 就是後來的看板方法, 我在2003 年的時候就清楚明白這點. 一開始我追求的是機械式的效益, 後來在實施精益技術時發現, 如果管理 WIP 是有意義的, 那限制 WIP 就更有意義, 因為它能夠釋放一部分管理的精力. 所以在 2004 年, 我嘗試在最基本的原則裡放入拉式系統. 那時候有個機會, 微軟有個經理找我, 希望我幫他管理內部一個正在做維護升級的 IT團隊. 第一個要落實的就是根據限制理論的拉式系統方案, 也就大家所知的 Drum-Buffer-Rope (鼓-緩衝-繩法). 效果非常棒, 週期時間減少了 92%, 生產力增加了 3 倍, 可預測性(due date performance, 截止日期績效)是非常令人滿意的 98%.

 

2005Donald Reinertsen 說服我去實踐完整的看板系統. 在 2006 年, 我掌管西雅圖 Corbis 公司的軟體工程部門, 因此我有個機會去實施看板. 在 2007 年, 我開始展示實施看板的成果. 在 2007 年五月, 在芝加哥的 Lean New Product Development Summit 中有了第一次簡報. 同年八月, 我接著在華盛頓 DC Agile 2007 大會裡的開放空間會議中也有分享. 那時候有 25 個人參加, 其中有 3 位來自 Yahoo: Aaron Sanders, Karl Scotland Joe Arnold. 當他們各自回到加州, 印度和英國後, 在原先很掙扎實施 Scrum 的團隊中, 去推行看板. 同時他們也成立了一個 Yahoo 討論群組, 在寫這個文章的同時, 已經有了 800 個成員. 看板已經被傳播開來了, 先驅者正在談論他們的經驗.

 

2009 年, 看板的採用率確實在成長, 越來越多一線的報告出來. 在過去五年, 我們在看板上學到很多東西, 並且也持續學習下去. 我現在的重心是在實施看板, 記錄看板, 講解看板, 和思索看板, 這都是為了更好理解看板, 並且和他人解釋. 我漸漸地不再比較看板和其他現有敏捷方法, 除了在 2008 年有花時間解釋, 為什麼看板也算是一種和敏捷相容的方法.

 

看板和 Scrum 比較起來如何這種問題, 我就留給其他比較有經驗的人回答. 我很高興 Henrik Kniberg Mattias Skarin 變成這方面的領導者. 身為這個領域的知識工作者, 你需要一些資訊來決策, 讓你知道要往哪裡走. Henrik Mattias 以我所不行的方式來滿足大家的需求. Henrik 善於全面的比較, 以及他的實事求是與公正均衡的表達方式, 給我留下了特別深刻的印象. 他的漫畫和圖片特別有見地, 可以讓你有一畫勝千言的感覺. Mattias 的實地案例非常重要, 他證明了看板不只是理論, 並且在透過實際案例, 向你展示了對你的組織有什麼用處.

 

我希望你能喜歡這書中對看板和 Scrum 的比較, 讓你更深入地了解敏捷, 尤其是看板和 Scrum. 如果你想要學習更多有關於看板的知識, 歡迎拜訪我們社群的網站: The Limited WIP Society,

http://www.limitedwipsociety.org/

 

 

David Anderson

史魁恩, 華盛頓, 美國

78日, 2009

 

arrow
arrow
    全站熱搜

    kojenchieh 發表在 痞客邦 留言(1) 人氣()