通过利用“业务映射”来构建敏捷组织

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）相关内容了，而我们接下来要做的事情还有很多。