敏捷合同-摘自网络

敏捷软件开发实践的文化中存在着一个断层，该断层同样体现在许多敏捷团队中。这个断层就是业务分析人员在敏捷项目中的角色——谁来担任这个角色？它的作用 和价值是什么？它又是如何发生改变的？这种情况的潜台词（其实我曾至少听人说过一次）就是：“我们不需要什么见鬼的分析师！”。无需赘言，我当然认为这是 大错特错！在本文中，我证明如下观点：只要以正确的方式向业务看齐，业务分析师就可以帮助敏捷团队成功，而不是像大多数情况那样以开发团队为导向。

为什么要有业务分析师这个角色？

我的观点是：没有业务分析人员，就会发生真的断层。举例来说：

• 谁会注意最大的组织问题？
• 为了高效工作，用户（可怕的词汇——不过这是另外一个话题了）有自己的需求，而管理层（说到底，他们是为开发软件买单的“客户”）的要求可能与之冲突，谁去识别这种潜在的冲突？
• 假如现在有1500人以目前现有的方式工作，如果我们实施了新的软件之后，他们的工作模式会发生很大变化，谁来发现这样的事情？
• 当组织的工作流程因为新软件的实施而发生改变时，有些人要负责设计新的工作流程，以保证业务可以继续顺利运转，那么谁来帮助这些人？
• 与客户交互不当产生的潜在业务损失，谁来发现？
• 我可以继续举例，不过我想你应该有概念了。

在Agile 2008大会上，Alan Cooper做了一个很棒的演讲，他热情洋溢地提到：敏捷项目中需要包含互动设计的工作，要有人能够理解人的行为、而且可以确保相关的产品能够在现实世界中有效工作。

我的观点是：最理想、最有效的做法，是由业务分析师承担这个职责；而且我们应该一直这样做。我们接受培训，部分上也是处于这个目的：理解更广泛的业务需求，并向负责技术的团队以他们可以理解的方式解释这些需求。一直以来，业务分析师一直充当客户需求的守护神。

业务分析师可以帮助团队成功

我 坚信：对业务分析师角色的轻视，是如今众多敏捷团队的严重问题。在很多组织中，由于缺乏组织架构和管理层的支持，分析师的职能被削弱了，他们无法完全体现 自己的价值。业务分析师应被视为客户的代言人，并加入以业务为核心的解决方案提供团队，而不是技术的提供者。在面对问题时，业务分析师能够带来不同的视角 和理解，因此他们应该被授以足够的权力、信任和感谢，他们应向负责业务改进的人员和部门报告自己的工作，而不是去报告给信息技术团队。在这样的组织结构 中，业务分析师将会给予足够的权限，以提升业务价值为明确目标，推荐项目的变化向这个目标努力；而不仅仅只是作为技术团队的一部分，被看做“技术的跟屁虫 ”。

那系统分析师又该如何？

注意这里的区别：我们所说的是业务分析师，而不是系统分析师。“系统分析师”是干什么的？虽然在多数情况下，系统分析师的技能足以有效地完成业务分析相关 的工作，我还是要区分开这两个角色，因为他们的角度不同——业务分析师的重点放在对业务需求的理解之上，并受其驱动；而系统分析师却常常从相反的角度考 虑，他们主要思考基于技术的解决方案，有时提出的方案甚至不利于真正解决业务问题（“Wow，我已经告诉你解决方案了！”）。系统分析师可以成为好的业务 分析师，但是他们一定要小心，必须压抑自己提出技术建议的冲动。

要业务分析师干什么？我们需要“客户”

业务分析师愿意花时间去接近 不同的“利益相关者”，也就是那些代表公司或组织、关心业务变更成功交付的人。业务分析师要理解多种不同维度的业务需求；与管理层讨论总体方向和目标；法 务部门一起工作，看看新的或是变更后的业务流程会产生哪些法务上的影响；跟后勤部门一起工作，识别办公空间或仓库布局的变化，理解流程变化对于物流、产品 直到发货过程的潜在影响；还要跟行政人员一起，搞清楚新的审核过程可能造成哪些潜在的瓶颈……以及诸如此类的事情。

