本文的某些读者可能认为，敏捷方法不需要业务分析师角色。对于那些担任这一职务的人，我鼓励您继续阅读。我建议无论选择哪种SDLC（瀑布式或敏捷式），仍然需要业务分析师的角色。作为开发人员，您可能会说：“但是，在没有BA角色的情况下，我们在我的敏捷项目中做得很好。”我想问您，“您是否检查了直接与利益相关者互动的扩展角色？”在IT业务的过去40年中，我经历了几种解决方案开发方法。似乎没有改变的一条规则是，无论使用哪种SDLC，角色提供的功能都将保留。在敏捷的情况下，软件开发团队的成员会承担BA功能的风险。
请注意，我假设读者熟悉瀑布式和敏捷SDLC方法，因此在本文中我不会尝试详细定义它们。出于本文的目的，使用了类似于Scrum的敏捷方法。
作为业务分析技术和实践的讲师，我经常提出有关敏捷分析软件开发团队中业务分析师（BA）的角色的问题，而不是传统的瀑布式解决方案开发生命周期（SDLC）方法。经过多方面的思考和投入，我相信敏捷软件开发团队需要业务分析员的角色。
BA促进者的作用
BA促进者的作用是指导有关开发视觉和软件解决方案的活动。这里的关键词是指南。 BA促进者角色提供了对设置进行分组的过程，并避免参与内容。通常，BA促进者的角色是利益相关者之间以及利益相关者与软件开发团队之间的联络。作为联络人，BA的促进者角色使用各种技术和情商技巧来协助项目发起人和/或团队负责人实现小组达成的目标：
- 识别解决方案功能的简化技术
- 建立解决方案的愿景和范围
- 集思广益-讨论想法
- 写作-提交书面想法进行讨论
- 精选功能和相关业务规则
- 焦点小组会议-征求意见
- 联合应用程序设计-解决冲突
- 分析功能-假设，约束，风险和问题
- 根本原因-石川图的五个原因
- 力场-列出负面和正面影响
- As-Is 和 To-Be Gap
- 决定功能和优先级
- 多次投票-主观削减很长的功能列表
- 基于标准的网格-权重要素值标准
- 影响/工作量网格-比较功能收益与工作量
- 建立解决方案的愿景和范围
- 与利益相关者互动的情商技能
- 主动倾听和释义
- 产生参与
- 中立性-专注于会议流程而不是解决方案内容
- 提问-寻找答案而不是提出解决方案
- 保持重点-使用停车场并发布议程外主题的日志
- 获得利益相关者的反馈
- 总结和综合思想
- 冲突干预
在敏捷的SDLC之下，BA的促进者角色主要参与两项活动：持续的愿景和范围会议，迭代的软件开发会议和研讨会。
每个项目都从解决方案的愿景和范围开始，以满足业务需求。这种看法可能是确定的，也可能是模糊的。无论定义如何，该愿景将反映优先级高的解决方案功能集，这实质上是软件开发团队要完成的工作范围。在敏捷方法中，定义愿景和范围是一系列连续的会话。每次会议代表当时由利益相关者确定的愿景和范围的快照。这些会议以增加，更改和/或改进的方式管理解决方案功能的范围，直到涉众完成其愿景为止。
这些愿景和范围会议由项目发起人主持。对于项目发起人而言，挑战在于确保项目愿景和范围是所有利益相关者之间的共同努力，因此需要BA促进者角色。 BA促进者的作用是通过提供和执行会议计划来协助项目发起人。每个愿景和范围计划包括：
- 确保正确的参与者参加
- 承担风险的核算
- 安排有利于合作的适当设施
- 制定适当的议程
该议程包含简化技术，这些技术将使利益相关者就软件开发团队将要寻求的一组优先级高级解决方案功能达成共识。在会议期间，BA的主持人角色将运用情商技巧，以确保所有利益相关者都参与其中，并确保他们的想法得到尊重。 BA促进者角色可通过“询问”确保功能合理，并可追溯到业务需求。请注意，所有功能均需获得项目发起人（会议主席）的批准。
迭代软件开发会议和研讨会
确定初始构想和范围功能后，软件开发会议首先就将在第一次迭代中开发哪些优先级的高级功能达成共识。一旦软件开发团队选择了一组有限的功能并将其设置为时间限制，便会举行一系列后续状态会议，以解决进度问题和消除障碍。在这些状态会议之间，软件开发团队与利益相关者举行研讨会以开发解决方案。这些迭代的研讨会以开发的解决方案的验证会议和项目发起人的实施决定为结尾。综上所述，
- 从优先列表中选择视觉和范围功能
- 在一个时间范围内为此迭代开发解决方案
- 举办研讨会，制作原型
- 举行进展情况状态会议
- 验证最终原型并在项目发起人的批准下实施
- 返回第一步以获取更多功能，并根据需要添加返工，直到功能列表用尽
请注意，在实施时，迭代软件开发会议将通过另一种优先处理的高级功能来进行更新。与此相关的利益相关者可能会通过与软件开发会议同时举行的进一步的愿景和范围会议来更改这些功能。
功能选择和状态会议由与项目经理相似的团队负责人主持。在这些会议中，团队负责人面临与项目发起人相同的挑战-确保解决方案开发是通过共识进行的协作。再一次，需要BA的促进者角色。与愿景和范围会议一样，BA协调人的作用是通过为每次会议提供计划并执行该计划来协助团队负责人。
软件开发团队是自我指导和/或自我组织的。团队将根据他们的技能和经验来运行研讨会，而不是使用团队负责人制定的计划。研讨会是软件开发团队和利益相关者之间的直接对话。这些研讨会涉及开发解决方案的重要业务和技术细节：
- 用户和系统功能要求
- 相关业务规则
- 信息需要管理
- 用户界面
- 技术实施方法
都 什么 needs to be developed 和 怎么样 在研讨会期间同时讨论将要实施的方法。这些讨论的结果是，开发团队通过一系列原型提供了解决方案，每个原型均经过利益相关者的直接反馈测试。然后，最终的原型（用于此迭代）将由项目发起人进行验证和批准以用于实施。然后，新的周期开始于从视觉和范围中选择其他功能，包括可能的返工项目...等，等等。
在研讨会上，BA协调员的角色与以前的计划会议不同。在计划会议期间，BA的主持人角色提供并执行了议程。 BA促进者在讲习班中的作用是协助利益相关者和软件开发团队从陈述的用户需求中确定系统需求，以构建原型。软件开发团队使用这些原型来构建增量解决方案。
BA促进者角色通过使用扩展的BA工具来完成上述工作，该工具包括：
- 用于识别和分析用户需求，系统需求和业务规则的业务建模工具
- 带泳道的活动工作流程-手动流程
- 用例-用户/系统对话-系统功能要求
- 故事板-用户/系统界面-屏幕流
- 实体关系-组织系统使用的信息
- 状态变更-信息随着流程和系统的进行而发生变化
- 类/对象-用于面向对象的实现
BA促进者角色使用业务建模的彻底性受到软件开发团队的需求的约束。 BA促进者角色没有像瀑布SDLC中那样全面记录在案的要求，而是产生了“ 刚刚够 软件开发团队根据需要编写文档以对原型进行编码。
结论-正式的BA促进者角色“只是确保”
每当定义，确定优先级，分析和/或开发解决方案功能时，自然会使用BA促进者角色来确保利益相关者认可并接受最终解决方案。无论是愿景和范围会议，迭代软件开发会议还是研讨会，BA促进者的角色都可以由软件开发团队的成员来担任。但是，请考虑与未接受过BA便利化培训和经验的人士达成共识所涉及的风险。生产力和共识程度直接取决于BA促进者工具集的有效使用。另外，利益相关者和开发人员可能会专注于原型的技术方面而不是需求方面。避免这种风险是谨慎的。至 ” 只要确保 团队的成功需要一个最佳实践，它是协助敏捷软件开发团队的正式BA促进者。
别忘了在下面留下您的评论
马克·A·蒙特里昂 持有学士学位物理学和硕士Texas A的计算机科学专业&M大学。他被项目管理学院（PMI®）认证为项目管理专业人员（PMP®），被国际商业分析学院（IIBA®）认证为业务分析专业人员（CBAP®），被ScrumMaster（CSM）认证为 TM值 值 ）和Scrum认证产品负责人（CSPO） TM值 值 ) by the Scrum Alliance. He holds an Advanced Master's Certificate in 项目管理 和 a 业务分析师 Certification (CBA®) from George Washington University School of Business. Mark is also a member of the Association for the Advancement of Cost Engineering (AACE) 和 the International Association of Facilitators (IAF).马克是Monteleone Consulting，LLC的总裁，可以通过电子邮件与他联系- [email protected]
本文首先刊登在2009年2月的IIBA新闻中。
