轻松Scrum之旅：敏捷开发故事（一）

初识敏捷，接触到下面这些这些新词汇。

• Scrum
• ScrumWorks
• Product Backlogs
• 每日Scrum会议
• Scrum会议回顾
• Scrum会议评审
• Sprint
• User Story
• 持续集成

1）Scrum

Scrum来自英式橄榄球，敏捷开发的团队就好比一只橄榄球队，他们拥有明确的最高目标，而且每时每刻都朝着目标努力，他们熟悉最佳实践，高度自我管理，高度协作，高度灵活的应对各种挑战。

2）ScrumWorks

ScrumWorks 是一个专门针对 Scrum 项目管理的商业软件，右边部分记录了所有的 Backlog，左边是每个 Sprint 对应的产品 Backlog 列表。每个 Backlog 都可以用 User story 来描述。针对每个 Backlog，ScrumWorks 提供了丰富的属性，比如商业权重(Business W e i g h t )、 投 资 回 报 率 ( R e t u r n O n I n v e s t m e n t ， R O I )、 收 益 ( B e n e f i t )、 惩 罚 ( P e n a l t y ) 等。根据这些属性可以帮助制定 Backlog 的优先级。

需要及时更新一下 ScrumWorks 上的 状态!

（ IBM Rational Team Concert 和 ScrumWorks。这两种工具都可以帮助我们有效地管 理 Scrum 流程，尤其适合地理位置不在一起的多个团队使用，能够大大增强 敏捷流程的可视化。）

3）每日Scrum会议

每日 Scrum 会议(Daily Scrum)，即团队每日例会，条件允许的话，每天都应该在 同样的时间和地点，组织所有成员站立举行，一般以站立的状态开会， 因此时间比较短，一般为 15 分钟左右。这个会议最好是在每天的早晨开，有利于团队 成员们安排好当天的工作计划。只有团队成员可以在每日 Scrum 会议上发言，其他人 员如果对项目进度有兴趣也可以参加，但只能旁听而不能发言。

团队所有成员都通过这个会 议同步信息，每天的问题都能及时发现，并能用最快的速度解决。另外，能 够形成一种相互之间的压力，每个人要对自己当天承诺要完成的事情负责， 每天都不敢怠慢。过去我们通常只是一周开一次例会，汇报一下状态，效率 就低多了。Daily Scrum 还给整个团队带来了凝聚力，每个人都觉得自己是团 队不可缺少的一员。

4）Scrum会议回顾

Sprint 回顾会议由产品责任人、Scrum 团队和 Scrum Master 参加，会议中需要讨 论有哪些好的建议或方法应该被采纳，在 Sprint 中有什么做法不可取，有哪些做法效果 很好，应该继续下去。

Sprint 结束后，Scrum 团队回顾刚结束的 Sprint，对其进行总结和反思，使整个团 队能持续成长。

5）Scrum会议评审

Sprint 评审会议在 Sprint 结束时召开，由开发团队展示这个 Sprint 中完成的功能， 长度为两个小时左右，不需要 PPT，一般是已经完成功能的 Demo，而且客户、管理层、 Product Owner 以及其他开发人员等都可以参加。

在每个 Sprint 结束时，应该组织一次 Sprint 评审会议。Scrum 开发团队将在会上 展示他们在这个 Sprint 中所做的工作，一般采用向大家演示产品新功能的方式来展示。

相对来说，Sprint 评审会议不必很正式。通常不需要用到 PPT，而且长度最好控制 在两个小时之内。也就是说，不要让 Sprint 评审会议成为 Scrum 团队的负担，不必让 他们花太多时间来准备这个会议。

在 Sprint 评审会议上，Scrum 团队用 Demo 的形式展示产品的新功能之后，与会人 员依据在 Sprint 计划会议上确定的这个 Sprint 的目标来评审具备了这些新功能的产品。

为什么一定要用 Demo 的形式来展示产品的新功能呢?

