Scrum，XP中的一种软件开发模式，是迭代式开发的一种具体实施方式。Scrum的详细定义可去wikipedia查询，这里只作一个笔记式要点记录。
使用Scrum方法开发一个软件，首先要有一个Backlog，这个Backlog是一个或者多个(User) Story的集合。这些story就是开发过程中我们必须完成的事情，也就是说Backlog定义了我们要实现什么。Scrum进行迭代式开发，一个完整的Scrum过程分为一个或者多个Sprint来完成。在所有列出的Story中，首先进行优先级排定，然后选择一些高优先级的Story，作为第一个Sprint要达到的目标。在Sprint中，又将这些Story在具体化为多个更贴近代码的Task，并将Task划分给具体的人去实施。完成一个Sprint之后，进行测试和总结，验收前一阶段的成果。然后再从Backlog中挑选未完成的Story作为第二个Sprint的目标。不断的重复这个过程直至所有的Story都被实现。Scrum讲究灵活快速的开发风格，所以每一个Sprint都不宜太长，一般一个Sprint控制在3－6工作周。
以下为我的一些认识，以及一些经验人士的实施体会：
1. 在进行开发之前，首先要做的事情是定义你需要什么东西。也就是常说的产品定义、功能定义或需求。在软件工程中，这三者是有区别的，但是在Scrum中Backlog仿佛却是三者的混合。项目一开始，Backlog中的Story可能只是一些很简单抽象的客户需求。经过分析，需要将这些需求式的Story转换为产品定义式的Story，最终转换为可以作为Project实施指导的功能式（产品特性）的Story。所以，Story是一个变化的过程，而不是一开始就设定好。
2. Scrum重过程，轻文档。倾向于在实施过程中不断修正方案（重构），而不是在开头做一个足够良好的设计。
3. Scrum重视Project实施中的细节，要求成员之间每天进行沟通和交流（5分钟晨会）。
4. Story中应该尽量详细的描述为什么要做这个Story，做什么，完成之后我们可以得到什么。如果不知道Story该怎么写，说明对Project理解不够，需要进一步的研究之后才能开始编码。
5. Story细化为task时，如果不知道如何划分或划分很困难，则应审视设计，或者重新理解产品
6. XPlanner，一个根据Scrum过程编写的项目工具
7. Scrum是一个项目过程控制方法，而不是一个员工绩效考核系统。由于Scrum过程中强调对具体task的精细划分，常常会被成员，尤其是不熟悉Scrum的成员误会，认为这是一个严厉的绩效考核体系。其实，Scrum重项目的完成情况，而不重个人的实际工作量。相反的，Scrum对于个人相当宽松，它允许拟定的工作量完不成，允许对原计划进行修订。因此，必须通过一定的方法使项目成员明白Scrum的作用。
8. Scrum作为项目管理的方式，其理想的方式在于每一个Sprint都能得到比上一个Sprint更进一步的产品。这种逐步求精的迭代式开发使得我们在短时间内就能得到一个部分可用的产品，然后逐步完善功能，最终形成产品。这使得及早发现产品的潜在问题和进行重构成为可能。
9. Scrum适合作为中小规模软件产品和小团队开发。对于大型产品来说，Scrum仍然有其用武之地，因为这类产品的开发也通常会划分为多个不同的小模块。
10. 开发人员在Scrum中相对平等，对于细化的story、task，Scrum鼓励开发人员按自己的兴趣和能力进行选择。
11. 每task的工作量控制在2－3天，利于发现问题，控制节奏
12. 划分task应尽量保持task的独立性，减少task之间的依赖
13. 一个团队初次使用scrum时必然会遇到各种各样的问题，比较典型的问题有对工作量不能准确估计等。一般来说需要3－4个月的实践，才能完全进入状态。
14. 一般按6小时/天来估计日工作量，留出必要的开销
15. 一个Story划分为多个task完成，出于各种原因，有可能不能完成。这是需要将原Story根据完成的部分划分为两个Story，一个作为本Sprint的部分，另一个则留到下一个story。原则上来讲，一般不会延长Sprint的时间，一个Sprint中未做完的部分都应该采用这种方式形成新的story留到下个sprint完成。以求保证scrum以良好的节奏前进。
16. 对于story优先级的划分相当重要，划分的原则可根据开发需要和客户需要量方面确定。
17. 鼓励由成员自己来估计每一个task的工作量，而不是由某个leader来指定。这样成员的开发积极性可能会更高。当然，这可能需要一段时间才能做到准确估计，也需要高级工程师必要的指导。
18. Scrum是动态的，story，task，工作量都需要根据实际情况变动，而不是固定不变的。随着项目的进展，以及对项目理解的深入，这些都会变动。
19. 通常也会把做计划本身当作一个story，放到sprint中完成
以上转自 ： http://goldencz.spaces.live.com/blog/cns!bdf1adf5c4d1f962!668.entry
一直疏忽了实践，理论也会忘却，今天竟然犯了个错误，在类库开发中，让同事去写story，概念都有点错，
所以分清，Backlog，Story，Task；另外应该直接去写需求，让他们去发掘需求，进而实现需求。