- 用户故事和Scrum
团队需要逐步地完善整个系统，不断地给软件添加更多的细节，软件的功能也由此越来越完备。Scrum是敏捷方法中一种迭代递增的软件过程，实施scrum过程的项目往往采用30天为周期的迭代，称为Sprint，团队确认这个Sprint需要完成的工作，将所有任务放到成为产品Backlog的列表中，团队根据自己的经验从产品Backlog中选择下一个Sprint能够完成的任务，放到另外一个Sprint Backlog的列表中。团队每天都会有一个简单的站会称为Daily Scrum审查团队的进度，并根据需要做出调整。
- Scrum团队
一个Scrum团队通常由4~7个成员组成，Product Owner产品负责人和Scrum Master,以及Development Team开发团队
- 产品Backlog
产品Backlog是指所有待开发产品功能的列表，在项目初期不需要写出所有的功能，通常产品负责人和团队写下一些相对显而易见的功能，随着开发的不断进行，不断对产品Backlog进行调整和扩充。产品负责人负责按照优先级对产品Backlog中的条目进行排序
- Sprint计划会议
每个Sprint的开始是Sprint计划会议,团队和产品负责人一起确定整体的Sprint目标,产品负责人为产品Backlog排列优先级,团队一起决定一轮迭代完成多少故事
- Sprint评审会议
在Sprint结束时,会有一个评审会议上,团队展示在Sprint中完成的工作,大家一起评估是否达到了在计划会议上设定的目标.
- 每日Scrum简会
在每日Scrum简会中,成员需要回答三个问题: 我昨天完成了什么? 今天要做什么? 碰到了哪些问题? 成员每天能够了解项目进展,重视任务分配的情况。
用户故事的优势与不足
在了解用户故事在项目中的实施和运用之后，我们来总结一下用户故事的优势和一些存在的不良的症状：
用户故事的优势
- 用户故事容易理解
- 用户故事的大小适合做计划
- 用户故事适合于迭代开发
- 用户故事鼓励延迟细节
- 用户故事支持随机应变的开发
- 用户故事鼓励参与性设计
用户故事鼓励参与性设计，用户成为软件设计的参与者，做出有价值的贡献。用户故事促使我们重视口头交流，与依赖书面文档的需求方法不同，认为交谈有更重大的意义。
用户故事的不良症状
- 故事太小，用户故事经常需要调整和估算
- 故事之间相互依赖
- 故事中包含太多的细节
- 客户难以为故事安排优先级
总结：
用户故事为软件开发的过程提供了思路，通过不断增加信息以及细节来完善软件的功能。用户故事与敏捷方法的结合，用相对更短的时间、更高效的方式完成软件开发的流程。
用户故事中高效的沟通使客户和团队成员都朝同一个方向前进，并且以更快的速度，更少的消耗来应对快速变化的需求。作者Mike Cohn在软件开发积累的丰富经验使本书充满实用的建议，希望读者们可以运用敏捷的优势，通过用户故事向客户持续的输出商业价值。