WeGroup 第五周总结

这一周的主要任务是修改用户故事

在写上一版的Vision和用户故事时，我们的方向过于发散，没有一个确定的开发目标。在上周听了助教和团委老师的讲解之后，及时修正了方向的问题，明确的了我们要做些什么。以后应该吸取这次的经验，在最初就应该把目标定好，挑选一个最有竞争力的特性去做，切忌贪多嚼不烂。

扯远了，回到这周的工作上来。两次的工作都是些用户故事，虽说是修改，但是由于上面的原因这一次基本是另起炉灶重新开始写。也算是积累了一些写用户故事的经验，在此做些记录。

格式

基本还全都是按照经典的格式去套：作为……，可以……，以便……。三句话分别说明了一项特性所对应的角色、功能和用户价值。用户故事一般不长，二三十字也就够了，所以最重要的就是在这么短的篇幅里清楚地说明所有的信息，所以用词要尽量准确！主语应该是不同角色的用户；功能应当是主语发出的动作，作为谓语，一般为动宾短语；而用户价值中可以加入一些形容词、副词，从而更好地描述这一项功能的意义，多传达些感情色彩。

其实我觉得，只要把应有的信息说清楚，完全可以不用拘泥于格式。对于每一项特性，应该选择适合它的表达方式去阐述。

粒度

分解用户故事也是在写用户故事时比较重要的一项，合适的粒度更有助于在开发时更好地理解需求，以免发生做出来和预想中不一样的悲剧。

所以怎样才是一个合适的粒度呢？上课说的是“不超过10个理想人天，至少在一个迭代中完成”。但是之前也没有进行过实践，对“人天”完全没有把握，所以感觉这一次的分解做的不是太好，在写下这一行字的的时候再回头去看一看写的用户故事...感觉好多写的都不太对......大概是在实践中时根本就顾不上理论了><

分解方式除去上课所说“根据所处理的不同数据分解”和“根据操作类型进行分解”

1. 用户角色分解法：当使用系统的用户包括多种不同角色，而一个功能对不同角色有差异化的处理逻辑，就可以为每个用户角色的特有需求分解出不同的故事；
2. CRUD分解法：常用于数据驱动的功能开发，将针对同一数据的创建(C)，读取(R)，更新(U)和删除(D)功能分别定义不同的故事；
3. 数据子集分解法：当需要处理的数据是一个很大的集合时，可以将其按某种标准分解为多个子集，而对每个子集数据的处理定义一个故事；
4. 演进分解法：对于一些处理复杂的需求，我们可以采用逐步演进的方法进行分解。也就是将一个完整功能可能的基本流程和分支流程（如权限控制，输入验证，通知等）分解为不同的故事，从核心的业务实现开始，通过多个故事逐渐将其完备起来。
5. 非功能需求分解法：也可以将一个特性的功能性需求和非功能性需求的实现分解为不同的故事，当然他们都应当在一个考虑周全的方案或设计下完成。

总而言之，我的理解的用户故事就是从用户的角度构造一个应用场景，以便于将产品的某一项特性更直观地表达清楚，这样的目的是为了减小需求人员和开发人员之间对功能理解的偏差。

于是问题来了...我们这种只有四个人，每个人的职务横跨需求、产品、开发、测试……用户故事真的有用么> <

以上

P.S. 分解方式转载于：http://blog.sina.com.cn/s/blog_626bfd2b01016cla.html