通過利用“業務映射”來構建敏捷組織

North：到目前為止遇到的最常見的情況就是，在某些情況下問題的解決方案已經在一些細節上達成了一致，甚至是在交付日期迫在眉急的節骨眼上，他們卻還想要使用敏捷方法從頭到尾重做，可想而知，這只會給功能的故障報錯顯示、軟件測試以及整個流程帶來更加復雜的流程。這就是俗稱的Water-Scrum-Fall（通常被描述成一種混合的敏捷工作方法），意即即使開發流程結束了，無論是前期的分析，還是后期的發布管理都在整個流程里起重量級作用的，更不能拖累產品的發布時間。

因為“敏捷”過程是完全和業務脫離的，所以從事敏捷開發的人們對于產品拖延發布已經見慣不怪了。在過去，開發團隊的老成員們常常是把這些事情交給一些剛入行的開發者來做，自己就在那等結果。而現在，他們要做的項目太多，需要兩周的時間來評估，剩下的幾個月完全在沖刺，只不過到最后環節項目流產也是常有的事情。更具諷刺意味的是，某些開發者的“敏捷經驗”就是拖延交付，將流程和開銷復雜化，導致工作效率差距很大。這就是當你沒有徹底理解敏捷方法和原則目標的時候盲目使用這一手段的常見弊端。

North：這是一個很有趣又很矛盾的現象。真正起到阻礙因素的是是否協作部門之間都愿意采納敏捷方法，而不是IT部門或業務部門之間的問題。要想解決這個問題，就得從內部的產品交付團隊和傳統的管理部門入手，就像項目和項目經理這樣的關系一樣。

North：業務映射是一套我和Chris Matts共同開發的技術的概括性術語總稱，他是一個投資和產品管理大師，之前還是一名商業分析師。我們曾經一起在ThoughtWorks共事10年，那個時候我們一起合作開發BDD（Business-driven Development業務驅動開發），以至于到現在還保持著聯系。直到一年前，我們才意識到我們共同獨立開發了非常相似的模型來進行縮放式開發。他是從組合層面內入手，有一個1500人左右的團隊；而我的500人團隊主要是從程序層面入手。目前，我們通過各自手里掌握的數據點，從兩個技術尺度找到了突破點。

去年我們花了很多時間和精力在對外闡明各種活動和技術的選擇上，這些動作都表明對業務敏捷性其作用的是以風險為基礎的方法，而不是常見的基于控制的方法。業務映射運用約束理論來公開不確定性和創造交付選項，而不是通過假設的方式提供約束和解決能力。

North：這要從頂部主動映射（Initiative Mapping）開始說起，主動映射是和關鍵業務驅動相并行的。然后，在一個主動映射的過程中得用到一個稱之為“需求映射（Demand Mapping）”的程序，這個程序能夠識別出并大致知道需要多大的業務能力來驅動主動映射。當然，作為輕量級的規劃項目，團隊應該有能力來確定技巧和能力的約束條件有哪些。在人們看來，一種被稱作為能力映射（Skills Mapping）的行為能夠搞清楚當前人們的能力和所期望的能力能做些什么成果，需要學習哪些新的技能，如何解決約束問題等需求。

最終的交付映射（Delivery Mapping）是一種有效組織團隊成員工作的方式，幫助優化開發流程和學習過程。這取決于對技能的需求程度，工作進度可以根據稀缺技能進行改期或重組，或者人們可以相互之間傳授技能，這樣也可以有效控制并平衡技能短缺的難題。這種方法，稱為技能流動性（Skills Liquidity），是一種新的替代傳統資源的均衡技術。

North：目前我和Chris還沒寫過這方面的書籍，但是我們打算記錄我們覺得有價值有幫助的內容，最初可能會在電子書出版發布平臺LeanPub上呈現出來。其實網上有很多在線課程講解需求映射（Demand Mapping），Chris 也早已在博客里分享技術流動性（Skills Liquidity）和實物期權（Real Options）相關內容了，而我們接下來要做的事情還有很多。