今天花了一天的时间，仔细的了解了一下Scrum方法。 其实很早以前（1-2年前吧），就听说并接触过Scrum方法，但是仅仅停留在了``听说"而已，没有真正的实践过。
Scrum是什么呢？ 套用介绍文章中的定义: ``Scrum has a simple implementation that is designed to increase productivity and reduce the time it takes to benefit from a software/product development. Importantly, it embraces adaptive and empirical systems development. "。用中文定义来说，就是: ``Scrum提供了一种经验方法，它使得团队成员能够独立地，集中地在创造性的环境下工作。它发现了软件工程的社会意义。这一过程是迅速，有适应性，自组织的，它代表了从顺序开发过程以来的重大变化"。
这种定义其实非常的``空洞"，关键在于Scrum的实践:
1. Scrum团队（5-7个人的小项目组）。 团队的负责人可能担负起Scrum Master的角色。
2. Backlog: 急待完成的一系列任务，包括：未细化的产品功能要求、Bugs、缺陷、用户提出的改进、具竞争力的功能及技术升级等，按优先级定义出来，这些任务可能不是完整的，甚至可能随时会更改或添加。
3. Sprint(冲刺): 通常为30天的迭代时间，把Backlog中的每一项安排在Sprint中，由团队估算出所需要的时间（按小时记）。 每一次Sprint之后，一定要有可以交付使用的功能。
4. Scrum会议: 这是与传统方式最大的区别，每天15-20分钟的Scrum会议，通常在每天的同一时间和同一个房间内举行(通常在午饭后举行)。 Scrum团队所有人都参加，也可以有旁听者（但不允许旁听者指手划脚）。 在这个15分钟的会议上，Scrum Master会询问每个成员三个问题:
a) 自上次Scrum会议后的1天里你做了什么？
b) 从现在到下次Scrum会议的1天时间里你准备做什么？
c) 你在工作中遇到了哪些困难？
每个成员在Backlog条目上所花费的时间会被记录到Spring backlog中。 Scrum Master在会上对存在的问题提出即时的解决方案或指导，使团队不断向着目标前进。Scrum会议不同于项目会议，对团队来说，它起到了快速简报的作用。
5. 通过Sprint Backlog的分析，可以了解Backlog的进度，尽早的了解所发生的问题
6. 管理者不在是项目或者团队的``老板", 而是帮助团队解决问题的``协调者"或是``助手"。
7. 每一次Sprint之后要review，团队按照既定的Sprint Backlog目标来演示完成的内容。
今天读了这些介绍Scrum方法的文章以后，才发现，其实在过去一段时间的产品开发和项目管理中，或多或少的在方式方法上，受到了Scrum的影响，但大部分是定性的在使用，比如: 每个月底会review这个月的工作，然后安排下一个月的工作(有点类似于制定一个Sprint Backlog)。 每周会详细的了解开发进度，解决问题(太过粗矿的Scrum Meeting)。 但是，我们并没有定量的使用这种灵巧的开发方式，比如: 没有为每项需求或者功能仔细的预估时间，对进度的了解过于粗粒度了而造成有时无法尽早了解发生的问题，没有一个直观的数据分析来协助团队了解总体的进展。
我想，我们会逐渐的在开发和实施的项目中开始使用Scrum这种敏捷的方式，也许先从个别的小团队开始尝试实施。
【参考链接】
http://www.controlchaos.com/about/
http://www.methodsandtools.com/archive/archive.php?id=18
http://wiki.scrums.org/index.cgi?HomePage
http://www2.cnblogs.com/jackyrong/archive/2006/07/09/446282.html
http://epjnpe.cnblogs.com/archive/2006/06/30/440034.html