• 参与会议的人都能直观地看到 Scrum 团队的工作成果;
• 其次，利益相关者们可 以据此提出更切合实际的反馈意见;
• 第三，为了完成 Demo，团队会努力完成并发布那 些功能，即使只是发布在测试环境下，也比没完成的好。如果不做 Demo，也许不少功 能会停留在“已完成 99%”的阶段。相比较起来，在有 Demo 的情况下，也许“已完 成”的功能数量会相对少一些，但它们是确确实实完成了的。否则，那些“99%”的貌 似完成的功能势必还要拖到下个 Sprint 来解决。

6）User Story

Sprint Backlog 里的项目我们通常用 User Story 来描述，User Story 是从用户的角 度对系统的某个功能模块所作的简短描述。一个 User Story 描述了项目中的一个小功 能，以及这个功能完成之后将会产生什么效果，或者说能为客户创造什么价值。

User Story 要由 Stakeholder 来编写。User Story 的形式很简单，人们可以很容易 地掌握编写 User Story 的方法。这样就可以保证是由与项目相关的领域专家们来写 User Story，而不是开发人员。

User Story 有一个通用的公式格式，大家可以套用一下试试，很简单。 作为<某个角色>，我可以<做什么>，以完成<什么目的>。

为了能及时、高效地完成每个 Story，Scrum 团队会把每个 Story 分解成若干个 Task。 每个 Task 都是可以在明确的时间内完成的，而且时间是以小时为计量单位的。

特别提示:每个 Task 的时间最好不要超过 8 小时，就是要保证在 1 个工作日内完 成，如果做计划时发现有些 Task 的时间超过了 8 小时，就说明 Task 的划分有问题，需 要特别注意。

7）测试方面

我们采用敏捷开发，测试很早就介入了，这样就再也不会出现半年多测 试部门无事可做，一旦介入便疯狂加班的情况。开发人员也不会由于要更改 很久以前的 Bug，而把很多时间和精力花费在回忆上。而且一旦发现重大的 问题，也不会出现疯狂加班的情况。由于测试的提早介入，开发人员可以立 即解决问题，还能够有效地调动测试人员的积极性和主动性，让他们也参与到软件的设计中来。在敏捷开发里，测试和开发的交流更多了。测试和开发 不再是两个孤立的部门，而是真正意义上的团队，这有效避免了过去测试和 开发之间一些消极的争斗和不合作的局面。

性能测试也是系统测试的一种。关于系统测试的介入时机问题，常见 的做法是在第 N+1 个迭代测试第 N 个迭代的功能。

8）文档方面

在文档管理方面，我们摒弃了过去烦冗的文档管理，节省了大量的时间 和精力。需求、计划以及设计文档我们通常只保留一个一页多的版本，并且 放在 Wiki 这样的敏捷文档系统上，任何人、任何时候都可以更新它。而且， 由于文档只记录必要的信息，所以不需要再像过去那样花大量时间保持同步， 不断修改。

7）实施 Scrum 这种敏捷方法的清单列表

• 一个具有优先级的Product Backlog，每一个Product Backlog用User story来描述，制定优先级和预估完成工作量。
• 确定团队构成，最好集中开发，方便面对面交流，团队人数5-10人左右。确定Scrum Master人选。
• 确定每一个Sprint周期。2周-2个月都可以，不宜超过2个月。
• 召开Sprint会议，把每一个Sprint要做的工作从Product Backlog按优先级排序，确定需求，将任务进一步分解，如人员分工。
• 每日Scrum会议，每天选择固定时间固定地点，15分钟左右即可。团队成员站着交流汇报，每人阐述三个问题：我昨天做了什么？我今天打算做什么？我遇到了哪些困难。

 

其他小tips：

1. 敏捷和Scrum倡导团队自我管理，在任务分配上倡导每个人按照兴趣和能力住选择任务。
2. 不要隐瞒团队的技术实力，否则很难做切合实际的计划和评估。
3. 无论以什么方式，尽早让客户参与到 Sprint 中来，无疑可以增加成功 的砝码。
4. 持续集成是敏捷开发中核心的工程实践，它是敏捷产出“可以工作的 软件”(Working Software)的有利保障。
5. IBM Rational Team Concert 是一个功能强大的、能够支持各种敏捷框 架的项目管理工具。