在需要频繁交付、不断收集用户反馈、拥抱变化、追求业务敏捷的项目中，软件的开发和交付是迭代式进行的。在这样的项目团队中，BA（业务分析师）通常需要在一个开发迭代开始之前完成该迭代开发任务的分析。但在特殊情况下，从收集客户需求到将功能细节传达给开发团队的周期会缩短到一至两天。BA可以用于思考和分析的时间远远少于可以预先做出所有设计的瀑布式项目。

　　那么在这样的敏捷项目中，BA如何能够适应这种交付模式，完成高质量的业务分析，协同团队为客户交付高价值的软件呢？

　　项目背景

　　ABC公司是一家知名的国际性会计师事务所，业务规模庞大，分支机构遍布全球170多个国家。

　　ThoughtWorks受邀对其“全球派遣服务（International Assignment Service）”业务部门提供IT解决方案，以及软件系统的开发。该系统包括收集其客户的全球派遣雇员的报税数据，以及管理ABC公司税务咨询师对这些数据的进行审核、汇算和出具报告的业务流程；逐步替换其目前已远远不能满足业务和性能需求的遗留系统。

　　该系统主要有两类用户，一类是ABC公司客户方被派往不同国家工作的雇员（以下简称Mary），这些雇员使用该系统填入报税需要的数据。另一类用户是ABC公司的税务咨询师（以下简称Kim），负责审核、处理Mary提交的数据。

　　BA在该项目中面临的主要挑战

　　● 该项目为分布式开发，ABC公司的决策方在美国，而ThoughtWorks的开发团队在中国，沟通反馈周期有时较长。

　　● 由于ABC公司对用户体验的重视，需要频繁交付软件，以便收集用户反馈并及时调整解决方案和后续开发计划。这大大缩短了从收集需求、开始分析到进入开发的周期，增加了分析中出现缺陷的风险。

　　● 当开发过程中发现问题时，无法马上与客户取得沟通，开发进度可能会受到影响。

　　识别业务价值

　　业务分析的重要性在于首先做正确的事情。理解客户的业务，关注需求背后的价值可以帮助项目团队在软件的设计方面做出正确的选择。

　　而我们面临的困难是，客户提出的需求，往往都是直接的软件功能，而不是需要解决的业务问题。如果BA只专注于针对客户需要的功能进行系统分析，就丧失了帮助客户优化解决方案以及改进业务流程的机会。

　　如何寻找业务价值？

　　以敏捷开发方法中的用户故事为例，找出客户要解决的业务问题的一个简单办法是，用以下方式概括每个用户故事的内容：

　　As…（角色），I want to…（完成什么样的功能），So that…（解决什么问题，带来什么价值）

　　“So that…”说明了该故事的业务价值，即要解决的业务问题。准确的寻找业务价值将有利于我们设计出最适合的“I want to”，这很可能优于客户直接提出的功能要求。

　　需要注意的是，不要把解决方案或功能当成该用户故事的价值。以ABC公司业务系统中的一个用户故事为例，BA对该需求业务价值的了解程度将直接影响到解决方案的优劣。

　　在该用户故事的两种不同表述中，由于第一种表述只说明了需要的功能，没有说明业务价值，在功能设计时，我们可能会将“行程统计数据”的内容设计的过于详细而造成浪费，使用户不明白此功能的意图。而第二种表述的业务目标就非常明确，可以帮助我们更加容易地设计出适合的解决方案。

　　此外，BA在了解客户的业务问题时，最好请客户提供一些真实案例/场景来证实其观点并加深自己的理解。

　　避免分析错误

　　在实际工作中，我们发现有以下两个方面的分析工作容易被BA忽略，而做出错误的决定。