Gitee 企业版于不久前推出了 Scrum 项目模板，Scrum 项目模板针对 Scrum 流程进行了针对性的组件设置和新特性的开发，确保研发团队在进行 Scrum 实践时的流畅顺滑。
本篇文章将着重介绍如何使用 Gitee 的 Scrum 项目模板来提高团队的敏捷研发协作能力。
在开始之前需要声明，敏捷不是一种方法论或者工作方式，而是一种可掌握的能力。我们通常所说的敏捷团队转型，更应该称之为团队作为一个整体，来学习敏捷这样的能力。
传统的开发模式例如瀑布模型、喷泉模型、螺旋模型等等，虽然有不断的进化与创新，但不具备足够适应日新月异的市场变化的能力。
为了面向市场不断提出的需求，IT 行业发展了很多轻量化的软件开发方法，比如 Scrum、水晶清透法、极限编程法等等，因为他们都是迭代和增量式的开发，即使是起源于敏捷开发宣言之前，但都可以统称为敏捷软件开发。
各种敏捷开发方法的差异在于理念、过程、术语不同，但相较于“非敏捷”，它们都更强调团队间的紧密协作、面对面的沟通、频繁的交付新版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发过程中人的作用。
每一个敏捷项目成员都知道即将做什么以及项目进展如何。
团队更需要编制易于阅读的文档，来对系统及其设计决策的依据进行描述。
投资于产品并运行项目的人应该定期评估该产品和流程。
对细小问题做快速调整，如果数据反馈表明你应当做出改变，那么请立即改变。
相对于瀑布开发而言，转型成为敏捷研发团队具有小快灵的开发能力，具体体现在：
敏捷是定期的，不是一次性的，我们都会经历产品或服务的迭代优化，因为市场在变化、用户需求在变化，根据市场反馈来对需求进行验证和矫正，以灵活敏捷的改变调整去适应变化，在一次次持续迭代中达到最终目标。
所以对于团队来说，与其努力创造完美的产品或服务，不如通过版本的迭代来不断改进。
一个软件交付计划可以被划分成多个迭代，每个迭代结束时必须能得到可交付程度的功能。若团队在2次迭代执行完成后，仍然存在无法按时交付/交付不完整的需求情况时， ScrumMaster 应该适当延长迭代时间。
首先，我们先新建一个项目：
项目可以是持续提供服务（longterm）的C端项目，也可以是阶段性交付，具有一定生命周期的B端项目。通常来说，团队会开发一个新项目，同时维护几个老项目。
新建完成后，我们直接进入规划页面创建我们的第一个需求：
如果已有任务可使用Gitee任务导入功能，直接从任务模块导入。
导入完成后，我们就有了1~2个需求（Epic层级）。
史诗（Epic） 是一个大功能的集合，通常能够提供一个完整的系统，一般是通过一个或多个迭代才能完成，以此来决定业务方向。
由于它非常大，无法或不容易进行估算，这时需要对Epic层级需求进行进一步拆分，做到可执行的Story层级，这里提供一个简单拆分示例:
例如我们在刚才的商城平台中，“商城”决定了我们下一步业务方向将围绕着电商展开。
拆分Epic，可以在商城（Epic）中新建子任务（Feature）：
本次示例中，最终拆分出4个Feature（特性），分别是：
商家管理端、用户端、测试任务、后台规则。
特性（Feature） 是指逻辑上相关的功能需求的集合，给用户提供一定处理能力的产品，并满足对应业务需求。
之后可以采用同样的方法，可以一直拆分到Story层级。
用户故事（Story） 描述的是一个情景，尽可能贴近操作人员的真实需求，用户可以轻松地对用户故事进行排序，下面是一个用户故事编写方法参考：
作为 我想要做 ，以便<实现 z的好处>。
例如：
作为一个管理员，我想要一个优惠券管理模块，以便实现对用户发放优惠券的功能。
在通过一系列需求评审之后，可在用户故事下拆分成可执行的任务/子任务，方便开发人员理解。
开发任务拆分完毕并指定好负责人，前期需求规划准备工作均已完成。
迭代功能对应敏捷开发流程中的“迭代（Sprint）”流程，迭代与版本（详见版本章节）都是管理单元，用于在一个时间范围内（通常为1~4周）同时管理产品目标、团队容量和交付进度。
我们可以先从新建一个或多个迭代开始：
团队可以根据需求池中的内容，通过迭代规划功能评估一次/多次迭代的内容。
为了方便评估工作量和实现难度，在开始迭代之前，产品经理（PM）需要联合敏捷教练（ScrumMaster），研发成员（RD）进行一次需求评审。
为了更好地贴合敏捷团队，我们特别在迭代中增加了文档模块，方便记录：
需求评审时可以打开自动生成的“评审记录”来编写会议纪要。
评审的目的是为了评价需求可行性，需求功能、需求交互设计和预估团队的开发工作量。
若要开始一个迭代，可以在迭代详情内点击“开始迭代”。
迭代开始时，系统会记录一次任务数量，可在团队速度报表中查看，详见第六章回顾与总结；
迭代开始后，研发团队可根据实际完成情况，改变作为负责人的任务状态。
迭代执行过程中，可以通过迭代文档中的站会记录完成敏捷研发的站会流程。
迭代过程中若出现紧急插入需求或超前完成的情况，可以通过迭代内的规划功能进行调整。
迭代结束当天，由敏捷教练（ScrumMaster）牵头，使用迭代内置的回顾记录模板开展一次回顾会议，总结迭代进行过程中团队优秀的点和需要改进的地方，同时可以列出对应优化方案。
由迭代负责人点击“结束迭代”按钮，完成这一阶段的工作。
版本虽然与迭代一样作为任务的集合单元存在，与迭代不同的是版本只强调功能产出。
作为产出规划型工具，可以根据需要进行版本紧急发布或计划发布，以下是三种常见的发布方式：
1.每日发布（迭代1:N版本）
2.迭代周期发布（迭代1:1版本）
3.多迭代发布（迭代N:1版本）
首先新建一个版本。
新建完成后如图所示：
点击右上角规划任务按钮，可以将想要发布的任务添加至版本内：
添加完成后，我们默认了3个环境：开发环境-测试环境-生产环境，悬停在横线上，可以根据需要添加新的环境。
点击图标，可以修改版本的发布状态。
当最右侧一个环境完成时，版本发布结束。
伴随着一次次的迭代和发版，团队的进步也是管理者所关心的问题，我们特别策划了针对团队效能的报表，以反馈团队的健康状态。
通过观察每期迭代评审需求数量和完成需求数量，判断团队的风险承受能力（既定工作是否受影响）。
了解迭代中各个成员的工作负荷情况，合理优化团队成员的工作安排。
Gitee 企业版的 Scrum 模板通过产品功能和敏捷流程中不同角色、步骤、工作的有机结合，来培养和提升团队的敏捷能力的同时反哺团队的工作效率。如果你的团队正在或准备使用敏捷流程来进行项目管理，那么 Gitee 企业版的 Scrum 模板将会是一个十分优秀的上手选择。
Gitee 企业版不仅能为需求管理、迭代规划、进度跟踪等经典 Scrum 环节提供工具支撑，还能很好的帮助企业有序管理研发全流程，云端/本地均可灵活部署，已为 20 万家企业提供服务。
如想要了解更多敏捷管理方法和有关私有化部署的信息，扫描下方二维码，即可免费申请专属您的行业解决方案。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。