4.1　缺陷管理系统

    4.1.1　项目进展不顺利的原因

    如果参加项目的多名成员同时还兼任其他工作，那么在推进项目的过程中重要的就是任务整理、进度管理和信息共享。

    项目成功 / 失败的形式各种各样，并且不同的项目和团队对于成功 / 失败的定义也各不相同。并不是完成了所有的任务就是成功。例如，即使所有的任务都按时完成了，但如果最终没有到达当初制定的目标，不也可以称之为失败吗？

    话虽如此，项目能够进展到可以评判成功 / 失败的阶段可以说还算不错的了。在这之前，有的项目就已经出现“进展不顺利、结束不了”的情况了。笔者有过很多这样的经历，相信读者也有类似的记忆吧。

    项目“进展不顺利、结束不了”的原因各种各样，大致有下面这些。

    • 目标错误

    • 估计错误，时间过紧，人员不足

    • 没有定义项目的结束

    • 成员的积极性不足，进度停滞不前

    从笔者的经验来看，“进展不顺利、结束不了”的项目有着以下这些共同的特征。

    • 项目无法可视化

    • 没有进行任务整理、进度管理和信息共享等

    换言之，这样的项目多数都没有做到“必须要做什么”这样的任务定义、由“谁”在“什么时候完成”这样的责任人和期限的管理、“以什么作为结束”这样的任务完成的定义，以及“现在正在作业中还是已经完成了”这样的进度管理。

    但是不进行任务管理的项目真的存在吗？毕竟笔者还没有听说过这样的事情，无论哪个现场都应该以某种形式对任务进行管理。那为什么还会有进展不顺利的项目呢？这可能是因为管理方法的问题。

    4.1.2　用纸、邮件、Excel 进行任务管理时的问题

    最近，随着缺陷管理系统的导入，像第 2 章问题 1 那样用邮件管理全部内容的开发现场已经越来越少了。

    即便如此，不使用缺陷管理系统也能够实现任务管理、进度管理和信息共享。年轻的读者之中可能有人不知道，在过去的开发现场，进度管理是用名为“bug 票”“问题管理表”这样纸质的管理票和账本来进行的。还有的开发现场用 Excel 制作问题管理表来进行管理。如果是小规模的开发现场，用邮件进行任务管理也不是不可能的。

    但是随着项目涉及的人数和任务数量的增加，这样的管理手法就会出现问题。用纸来管理既影响开发速度又不适合在多人之间共享信息。

    可能有人认为用 Excel 进行管理应该还是可行的 1 ，但因为 Excel 自身并不是专门的问题管理工具，所以在稳定性等方面存在问题。用 Excel 制作问题管理表，并将其存放在共享目录中进行管理，多人同时编辑后文件就损坏了，这样的经历相信大家都有过吧 2 。

    1 实际上设法用 Excel 进行管理的开发现场不在少数。

    2 无法用邮件进行管理的原因在第 2 章说明过了，这里就不再提了。

    还有一些开发现场使用的是 Microsoft Project3 。该产品适用于项目经理从高层次的视角向利益相关者汇报项目的情况，并不太适合现场的作业管理。和 Excel 相同，在多人同时编辑时稳定性方面存在问题。除此之外，纸、邮件、Excel 等还有其他欠缺的地方，那就是信息的统一管理和检索。

    3 微软开发的项目管理软件程序。

    对于后来加入项目或团队的成员来说，过去的事情以及需求等信息统一记录在一处，并且能够进行检索是非常重要的。如果能够做到这一点的话，之后加入的成员就能够进行自学，加快追赶的速度。最终项目的成功率也会相应地上升。

    多数的缺陷管理系统都附带有 Wiki 的机制，该机制能够在信息共享方面起到作用。例如使用问题票对课题进行调查和交流，最后把调查获得的知识以及确定下来的需求等总结记录在 Wiki 中。这样做能够提高信息的精确度，提高项目和团队的工作效率。

    4.1.3　导入缺陷管理系统的优点

    可能和之前的说明有所重复，这里让我们从软件开发项目这一大背 景出发，再来确认下导入缺陷管理系统的优点。

    ●…… 具有任务管理所需的基本功能

    缺陷管理系统的显著优点是具备下列这些功能。

    • “必须要做什么”这样的任务定义

    • “谁来做”这样的职责分配

    • “什么时候完成”这样的期限管理

    • “现在正处于作业中还是已经完成了”这样的状态管理

    另外，作为项目中专门的任务管理程序，多数缺陷管理系统都是以多人使用为前提进行设计的，因此高稳定性及高可靠性也是其主要的优点之一。

    ●…… 直观性、检索性较强

    在管理复杂项目的过程中，将项目中的问题、任务列表以各种形式显示出来是非常重要的。另外，能够检索找到过去的各类处理记录也是非常重要的。

    ●…… 能够对信息进行统一管理及共享

    过去的处理记录、从中获得的知识，以及项目的需求等对于项目来说都是非常重要的信息，将这些信息统一管理并共享是非常重要的。这些功能加上之前提到的高检索性，使得缺陷管理系统超越了单纯的任务管理系统的范畴，还具备了知识数据库的特性。

    ●…… 能够生成各类报表

    统一管理数据所带来的显著优点之一就是易于生成各类报表。例如每周生成的在进度会议上要使用的工作完成情况报告、能够一目了然地掌握团队状态的燃尽图，以及向顾客说明时使用的甘特图等，缺陷管理系统能够方便地生成各式各样的报表。

    能够以怎样的程度生成怎样的报表，这方面不同的缺陷管理系统会有所差异。有些是作为系统的基本功能提供的，有些是以插件的形式提供的。大多数的系统都提供了数据下载功能，如果没有符合需求的报表，可以下载数据后使用电子表格等软件自己生成报表。如果系统提供了 API 或插件系统，还能够用其来自由地开发报表功能，这部分内容稍后会详细介绍。

    随着团队开发的推进，需要报表的情况会越来越多。强大的报表功能就意味着制作报表所用的时间能大大减少，这也是导入缺陷管理系统的显著优点之一。

    ●…… 能够和其他系统进行关联，具有可扩展性

    特别想强调的就是这一点。随着缺陷管理系统和版本管理系统以及持续集成（Continuous Integration，CI）系统之间的关联的逐渐深入，从问题的发生到代码的修改内容、测试结果、发布情况等所有的内容都可以相关联地进行管理。

    通过使用该功能，就可以从版本管理系统的提交记录追溯到原本的问题票，确认原本的修改理由，或者倒过来检索过去的问题找到对应的问题票，再从问题票找出相关联的提交和测试结果，以了解该问题是如何解决的。这样就能够追溯到项目内的活动的各个方面，使得可追溯性有飞跃性的提高。具体方法将稍后叙述。

    具备和外部系统关联的可扩展性也是导入缺陷管理系统的显著优点。大部分的缺陷管理系统都具备插件功能或者能够从外部操控问题票的 API 接口，因此能够满足项目的各种需求。

    4.1.4　什么是缺陷驱动开发

    使用缺陷管理系统，以问题票（ticket）为中心构建开发流程的方法论称为缺陷驱动开发（TiDD）。这个名字是仿照测试驱动开发 TDD（Test Driven Development）这一敏捷开发的方法而取的。

    实践缺陷驱动开发的规则原则上只有一条，那就是“禁止没有问题票的提交”。提交记录和问题票必须一对一地进行管理，以此来明确代码修改的理由，这便是缺陷驱动开发的目的所在。

    ●…… 缺陷驱动开发的具体步骤

    缺陷驱动开发每次都是以在新功能开发和 bug 修正时新建记有内容和目的的问题票开始的。

    其次是根据问题票的内容对代码进行修正并提交。这时在提交记录中记下问题票号是非常重要的，同时还要在问题票中记录下提交记录号。这样问题票和代码修正提交之间的相互关系就创建起来了，明确了代码的修改理由，日后进行问题调查也变得容易了。

    缺陷驱动开发是方法论，对工具的使用并不是必需的。如果只是关联提交记录和问题票的话，手动作业也是可行的。实际上手工关联提交记录和问题票的开发现场并不在少数。

    虽说如此，但如果能够合理使用缺陷管理系统的话，关联作业也可以实现自动化。这样就能避免操作遗漏，准确地关联提交记录和问题票，进而促进项目的可视化。

    从下节开始将主要介绍缺陷管理系统，说明其同版本管理系统关联的方法。另外，应该和缺陷管理系统关联的并不仅限于版本管理系统。在和提交相关联并实行 CI 的情况下，CI 的结果也要记录到问题票中，以方便日后调查。因此还会讲解和 CI 系统关联的相关内容。

    专栏　彻底贯彻缺陷驱动开发的情况
    上文中提到了在缺陷驱动开发的实践中工具的使用并不是必需的，手工关联问题票和提交也是可行的。话虽如此，手动作业的话容易发生问题票和提交之间的关联遗漏。
    要想彻底贯彻缺陷驱动开发，可以使用版本管理系统提供的客户端挂钩（client side hook）和服务器端挂钩（server side hook）。在上述挂钩中能够检查提交信息中是否包含问题票号，如果不包含的话则拒绝接受该提交（或 Push）。
    这样就可以系统性地保证问题票和提交之间的关联，原因不明的修改将无法提交到代码库，项目也就更安全了。并且之后回顾修改时也一定能找到作为修改原因的问题票，这点在管理上非常有优势。
    但是在管理方面的优势有所增加的同时，反过来开发的速度就可能受到影响。这方面需要权衡考虑，要根据项目的目的和状况进行平衡。