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

2022-02-08 11:09:30
万象教育
转贴:
微信公众号
1192
一、业务传递
在交接业务上下文的环节中,一方面,我们可能是作为初来乍到的介入者,需要接受他人信息的灌输;另一方面,我们可能是作为业务信息流中的一环,承担着向他人传递信息的责任。
  • 业务背景,包括基础的客户业务领域背景,部分专有名词释义;
  • 客户背景,客户方的干系人信息,明确决策者与产品/服务的最终用户,了解不同干系人的预期,是否有其他合作供应商等;
  • 项目背景,包括项目目的/范围、项目排期计划、项目成员、当前进度,了解项目活动、工作工具和项目上的规则,如站会时间等;
  • 产品背景,包括目标用户、产品愿景、用户旅程、当前痛点等信息,以及涉及的相关业务系统;
  • 其他信息,比如项目此前发生过的生产事故之类的信息。


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


在方案细化阶段,我们需要和客户沟通多轮;而在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时常会遇到一些异常错误,导致整个流程无法进行下去。这个时候,我们应当尽量保持淡定,无需惊慌。若有准备录制视频,可选择备用方案;反之,则应该对客户进行相应解释,征求其他时间进行演示。
文章分类
联系我们
  • 联系人:郑女士
  • 联系方式: 13792883250
  • 邮箱:zhengqiaoyin@cnezsoft.com
  • 地址:青岛市黄岛区井冈山路157号中南金石国际广场A座3202室
投稿邀请

如果您有优秀的原创文章,欢迎添加联系人直接与我们联系,或通过下方邮箱发送投稿文章,一经采用,我们会付以一定的稿件报酬。

  • 投稿邮箱: yanruiyu@easycorp.ltd
  • 投稿标题:向 [敏捷开发] 网站投稿
  • 稿件要求:与敏捷开发相关的任何内容

更多投稿相关请点击 更多进行了解~