分析调研进行到某个时间点时，我们会发现：要解决某个业务问题，就得在技术上想办法。此时，业务分析师的角色会有点变化，我们要加入到技术可行性的讨论之 中，要决定是“构建vs购买”，或是决定内包还是外包。在这个阶段中，传统的业务分析师就会参与业务案例的制定，组织在实施敏捷时可以借助这些案例；至于 对项目的判断，要看它们能够为组织带来哪些业务上的好处。如果没有这个价值取向，为了管理敏捷待办事项列表而正在进行的优先级排定工作，可能就会缺乏对项 目愿景的全面理解，从而导致需求出现问题。

上述决策确定之后，而且组织也打算在技术上投入一定资金，此时业务分析师的角色就又变了，成为了需求的 看护者、用户故事的收集者和指导者。业务分析师也是在此时积极参与到敏捷项目中，并成为敏捷软件开发项目团队的重要成员，代表客户和最终用户，并与其他团 队成员协作，以达成明确的业务需求，使其受益于基于技术的解决方案。

业务分析师与项目团队一起工作，保证用户故事的正确实现。对于团队来说，他们是客户的代言人，推进用户故事的详细说 明。在面对更广泛的利益相关者群体时，他们充当项目的代言人，负责在正确的时间将客户正确的声音传达给项目团队。一般来说，这里的“客户”，在很多敏捷相 关的文化中都有提到，并不是一个单一的个人，而是表示很多“利益相关者”构成的群体。这群人构成多样，经常意见相左，互相角力，有时甚至彼此敌对。他们对 于业务需求和“完成”的定义经常充满分歧。

看完上面这段话，你是不是觉得我不相信“现场客户”的作用？绝 对不是！我120%地坚信：敏捷开发过程要想成功，我们必须有现场客户。我们所面对的挑战在于：有太多不同客户的声音，经常向团队发出彼此冲突的命令。在 整个项目中，业务分析师必须随时能够从这些“噪音”中过滤出有用的信号，并识别出那个时刻哪个客户适于作为代表。

那么业务分析师到底是干嘛的？

在 敏捷项目中，业务分析师也是用户故事的守护者。他们会引导发现过程，并促进团队之间的沟通，通过提出“如果……会怎么样？”之类调查性的问题帮助客户代 表；而这些问题来自于他们对项目发端因素的广泛调查， 对于利益相关者群体的印象，以及对于组织正式结构之下错综复杂的政治和人际关系的理解。他们还有能力接触出资方，争取机会访问真实的客户（这些人是真正为 系统提供的服务付钱的人），知道应该怎么做才能形成竞争优势，让客户满意，并最终让组织取得商业上的成功。

业 务分析师要广泛掌握调研和人际交往技能，掌握使用批判性思维和怀疑思考的能力，还要使用多种多样的建模技巧和其他工具，帮助客户代表发现构成系统的故事范 围。业务分析师还能帮助客户代表用清晰易懂的方式表达这些故事，从而让“完成”的含义一目了然，同时与测试人员和客户代表共同工作，帮人们看清用户故事必 须要具备的验收条件。

最好的业务分析师会参与故事各个方面的讨论，并积极加入到系统的交互设计过程中。他们深刻理解用户群体与系统交互的多种方式，知道不同需求之间的分歧，并可以平衡这些分歧，让系统在设计上满足不同利益相关者的要求。

敏 捷业务分析师也是设计师，他们对系统的理解远不仅仅是识别和记录需求文档这么简单。他们知道屏幕上的功能流程背后意味着什么，也能保证系统的流程符合人们 实际的工作流程。颜色和字体、屏幕的界面布局和响应时间，这些因素对系统使用者的工作效率会产生哪些影响，敏捷业务分析师都了如指掌。他们寻找一切机会创 建人们愿意使用的、真正实用的系统，并愿意引导开发人员构建符合人的直觉和自然使用习惯的用户界面。在理想状况下，用户界面会让人觉得似乎消失不见了，因 为它们非常易用，操作人员甚至感觉不到界面的存在。

传统的分析方法，希望在弄明白“怎么做”之前先搞清楚要“做什么”。可这不适用于敏捷项目。敏捷开发过程有一种与生俱来的工作方式，就是在一个高效的迭代开发周期之中，我们总是要通过“怎么做”的过程来知道“做什么”。

