00.本用户故事源自于基线编程，所以故事能够很自然地狱基线编程的其他时间形成一个体系。不过，用户故事作为一种管理需求的方法，也可以应用到其他类型的软件过程中。

01.一轮迭代过程是一种持续改进的过程。开发团队首先针对系统的一部分开始开发。团队十分清楚系统还是不完备的，有些地方甚至比较差。

02.一个递增的软件过程是指团队按照功能点开发和发布软件。每个功能点，或者称为功能增量，戴白哦一个完成的功能子集

03.可参考www.controlchaos.com

04.尽管在Scrum团队中可能某些人有特长，如测试人员和数据库管理员，但整个团队总是同舟共济。如果需要完成测试任务，但是没有空闲的测试人员，其他的开发人员也会参与测试。大家共同负责结果。

05.开发团队还有两个承担特殊角色的人员：产品负责人和ScrumMaster.Scrum产品负责人主要负责管理Product Backlog的内容以及排列优先级。ScrumMaster的职能类似于项目经理，只不过他不是管理者的角色，更像一个领导者。由于Scrum团队采取字组织的方式，团队成员自己决定如何完成当前Sprint的任务，因此ScrumMaster更多的是为Scrum团队服务，而不是指手画脚。ScrumMaster主要负责为团队排除障碍，保证开发的顺利进行，确保整个团队按照Scrum的简单规则进行开发。

06.Scrum的主要规则

　　a.在sprint开始的时候召开sprint计划会议

　　b.每个sprint必须发布可以工作的、经过测试代码，这些代码能够完成对最终客户有价值的一些功能

　　c.产品负责人为产品Backlog排列优先级

　　d.团队一起决定一轮迭代完成多少故事

　　e.在热呢还时候都额可以想产品Backlog中添加故事，或者重新排列优先级

　　f.每天有一个Scrum短会。每个项目成员回答三个问题：我昨天坐了什么？我今天打算做什么？我有什么困难？

　　g.只有团队成员能每日Scrum简会中发言，其他人包括对项目感兴趣的观察者或利益相关者都不能发言

　　h.在Sprint结束时的Sprint评审会议中，团队会延时完成的成果

　　i.团队延时的是可以工作的软件，而不是幻灯片

　　j.准备Sprint评审会议的时间不得超过两个小时。

07.整个团队包括产品负责人和ScrumMaster都要参加Spint评审会议。其他任何人（如管理层、客户和其他项目组的成员）如果感兴趣，也可以参加。

08.Scrum是记载第一种包括每日短会的软件过程，这个短会叫每日Scrum简会(Daily Scrum)。其中很多敏捷过程包括基线编程和特征驱动开发（FDD-Feature Driven Developemnt）。

09.会议必须简短，一般在15分钟内结束，最多不超过30分钟。为了保证会议时间不至于过长，很多团队要求参加者站着开会。不要每日Scrum简会演变为成员向ScrumMaster汇报工作的会议。这个会议的一个重要目的是让每个人在自己以及同时前面做出承诺。这个承诺不是想经理或者公司的承诺而是团队成员之间承诺。

10.必须回答：a.你昨天做了什么？b.你今天打算做什么？c.有什么困难？

11.如果团队以外的人员参加会议，需要遵守一个规则，即在会议中有项目组内部人员才能够提问。因此，大老板可以参加并留心倾听，但是他不能在会议上提任何问题，因为这样会干扰会议的顺利进行。

12.用户故事给每日Scrum简会带来的好处是，确保整个团队关注于完成余下面向客户和最终用户的任务。由于在Sprint之前没有需求或者分析阶段，所以在Sprint开始的时候，团队对要完成的任务只有一个大体概念。团队可能知道需要加一个搜索页面，不过他们可能不确定可以用哪些关键字进行搜索，是否支持检索条件组合，等等。

13.在极限编程里面的客户角色，在Scrum中称为产品负责人。