需求分解颗粒度

排排坐

需求分解颗粒度，足够的细致，才有足够的质量！
在Jira里，管理需求有非常熟悉的三种粒度：OR（产品需求）、DR（交付评审点）、Story（故事片段）。
在OR之前其实是原始需求，经过BA（业务分析）后才会转化成产品需求，进一步分解成可交付评审的功能点，最后才是我们常说的Story。
举个例子，在excel中，用户说我有这么一个场景，需要对齐字体、图片、表单等，这种粗糙的话语意味着原始需求；BA经过处理后转化为OR，用户的需求是给各种元素提供对齐功能；OR再转化成DR，意味着excel中提供的对齐方式功能，需要团队交付对齐方式这个功能；DR分解下来就会划分多种Story场景，Story的描述通常都是这样的“为了X，作为Y，希望Z”，“为了让我的数据都能在中间显示，作为表格的排版人员，我希望有居中对齐的功能”…
Story是描述了对于系统或软件的客户或用户有价值的一个功能点；它应该是有价值的功能片段，标识了某类用户的需求，这里特别强调价值。
针对Story的要求：
1、独立的，这个功能是独立实现的，低耦合；
2、可交付，这个功能是可以交付使用的或验证的，不是幻想的功能；
3、可商讨，这个功能是有细节的，可以讨论更具体的内容（Story本身可以再次分解，不过一般来说没必要，有细节即可，可以见后文细节部分）；
4、有价值，强调价值；
5、可估计，主要强调每个Story可以估算工作量；
6、合适的小，通常来说可以让一两个开发花费一两天可以做完。
Story的细节可以以卡片的方式，经过交流来确认，在交流过程中需要进行价值分析、识别用户角色（属于哪类用户需要的功能），按照XYZ方式写出Story，确定Story的优先级。
那么了解上面这些内容有什么用呢？这些内容告诉了质量人员，什么样的需求分解颗粒度才是有质量的，什么样的需求->Story才是有价值的，只有有价值有质量的需求，才能保证客户满意度；毕竟，质量的定义明明就是“一组固有特性满足客户需求的程度”！
让我们从需求分解颗粒度的源头开始做起，评估好需求的质量吧！



文章首发于微信公众号“流程与质量”

昨夜楓

请问下story可以独立发布吗

娄小娄

story颗粒度的意思是：将已定的需求拆分成一个个合适大小的功能点。可以这样理解吗

友缘双醉

是的，你可以看譬如Excel里边的一个个非常小的功能