在处理系统与用户互动的界面工作时，系统的外观和感觉很重要，敏捷业务分析师能将这方面的工作清晰地展现出来，使其得到团队的重点关注。

敏捷业务分析师要确保真正的业务价值得到发掘和展现，他们要跟项目团队和客户代表一起找到这些价值，这可以使得所有人的工作都变得更加简单、高效，同时达成客户的满意度和“粘性”。我们的客户也就会一而再、再而三地跟我们反复做生意。

谁应扮演业务分析师的角色？

在 Scrum项目中，产品负责人或首席客户推广人员最适于充当敏捷业务分析师。因为他们有足够的权力，也能得到相应支持，足以代表客户。这些分析师要积极参 与管理产品待办事项列表，并识别产品功能的优先级。此外，还要构建与业务利益相关者的良好关系，同时理解技术实现的可行性；有了这些作为基础，业务分析师 就可以积极参与项目价值的交付过程。敏捷业务分析师必须要成为业务项目团队的积极成员，还得努力做出贡献；而不仅仅是试着产生一长串带有“应该”之类词汇 的句子；还要代表、放大、守护许许多多客户的声音，提出“你们有没有想过……”这样艰难的问题，从而保证我们交付的产品可以达成客户多样化、相互牵制的需 求；还要基于以往和眼下的用户故事，与整个项目团队一起讨论和互动，以理解并识别缺陷、流程和问题。

业务分析师角色对于项目的成功不可或缺

技术是为了满足人的需要而存在，而不是成为人的需要！ ——Malcolm Watson, 墨尔本Pronto软件公司开发经理

业务分析师人群应该走上前台，成为敏捷协作团队的积极参与者，因为他们力图创建可以交付真正的价值和客户满意度的系统。主动承担“业务分析师”的角色，将 问题拆分成各个组成部分，理解真正的潜在需要，然后成为项目团队的积极参与者；这样交付的解决方案，能够创建出真正的竞争优势，提升客户满意度！

谁是我指出的这些“业务分析师”？

国际业务分析师协会（IIBA）指出：业务分析师“要充当各个利益相关者之间的联系人，从而提炼、分析、构成、验证与业务流程、方针政策、信息系统的变更相关的需求”。

业务分析师要承担“万能沟通者”的角色，以清晰有力的方式理解并表述出不同利益相关者考虑问题的角度，协助业务人员发现模糊的潜在需求并使其逐渐清晰，从而识别出真正有附加值的需求。

这个角色超越了使用的开发方法论，最新版本的BABoK™（Business Analysis Body of Knowledge，业务分析知识体系）明确说明了敏捷相关技巧的价值和重要性，还介绍了业务分析活动在敏捷项目中的变化。

关于IIBA

国际业务分析师协会（IIBA）是一个职业组织，它这样描述自己：“世界领先的业务分析师职业联合会”。IIBA在全球13个国家有78个分部，涵盖44个国家的7128位成员，它的宗旨是：“为业务分析师的实践和相关认证制定并维护相关标准。”

IIBA发布了BABoK™这个知识体系，其中涵盖了作为职业业务分析师应该具备的广泛技能和素质。BABoK™不特定于某种特定的方法论，不过在2.0版本中明确指出了敏捷方法对于开发软件解决业务问题这方面的重要贡献。

IIBA为业务分析师提供了认证计划，称为“业务分析职业认证”（CBAP™），主要基于该领域中经过验证的经验和BABoK™知识领域中的知识。

关于作者

Shane Hastie是Software Education的 首席知识官，Software Education是位于澳大利亚和新西兰的培训和咨询提供商。Shane教授的课程和提供的咨询服务涵盖下列领域：敏捷相关技巧、软件项目管理、业务分 析、软件测试。Shane通过了“业务分析职业认证”（CBAP™），并在2007年拿到了他的信息管理专业的硕士学位。他的硕士案例研究了在一家澳大利 亚ERP厂商实施敏捷方法带来的好处。他还是一名通过认证的ScrumMaster（Certified ScrumMaster），并于2008年12月2日开始生效。Shane有25年以上的经验，长于为业务问题提供技术解决方案，涵盖包括财务机构、航空 公司、制药公司、设施管理、车队管理和电信等诸多行业。