敏捷开发流程中的交付BA角色——项目实践工作方法论

一、业务传递
在交接业务上下文的环节中，一方面，我们可能是作为初来乍到的介入者，需要接受他人信息的灌输；另一方面，我们可能是作为业务信息流中的一环，承担着向他人传递信息的责任。

业务背景，包括基础的客户业务领域背景，部分专有名词释义；

客户背景，客户方的干系人信息，明确决策者与产品/服务的最终用户，了解不同干系人的预期，是否有其他合作供应商等；

项目背景，包括项目目的/范围、项目排期计划、项目成员、当前进度，了解项目活动、工作工具和项目上的规则，如站会时间等；

产品背景，包括目标用户、产品愿景、用户旅程、当前痛点等信息，以及涉及的相关业务系统；

其他信息，比如项目此前发生过的生产事故之类的信息。

二、方案计划和迭代计划会议

在方案细化阶段，我们需要和客户沟通多轮；而在IPM中，我们需要在团队内部进行多次讨论。在这个环节中，一方面，我们需要有基本的业务素养，能够对规划方案进行合理分析并细化；另一方面，我们需要有良好的表达沟通能力，能够搭建起业务与技术之间的沟通桥梁。

三、基本业务能力

作为交付BA的基本业务能力，包括但不限于：

细化需求方案

绘制设计稿

撰写Story Cards(/PRD)

其他

首先是会议，为了使整个会议高效有序地进行，我们一般都会提前准备会议材料，发送会议日程给相关与会人员。但即使是这样，我们依旧会遇到这些问题：

客户方内部意见不一，且会上不提，会后反水；

讨论内容慢慢发散，逐渐偏离原定主题；

讨论内容无结论产出。

对于问题1，我们都会想到应该让客户内部先商讨达成一致意见，我们再加入讨论，但实际情况可能是客户内部各方话语权比重不一，话语权弱的客户并不愿意在会上直面高层领导，所以我们或许需要做一个各方的调和者，收集各方的真实想法，再去给出最终的解决方案。对于问题2，那就需要大家能够勇于打断会议上无关言论的讨论，可以告诉客户我们先记录下这些信息，放在后续再进行相关讨论，重点是需要让客户再次聚焦于我们本次的会议讨论主题上来。对于问题3，由于一些不可抗因素，导致会议的讨论并没有实质性的结论时，一定要及时约定下一次的会议行程，尽早解决遗留问题。

其次是文档，较常接触到的主要是会议纪要、需求文档（包括Story Card），根据项目情况的不同，可能会有其他文档，比如指标文档。对于文档而言，一方面，需要注意文档格式以及语病句、错别字的问题；另一方面，需要做好文档的版本管理，以便于后期进行问题溯源。那么在这里，有同学可能会有疑问，如何才能写好Story Card，或者应该如何拆卡？我们都学习过以下的格式信息：

As…, I want…, so that….

Given…, when…, then….

也都了解拆卡要遵循INVEST原则，但当我们进入实际项目中时，一开始可能会不知如何下笔，会询问各个BA的写卡方法。由于大家的工作方式与风格存在差异，我们收获到的答案如图3所示，可能各不相同，但他们基本上都离不开“given/when/then”的原则，即围绕着场景写检验标准(AC)。我相信当你在苦思冥想后写下了属于你的第一张故事卡后，你就会越来越熟练。

四、客户管理
由于细化需求需要和客户不断地确认细节信息，那么在讨论的过程中，我们可能会遇到：

客户想要改变原有想法，推倒重来；

客户有了新的想法，想增加新的内容；

客户不愿和你多说，他认为这些问题以前说过，不想再重述；

客户的说话语气让你感觉不适。

面对前两种情况时，我们要做的就是站在客户或者用户的角度，去帮助他们认清自己想要的东西。而对于客户不愿交谈的时候，也许我们需要暂停与客户的沟通，先在团队内部询问相关知情者了解信息，重新梳理后，再与客户确认确实缺失的细节内容。另外，确认客户的时间安排，因为我们可能会碰到很难约上的客户，也许我们只能在他的会议间隙进行5～10分钟的询问。最后一点，如图5所示，我们需要调节好自己的情绪，时刻展现出我们作为专业咨询人士的那一面。

五、IPM

在故事卡片撰写完成后，我们会召开迭代计划会议，将需求内容传达给团队内部。同时，根据开发人员的讨论得出较为合适的开发工作量。那么在IPM中，我们可能会遇到以下问题：

工作量估得太小或太大，导致开发进度与预期严重不符；

各需求卡片讨论太久，导致整体计划重新排布；

长时间的会议导致部分成员无心与会。

首先，关于需求工作量的评估，一般地，我们会与项目中的技术Leader提前粗略估计各张故事卡片的工作量大小。但在项目初期，大家并不熟悉整个项目的情况，对于工作量的评估就有可能出现太小或者太大的情况，那么最好是能在迭代后的复盘会议上，及时提出这个问题，以便于之后的工作量评估环节能有较好的改进。

