分类: 敏捷

在敏捷社区里, 下面这10个关于业务分析的问题会经常被人问及。我也一直在思考这些问题,结合过去8年来的敏捷项目上的经验,试着做个简单的解答,希望能给大家以启发。

1.进入到迭代的用户故事,到底拆到多大尺寸为好?

我会尽可能让拆分出来的卡,3天左右能够开发完成(无论是否结对)。比这个尺寸大的卡,因为请假、周末等中断会导致更多的背景重建时间,而且会让开发易产生“疲劳感”;比这个尺寸小的卡,卡片管理的边际成本会比较高。

2.在迭代计划时,是否重新评估并调整用户故事的点数?

我会尽一切可能不去讨论、调整卡的点数,而且会尽可能防止团队这样做。经验告诉我,这完全在浪费时间。当项目进入交付阶段后,只要业务需求范围没有变化,就不应该出现点数变动。

3.临时拆分出的技术任务卡和迭代中发现的缺陷卡,要不要给点数?

不给。同上,只要业务需求范围没有变化,就不应该出现点数变动。

4.不同的卡中,验收标准可以有重复吗?比如我们有按关键字、名称、地址来搜索客户的功能,搜索结果的页面都要分页。现在我们每个卡中都有分页相关的验收标准。

不要有重复。我们知道测试用例讲究“相互独立,完全穷尽”,这同样适用于需求。所有卡片上的验收标准,组合起来应该不多不少刚好等于整个项目的需求范围。好比图A。当有不同卡片的验收标准重复,不完全独立,就像是图B,导致额外的重复成本;当所有卡上的验收标准组合起来,不能覆盖到整个项目的需求范围,就是有需求遗漏,好比图C。

 

图C

 

对于这个问题中的例子,我的做法是把搜索结果的分页显示拆分成一个独立的卡,然后在每一个搜索卡中,加一个标注说,搜索结果需要分页,并关联到这个分页卡。

还有例子的“跨功能性需求”(Cross Functional Requirements)。比如做UI的卡,都需要遵循统一的VI标准,比如用什么样的按钮、什么样的字体、颜色风格等,我一般会创建一个共享页面,来描述这个所有UI卡都要遵循的UI标准,然后在每个UI卡,标注说UI细节请参照共享页上的UI标准。

另外一个典型例子是做API项目。不同的API接口也都需要共同遵循一个技术标准,这个也不用在每个卡上重复去写,也是建一个共享页面来描述这个标准,其他卡来引用这个页面。

5.迭代计划或迭代汇报时,大家总是对着“点数”斤斤计较,客户希望加几个点,团队希望少做几个点,于是讨论焦点就变成和客户争执某个卡到底应该是2个点还是5个点,怎么办?

首先深表同情 – 但这是一开始犯下的错,估计纠正起来需要花不少精力。我的做法是,从迭代0开始,就引导客户“轻视”点数。做法是:

  • 做计划的时候,要对照着故事墙(或“业务全景图”),来列出迭代要完成的功能目标,强调为什么要完成这些目标,否则对整个交付计划的影响,在最后的10%的垃圾时间,顺带提下计划的点数是多少,想争论点数,啊没时间了!所以shut up。
  • 做汇报的时候,同样,强调完成了什么样的功能目标,有没有里程碑完成,利用故事墙(“业务全景图”)展示整体进度;当前核心的Blocker和Issue是什么,有什么行动来解决,然后再顺带提下原计划多少点数,完成了多少点数。如下图:

X review
总之,引导客户和整个团队,去看到整体需求完成情况,点数信息做参考,而不是围着点数转。

6.在项目快速启动(Inception)时,得到的“RAIDs” (分别代表Risk, Assumptions, Issues, Dependencies),在交付期间到底还有没有用?

