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

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

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

问题

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

答案

方案1：

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

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

若是能在评审会上对产品将来的应用作出一点预测，对以后的迭代会有帮助。

方案2：

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

各类解答应该具备预见性，由于所谓软件需求，无非是业务需求在软件中的体现。业务需求不多是没有计划就盲目开展的，所以若能提供预见性的解答，对整个产品将来的方向都会有很大的帮助。

方案3：

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

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

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

方案4：

变敏捷开发为敏捷交付。

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

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

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

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

案例

1. 某银行

在访谈某银行的开发过程时，开发部门抱怨说业务部门的人只能说出零星的功能，并且还常常在变化，致使变动不少。

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

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

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

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

分析

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

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

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

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

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

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