Gitee 企业版于不久前推出了 Scrum 项目模板，Scrum 项目模板针对 Scrum 流程进行了针对性的组件设置和新特性的开发，确保研发团队在进行 Scrum 实践时的流畅顺滑。

本篇文章将着重介绍如何使用 Gitee 的 Scrum 项目模板来提高团队的敏捷研发协作能力。

一、敏捷概述

1.敏捷是一种团队能力

在开始之前需要声明，敏捷不是一种方法论或者工作方式，而是一种可掌握的能力。我们通常所说的敏捷团队转型，更应该称之为团队作为一个整体，来学习敏捷这样的能力。

传统的开发模式例如瀑布模型、喷泉模型、螺旋模型等等，虽然有不断的进化与创新，但不具备足够适应日新月异的市场变化的能力。

为了面向市场不断提出的需求，IT 行业发展了很多轻量化的软件开发方法，比如 Scrum、水晶清透法、极限编程法等等，因为他们都是迭代和增量式的开发，即使是起源于敏捷开发宣言之前，但都可以统称为敏捷软件开发。

各种敏捷开发方法的差异在于理念、过程、术语不同，但相较于“非敏捷”，它们都更强调团队间的紧密协作、面对面的沟通、频繁的交付新版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发过程中人的作用。

2.敏捷开发价值观

• 个体和互动高于流程和工具

每一个敏捷项目成员都知道即将做什么以及项目进展如何。

• 工作的软件高于详尽的文档

团队更需要编制易于阅读的文档，来对系统及其设计决策的依据进行描述。

• 客户合作高于合同谈判

投资于产品并运行项目的人应该定期评估该产品和流程。

• 拥抱变化

对细小问题做快速调整，如果数据反馈表明你应当做出改变，那么请立即改变。

3.敏捷开发的特点

相对于瀑布开发而言，转型成为敏捷研发团队具有小快灵的开发能力，具体体现在：

• 小，每一次版本发布时间可缩短为1~4周；
• 快，对需求处理快速决策，快速处理；
• 灵，团队节奏灵活多变，可以随时调整工作节奏来适应快速变化的市场需求。

敏捷是定期的，不是一次性的，我们都会经历产品或服务的迭代优化，因为市场在变化、用户需求在变化，根据市场反馈来对需求进行验证和矫正，以灵活敏捷的改变调整去适应变化，在一次次持续迭代中达到最终目标。

所以对于团队来说，与其努力创造完美的产品或服务，不如通过版本的迭代来不断改进。

一个软件交付计划可以被划分成多个迭代，每个迭代结束时必须能得到可交付程度的功能。若团队在2次迭代执行完成后，仍然存在无法按时交付/交付不完整的需求情况时， ScrumMaster 应该适当延长迭代时间。

4.敏捷角色介绍

• 敏捷团队：即负责软件开发的跨职能团队，包含了产品经理、设计师、程序员、架构师、运维等角色，一个产品可以由多个敏捷团队分模块共同创建；为保证沟通质量，一个敏捷团队一般会控制在5-9人，人数太少则生产力受限，人数太多则容易增加沟通成本。
• 敏捷教练（Scrum Master）：作为管理整个敏捷流程的领导者，SM的作用是提高团队工作效率，尽量降低外界干扰，促进各方打成团队目标一致。
• 利益相关者:用户、客户、股东及管理层等等，他们会受到产品交付成果的影响，同时他们也能影响着产品决策。
• 产品负责人（PO）：负责敏捷团队和利益相关者的连接，梳理、拆解、估算需求，确保产品列表对所有人可见、透明、清晰，帮助团队成员清晰理解需求和目标；中小型企业多以产品经理（PM）负责，一些大型To B企业则是由业务分析师（BA）负责，具体情况视产品属性及体量规模而定（在本文统一使用“PO”这一称谓）。

二、需求规划

1.项目

首先，我们先新建一个项目：

项目可以是持续提供服务（longterm）的C端项目，也可以是阶段性交付，具有一定生命周期的B端项目。通常来说，团队会开发一个新项目，同时维护几个老项目。

2.Epic史诗故事

新建完成后，我们直接进入规划页面创建我们的第一个需求：

如果已有任务可使用Gitee任务导入功能，直接从任务模块导入。

导入完成后，我们就有了1~2个需求（Epic层级）。

史诗（Epic） 是一个大功能的集合，通常能够提供一个完整的系统，一般是通过一个或多个迭代才能完成，以此来决定业务方向。

由于它非常大，无法或不容易进行估算，这时需要对Epic层级需求进行进一步拆分，做到可执行的Story层级，这里提供一个简单拆分示例:

