小猪大虾_码农叮咚变
十多年外企经验，熟悉质量体系，流程方法，项目管理等
欢迎关注大虾，从技术到技术管理，少走弯路
硬技能是咱技术人的基础，软技能才真正拉开人与人之间的差距
您正在阅读的是软技能入门《程序员必备软技能 – 质量篇》系列
各篇相对独立，也欢迎您从本系列的第一篇 《质量之缘起》开始，系统化学习
概要
我们已经了解了“尽早发现”的必要性及方法。那么当我们发现缺陷之后，一定要报告，记录，追踪，修复，验证，直至被关闭。只有当缺陷走完整个生命周期，确认被干掉，我们才能安心。
现在有很多缺陷管理工具，可以提供缺陷追踪的支持。但是大虾不想同学们只会使用工具，更希望同学们能掌握定制流程的能力。无论碰到什么的情况，都能根据项目实际情况，定制出合适的方案。因此，本章大虾着重介绍了状态图，泳道图，以及如何将这两者与缺陷管理工具JIRA结合起来。最后，通过解决一个工作中的实际问题为例，讲解如何通过定制流程来解决这个问题，做到学以致用。
为什么要密切追踪
缺陷在适当的条件下会被激活产生故障，甚至导致软件失效，影响客户对我们的满意度，进而影响领导对我们的评价，最终影响我们的升值加薪。因此，我们一旦发现缺陷，一定要报告，记录，追踪，修复，验证，直至被关闭。只有缺陷走完整个生命周期，确认被干掉，我们才能安心。如果缺陷已经被发现，但是由于某些原因导致没有被关闭并引发生产问题，那就太可惜了。
有的同学会说缺陷大家都很重视，怎么可能跟丢呢。正常情况测试人员测试出缺陷就会到缺陷管理系统里起票，一般是不会跟丢的。下面大虾举个真实的例子：开发人员发现了一个缺陷，由于只有测试人员有权限起票，便在群里喊了一声，让测试人员起票，测试人员回复好的。后来测试人员由于各种原因忘记起票，最终导致此缺陷在生产上被客户发现了。
最后大虾明确下本章“密切追踪”所针对缺陷的范围。对于需求文档，设计文档等文档中的缺陷，我们通常会在评审时进行标注。再次评审时，对照之前评审的结果，确认是否已经被正确修复。通常不需要使用复杂的追踪流程。另外，开发人员进行单元测试时发现的缺陷，通常会立即进行修复。因此，本章我们讨论的密切追踪主要是针对集成测试及之后，包括：功能测试，生产阶段等发现的缺陷。这类缺陷从报告，记录，修复，验证，到最终被关闭的整个生命周期，会涉及多种状态间的转化，以及多种角色的密切配合。如果流程定义不好，或者协作过程中出现纰漏，都可能导致缺陷没有被有效追踪，没有走完整个生命周期。
工欲善其事必先利其器
以功能测试为例，做过项目的同学都知道，项目一般会使用缺陷管理系统对缺陷的整个生命周期进行追踪，例如：JIRA，禅道等等。像JIRA我们可以使用模版流程，当然也可以自定义流程，用来满足项目的个性化需求。所以这类缺陷管理系统仅仅是工具，流程才是核心，具备定制流程的能力才是核心能力。因此，本章我们要重点介绍状态图，泳道图，以及如何将这些图应用到JIRA系统中，最后展示如果通过灵活运用这些工具，解决之前提到“缺陷漏记”的问题。
状态图
状态图也叫状态迁移图，顾名思义状态迁移图就是体现事物的各种状态以及状态间如何迁移的图。请先看下面的缺陷状态图。
从图中我们可以非常清楚的看到，缺陷一共有多少种状态。如图中椭圆形所示包含：OPEN，REOPEN，修复中，待测试，测试中，CLOSED。另外，有向线表示状态迁移的方向，线上的文字表示迁移需要的动作。比如：从图中我们可以看出“测试中”状态可以迁移到“REOPEN”和“CLOSED”两种状态。如果测试不通过则状态变为“REOPEN”，如果测试通过则状态变为“CLOSED”。
如上图所示，状态图可以摒弃很多细节，聚焦在状态及状态间的迁移上。通常被应用于状态较多，或者状态间转化复杂的场景。比如：订单涉及多种状态包括：创建，待支付，待发货，待评价，关闭，取消订单，退货等等。状态图有助于我们迅速理解核心业务要素的全貌，常用于帮助理解及方便沟通的情况。因此，我们经常在理解业务时会画出状态图便于沟通，或者在设计阶段将需求的零散描述整理成状态图，毕竟一图胜千言哈。另外举个例子，大虾曾经接手一个高端理财的项目，面对几乎没有文档的代码，大虾边读代码边画预约单（订单）的状态图，后面这张图发挥了非常大的作用，无论是快速查询状态迁移的路径，还是在新人培训等方面。
缺陷追踪的状态图需要根据实际情况进行绘制，还以上图为例，我们会发现上图有两个状态“OPEN”和“REOPEN”很类似，我们只用一个状态行不行呢？当然可以，主要还是看项目实际情况。如果去掉“REOPEN”状态，我们可以将上图改为如下图所示。
这张图不仅仅是少了“REOPEN”这个状态，同时也意味着，我们无法区分“OPEN”状态的缺陷是刚起票的，还是已经修复但测试不通过的。当然也意味着我们无法对缺陷进行更细致的分析。通过更细致的分析，我们可能会发现有一些缺陷通过一次修复及测试还没有被解决，对其进行深入分析可以找到问题的点，从而进行改进。这个方法属于持续优化的范围，具体将在“持续优化”章节详细讲解。所以以上的两个状态图体现的缺陷追踪流程都是可以的，没有对错，只有适合不适合，只要根据项目实际情况选择就可以啦。
有了状态图是否就足够了呢？答案是否定的。状态图的优点是摒弃很多细节，让我们聚焦到关键的点上。但是仅仅根据状态图，我们是无法指导多个角色进行很好的协作。首先状态图上的动作，无法得知是由哪个角色发起的。另外也无法得知一个角色做完自己的动作，如何通知下一个角色开始自己的动作，这类协作流程的细节。聊到这里，相信有些同学已经想到了，我们需要“流程图”的辅助来定义具体的协作流程。
泳道图
流程图作为一项基本功，所有的同学都应该熟练掌握。现实工作中，我们很难找到只有一个步骤的任务，几乎所有的任务都是由多个步骤组成，稍微复杂点的任务还会涉及多个角色。流程图作为一项通用的“语言”，常用于辅助沟通，定义任务中各角色的工作范围及如何协同，也被用于各类审批流程等等。
同学们可能觉得奇怪，大虾讲了半天的流程图，却没有涉及到本节的重点“泳道图”。如果有同学不清楚流程图怎么画，可以自己到网上搜寻资料进行学习，这里不在赘述。
下面我们给出“流程图”和“泳道图”，虽然他们描述相同的任务，但是差异却很大，同学们应该可以直观的看出他们的不同。
首先我们来看下泳道图和流程图的差别。泳道图多了几条竖线，并且在最上方标注不同的角色名称，是不是很像各个角色的专属泳道哈。泳道里的动作都是由泳道所属的角色来完成的，比如：技术leader只需要完成指派这个动作。每个人承担的工作是不是一目了然呢。我们在回到流程图，可以看到文字明显多了很多，因为要描述具体动作是由谁发起的。文字多必然会耗费大家更多时间进行阅读及理解。由此可以看出泳道图的优势很明显，大虾也是建议同学们尽量使用泳道图。但是如果只有一个角色，或者两个角色且流程不复杂的情况，同学们可以随意的，毕竟单独一个泳道还是有点奇怪的。
追踪工具
缺陷追踪的工具非常多，如：禅道，JIRA等。下面我们以JIRA为例，聊下缺陷追踪工具。大虾之前已经提到了工具只是辅助，定制流程的能力才是核心技术。因此，只要掌握了之前的状态图，泳道图，接下来的内容也就简单啦。
同学们看下面这张图是JIRA里的流程图，是否很像之前章节介绍的“状态图”呢。图中的方块就是状态图中的状态，有向线和状态图的完全一样。图中“TO DO”到“IN PROGRESS”的有向线没有标注动作，是JIRA显示的原因，只要将鼠标移动到“TO DO”上，与他相关的线及动作都会高亮显示。下图是鼠标移动到“测试”状态上的显示效果。
另外，在JIRA中，动作在页面上体现为按钮，如下图所示，当开发人员在页面点击“编码完成”按钮，则状态迁移到“测试”状态。测试人员进来的页面如下，可以看到有“测试通过”和“测试不通过”按钮，点击“测试通过”则流转到“DONE”状态，点击“测试不通过”则回到“IN PROGRESS”状态。此外，这些按钮是可以设置权限的，比如：只有某个角色，或某个制定人才能点击。
状态在流转的过程，如何通知到下一个角色或者下一个人呢。一方面JIRA上提供了如下图所示的看板，每个任务处于哪个阶段一目了然，各角色可以方便找到各自的任务，当然系统也会发邮件通知相关的人员，包括起票者，被指派的人员等等。
通过以上介绍我们可以发现工具可以让各角色顺畅地协同工作提高效率。类似JIRA之类的系统通常会有很多标准的模版流程，大部分情况我们直接使用即可，针对有特殊需求的项目，只要我们掌握了定义流程的核心技术，再加上工具使用的相关知识，就可以非常容易的进行定制了。如上面介绍的JIRA，我们只需要定制JIRA的流程图（即之前章节介绍的状态图），然后再逐步完善权限，流转等细节就可以啦。
学以致用
本章的开头我们遗留了一个问题：开发人员发现缺陷并在微信群里通知测试人员起票，但测试人员忘记起票，导致最终客户在生产环境发现这个缺陷。面对血淋淋的教训，我们该如何总结经验教训，并进行优化呢。具体的方法我们在“持续优化”章节进行更深入的探讨。本章我们主要聚焦，如何通过定制流程来解决这个问题，以便同学们能够感受到流程带来的力量，并能学以致用。
如上图所示，测试人员发现缺陷后会到JIRA系统起票，之后缺陷就会被追踪。但是当开发等人员发现缺陷时应该怎么处理，却没有明确的规定。大虾项目组当时的情况是：开发人员在微信群里通知测试人员到系统中起票，然后测试人员也说好的，但是最后忘记起票。通过泳道图我们可以发现缺陷报告及记录流程是不完整的，只定义了测试人员发现缺陷时如何记录，而没有定义其他人发现时应该如何处理。
同学们会想到什么解决方案呢？很多同学都能想到，如果开发人员能一直追踪到测试人员确认已经起票，那么就不会发生这个问题。那么我们很容易想到一个方案：测试以外的人员一旦发现缺陷，必须发送邮件给测试人员，邮件必须写明缺陷的重现方式，并要求测试人员起票后回复邮件，并在回复邮件中写明JIRA票的编号。于是，拥有流程定制核心技术的同学很快就能得出如下泳道图。泳道图中红框部分为本次添加的流程，后续的流程与之前相同。
以上方案虽然解决了忘记起票的问题，但还是比较麻烦，并且有点绕。本来目的就是为了起票，结果做了很多起票以外的工作。换个角度想，让所有人员都可以起票不就解决问题了吗，于是有了以下的方案。红框内为本次变化的内容。
如上图所示我们增加了一个“草稿”状态，任何人都可以起票，只不过起票之后状态为“草稿”。如果测试人员确认为缺陷则状态变为“OPEN”，之后的流程同以前流程。如果测试人员确认不是缺陷则状态变为“CLOSE”。当然泳道图也随之变为如下图所示。
还是那句话，不管是邮件方案，还是增加”草稿“方案，还是其他方案，只要适合项目的就是好方案。虽然通过邮件确认比较繁琐，但是如果测试以外人员发现缺陷的概率不高，偶尔使用邮件确认也不会增加什么工作量。这种情况选择邮件方案符合项目实际情况的。
小结
缺陷在适当的条件下会被激活产生故障，甚至导致软件失效，影响客户对我们的满意度，进而影响领导对我们的评价，最终影响我们的升值加薪。因此，我们一定要对缺陷密切追踪。
现在有很多缺陷管理工具，可以提供缺陷追踪的支持。但是大虾不想同学们只会使用工具，更希望同学们能掌握定制流程的能力。无论碰到什么的情况，都能根据项目实际情况，定制出合适的方案。因此，大虾着重介绍了状态图，泳道图，以及如何将这两者与JIRA联系起来。最后，通过解决一个实际问题为例，结合状态图，泳道图，以及工具给出了两个不同的解决方案。不知道在此过程中，同学们是否也能感受到“指点江山”的豪迈感。只是简单的几个调整就可以构建出解决方案，就可以让一切运行得井然有序。
最后，大虾希望同学们能在项目中多多实践，切实把这几个工具掌握好，必能受益终身。关于流程定制本章只能算是初步涉及，后续会有章节进行更加详细的介绍。记得关注大虾，后续更精彩。