如何使用 Gitee 企业版进行全流程管理?
一、需求管理
在软件研发流程中,首要是处理通过业务收集而来的诸多需求。下面将详细介绍如何在 Gitee 企业版中进行需求的管理。
1.1 需求的归属 ——「项目」
1.首先应当根据目前所在企业的业务情况,确定需求的归属。如下图案例,企业中有「Gitee研发效能项目」和「Gitee天气新功能」两个功能模块同时进行开发,就建立对应的「项目」。
之后点击项目卡片,进入「项目-任务」,查看本项目中的待办事项。与此功能模块相关的需求在这里创建。
1.2 需求的拆分与落地——「子任务」
确定好需求的归属之后,对于粒度相对较大的需求,应当进行拆分。在Gitee 企业版中,需要拆分一个「需求」任务时,应当由相关人员(譬如需求分析师、产品经理等)在它下面创建若干的子任务,以便保证之间的关联。
如果「需求」本身无需拆分就可以立即落地,应当创建若干个类型为「任务」的子任务,由团队成员(譬如前端开发、后端开发、测试人员)分别前去执行。
小提示:需求的拆分通常不超过三级。业内常把需求按大小依次分为「Epic」、「Feature」、「Story」三级,同时把落地执行的待办事项称为「Task」。在Gitee 企业版中,企业管理员可以通过进入「管理-任务类型与状态」,然后新建名为「Epic」、「Feature」、「Story」、「Task」的任务类型来满足上述的管理需要。
二、规划与排期
2.1 确定迭代或版本的范围——「里程碑」
当需求人员已经准备好相应的待办事项时,建议项目人员使用「里程碑」功能来着手进行下一个迭代或者版本要交付的需求范围。
1.下图所示,创建了2021年4月份每周迭代计划的「里程碑」:
2.根据需求,从待办事项中拖动计划在那段时间内完成的「任务」到对应的里程碑里。
3.分配完成之后,进入对应里程碑查看待办事项的情况。
2.2 整理任务排期——「甘特图」
确定了计划需要交付的需求范围之后,下一步就是确认每个执行项的时间安排。
- 进入「甘特图」视图后,先筛选到想要查看的计划范围(以「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(中文版)。
- 代码仓库应该有且仅有一个名为 master 的主分支,版本库初始化以后,默认就是在主分支在进行开发。所有提供给用户使用的正式版本,也都可以在这个主分支上发布。这个分支也是仓库中唯一需要长期存在的分支。
- 每次开发新功能,都应该新建一个单独的分支。常用的场景为:增加新功能、修复缺陷、预发布等。
小提示:某些研发协作实践中,不同功能的分支会有不同的命名来区分它。详情可以参考Git分支管理策略。
4.2 代码评审
在本地修改代码完成,增加新的 commit 并 push 到 Gitee 的代码仓库上之后,可以通过创建 Pull Request 的方式来向团队 leader(也就是代码仓库的管理者)申请代码评审。
1.由代码的提交者进入提交代码完成的代码仓库,选择「+Pull Request」
- 源分支是提交者刚刚提交代码的分支,目标分支是 master 分支。在Pull Request中写清楚必要的信息,仓库的管理者就能收到提醒开始代码评审了。
- 在代码评审时,提交者可以主动把代码评审的Pull Request与他所解决的事项(来自于需求)关联起来,便于管理者理解。同时评审通过代码合并后,那个任务也会自动变为完成状态。
4.3 合并代码
管理者收到代码评审的申请,可以前往对应的Pull Request中查看更改的代码内容,确认无误后即可合并代码到目标分支上。
小提示:代码评审过程中,除了人工审查外,Gitee 企业版还提供了检测代码缺陷、规范、依赖项漏洞的自动化工具Gitee Scan,为代码质量保驾护航。
五、缺陷管理
测试人员在测试功能时发现了异常,可以新建一个任务类型为「缺陷」的待办事项来描述Bug。并放入相关的项目中。
如果是在需求上线之前的测试,若Bug本身与某个需求相关,要把「缺陷」与「需求」关联起来。
小提示:如果团队要求,一个「需求」必须把相关联的所有「缺陷」都解决才可以视作完成。Gitee 企业版支持「依赖」的能力,可以通过「依赖」能力,设置必须先完成「缺陷」之后,才能完成「需求」。
六、工作成果
团队成员完成了某一阶段的任务交付后,leader要基于他们的工作成果了解实际的生产情况,在「统计」中提供了一些相关能力。
企业内的开发者需要设置自己的邮箱为提交邮箱,在此处就可以统计到他的工作成果了。详情参考代码贡献
小提示:在一些管理实践中,会把开发人员的「完成任务数量」视为他的产出,「提交数」和「代码行数」视为他达成产出所付出的成本。不过企业之间的情况千差万别,请结合业务实际自行取用。
本文系作者 @Gitee 原创发布在 Gitee 官方博客。未经许可,禁止转载。