- 用户故事和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在软件开发积累的丰富经验使本书充满实用的建议,希望读者们可以运用敏捷的优势,通过用户故事向客户持续的输出商业价值。
标签:故事,读书笔记,Scrum,用户,敏捷,Sprint,团队,Backlog From: https://www.cnblogs.com/joranger/p/17326832.html