SCRUM is a good thing.--a simple intruduction about the scrum

Scrum是一种灵活的软件管理过程，它可以帮助你驾驭迭代，递增的软件开发过程。这个轻量的过程可以作为包装器，也就是说你可以把Scrum与其它灵活的过程框架组合起来，比如说RUP。

RUP（Rational Unified Process，Rational 统一过程），是一种被广泛使用的软件过程框架。它可以很好地迎合你的软件开发过程的需要，还可以容纳其他技术。Scrum是一系列有趣的，用来包装灵活软件项目的项目管理模式。

Scrum 提供了一种经验方法，它使得团队成员能够独立地，集中地在创造性的环境下工作。它发现了软件工程的社会意义。这一过程是迅速，有适应性，自组织的，它代表 了从顺序开发过程以来的重大变化。Scrum认为软件的开发不应使用和一般制造业相同的方法，也就是不应采用一种反复的模式。这种重复使得输入和输出参数 更加容易预测和描述，但这并不是当今软件工程的有益目标。现代软件工程的主要挑战包括上市时间，投资回报，以及影响顾客的需要等。RUP和其他敏捷软件工 程过程能够很好地迎接这些挑战。

Scrum区别于其他开发过程之处是什么？最显而易见的不同将是每天的短会，通常在每天的同一时间在同一个房间内举行。这个会议也叫Scrum，在会议中每个团队成员仅就以下三点发言：

自上次Scrum会议后你做了什么？
从现在到下次Scrum会议的时间里你准备做什么？
你在工作中遇到了哪些困难？

Scrum团队的组成
由 于一个Scrum团队最多由7人组成，会议应当不超过15分钟。Scrum管理者*主持会议，并且对整个项目的成败负责。他倾听每个成员的发言并设法解决 会议中提到的各种障碍。Scrum管理者在会上对障碍提出即时的解决方案或指导，使团队不断向着目标前进。Scrum会议不同于项目会议，对团队来说，它 起到了快速简报的作用。如果问题得不到解决，团队成员应向Scrum管理者或大项目成员提出质疑。

只有团队成员可以在Scrum会议上发言，但是允许有旁听者。对于人数多于7人的项目团队，Scrum建议与其扩大团队规模不如将团队分组。分组可 依据功能，结构主体，或者应用，包括子应用等进行。分组后各个子团队就可以并行工作了，而且Scrum管理者可以通过Scrum会议对各个子团队的工作进 行同步。Scrum甚至可以兼顾在其他地方工作的团队成员。

Scrum团队不止是一个程序员队伍，它由各种背景下的不同角色组合而成，包括商业分析者，设计师，程序员和测试者等等。更多时候，成员可以身兼多职；正确的组合决定了团队的能力和效率。

项目规划
Scrum的迭代过程被称为“疾跑”，时间为30天。在RUP中，迭代过程通常在2至6周之间，每次“疾跑”都以获得可执行可测试的代码为结束。

产品拥有者持有产品订单，他控制并区分功能的开发次序，但是工作量的评估是由Scrum团队来完成的。产品风险的所有承担者，包括Scrum团队和产品所有者，共同检视订单，然后根据优先级次序决定先开发哪一功能。除去优先级，RUP的迭代规划过程也是基于风险的。

现在团队定义的“疾跑”目标已经成为了进展控制的指导。“疾跑”过程一旦开始，团队全部与外界的交流都必须经由Scrum管理者进行。Scrum管理者务必保证团队能够专心于既定目标而不受外界干扰。

Scrum团队持有自己的“疾跑”订单，上面记录了更多关于待实现目标的具体任务的细节。在团队对“疾跑”的作用有更多了解以后，团队成员就可以调整原始的产品评估，并将“疾跑”过程中获得的信息加入到产品订单中。这些做法对Scrum进度回溯都是有益的。

Scrum团队由每天的Scrum会议，每月的“疾跑”计划和“疾跑”审查会议紧密相连，鉴于此，整个组织必然存在一种纵向的透明度。这就使得组织 上的问题和挑战清晰明显。由于团队成员都亲自观察整个项目，交流也就变得简短，迅速和有效。团队是自组织的，着眼于“疾跑”的目标，这样就最大限度发挥了 每一个团队成员的作用。Scrum管理者充当一个问题和交流的“票据交换所”，而不是一个控制整个团队的老板。

“疾跑”审查会议持续半天。在会上，团队向项目的风险承担者展示完成的功能模块。团队按照既定的“疾跑”目标来演示完成的内容。

订单，“疾跑”计划和回顾，管理承诺，每日Scrum会议，进度回溯，以及其他Scrum技术都是基于主要用于软件项目管理的进程模式的。这些模式在过去的大小项目和不同商业领域中都获得了成功。