作者：陈 昱旻, 软件工程师, IBM
转自：http://www.ibm.com/developerworks/cn/rational/r-cn-jazzrtc20iterations/index.html?ca=drs-cn-0924
Sprint 是 Scrum 项目开发的基本单元，顺利执行好每一个 Sprint 是保证 Scrum 项目成功的基础。在本篇文章中，通过对如何在 Rational Team Concert 2.0（RTC 2.0）中开始一个 Sprint 的完整描述，解释了 Product Backlog 及 Sprint Plan 等相关概念，并详细阐述了如何在 RTC 中创建它们，以及它们之间的关系。最后介绍了 User Story、Task 这两种最主要的 Work Item，以及它们的关键属性。文中还通过结合实际案例，向读者展示了在 RTC 中工作的一些常用技巧以及相关经验。
当要开发的项目在 Rational Team Concert 2.0（RTC 2.0）中创建并配置好以后，我们就可以进入第一个 Sprint 了，这意味所有 Team（开发团队）成员将要开始在 RTC 中进行协同工作。在此之前，我们需要做好以下几项准备工作：
- 所有项目成员已了解并熟悉 Scrum 开发的流程和方法；
- 所有项目成员均已安装 RTC Eclipse 客户端，并可成功连接到 RTC 项目。注意：使用 RTC Web 客户端也可完成大部分日常操作功能，但仍然推荐使用 Eclipse 客户端，因为它功能更全面，操作也更方便。而且，整个团队使用同一种客户端更有利于互相之间的交流和沟通。
- 所有项目成员检查并确认自己的角色及权限设置。
从 Scrum 方法的开发流程中我们可以看到，Product Backlog 是一个 Scrum 项目的起点，它定义了产品的需求列表，是所有后续开发的依据。因此，我们首先需要在 RTC 中创建 Product Backlog。
在前面的文章中，已经提到了我们的项目是开发一个叫做“File Finder”的文件搜索小工具，并且也介绍了整个开发团队的人员构成，各成员的角色，以及项目的开发计划。整个项目一共分成 4 个 Sprint，创建好的 RTC 项目如下图所示：
图 1. RTC 中的 File Finder 项目
Scott 是该项目的 Product Owner，由他来创建 Product Backlog。在上图中我们可以看到一个名叫“Release 1.0”的结点，这就是我们要开发的软件的第一个版本。选中该结点后点击右键，从菜单中选择 NewPlan…，在下面的弹出对话框中选择“Product Backlog”并输入 Name：Product Backlog，其他项保留缺省值，点 Finish 即可。
图 2. 创建 Product Backlog
接下来，Scott 需要往这个新建的 Product Backlog 里面添加用户需求。在 Scrum 项目中，我们使用 User Story（用户用例）来描述用户需求，也就是从用户的角度来定义并描述产品的各项功能，通常它有一个固定的格式，看起来象这样：As a User I want to be able to do …
因此，建立 Product Backlog 的过程也就是将用户的需求转化为一个个 User Story 并确定其优先级的过程。让我们来看看 Scott 怎么在 Product Backlog 中创建第一个 User Story。双击打开刚才建立好的 Product Backlog，在屏幕下方选择 Planned Items 页面，在“Team 1”标题栏上点击鼠标右键，从菜单里选择 Add Work Item Story，一个新行出现了，Scott 输入它的 Summary（标题），然后点“Save”，一个新的 User Story 就创建成功了。
注意：缺省的情况下，Product Backlog 是按 Team 分组显示的。在我们这个简单的示例项目中，所有的项目成员都在一个 Team 内，并且直接使用了缺省的 Team 名称“Team 1”。如果是比较大的开发项目，在这里，你可能会看到更多的 Team 分组。
在这里，你也可以使用快捷键来创建 User Story：选择 Team 1 标题栏，按下 Ctrl + Enter 来打开创建各种 Work Item（工作条目）的快捷菜单，在其中选择 Story。如果在下图 3 的菜单中使用 Set Default…选项预先将 Story 设为缺省 Work Item，那么 Ctrl + Enter 会直接创建 Story，无需从菜单中选择，这给同时创建多个 Story 带来了很大的便利。
图 3 使用右键菜单创建 User Story
图 4. 新建的一个 Story
接下来 Scott 双击打开它进入详细信息页面，我们将会看到一个 User Story 有很多属性，其中最重要的是 Description，Story Points，Priority 和 Owner。但在创建 Product Backlog 阶段，Scott 需要填入的是 Description（详细描述）和 Priority（优先级）。在 Description 部分要详细描述这个 User Story 需要完成什么样的功能，以及用户对界面或性能的要求；Priority 则用来设定这个 User Story 所代表的商业价值的高低，越高的优先级越高，应该最早被开发完成，从而能够更快地得到用户的反馈以便进行适当调整。这也是敏捷开发的核心价值的具体体现。
图 5. Story 详细信息
接下来，Scott 将这个产品的所有需求变成一一个的 User Story 逐个地加入到 Planned Items 视图里，全部保存后就完成了 Product Backlog 的创建。
在 Product Backlog 确定以后，我们开始进入正式的开发过程，也就是开始第一个 Sprint。在 Sprint 开始之前，项目所有成员需要一起召开一个 Planning Meeting 来制定这个 Sprint 的开发计划，也就是 Sprint Plan。那么让我们来看看，在 RTC 中，这个 Sprint Plan 是如何被创建并保存的。
回到前面的图 1，我们可以看到在 Release 1.0 下面列出了所有计划好的 Sprint，Scott 在 Sprint 1 上点击右键，从菜单中选择 NewPlan…，在下面的弹出对话框中选择“ Sprint Backlog”并输入 Name：Sprint 1 Plan，其他项保留缺省值，点 Finish 保存。这个过程与创建 Product Backlog 十分类似，唯一的区别是 Plan Type 的不同。
在会议开始前，Scott 要从 Product Backlog 里选取优先级最高的一些 User Story，作为第一个 Sprint 的备选的开发内容。然后，在会议中，开发团队对每一个 User Story 进行评估，估算开发工作量，最终确定在这个 Sprint 中可以完成哪些产品功能。
如何把备选的 User Story 从 Product Backlog 中移出到 Sprint Plan 1 里来呢？这个操作相当简单，只需要对 User Story 的一个属性 Planned For（见图 5）进行修改即可，从下拉列表中将 Release 1.0 改为 Sprint 1。相应的，如果要把一个 Story 重新放回 Backlog 也只需要再把这个属性值改回来。这种情况发生在当 Planning 会议结束后，开发团队认为在本 Sprint 内无法完成该 Story 的时候。
前面我们提到，每个 User Story 都有四个主要的属性。在创建 Product Backlog 时，Description 和 Priority 已经被输入或指定；那么在制定 Sprint Plan 的时候，我们需要指定的则是另外两个重要属性：Story Points 以及 Owner。
Story Points 是 Scrum 里的一个重要概念，它既不是完成该 Story 所需的具体工作量（人天），也不是单纯的时间量（天），而是对 Story 工作量，或者说难易程度的一种度量方法。独立地来看，任何一个 Story 的 Points 都没有太大的意义，只有通过不同 Story 的 Points 之间的对比，你才能了解一个 User Story 的相对大小。比如，将一个最简单的 Story 的 Points 定为 1，那么你便可以了解到一个 Points 为 5 的 Story 所代表的工作量大约是那个 Story 的 5 倍。
Story Points 的值需要由全体开发成员参与讨论并最终确定，这个值需要得到全体成员的认可。Story Points 的选值不是随意的，有一个固定的序列，通常是 1，2，3，5，8，13，21……关于如何确定一个 Story 的 Points，有一种推荐的“计划扑克”（Planning Poker）的方法可以使用，鉴于篇幅，在此不做详细介绍，有兴趣的读者可以自行参考相关资料。
准确评估 Story Points 的重要性在于——在 Sprint 结束时，通过对所有完成的 Story 的 Points 进行累加，我们便可以得到团队在一个 Sprint 中的开发能力（Team Capacity）的参考值，它将会对下一次制定 Sprint Plan 起到积极的指导意义，使我们的 Sprint Plan 制定得更加合理，从而保证项目开发的有序进行。
在进行评估之前，首先由 Product Owner Scott 对每个 Story 进行解释，澄清团队各成员的问题。Development Lead Eric 在此基础上对原有的 Description 描述进行必要的细化，从开发的角度明确定义该 Story 要做的内容。在全体成员评估结束后，得到合适的 Story Points，并由 Eric 设定 Owner，分配该 Story 给某个 Developer。
在这里，值得一提的还有另一个属性值：Tag（标签）。相信大家对 Tag 一定不陌生，这个在 Web 2.0 时代大行其道的小标签也被 RTC 引入进来，用来给所有的 Work Item 添加必要的附加说明。Eric 给这个 Story 加了一个叫“UI”的标签，以后他就可以利用这个标签来查找所有类似的关于界面开发的 User Story 了。
最后，一个完成的 User Story 的例子如下：
在 Planning Meeting 结束后，各个不同的 Team 可能还会添加一些与产品功能并不直接相关的 User Story，这些 Story 往往是属于 Team 内部的工作，与其他 Team 的工作没有交集，因此不需要在 Meeting 上集体讨论。在这里，我们将这种 Story 称之为 Dev Only 或者 QA Only 的 User Story。比如说：对 QA Team 而言，除了在每个 Sprint 中手工验证新实现的功能是否工作正常外，还需要及时地开发一些 Automation Cases 来方便以后的 Regression 测试，因此，测试工程师 Simon 添加了一个下面的 Story：
注意看这个 Story 的命名，它在前面多了一个“QA –”的前缀。这个前缀可以让大家一眼就能看出这是一个测试组内部的 User Story，其他 Team 的成员可以不用去关心它的具体内容。同时这个前缀也可以方便以后的对 User Story 的查找，以及对查找结果的排序。这个技巧十分有用，尤其是在你的项目比较大，Story 比较多的时候。
同样地，Globalization Team 和 Documentation Team 也会创建一些属于自己的 Story，最后，在 Sprint Plan 视图中，我们会看到很多 User Story，缺省的时候它们是按 Owner 来分组的，每位 Team 成员的名字下显示他所负责的那些 User Story。
对 Scrum Master 或 Team Lead 而言，这种视图并不十分方便，他们希望能将 Story 按不同的小组分类，这样，他们可以一目了然地看到每个组的进展状态，而不用一个成员一个成员地去逐个检查。在 RTC 2.0 中，对这一点有着很体贴的设计，不仅有好几种预定义的显示方案供你选择，而且可以方便地自定制显示方案。
打开 Sprint Plan 视图，注意下图所示的“View As”面板，缺省的时候选择的是“Work Breakdown”，也就是上面说的按 Owner 分组。如果要按小组分类，你需要选择“Team Folders”。如果你想要自定制显示方案，点击“Edit”，就可以进入左侧的详细设置页面，在这里，你可以随意设定自己想要的显示方案。
在 Team Folders 模式下，最初只有两个预定义好的 Folder，它们是“Top Items”和“Defects & Enhancements”，所有的 Story 一般都在 Top Items 下面。因此你需要自己创建代表不同组的 Folder。创建 Folder 相当简单，只要在“Top Items”栏上点右键，选择“Create Folder”，输入新目录的名称就可以了。在为各个 Team 创建了相应的 Folder 以后，就可以把对应的 Story 拖拽进去，最后别忘了 Save（保存）。这样，全部完成后的 Sprint Plan 看起来就象下图一样整洁且分类有序了。
Sprint Plan 的完成，标志着 Sprint 的正式开始。在 RTC 里，我们最后要做的就是将这个 Sprint 置为当前 Sprint，这样，它就会被显示在整个 Plan 结点的最上端，当团队成员登录到 RTC 后便可以清楚地知道当前正在进行的是哪个 Sprint，同时也可以很方便地打开当前的 Sprint Plan。
在最初创建 Scrum 项目的时候，RTC 会自动将 Sprint 1 置为当前 Sprint，因此在进行第一个 Sprint 的时候，我们不需要手动设置。但当进入到下一个 Sprint 的时候，我们就需要打开 Project Area 面板去手动设置其为当前 Sprint。如下图所示，选中一个 Sprint，点击右上角带蓝箭头的按钮。
至此为止，我们确定了 Sprint Plan 并已经创建了所有的 User Story，是不是现在我们就可以着手进行代码的开发及测试工作了呢？不，我们还需要对 User Story 所包含的开发工作进行进一步的细化，将其变成一项项的更小的具体任务。
以我们前面提到的那个 Story 为例，对 Developer 而言，这意味着需要编写新的代码来实现功能；而对 QA 而言，则需要在编码完成后对该功能进行测试，以验证该功能的实现与需求一致。这些任务在 RTC 里都需要创建相应的 Task（任务）来记录工作时间并跟踪完成状态，这些 Task 由负责开发及测试的团队成员自己负责创建。按照 Scrum 理论，为了使每一项任务可易完成，更可控。一般来说，一个 Task 的时间应该控制在 1 天以内。
创建一个 Task 与创建一个 User Story 类似，你可以从多个不同的地方进行创建。通常我们仍然会从 Sprint Plan 视图里来创建它。找到你想要在其下创建 Task 的 User Story，从右键菜单或 Ctrl + Enter 选择创建一个 Task，输入 Summary，接着按下 Tab 键使其缩进，这样它便成为了这个 Story 的子任务，也就是在它们之间建立了父子（Parent-Child）关联（Link）。
创建关联还有其他的方法，包括在 Sprint Plan 视图里拖拽子 Task 到父 Story，或者打开父 Story，在 Links 页面上手动添加子 Task 关联等。总之通过在 Story 和 Task 之间建立关联，我们可以轻松地将 Story 分解成若干小的 Task，并使得它们以树形结构的方式一起展示。
除了将 Story 细化以外，Task 还有另外一个重要功能，哪就是记录工作时间：在创建 Task 的时候，需要填入 Estimate Time（估计完成所需时间）；工作进行中需每天更新 Remaining Time（剩余时间）报告工作进展；在完成后记录 Correction Time（实际花费时间）。这些 Task 上的时间记录，汇总后会反应在其父 Story 的时间指示条上，项目的管理者或 Team Lead 就可以轻松的掌握每个 Story 每天的进展情况。而且通过对 Estimate Time 及 Correction Time 的对比检查，也可以进一步提高对相似 Task 完成时间的估计能力。
在所有的 User Story 都被细分成不同的 Task 并被分配到相应的团队成员以后，接下来要做的就是具体的开发，测试工作，以及如何通过不同成员在 RTC 中的协同工作来达成每个 Sprint 的目标。这些内容将在下一篇文章中为大家做具体的介绍。
Product Backlog 是产品开发的需求列表，也是一个 Scrum 项目的起点； Sprint Plan 则是一个 Sprint 的具体开发计划，它的确定，标志着一个 Sprint 的正式开始。它们是 Scrum 项目中最重要的两种资产。合理规划 Product Backlog，制定切实可行 Sprint Plan 将在最大程度上保证项目的顺利进行。在 Sprint 开始之初，最重要的是将各个 User Story 分解成相对较小的，时间较短的子 Task，这样使得每个 User Story 的完成时间更加可控，有利于项目的管理实施。顺利开始并完成第一个 Sprint 对整个项目具有重要意义，它将为后续的 Scrum 实施打下坚实的基础，并提供宝贵经验。
本文包含解决方案。IBM 授予您（“被许可方”）使用这个解决方案的非专有的、版权免费的许可证。然而，解决方案是以“按现状”的基础提供的，不附有任何形式的（不论是明示的，还是默示的）保证，包括对适销性、适用于某特定用途或非侵权性的默示保证。IBM 及其许可方不对被许可方使用该软件所导致的任何损失负责。任何情况下，无论损失是如何发生的，也不管责任条款怎样，IBM 或其许可方都不对由使用该软件或不能使用该软件所引起的收入的减少、利润的损失或数据的丢失，或者直接的、间接的、特殊的、由此产生的、附带的损失或惩罚性的损失赔偿负责，即使 IBM 已经被明确告知此类损害的可能性，也是如此。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14780873/viewspace-615626/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/14780873/viewspace-615626/
120
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
