今日洞见
本文作者：ThoughtWorks-亢江妹。
本文所有内容，包括文字、图片和音视频资料，版权均属ThoughtWorks公司所有，任何媒体、网站或个人未经本网协议授权不得转载、链接、转贴或以其他方式复制发布/发表。已经本网协议授权的媒体、网站，在使用时必须注明"内容来源：ThoughtWorks洞见"，并指定原文链接，违者本网将依法追究责任。
在敏捷社区里，下面这10个关于业务分析的问题会经常被人问及。我也一直在思考这些问题，结合过去8年来的敏捷项目上的经验，试着做个简单的解答，希望能给大家以启发。
1. 进入到迭代的用户故事，到底拆到多大尺寸为好？
我会尽可能让拆分出来的卡，3天左右能够开发完成（无论是否结对）。比这个尺寸大的卡，因为请假、周末等中断会导致更多的背景重建时间，而且会让开发易产生“疲劳感”；比这个尺寸小的卡，卡片管理的边际成本会比较高。
2. 在迭代计划时，是否重新评估并调整用户故事的点数？
我会尽一切可能不去讨论、调整卡的点数，而且会尽可能防止团队这样做。经验告诉我，这完全在浪费时间。当项目进入交付阶段后，只要业务需求范围没有变化，就不应该出现点数变动。
3. 临时拆分出的技术任务卡和迭代中发现的缺陷卡，要不要给点数？
不给。同上，只要业务需求范围没有变化，就不应该出现点数变动。
4. 不同的卡中，验收标准可以有重复吗？比如我们有按关键字、名称、地址来搜索客户的功能，搜索结果的页面都要分页。现在我们每个卡中都有分页相关的验收标准。
不要有重复。我们知道测试用例讲究“相互独立，完全穷尽”，这同样适用于需求。所有卡片上的验收标准，组合起来应该不多不少刚好等于整个项目的需求范围。好比图A。当有不同卡片的验收标准重复，不完全独立，就像是图B，导致额外的重复成本；当所有卡上的验收标准组合起来，不能覆盖到整个项目的需求范围，就是有需求遗漏，好比图C。
对于这个问题中的例子，我的做法是把搜索结果的分页显示拆分成一个独立的卡，然后在每一个搜索卡中，加一个标注说，搜索结果需要分页，并关联到这个分页卡。
还有例子的“跨功能性需求”（Cross Functional Requirements）。比如做UI的卡，都需要遵循统一的VI标准，比如用什么样的按钮、什么样的字体、颜色风格等，我一般会创建一个共享页面，来描述这个所有UI卡都要遵循的UI标准，然后在每个UI卡，标注说UI细节请参照共享页上的UI标准。
另外一个典型例子是做API项目。不同的API接口也都需要共同遵循一个技术标准，这个也不用在每个卡上重复去写，也是建一个共享页面来描述这个标准，其他卡来引用这个页面。
5. 迭代计划或迭代汇报时，大家总是对着“点数”斤斤计较，客户希望加几个点，团队希望少做几个点，于是讨论焦点就变成和客户争执某个卡到底应该是2个点还是5个点，怎么办？
首先深表同情 - 但这是一开始犯下的错，估计纠正起来需要花不少精力。我的做法是，从迭代0开始，就引导客户“轻视”点数。做法是：
- 做计划的时候，要对照着故事墙（或“业务全景图”），来列出迭代要完成的功能目标，强调为什么要完成这些目标，否则对整个交付计划的影响，在最后的10%的垃圾时间，顺带提下计划的点数是多少，想争论点数，啊没时间了！所以shut up。
- 做汇报的时候，同样，强调完成了什么样的功能目标，有没有里程碑完成，利用故事墙（“业务全景图”）展示整体进度；当前核心的Blocker和Issue是什么，有什么行动来解决，然后再顺带提下原计划多少点数，完成了多少点数。如下图：
总之，引导客户和整个团队，去看到整体需求完成情况，点数信息做参考，而不是围着点数转。
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自己去写，我来审核。另外我一定会给自己找出额外的时间，用于学习了解相关产品行业、总结等。“磨刀不误砍柴工”，有时新的解决业务问题的思路、新的工具会让你“事半功倍”。
“敏捷无定式”， 这些答案仅是个人项目中的经验，可能不适用于所有的企业、项目和团队，有启发、能带来思考就好。
