【标题】：用户故事与敏捷方法（下）
【字数】：827
用户故事也写有几章，今天我尝试直接跳到最后两章，看一下具体Scrum是怎么与用户故事产生故事关联的。学了这么久的道法，切换一下器术。
1、Scrum是迭代是递增的
用户故事是管理需求的方法，当然是可以和Scrum结合在一起使用，与极限编程类似，Scrum也是一种迭代递增的软件过程。虽然极限编程经常出现在我的身边，但是我确实忘记了去了解这个敏捷方法。
迭代是递增其实很容易理解，因为我们每天都在做这个事情。一个系统，不可能一次性就能完整的做出来。我们都是针对系统的一部分进行开发，经过严谨的测试，保证当前开发的功能是完整实现和测试通过的，减少了到最后返工的几率。一轮迭代的过程是一种持续改进的过程。
2、Scrum的基础
3个角色：产品负责人（PO）（负责确定项目需求，维护PBIs）、Scrum Master（SM）（负责主持会议，排除团队遇到的困难以及外界的干扰）、Scrum Team（整个开发和测试团队）。
3个产出：Product Backlog（产品功能列表）、Sprint Backlog（Sprint冲刺列表）、燃尽图。
4个会议：Sprint计划会、每日站会、Sprint评审会、Sprint回顾会。
3、Scrum团队
Scrum团队采取是自组织的方式，团队成员可以自己决定完成什么任务，SM更多的是服务团队成员，为团队搜请障碍，保证正常开发，而不是指手画脚。
说到这里，其实看起来好像不是很贴近实际，毕竟，你没办法判断每个人是否真的已经完全接受了Scrum的敏捷流程，所以我觉得SM还是需要一定的领导力或决策能力，才能避免这个风险的产生。
4、Sprint计划会议
Sprint计划会议的核心就是让全员都参与到用户故事的讨论中来。
会议上，产品负责人主要介绍高优先级的条目，优先级低的可以放在后面的Sprint讨论。会议上确定好Sprint目标，然后针对每一个目标确定当前团队能完成工作总量。一般来说，一旦在计划会议上确定了工作量，任何人（包括CEO）都不能让团队去做产品负责人没有提出来的工作。
5、最后
Scrum 让一群共同拥有所有技能和专长的人员参与进来完成工作，并根据需要分享或获得所需技能。
Scrum是一个框架，指导我们从项目发起到发布一系列过程，在框架里面的每一步，用户可以根据自己的需要完善内容，实施它。
今天更多的是加深一下对Scrum的印象，真正能完全掌握的，还是需求团队去试用，不断在使用中找到可以优化的问题，团队和个体才能不断进步。
