我的本土客户敏捷项目BA体验（二）

在一段时间的工作后，发现了工作所涉及到的六个方面：

 

Value Miner

找到客户的价值所在。我们相信，客户清楚自己想要什么。而这部分的难点，一是如何引导客户将自己想要的表达出来；二是如何正确理解客户的价值；三是如何保证整个team能够用合理的effort实现这个价值。

而国内的客户，寄希望于开发团队能够提供业务相关的整套解决方案。他们也许知道自己想要什么，但是他们认为，开发团队里的领域专家的意见会更适合他们。换句话说，他们依赖领域专家，领域专家的意见甚至比他们的实际需求更加应该重视。

领域专家的确是可以、也应该依赖的。我们的问题是，我们并不认为，一个开发团队必备领域专家。所以，在项目中，BA充当了一定意义上的领域专家角色。但说实话，这并不是我们擅长的。

Scope Controller

控制需求的范围。这部分看似应属于项目经理的工作范围。但实际情况是，每天都和客户交流的角色是BA，真正去执行需求范围控制的，是BA。

在面对习惯于签订固定价格合同的客户，需求范围控制尤为重要。固定价格意味着固定工作量，但客户需求却是永远不可能固定的。所以，如何在变化的需求中，理解并准确抓住客户真正想要实现的价值，并确保在固定的工作量内完成，且得到客户的认同，是BA必须做好的工作。

Iteration Planner

迭代计划。BA需要配合IM做好迭代计划。BA是整个团队对客户的业务流程、价值理解最清楚的角色。当然，对用户故事的优先级和依赖关系也理解的最清楚，这些是做好迭代计划的基础。

Story Recognizer

识别用户故事。用户故事是需求与实现的桥梁。根据用户故事INVEST（独立、可协商、体现价值、可估计、小、可测试）原则可知，好的用户故事在需求上、在实现上都是低耦合高内聚的。这要求BA有一定的技术功底，或者可以顺畅的和Dev一起工作。

AC Writer

理论上讲，BA关注的AC，应该更侧重于该用户故事是否正确的承载了其在业务流程上的功能，而QA所关注的测试用例应该涵盖软件的所有属性（可用行、健壮性、安全性、易用性等等）。实际操作中，无法将二者界定的十分清楚，所以，BA需要和QA一起，完成用户故事的测试以及质量保证。

UI Designer

所谓软件功能，是一定要通过用户接口来体现给用户的。在项目初期，BA往往需要借助Lofi设计图来更好的和客户交流。此时，要求BA至少要掌握基本的UE原则。