4.7　本章总结

    综上所述，通过关联缺陷管理系统和版本管理系统，代码的可追溯性有了很大的提高。

    本章介绍了包括免费 / 收费在内的各类缺陷管理系统。最近几乎所有的缺陷管理系统都提供了和版本管理系统进行关联的功能，这里对关联的方法也进行了说明。

    通过关联缺陷管理系统和版本管理系统并加以有效地利用，就能够知道什么时候、谁、进行了什么操作这一连串的信息，并且还能加快发生问题时查找原因的速度。

    这和既不使用缺陷管理系统也不和版本管理系统进行关联的情况比起来可以说是天壤之别。请回忆一下第 2 章中的案例分析。在那个案例中，收到通过邮件发来的调查请求，却无法检索版本管理系统的提交记录，即便确认了提交记录也不知道这样修改的理由。

    第 2 章的案例分析中还有个例子是：根据收到的调查请求进行的修改被其他开发人员用别的提交覆盖掉了。如果关联了缺陷管理系统和版本管理系统的话，就能从提交记录找出对应的问题票，进而就应该能知道进行如此修改的缘由。

    但即使这样还是觉得有所不足，并不是说仅仅找出有问题的提交，并调查出作为提交原因的问题票就足够了。不能一开始就阻止这样有问题的提交吗？不能在每次提交时都对其正确性进行检查吗？

    如果能够实现上述机制，就能在更早的阶段确保提交的正确性，开发的质量也会相应地提高。这样的机制就是将在第 5 章进行说明的 CI。

    专栏　缺陷管理、bug 管理以及需求管理
    本章主要讲述了用缺陷管理系统对开发中的任务进行管理的相关内容。而在任务确立之前的阶段，软件开发团队还有必要对课题进行管理。
    缺陷管理系统能够覆盖哪些范围呢？或者说应该覆盖哪些范围呢？
    这里我们借鉴敏捷开发方法论之一的 Scrum 的部分术语，将课题分为 epic、story、task、bug 这 4 类，并分别对它们的粒度进行说明。
    epic（很大的需求、跨部门的课题等）
    可以称为 epic 的大粒度的课题一般有如下特征。不熟悉 epic 这个术语的话可以回想一下系统需求确定下来之前的需求定义阶段，这样会比较容易理解。
    • 和工程师不相关的事情占多数
    以确定优先顺序为主要目的，因此以一览表的形式呈现出来很重要
    • 刚开始时多处于模煳的状态，因此不适合采用固定的格式，最好是能够灵活修改的
    方便多人进行编辑、共享
    这样的粒度下一般会使用电子表格工具。因为工程师之外的团队成员也能够直观地进行编辑，所以是最简便的方法。如果考虑到共享和同时编辑的问题，最好使用 GoogleDocs 这样的在线工具。
    epic 的内容示例：
    • 构筑开拓新市场用的系统
    为每个客户准备信息中心，提供对其所使用的产品的统计信息和用户的访问情况进行分析的功能
    story（具体的需求，和功能性需求或规格程度相近）
    称为 stroy 的粒度有如下这些特征。它在 Scrum 中表示为用户带来的价值。如果对 Scrum 不熟悉的话可以理解为程度上近似于具体的功能要求或规格。
    • 一般多由产品的负责人编写（Scrum 中的用语是 product owner）
    根据团队或项目的情况，可以由工程师以外的成员编写，也可以由程序员编写
    • 需要进行状态管理
    最好开始和代码创建关联
    • 负责人可以是多人也可以是一个人
    这样的粒度可以考虑使用缺陷管理系统进行管理。关系到多个负责人的大型 story 的话需要再想想办法。
    方法之一就是先创建问题票再分割为子任务。如果系统支持在问题票之间创建继承关系，可以直接使用该功能，这样管理起来也较为方便。
    根据相关人员的数量，也可能是使用电子表格工具进行管理更为理想。至于应该如何确定缺陷管理系统和电子表格工具的分界线，每个项目、每个团队都有自己不同的标准，很难说哪个是最好的，请根据项目的实际情况探讨合适的方法。
    比较常用的方法是以团队为分界线。如果课题涉及多个部门，可以采用电子表格工具进行管理，等具体的开发内容确定下来后再由各部门自行创建问题票。由于管理方面职责明确，因此较大的开发团队多采用该方法。
    stroy 的内容示例：
    • 为了体现出对顾客的欢迎，想要在顾客登录时根据顾客的信息显示欢迎或其他消息等
    将每个用户 ID 的用户访问状况，以小时、属性分别进行统计，并且支持在信息中心阅览和下载
    task
    即作业。和价值没有直接关系，但如果不完成 task 的话 story 的完成就无从谈起。task 的概念应该还是比较容易理解的。
    • 具体的作业内容
    大致的印象是 story 下关联着多个 task
    • 只有一个负责人
    根据内容确定是否需要和代码进行关联
    task 应该采用缺陷管理系统进行管理。如果系统支持问题票之间有继承关系，或者允许在问题票下定义附属问题票，可以将 story 定义为问题票，将 task 定义为子问题票或者附属问题票。
    task 的内容示例：
    • 初始化系统
    写单元测试
    bug、故障处理、调查
    即 QA 部门发来的 bug 报告、故障的处理以及顾客的咨询等。
    • 程度上和 task 相近
    通常由单个开发人员负责
    • 需要和代码进行关联
    应该作为缺陷管理系统的管理对象。至于是以 task 的粒度进行管理还是以 story 的粒度进行管理，可以根据项目或团队的具体情况选择合适的方式。
    在 bug 数量很多的情况下，可以将 bug 管理和其他的问题票区分开，使用其他的系统进行管理。这也是一种方法，但这样的话管理上就会变得复杂，所以并不推荐。应该尽可能地在同一缺陷管理系统下对 story 和 bug 进行管理。
    总结
    至此我们一起看了课题的分类和管理方法。这样的分类方法是灵活的，并非一成不变的。如果团队有自己一贯采用的分类方法也完全适用。
    能够肯定的是：缺陷管理系统适用于目的以及内容在一定程度上确定下来之后的管理，不适合在此之前的那些比较模煳的、不确定的事物的管理。在这个阶段，使用电子表格工具等形式不固定的工具进行管理会比较好。
    表格工具和缺陷管理系统的分界线取决于相关的部门数或人数，另外，在负责的部门发生变化时切换到缺陷管理系统也是可以的。
    没有必要只使用一种工具，同样，也没有必要拘泥于一种定义，我们要做的应该是摸索出一套最适合自己团队的方法。