其次，需求内容的讨论，是IPM会议中必不可少的环节，也是最重要的部分。那么为了提高大家的讨论效率，建议在会议之前，与会人员能够提前熟悉故事卡片内容，并记录下自己的相关疑问。

最后，对于把控整个会议的BA而言，一方面需要在会议前做好充足准备，包括会议时间/地点/参会人员的安排与通知，会议材料的提前发布；另一方面则需要注意整个会议的时间控制，明确此次会议要讨论的需求数量，以及各需求之间的依赖关系。同时，针对讨论内容，可能需要对故事卡内容进行相应的补充或修正。而对于需求的讲解方式，通常我们会结合故事卡与设计稿进行讲解，或者在时间充裕的情况下，可以准备演示文档进行讲解。不论何种方式，重要的是能清晰、细致、全面地传达需求内容。

六、开发和测试
在开发人员要进行开发前，会找到BA、QA以及UX讲解他所理解的需求内容，BA和UX分别针对业务、界面设计和交互设计的相关问题进行解答，直到大家对此需求内容达成一致时，开发人员才会准备开始该功能的开发。同时，BA同学可以记录下相应的开卡记录，辅助项目进度的维护与管理。或许有同学会对开卡环节抱有疑问，既然IPM已经讨论过各个卡片的内容，为什么还需要再进行开卡这个环节？因为可能会存在以下几种情况：

当前距离IPM会议已时隔较久；

项目有新成员加入，且未参与之前的IPM；

IPM大量信息的灌输，导致部分信息有所遗漏。

即使在开发前已经有过一次小型的需求对齐会议，我们同样会在开发人员的开发过程中收到他们的疑问。为了产品能够按时保质的完成，我们需要及时提供给开发人员明确的答复，如果中途涉及到需求调整，则需要将相关信息同步给测试人员以及依赖功能开发人员，并做好版本记录管理。

当功能完成开发后，我们会进行Desk Check(DC)，即关卡。此时，需要对着故事卡中的AC一条一条进行检验。除此之外，也需要注意界面设计以及交互方式是否满足要求。大多数时候当关键AC不被满足时，在开发人员修改后需要进行二次DC，而对于普通的小问题，比如缺少一个筛选值集，通常由开发人员在修改完成后直接告知测试人员，测试人员在测试环节时再进行验证。

作为BA同学可能会发现进入交付后，一天中的大部分时间都花费在了开卡和关卡上。与此同时，可能还需要兼顾其他内容需求细化分析或者编写故事卡。那么为了提高开卡、关卡的效率，开卡前，开发人员与测试人员最好能够提前阅读需求内容，记录疑问；关卡前，开发人员在自测后准备好测试数据。

另外，我们难免会遇到开发人员想要开\关卡，但BA由于在与客户开会等不可抗因素的影响下无法参与时，那么对于开卡来说，可以先行开卡，并将疑问及时提给BA，对于关卡来说，BA可以上测试环节进行二次检验。

在测试环节，一般都由QA进行测试。当项目节奏紧张时，可能会发动项目上的其他成员加入测试。我们需要做的是，按照测试人员写的bug卡，写下我们所发现的问题。当我们发现问题后，最好进行二次尝试，明确该问题是偶现bug还是重现bug，若无法确定是否为bug时，可以与QA同学一起复现一次。一般卡片内容包括：

环境，开发环境、测试环境或生产环境；

场景，描述问题发生的操作步骤；

结论，提供该步骤带来的结果；

期望，给出该步骤后，实际的需求预期结果；

其他，截图、日志等，方便开发人员定位问题。

另一种情形是Bug bash，一般在上线前或者重大功能发布前，会组织团队成员进行bug bash，以提早发现大部分问题，避免生产环境遇到严重问题。同时，会对各成员需要测试的内容进行分工，以便提高整体测试效率。Bug bash后，需要对记录下的bug进行优先级的排列，排入迭代计划依次修复。

七、SHOWCASE
当产品开发到一定阶段时，我们可能会组织一场Showcase，将我们近期的成果展示给客户，让客户了解到我们最近所做出的成果。而培训，则像是一场更为正式的大型Showcase。

对于Showcase，我们需要准备演示脚本，以及备选方案，比如提前录制好需要演示的流程视频，确定演示时间、地点及参与人员，提前进行设备调试。一般来说，演示时并不是基于真实的生产环境，因此，showcase时常会遇到一些异常错误，导致整个流程无法进行下去。这个时候，我们应当尽量保持淡定，无需惊慌。若有准备录制视频，可选择备用方案；反之，则应该对客户进行相应解释，征求其他时间进行演示。

起源

流派

视频

书籍

敏捷动态

培训

关于我们