如何写好User Story的分析与设计

        首先声明，这里记录的是我自己在项目运转过程中的心得体会，和敏捷官方的材料也许会有不一致，那么请遵循官方的说明。

        计算机是一个确定性比较强的系统，通常情况下，输入确定，输出即是确定的。但人和计算机是有差别的，比如在不同的情绪下面对相同的事物时，有可能给出不同的反应，相信有家属的兄弟对这一点有深刻的理解。那么，依据我的理解，写作User Story的分析和设计，最主要的工作就是理清输入和输出，方便交流和学习。此外要注意到，在面对分析和设计时，不同的立场决定了输入和输出的概念有细微的差别而已。

Story分析的格式

        格式其实不重要，关键是内容，但是为了方便阅读和学习，以及美观，还是需要整理一份项目组内认可的模板出来，后续成员都按照使用相同的模板输出材料。

        User Story分析材料（下面简称Story分析材料）的读者，照我的理解，Story分析就是针对一个小特性的说明材料，辅助交流和记录问题与解答，大部分情况下它的读者比较单一，比如认领Story的开发人员和对应的测试人员，以及后续维护该特性的开发人员。假如需求前端人员的输出材料比较简单，Story的分析材料还担负起了与前端需求人员交流的作用，这时前端需求分析人员也会成为Story的读者。因此，Story分析材料的格式和内容需要依据用途来做一定的适配。

Story分析的内容

        Story分析中常用的组成部分，比如应用场景，系统现状，功能设计，性能设计，外部依赖，外部接口等等，当然有时还需要根据项目特殊性增加一些标题，用以提醒团队成员做专门的分析。

        Story分析需要写什么，我个人的理解，切合Story分析的作用，应当有三部分内容：

1、站在使用者的角度，从功能层面说明Story的特性和能力，比如用户做一些操作，产品会有什么样的反馈；

2、站在开发者的角度，从实现层面说明为了实现前述能力，产品内部需要做哪些调整，针对不同的操作要实现怎样的处理流程；

3、作为记事本，记录Story分析过程中的疑问和问题，用于和用户、团队的其他成员交流，同时方便后续团队成员查看和学习；

 Story分析怎么去做

        这个其实不是问题，直白点讲，需求理解了，怎么想就怎么写。在我所在的团队，Story分析材料不限体裁，不限字数，不限文笔，只要思路清晰，把关键点描述到位，不影响项目组其他同事学习和交流，其它方面都不会太在意。但从项目实地运作的过程看，不少理科出身的程序员同事在写作Story分析时，经常出现思路不清晰、跳跃性强、关键点缺失或者特性分析不完整的问题，部分同事在修改几次之后仍然会有这样那样的问题。这说明平时缺少写作经验，不善于通过书面语言表达自己的想法，虽然可能对项目编码影响不大，但显而易见，对个人发展会很不利。

        从项目实地运作过程中，我个人觉得，分析到位的Story分析材料有如下的特点：

1、由外及内，站在客户角度观察特性，分析出特性提供给客户的各项能力，描述出客户的使用场景和使用顺序，判定出客户的正常行为以及异常行为；

2、由内及外，站在系统内部，分析出参与特性实现的相关模块，确定修改范围；

3、确定上述两点后，理清系统边界，确定本Story的交付范围和质量要求，以及依赖的资源；

4、识别出隐性要求，比如性能需求，要求多长时间内必须响应，或者每秒处理用户的多少次操作，或者满足多少用户同时在线操作；比如可靠性需求，识别出用户的异常行为，避免系统承受一定的攻击行为，避免系统崩溃；

5、思维清晰，很有条理，文字比较简单，意义明确，没有歧义，阅读起来很方便。

        另外，项目成员作为一个团队，聚集在一起为了相同的目标努力，为了降低成员之间的学习成本，对于 Story分析的格式和叙事风格应当形成统一的认识和理解，并在项目进行当中随时修正，始终保证文档的可用性。

结尾

        先贤有云，以人为镜，可以明得失。两年前的我虽然也参与敏捷项目，但是理解不深刻，做Story分析时也不上心，总觉得的代码写完、按照提交代码才是王道。自从去年开始指导新进员工，发现新进的员工大多出身理科，口头表达能力还不错，逻辑都比较清晰，但书面表达能力则不能令人恭维。虽然都采用项目组提前准备好的Story分析的模板，但仍然有不少同事输出的Story分析材料存在诸如格式混乱、思维不清晰、表述不严谨、特性丢失、方案不合理等等问题。在指导新员工完成Story分析材料的过程中，我逐渐意识到Story分析方法以及写作方式的重要性，前述小节就是我一段时间内反省后的小结。