今日洞见
本文作者:ThoughtWorks-亢江妹。
本文所有内容,包括文字、图片和音视频资料,版权均属ThoughtWorks公司所有,任何媒体、网站或个人未经本网协议授权不得转载、链接、转贴或以其他方式复制发布/发表。已经本网协议授权的媒体、网站,在使用时必须注明"内容来源:ThoughtWorks洞见",并指定原文链接,违者本网将依法追究责任。
在敏捷社区里,下面这10个关于业务分析的问题会经常被人问及。我也一直在思考这些问题,结合过去8年来的敏捷项目上的经验,试着做个简单的解答,希望能给大家以启发。
我会尽可能让拆分出来的卡,3天左右能够开发完成(无论是否结对)。比这个尺寸大的卡,因为请假、周末等中断会导致更多的背景重建时间,而且会让开发易产生“疲劳感”;比这个尺寸小的卡,卡片管理的边际成本会比较高。
我会尽一切可能不去讨论、调整卡的点数,而且会尽可能防止团队这样做。经验告诉我,这完全在浪费时间。当项目进入交付阶段后,只要业务需求范围没有变化,就不应该出现点数变动。
不给。同上,只要业务需求范围没有变化,就不应该出现点数变动。
不要有重复。我们知道测试用例讲究“相互独立,完全穷尽”,这同样适用于需求。所有卡片上的验收标准,组合起来应该不多不少刚好等于整个项目的需求范围。好比图A。当有不同卡片的验收标准重复,不完全独立,就像是图B,导致额外的重复成本;当所有卡上的验收标准组合起来,不能覆盖到整个项目的需求范围,就是有需求遗漏,好比图C。
对于这个问题中的例子,我的做法是把搜索结果的分页显示拆分成一个独立的卡,然后在每一个搜索卡中,加一个标注说,搜索结果需要分页,并关联到这个分页卡。
还有例子的“跨功能性需求”(Cross Functional Requirements)。比如做UI的卡,都需要遵循统一的VI标准,比如用什么样的按钮、什么样的字体、颜色风格等,我一般会创建一个共享页面,来描述这个所有UI卡都要遵循的UI标准,然后在每个UI卡,标注说UI细节请参照共享页上的UI标准。
另外一个典型例子是做API项目。不同的API接口也都需要共同遵循一个技术标准,这个也不用在每个卡上重复去写,也是建一个共享页面来描述这个标准,其他卡来引用这个页面。
首先深表同情 - 但这是一开始犯下的错,估计纠正起来需要花不少精力。我的做法是,从迭代0开始,就引导客户“轻视”点数。做法是:
总之,引导客户和整个团队,去看到整体需求完成情况,点数信息做参考,而不是围着点数转。
大有用处。如目前的项目,我70%的精力其实都是在花在“RAIDs”上。其实在交付过程中,分析常规性需求是相对简单的;给交付带来困难和挑战的往往是这些RAIDs。分析、理解、跟踪、提前采取措施消除其影响,就会有效避免需求蔓延、提前化解“大老虎”危险需求、及时调整好客户期望,避免大的矛盾发生。每一个项目,我会去建立一个共享页面,列出所有的假设、风险、问题和依赖;提前1-2个迭代去分析这个列表:
这些都是与需求紧密相关的,不能甩手扔给PM。在每一个迭代汇报或演示时,除了汇报进度,更要汇报RAIDs的最新状态;需要领导注意的高亮出来,经验证明这种场合消除问题会很有效。
要。这些可能会成为阻碍(blocker),我一定都会让它们可视化在墙上,这样客户、团队中的每个人每天可以看到。一块干净的玻璃,如果上面有一块明显的污垢,人天性里都回有擦除它的欲望。放在墙上,是同样道理。只不过这类卡片不应该有点数,或者点数为0。
不要。对于绝大多数组织来说,尤其大型组织,所谓创新难有一个主要因素是“执行乏力”。从产品概念产生到第一个雏形上市,这是一个“快速试错”的过程;越试得快,离“正确”的目标就越近;即使第一次方向针对选错了,完整地收尾才能真正学习到“错误”在哪里。反复犹疑,只能让“不确定”越来越多,越不知道该怎么做。我自己的经验,一旦进入交付,尤其是短期极速交付,就是要尽一切努力帮助客户收敛,收敛,收敛。所以当我们去跟客户沟通需求时,不是真正地让他来告诉我们做什么,怎么做;而是“诱导”他同意按照我们想好的“性价比”最高的方式做。
先暂时放下这个“事”,下点功夫在“人的需求”上面,挖掘下想客户最真实的个人诉求是什么?《商战往事》有段话我印象非常深刻“项目需求在内外部运作中、竞争中会源源不断地给个人需求提供机会,而个人需求在这个基础上,还包括内外部环境变革中源源不断地给项目需求制造动机,一个问题,一个概念,一个挫折,一种情绪,都会改变需求…”, 所以要追根溯源,才有可能解开谜结。
刚才说的,项目中的时间,60%用于跟踪和管理RAIDs;15-20%时间来分析卡的细节并写出来;15-20%的时间做需求确认(做预验收和给客户演示)。这样自己与客户间的对话尽可能保持在骨干需求级别; 而不仅仅是需求的细节,这样才能把控需求大局。如果需求分析透了,写卡这件事其实比较简单,我会让我们团队的Dev/QA自己去写,我来审核。另外我一定会给自己找出额外的时间,用于学习了解相关产品行业、总结等。“磨刀不误砍柴工”,有时新的解决业务问题的思路、新的工具会让你“事半功倍”。
“敏捷无定式”, 这些答案仅是个人项目中的经验,可能不适用于所有的企业、项目和团队,有启发、能带来思考就好。