大有用处。如目前的项目,我70%的精力其实都是在花在“RAIDs”上。其实在交付过程中,分析常规性需求是相对简单的;给交付带来困难和挑战的往往是这些RAIDs。分析、理解、跟踪、提前采取措施消除其影响,就会有效避免需求蔓延、提前化解“大老虎”危险需求、及时调整好客户期望,避免大的矛盾发生。每一个项目,我会去建立一个共享页面,列出所有的假设、风险、问题和依赖;提前1-2个迭代去分析这个列表:

  • 假设:有哪些假设现在就能确认是对的?有哪些假设是错的?错的假设意味着演变成了一个问题,需要移到问题列表上;迟迟无法验证的假设,请从假设列表移到风险列表。
  • 风险:如果发生了,会影响需求范围吗?有哪些备选方案?需要提前做什么准备?如果已发生,需要转移到问题列表。
  • 问题:所有的问题在创建之前,其实应该已经跟客户沟通过,不应该有意外;跟踪更多是报告状态,追着相关的人完成。
  • 依赖:跟外部接口人做好沟通了吗?最好/最差情况什么时候能解除依赖?

这些都是与需求紧密相关的,不能甩手扔给PM。在每一个迭代汇报或演示时,除了汇报进度,更要汇报RAIDs的最新状态;需要领导注意的高亮出来,经验证明这种场合消除问题会很有效。

7.BA(Business Analyst,也即业务分析师,是敏捷团队中的必要角色,下同)经常需要跟踪依赖和一些待处理的问题,这些需不需要可视化在故事墙/看板上?

要。这些可能会成为阻碍(blocker),我一定都会让它们可视化在墙上,这样客户、团队中的每个人每天可以看到。一块干净的玻璃,如果上面有一块明显的污垢,人天性里都回有擦除它的欲望。放在墙上,是同样道理。只不过这类卡片不应该有点数,或者点数为0。

8.在项目快速启动(Inception)时,我们已经找出了MVP,并确定为第一次发布的需求范围,且交付时间很紧张只有3个月。在交付过程中,有一个客户提出方向可能不对,建议重新发散想法确定需求,要不要这样做?

不要。对于绝大多数组织来说,尤其大型组织,所谓创新难有一个主要因素是“执行乏力”。从产品概念产生到第一个雏形上市,这是一个“快速试错”的过程;越试得快,离“正确”的目标就越近;即使第一次方向针对选错了,完整地收尾才能真正学习到“错误”在哪里。反复犹疑,只能让“不确定”越来越多,越不知道该怎么做。我自己的经验,一旦进入交付,尤其是短期极速交付,就是要尽一切努力帮助客户收敛,收敛,收敛。所以当我们去跟客户沟通需求时,不是真正地让他来告诉我们做什么,怎么做;而是“诱导”他同意按照我们想好的“性价比”最高的方式做。

9.客户提出了一些新需求,我做了足够扎实的分析,排了个优先级,想让客户放弃一些低优先级的需求,可无论我怎么说,客户都说这个优先级都是一样的,必须得做?

先暂时放下这个“事”,下点功夫在“人的需求”上面,挖掘下想客户最真实的个人诉求是什么?《商战往事》有段话我印象非常深刻“项目需求在内外部运作中、竞争中会源源不断地给个人需求提供机会,而个人需求在这个基础上,还包括内外部环境变革中源源不断地给项目需求制造动机,一个问题,一个概念,一个挫折,一种情绪,都会改变需求…”, 所以要追根溯源,才有可能解开谜结。

10.我好像绝大多数时间都在写卡,都没时间去想产品和业务,更别说去写总结和分享了。作为BA,该怎么分配自己的时间和精力?

刚才说的,项目中的时间,60%用于跟踪和管理RAIDs;15-20%时间来分析卡的细节并写出来;15-20%的时间做需求确认(做预验收和给客户演示)。这样自己与客户间的对话尽可能保持在骨干需求级别; 而不仅仅是需求的细节,这样才能把控需求大局。如果需求分析透了,写卡这件事其实比较简单,我会让我们团队的Dev/QA自己去写,我来审核。另外我一定会给自己找出额外的时间,用于学习了解相关产品行业、总结等。“磨刀不误砍柴工”,有时新的解决业务问题的思路、新的工具会让你“事半功倍”。

“敏捷无定式”, 这些答案仅是个人项目中的经验,可能不适用于所有的企业、项目和团队,有启发、能带来思考就好。

Share

发表评论

评论