敏捷转型中的看板
Scrumban最初是一種從Scrum向精益看板轉換的機制，現在它已經支持雙方向的轉換，并可以應用到項目和精簡BAU(常規商業運營)工作流。能夠實施Scrum和精益方法的相互轉換自然是很好的。但當你的客戶不具備實踐這些方法的條件時，你如何去幫助他們實現一個靈活的敏捷模型呢？當一個客戶當下沒有使用Scrum、精益看板或者其它任何一種敏捷方法時，他們如何才能從Scrumban這類方法中獲益呢？萬一Scrumban方法關聯的項目或BAU工作流出狀況了呢？你如何去幫助一個“十分努力才勉強運行”的客戶提升呢？
\u0026#xD;\n敏捷咨詢顧問Ian Mitchell認為，成功實現敏捷轉換的第一步是實現透明度，利用好看板。
\u0026#xD;\n\u0026#xD;\n我認為使用一個看板（Kanban board）就可以達到這個效果。在這個看板上，我們用卡片來代表不同工作。團隊選擇的是Scrum方法還是要其它方法并不重要。重要的是這個項目中有這么一塊板子，并且這個板子是可見的。我認為最初階段的目標就是展示現狀…誰都在做什么。在這個階段我不會試圖去推動進程。我追求的只是在板子上進行信息的首次呈現。
\u0026#xD;\n通常，最初人們會認為自己有很多工作要做。現在我將通過標注人們真正做的工作來糾正這一觀點。我們暫且將這些工作都放在“正在進行”狀態欄中，并查出是不是有阻礙它們的事情。我將把內部阻礙與外部阻礙分離開——即團隊自身就可以解決的阻礙、必須依靠外界力量來解決的阻礙。我也標注出開發者認為自己很快就可以完成的工作——貼在待辦欄的第一個。除此之外，我對過程不做其它假設。客戶可以采用“瀑布模式”（waterfall scheme），也可以不采用。
\u0026#xD;\n\u0026#xD;\n對于一個典型的看板，相比于大部分人認為開發者應該做的，Ian對開發者實際做的和開發者期待自己做的更感興趣。
\u0026#xD;\n很明顯，這個階段沒有什么最佳實踐。Ian認為，在看板上不會有在制品（Work In Progress）限制，也不會有對速度以及其它指標的鼓勵、督促或記錄。這是一種有爭議的方法，甚至有些人稱之為“歪門邪道”。很多敏捷指導，包括許多知識淵博的精益教練都提倡在敏捷轉換中首先要嵌入一個好的流程。如果非要使用看板的話，看板排在第二。
\u0026#xD;\nIan舉了實例：例如，Jim Coplien將最近看板的流行看作是Taichi Ohno推動的一場對精益系統的侵吞運動。Coplien認為開發者首先要有一個優化整體流動性的精益流程。他指出：“我們看到有些團隊采用這種濫用的看板方法，將看板作為一種工具或方法，而不是作為一種‘世界觀’，也不事先構建單件流水作業所需的基礎和規律。”Coplien還表示，當最優的實踐嵌入以后，我們甚至可能沒有必要再使用看板了。他提到了結對編程，并認為這種方法是實現單件流水作業的催化劑，也會降低對透明性的需求。“好的結對編程是相當無組織的，”他說，“因為反饋流程是在本地進行的，于是一下子間開發者就不需要文字化的看板了。”我考慮了這個觀點背后的理論依據。不過，我認為看板具有重要價值是因為它可以作為提供透明度的工具，而不是因為它是所謂的系統“世界觀”的一部分。我認為這是為實現成功的敏捷方法所邁出的探索性的一步。你總要從某個地方起步…并且按我的經驗，實現敏捷方法的關鍵是清楚的認識你現在所處的狀態。
\u0026#xD;\n\u0026#xD;\n當然我也看到了一些例外。例如，Jeff Sutherland帶著他的Scrum轉換“休克療法”投身到“過程改進第一”的大陣營中，我也清楚這之后的基本原理。我認為這種方法類似于學習外語時的“全浸入”方法。在我看來這是一項偉大的方法….如果你僥幸能夠成功的話。毫無疑問，“休克療法”可以帶來很棒的結果，而且其它方法可能需要很長時間才能達到這么好的結果。問題是很多客戶——我甚至可以說絕大部分客戶——在采用“休克方法”方法時并不具備很大的吸收能力。這并不是因為缺乏勇氣。一個組織很少進行整個組織的轉換。實際上，你僅可以幫助整個企業中很小的一部分。你可以幫助那些依賴于非敏捷部門并且深受限制的人們，那些持敵對態度的人們，或者那些在與其它部門交涉進程緩慢的人們。看板上貼出的第一組卡片所描述的工作中，有百分之九十以上都將會因為這些依賴性而停滯。認識到這一點，并意識到需要尋求解決辦法已經是客戶所能達到的極限了。所以我認為首要的是展示什么在發生。這也是最初引入看板的原因。我希望可以做到透明度第一，這樣我就可以展示什么在進行。當然當我們想要更好地實現敏捷方法時，我們要改進流程，但這是第二位的事情。
\u0026#xD;\n總結
- 上一篇： 故乡的路：十位少数民族摄影师联展
- 下一篇： 真实，让文学回到原点:关于非虚构写作的思