为什么要用户故事？

高校软件需求是一个沟通过程。需要用户与开发人员共同交流。一个项目的成功，依赖于多方面的信息取舍。在沟通过程中，一旦任何一方在沟通中占据了绝对地位，项目就会遭受到损失。如果业务方把持主要地位，他们就会关注软件的功能和交付日期，却很少关注开发人员是否能够同时满足这两个目标，或者开发人员是否确切的了解需求，以及有限资源与技术的局限性。如果开发人员把持了绝对地位，技术术语就会代替业务语言，从而导致开发人员无法倾听业务方面的实际需求，或在功能实现时打折扣。

我们需要一种风格，一种协同工作的方法，让双方都不占据绝对主导地位，共同面对软件需求及开发、测试全过程。这就是用户故事。

什么是用户故事？

用户故事描述了对用户、系统或软件购买者有价值的功能。用户故事一般由几个要素：一份书面的故事描述，用来做计划和作为提示；有关故事的对话，用于具体化故事细节；测试，用于表达和编档故事细节且可用于确定故事完成时间。比如网上报修的用户故事卡可以是这样的：

1.      完成师生用户的网上报修功能

    1.1   公寓水电报修

        1.1.1         选择楼栋、房间号、报修水电。

        1.1.2         可以上传图片

        1.1.3         可以自动派单

    1.2 家具报修

    1.3 房屋报修

用户故事里有史诗级别的故事，“我们要完成一个互联网+后勤服务管理系统”，史诗级故事可以分成多个长篇故事，再进一步分为章、节、段……过去客户只是写下这些细节，现在，我们让开发团队和客户讨论这些细节，即在这些细节变得重要时讨论。在我们的开发过程中，故事也并不是契约性质，达成的协议将由测试来记录，这些测试将演示故事是否被正确开发。系统的有效开发，有赖于团队的平衡，用户与技术、与投入资源的平衡。

传统开发使用瀑布模型，从书写需求、分析需求，到确认需求，转入设计方案、编码、最终测试，前期主要是用户，后期主要是技术人员。如今，这种方法并不理想。对于故事驱动的项目而言，最吸引的是客户与用户在整个过程的全程参与，技术人员与客户和用户形成平衡团队。软件的客户和最终用户在编写用户故事时承担着活跃的角色，尤其是在团队使用极限编程进行软件开发时。因技术人员的参与，编写故事时又增加了系统与技术的考量。

客户团队和开发团队共同选择一个迭代长度，可能是一周到四周的时间，根据不同的故事难度和工作量及时调整与修正。每一个发布又由一个或多个迭代组成。进行发布规划时，客户团队根据对特定特性的渴望程度，故事之间的关系及其他需求的满足。

测试是用户故事开发模式的重要一步，用来证实现实用户的故事及技术人员开发时候符合真正的需求。测试安排在迭代过程之中，从早期到发布之前。

我们为什么选择用户故事和敏捷方法：

1）用户故事强调对话交流而不是书面沟通；

2）用户故事可以同事被用户和开发人员理解；

3）用户故事的大小更适合做项目计划；

4）用户故事使用与迭代与敏捷方法；

5）用户故事让信息化更理解，服务更精准。