怎么做网站原型,软文推广多少钱,园岭网站建设,数字营销证书敏捷软件开发实践的文化中存在着一个断层#xff0c;该断层同样体现在许多敏捷团队中。这个断层就是业务分析人员在敏捷项目中的角色——谁来担任这个角色#xff1f;它的作用 和价值是什么#xff1f;它又是如何发生改变的#xff1f;这种情况的潜台词#xff08;其实我曾…敏捷软件开发实践的文化中存在着一个断层该断层同样体现在许多敏捷团队中。这个断层就是业务分析人员在敏捷项目中的角色——谁来担任这个角色它的作用 和价值是什么它又是如何发生改变的这种情况的潜台词其实我曾至少听人说过一次就是“我们不需要什么见鬼的分析师”。无需赘言我当然认为这是 大错特错在本文中我证明如下观点只要以正确的方式向业务看齐业务分析师就可以帮助敏捷团队成功而不是像大多数情况那样以开发团队为导向。 为什么要有业务分析师这个角色 我的观点是没有业务分析人员就会发生真的断层。举例来说 谁会注意最大的组织问题为了高效工作用户可怕的词汇——不过这是另外一个话题了有自己的需求而管理层说到底他们是为开发软件买单的“客户”的要求可能与之冲突谁去识别这种潜在的冲突假如现在有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厂商实施敏捷方法带来的好处。他还是一名通过认证的ScrumMasterCertified ScrumMaster并于2008年12月2日开始生效。Shane有25年以上的经验长于为业务问题提供技术解决方案涵盖包括财务机构、航空 公司、制药公司、设施管理、车队管理和电信等诸多行业。转载于:https://www.cnblogs.com/haoliansheng/archive/2013/05/24/3096081.html
