敏捷开发一千零一问系列之六：业务人员怎样参与开发？

这是敏捷开发一千零一问系列的第四篇。（之一，之二，之三，问题总目录）

有一次课程上居然来了一个非开发人员，他是个网站的业务人员，提出了这个问题，并被评为课堂最佳问题之一。

问题
一线业务部门应该怎样具体参与到敏捷开发中来？

答案
方案1：

敏捷开发中有很多活动是需要业务部门参与的，如果没有时间，第一个要参与的事情是“评审会”，就是阶段性验收产品的会议。在会上应该思考产品在实际应用中是否可用，并提出改进意见。

但是要注意改进意见不要急于实现，而是应该询问下一步原来的计划，或许原来的计划更加重要。

如果能在评审会上对产品未来的应用做出一点预测，对之后的迭代会有帮助。

方案2：

如果能选出一个代表，参与到计划会中，对于产品经理难以解答的问题给出补充解答，是一个更好的活动。

各种解答应该具有预见性，因为所谓软件需求，无非是业务需求在软件中的体现。业务需求很少是没有计划就盲目开展的，因此若能提供预见性的解答，对整个产品未来的方向都会有很大的帮助。

方案3：

将业务架构、商业计划转达给开发人员。

技术架构实际上是业务架构的体现，比如360，其业务从最开始就没打算局限于杀毒，所以业务部门就可以提前告诉开发组，当有一天要开发聊天、安全桌面、安全浏览器的时候，开发组并不需要把一个杀毒软件“重构”成一个聊天软件，这是不可能的。

对于产品研发，业务部门若能将市场定位、商业计划、竞争对手等信息充分与开发人员沟通，可以有效地避免闭门造车、缺乏预见性、变更频繁等情况。

方案4：

变敏捷开发为敏捷交付。

敏捷交付是最近的一个热词，其核心是真正地次第地交付产品。

在以往的开发中，比如微软、Nokia，都是做敏捷开发、持续集成的高手，但是他们的产品都不是“敏捷交付”的，都有巨大的版本和断代存在，而销售模式也是工业时代的模式：一次付款，不退不换。

在新兴的企业中，比如腾讯、苹果、Google、Facebook及众多网络游戏，都会感觉到他们的产品不是“一次买来的”，每次使用都可能有所更新（苹果是更新应用），这就叫做敏捷交付。

敏捷交付创造了新型的互动关系，使得“拥抱整个市场的变化”落到实处，而不再是“把可用产品拿给部分用户评价一番”，这将是未来业务架构的趋势。

案例
1. 某银行

在访谈某银行的开发过程时，开发部门抱怨说业务部门的人只能说出零星的功能，而且还经常在变化，导致变更很多。

后来访谈业务部门的时候，业务部门却抱怨说开发部门每次开发的产品都不太符合自己的预想，而且每次增加功能都要“重构”，反应时间较长。

后来又访谈一个“战略规划部”，发现原来业务部门的业务发展，远在一年前就会有详尽的规划，业务部门所提出的零星需求，其实都是基于这些计划产生的。若能与研发部门事先沟通这些计划，开发部门就能充分理解需求的来源、根本目的、未来走向等等客户价值相关的信息，开发出更加好的需求。

战略规划部接受了一个建议：将定期与研发部沟通未来的计划，从而让研发部能看到整个业务的全貌。

实际上在银行这类业务预见性较强的领域，“拥抱变化”不是不断改进核心价值（在互联网则是），而是在确定业务目标的情况下，不断改进具体的实现方法而已。

分析
1. 在很多场景中，业务部门都以“客户”自居（尤其是甲乙方真正的合同关系时），认为摸索、返工这些事情都是开发组的负担，与自己无关（有我）。

但实际上，如果开发混乱，真正受害的无疑是业务人员这些终端用户。因此应该以无我的精神，去帮助那些为自己“交付价值”的开发人员，最终自己也将受益。

2. 从案例中可见，“拥抱变化”和低头走路是两码事

在能看到未来的时候，有时候可以延长Sprint0中做架构的时间，将变化局限于具体业务细化、评审会上改进产品等活动，开发出来的产品反而更好。

人们在“敏捷地”寻找最佳方法的时候，找到的未必是“敏捷的”方法，而是一种相对重型的方法，因为其业务本身是重型的。这是“无住”的一种典型体现。

用副词“敏捷地”来描述敏捷开发的时候，一个问题就成了伪命题：“什么项目（不）适合敏捷？”任何项目，都应该敏捷地寻找最佳方法。