一、需求管理

在软件研发流程中，首要是处理通过业务收集而来的诸多需求。下面将详细介绍如何在 Gitee 企业版中进行需求的管理。

1.1 需求的归属 ——「项目」

1.首先应当根据目前所在企业的业务情况，确定需求的归属。如下图案例，企业中有「Gitee研发效能项目」和「Gitee天气新功能」两个功能?？橥苯锌ⅲ徒⒍杂Φ?strong>「项目」。

之后点击项目卡片，进入「项目-任务」，查看本项目中的待办事项。与此功能?？橄喙氐男枨笤谡饫锎唇?。

1.2 需求的拆分与落地——「子任务」

确定好需求的归属之后，对于粒度相对较大的需求，应当进行拆分。在Gitee 企业版中，需要拆分一个「需求」任务时，应当由相关人员（譬如需求分析师、产品经理等）在它下面创建若干的子任务，以便保证之间的关联。

如果「需求」本身无需拆分就可以立即落地，应当创建若干个类型为「任务」的子任务，由团队成员（譬如前端开发、后端开发、测试人员）分别前去执行。

小提示：需求的拆分通常不超过三级。业内常把需求按大小依次分为「Epic」、「Feature」、「Story」三级，同时把落地执行的待办事项称为「Task」。在Gitee 企业版中，企业管理员可以通过进入「管理-任务类型与状态」，然后新建名为「Epic」、「Feature」、「Story」、「Task」的任务类型来满足上述的管理需要。

二、规划与排期

2.1 确定迭代或版本的范围——「里程碑」

当需求人员已经准备好相应的待办事项时，建议项目人员使用「里程碑」功能来着手进行下一个迭代或者版本要交付的需求范围。

1.下图所示，创建了2021年4月份每周迭代计划的「里程碑」：

2.根据需求，从待办事项中拖动计划在那段时间内完成的「任务」到对应的里程碑里。

3.分配完成之后，进入对应里程碑查看待办事项的情况。

2.2 整理任务排期——「甘特图」

确定了计划需要交付的需求范围之后，下一步就是确认每个执行项的时间安排。

1. 进入「甘特图」视图后，先筛选到想要查看的计划范围（以「2021年4月第一周」的里程碑为例）：

2.根据需要可以拖动更改需求的排期。

2.3 分配任务给团队成员——「成员看板」

排期敲定之后，着手让团队成员开始逐步解决那些待办事项了。

进入某个里程碑的「成员看板」视图，可以找到当前哪些待办事项是还没有落实到负责人的。通过拖动待办事项的卡片将它交由对应的成员前去处理。

同时也能看到在这个里程碑中每位成员承担的任务数量?？删荽说髡稍钡墓ぷ鞲汉?。

小提示：在某些敏捷实践中，强调「未被解决的待办事项」应该由团队成员主动领取，而不是由团队leader分派。

三、追踪进度——「状态看板」

除了直接查看甘特图来追踪研发计划完成的进度外，还可以通过里程碑中的「状态看板」。

选择要查看的任务类型为「任务」后，观察它们的流转情况，以便及时应对问题。

四、设计编码

完成需求处理和排期之后，研发流程进入到编码的环节。Gitee 企业版中推荐采用基于 Pull Request 的代码协同方式。

小提示：基于Pull Request的代码协同方式简单来说就是一个仓库只会长期存在一个 master 分支用于发布。每当有新的改动，都会基于 master 新建一个分支，在该分支上完成改动后，创建一个Pull Request（意思是：我的代码已经完成，请求向 master 分支合并我的分支）。管理员们在Pull Request中进行代码评审，确认无误后把改动的部分合并到 master 分支上。

4.1 创建分支

1.在一切的开始，应该先在Gitee 企业版下先建立一个代码仓库。支持直接新建或者从本地推送一个已存在的Git代码仓库。关于Git的使用，可以参考Pro Git(中文版)。

2. 代码仓库应该有且仅有一个名为 master 的主分支，版本库初始化以后，默认就是在主分支在进行开发。所有提供给用户使用的正式版本，也都可以在这个主分支上发布。这个分支也是仓库中唯一需要长期存在的分支。
3. 每次开发新功能，都应该新建一个单独的分支。常用的场景为：增加新功能、修复缺陷、预发布等。

小提示：某些研发协作实践中，不同功能的分支会有不同的命名来区分它。详情可以参考Git分支管理策略。

4.2 代码评审

在本地修改代码完成，增加新的 commit 并 push 到 Gitee 的代码仓库上之后，可以通过创建 Pull Request 的方式来向团队 leader（也就是代码仓库的管理者）申请代码评审。

1.由代码的提交者进入提交代码完成的代码仓库，选择「+Pull Request」

2. 源分支是提交者刚刚提交代码的分支，目标分支是 master 分支。在Pull Request中写清楚必要的信息，仓库的管理者就能收到提醒开始代码评审了。

3. 在代码评审时，提交者可以主动把代码评审的Pull Request与他所解决的事项（来自于需求）关联起来，便于管理者理解。同时评审通过代码合并后，那个任务也会自动变为完成状态。

4.3 合并代码

管理者收到代码评审的申请，可以前往对应的Pull Request中查看更改的代码内容，确认无误后即可合并代码到目标分支上。

小提示：代码评审过程中，除了人工审查外，Gitee 企业版还提供了检测代码缺陷、规范、依赖项漏洞的自动化工具Gitee Scan，为代码质量保驾护航。

五、缺陷管理

测试人员在测试功能时发现了异常，可以新建一个任务类型为「缺陷」的待办事项来描述Bug。并放入相关的项目中。

如果是在需求上线之前的测试，若Bug本身与某个需求相关，要把「缺陷」与「需求」关联起来。

小提示：如果团队要求，一个「需求」必须把相关联的所有「缺陷」都解决才可以视作完成。Gitee 企业版支持「依赖」的能力，可以通过「依赖」能力，设置必须先完成「缺陷」之后，才能完成「需求」。

六、工作成果

团队成员完成了某一阶段的任务交付后，leader要基于他们的工作成果了解实际的生产情况，在「统计」中提供了一些相关能力。

企业内的开发者需要设置自己的邮箱为提交邮箱，在此处就可以统计到他的工作成果了。详情参考代码贡献

小提示：在一些管理实践中，会把开发人员的「完成任务数量」视为他的产出，「提交数」和「代码行数」视为他达成产出所付出的成本。不过企业之间的情况千差万别，请结合业务实际自行取用。