4.4　新功能开发、修改 bug 时的工作流程

缺陷管理系统和版本管理系统关联后，新功能开发 / 修改 bug 时的工作流程如下。本节以 JIRA 缺陷管理系统、Git（GitHub）版本管理系统为例来进行说明。

❶ 创建问题票

❷ 指定责任人

❸ 开发

❹ 提交

❺ Push 到代码库

4.4.1　工作流程

●…… ❶ 创建问题票

首先根据问题内容创建问题票（图 4.18）。

图 4.18　创建问题票

●…… ❷ 指定负责人

指定负责该问题票的开发人员 34 。

34 在传统的项目管理中，由项目经理来指派合适的开发人员。而在敏捷开发的团队中，则是开发人员自行创建问题票，再将问题票指派给自己。特别是采用 Scrum 的团队开发，问题票创建时负责人一栏是空白的，在每天的例会（晨会）上由开发人员自己举手认领问题票。

●…… ❸ 开发

开发人员将问题票的状态更改为“In Progress”（作业中）并开始作业。

●…… ❹ 提交

为了实现或修改功能，对代码进行修改并提交。这时要在提交记录中添加问题票的票号。不同缺陷管理系统对应的提交记录格式可能有所不同，JIRA 的提交记录如下。

●…… ❺ Push 到代码库

在将提交的内容 Push 到代码库（图 4.19）的同时，系统会在关联的问题票中添加提交的链接（图 4.20）。这样问题票和提交之间的关联就创建起来了 35 。

35 在这个例子中没有对提交时的提交记录进行检查，因此即使忘记在提交记录中添加问题票号也能够顺利提交。如果希望系统强制要求输入问题票号的话，可以使用版本管理系统提供的 Hook 机制，在提交时对是否记载了问题票号进行检查。

图 4.19　代码库的提交记录

图 4.20　在问题票中添加链接

在介绍 Pivotal Tracker 和 Backlog 时已经提到过，在提交记录的问题票号中插入 Fixs、Fixed、Delivered 等特定的命令语句的话，在添加链接的同时还能改变问题票的状态。命令语句的格式以及与之对应的状态变化，各个缺陷管理系统不尽相同，请参考相应的帮助文档。