敏捷">软件开发实践的文化中存在着一个断层，该断层同样体现在许多敏捷团队中。这个断层就是业务分析人员在敏捷项目中的角色——谁来担任这个角色？它的作用 和价值是什么？它又是如何发生改变的？这种情况的潜台词（其实我曾至少听人说过一次）就是：“我们不需要什么见鬼的分析师！”。无需赘言，我当然认为这是 大错特错！在本文中，我证明如下观点：只要以正确的方式向业务看齐，业务分析师就可以帮助敏捷团队成功，而不是像大多数情况那样以开发团队为导向。
为什么要有业务分析师这个角色？
我的观点是：没有业务分析人员，就会发生真的断层。举例来说：
谁会注意最大的组织问题？
为了高效工作，用户（可怕的词汇——不过这是另外一个话题了）有自己的需求，而管理层（说到底，他们是为开发软件买单的“客户”）的要求可能与之冲突，谁去识别这种潜在的冲突？
假如现在有1500人以目前现有的方式工作，如果我们实施了新的软件之后，他们的工作模式会发生很大变化，谁来发现这样的事情？
当组织的工作流程因为新软件的实施而发生改变时，有些人要负责设计新的工作流程，以保证业务可以继续顺利运转，那么谁来帮助这些人？
与客户交互不当产生的潜在业务损失，谁来发现？
我可以继续举例，不过我想你应该有概念了。
在Agile 2008大会上，Alan Cooper做了一个很棒的演讲，他热情洋溢地提到：敏捷项目中需要包含互动设计的工作，要有人能够理解人的行为、而且可以确保相关的产品能够在现实世界中有效工作。
我的观点是：最理想、最有效的做法，是由业务分析师承担这个职责；而且我们应该一直这样做。我们接受培训，部分上也是处于这个目的：理解更广泛的业务需求，并向负责技术的团队以他们可以理解的方式解释这些需求。一直以来，业务分析师一直充当客户需求的守护神。
业务分析师可以帮助团队成功
我 坚信：对业务分析师角色的轻视，是如今众多敏捷团队的严重问题。在很多组织中，由于缺乏组织架构和管理层的支持，分析师的职能被削弱了，他们无法完全体现 自己的价值。业务分析师应被视为客户的代言人，并加入以业务为核心的解决方案提供团队，而不是技术的提供者。在面对问题时，业务分析师能够带来不同的视角 和理解，因此他们应该被授以足够的权力、信任和感谢，他们应向负责业务改进的人员和部门报告自己的工作，而不是去报告给信息技术团队。在这样的组织结构 中，业务分析师将会给予足够的权限，以提升业务价值为明确目标，推荐项目的变化向这个目标努力；而不仅仅只是作为技术团队的一部分，被看做“技术的跟屁虫 ”。
那系统分析师又该如何？
注意这里的区别：我们所说的是业务分析师，而不是系统分析师。“系统分析师”是干什么的？虽然在多数情况下，系统分析师的技能足以有效地完成业务分析相关 的工作，我还是要区分开这两个角色，因为他们的角度不同——业务分析师的重点放在对业务需求的理解之上，并受其驱动；而系统分析师却常常从相反的角度考 虑，他们主要思考基于技术的解决方案，有时提出的方案甚至不利于真正解决业务问题（“Wow，我已经告诉你解决方案了！”）。系统分析师可以成为好的业务 分析师，但是他们一定要小心，必须压抑自己提出技术建议的冲动。
要业务分析师干什么？我们需要“客户”
业务分析师愿意花时间去接近 不同的“利益相关者”，也就是那些代表公司或组织、关心业务变更成功交付的人。业务分析师要理解多种不同维度的业务需求；与管理层讨论总体方向和目标；法 务部门一起工作，看看新的或是变更后的业务流程会产生哪些法务上的影响；跟后勤部门一起工作，识别办公空间或仓库布局的变化，理解流程变化对于物流、产品 直到发货过程的潜在影响；还要跟行政人员一起，搞清楚新的审核过程可能造成哪些潜在的瓶颈……以及诸如此类的事情。