例如我们在刚才的商城平台中，“商城”决定了我们下一步业务方向将围绕着电商展开。
拆分Epic，可以在商城（Epic）中新建子任务（Feature）：

本次示例中，最终拆分出4个Feature（特性），分别是：
商家管理端、用户端、测试任务、后台规则。

3.Feature特性

特性（Feature） 是指逻辑上相关的功能需求的集合，给用户提供一定处理能力的产品，并满足对应业务需求。

之后可以采用同样的方法，可以一直拆分到Story层级。

4.Story用户故事

用户故事（Story） 描述的是一个情景，尽可能贴近操作人员的真实需求，用户可以轻松地对用户故事进行排序，下面是一个用户故事编写方法参考：
作为 我想要做 ，以便<实现 z的好处>。

例如：
作为一个管理员，我想要一个优惠券管理模块，以便实现对用户发放优惠券的功能。

在通过一系列需求评审之后，可在用户故事下拆分成可执行的任务/子任务，方便开发人员理解。
开发任务拆分完毕并指定好负责人，前期需求规划准备工作均已完成。

三、迭代准备

迭代功能对应敏捷开发流程中的“迭代（Sprint）”流程，迭代与版本（详见版本章节）都是管理单元，用于在一个时间范围内（通常为1~4周）同时管理产品目标、团队容量和交付进度。

1.新建迭代

我们可以先从新建一个或多个迭代开始：

团队可以根据需求池中的内容，通过迭代规划功能评估一次/多次迭代的内容。

为了方便评估工作量和实现难度，在开始迭代之前，产品经理（PM）需要联合敏捷教练（ScrumMaster），研发成员（RD）进行一次需求评审。

为了更好地贴合敏捷团队，我们特别在迭代中增加了文档模块，方便记录：

2.需求讨论&评审

需求评审时可以打开自动生成的“评审记录”来编写会议纪要。

评审的目的是为了评价需求可行性，需求功能、需求交互设计和预估团队的开发工作量。

四、敏捷团队之旅

若要开始一个迭代，可以在迭代详情内点击“开始迭代”。

迭代开始时，系统会记录一次任务数量，可在团队速度报表中查看，详见第六章回顾与总结；

迭代开始后，研发团队可根据实际完成情况，改变作为负责人的任务状态。

迭代执行过程中，可以通过迭代文档中的站会记录完成敏捷研发的站会流程。

迭代过程中若出现紧急插入需求或超前完成的情况，可以通过迭代内的规划功能进行调整。

迭代结束当天，由敏捷教练（ScrumMaster）牵头，使用迭代内置的回顾记录模板开展一次回顾会议，总结迭代进行过程中团队优秀的点和需要改进的地方，同时可以列出对应优化方案。

由迭代负责人点击“结束迭代”按钮，完成这一阶段的工作。

五、发布版本

1.版本介绍

版本虽然与迭代一样作为任务的集合单元存在，与迭代不同的是版本只强调功能产出。
作为产出规划型工具，可以根据需要进行版本紧急发布或计划发布，以下是三种常见的发布方式：

1.每日发布（迭代1:N版本）

2.迭代周期发布（迭代1:1版本）

3.多迭代发布（迭代N:1版本）

2.版本发布

首先新建一个版本。

新建完成后如图所示：

点击右上角规划任务按钮，可以将想要发布的任务添加至版本内：

添加完成后，我们默认了3个环境：开发环境-测试环境-生产环境，悬停在横线上，可以根据需要添加新的环境。

点击图标，可以修改版本的发布状态。

当最右侧一个环境完成时，版本发布结束。

六、团队回顾与总结

伴随着一次次的迭代和发版，团队的进步也是管理者所关心的问题，我们特别策划了针对团队效能的报表，以反馈团队的健康状态。

1.团队速度报表

通过观察每期迭代评审需求数量和完成需求数量，判断团队的风险承受能力（既定工作是否受影响）。

2.成员负荷报表

了解迭代中各个成员的工作负荷情况，合理优化团队成员的工作安排。

Gitee 企业版的 Scrum 模板通过产品功能和敏捷流程中不同角色、步骤、工作的有机结合，来培养和提升团队的敏捷能力的同时反哺团队的工作效率。如果你的团队正在或准备使用敏捷流程来进行项目管理，那么 Gitee 企业版的 Scrum 模板将会是一个十分优秀的上手选择。

---

Gitee 企业版不仅能为需求管理、迭代规划、进度跟踪等经典 Scrum 环节提供工具支撑，还能很好的帮助企业有序管理研发全流程，云端/本地均可灵活部署，已为 20 万家企业提供服务。

如想要了解更多敏捷管理方法和有关私有化部署的信息，扫描下方二维码，即可免费申请专属您的行业解决方案。