如何既满足ASPICE要求，又减少开发过程文档

经常听到一些团队说，我们是想满足ASPICE，但是ASPICE要求的文档太多了，有没有一种方法，既能让我们的开发过程满足ASPICE标准要求，同时又能减少开发过程文档？

首先我们来分析这个问题。

既然我们想要减少开发过程文档，那么首先就需要知道， 1. ASPICE究竟要求了哪些开发过程文档？

如果能找到这些最耗时的开发过程文档，接下来我们可以考虑，2. 是否能直接减少这些开发过程文档？

直接减少开发过程文档本身，相当于在直接挑战ASPICE框架，是很难说服评审师的，有很大的失败风险。我们换个角度，3. 能不能让开发过程文档的准备不那么耗时？

这篇文章，我们重点来回复问题1和3.

1. ASPICE究竟要求了哪些开发过程文档？

基于我的经验，我把ASPICE中涉及的最重要（最难搞、最难整理、最难出具evidence……）的开发过程文档，分为如下 4 类，如果能使如下4 类开发过程文档的出具变得比较简单，那ASPICE项目的评审时长可以缩短50%以上，项目开发效率也可以提高30%以上。

第1类是设计规范（Specification），所谓的设计规范指的是，需求文档、架构文档、详细设计文档，测试用例文档也可以放在这一类里面。一般来说这类文档拥有严格的格式，每一家公司有所不同，但都大同小异。

第2类是评审文档，包含了评审清单（checklist）、评审问题的记录、以及评审问题的追踪过程。

第3类是基线文档，很多团队的基线库里面，存储了N条基线，每条基线包含了一次开发过程的所有文档，比如需求文档、设计文档、测试用例等。基线管理对很多团队来说都是一个难点，一是没搞清楚基线管理的底层逻辑，二是没有找到合适的工具。有关基线管理，可以参考我上一篇文章《汽车行业如何做基线管理？》

第4类是变更文档，包含了变更请求、变更影响分析、变更评审结果、变更执行情况等。

3. 能不能让开发过程文档的准备不那么耗时？

这里我先说一个大胆的结论：不要写文档！那文档的准备时间就是0了。

看到这里，有些同学可能要划走了，“你们互联网造车真是666，上来就直接不写文档，汽车行业用血的教训，ASPICE搞了几十年，你们一上来就要颠覆它，6啊！“

这里我要对“不要写文档”作进一步的修饰：不要专门写文档，团队成员应该专注于项目推进，专注于解决一个个具体的任务，花更多时间来详细描述任务，然后通过工具，来帮助自动生成文档。

我以上述 4 类文档来一一举例，如何实现上述想法。

第一类，“设计规范不是写完了就束之高阁的，设计规范就是待办任务”。

这句话怎么理解？有些团队把设计文档写地非常清晰，非常美观，具有层次感，恨不得从最开始就把所有的细节都写出来，他们写完了一个 50 页或100 页的文档。接下来他们需要基于这些 Specification 去安排他们的任务。这时候发现，Specification 太复杂了，太详细了，使用的工具Word或其他类似Word的在线编辑器，也不适合安排任务，然后他们开始基于Specification，去某些任务跟踪系统中创建新的任务。你瞧，这里面做了重复性的工作。

为什么设计文档本身，不能直接作为待办任务跟踪呢？

所以一种常见的拉低效率的方式是先写文档，再基于文档去重写一遍任务，当任务有更新的时候，又要反过来更新文档。或者先更新文档，再更新任务。如果不进行双向更新，显然不满足ASPICE的一致性要求，如果更新，又将是一个巨大的工作量。

另一种常见的耗时方式是，先去任务跟踪系统中创建任务，等到ASPICE评审老师要来评审时，再基于这些任务，去创建设计文档。此时任务在系统中已经非常繁杂了，结构性、追溯性的整理都非常麻烦，准备文档非常耗时，并且往往是为了准备文档而准备文档。这也是很多团队觉得，ASPICE不能帮助改进开发流程，而只会增加工作量的最大原因。

我们更推荐的方式是直接写待办任务，然后去丰富待办任务。

当待办任务写完之后，按照待办任务的组织架构方式，直接生成设计文档，甚至可以导出word格式的设计文档。

 

第二类，“评审过程本身是简单的，难的是应审”。

相信做过ASPICE应审的同学都会深有感触。对于团队来说，评审一份设计规范是经常要做的行为，即便没有ASPICE要求，也会这样做，但是他们做的过程一般是直接进行线下讨论，讨论的过程中如果发现问题，当场就直接修改了，这种方式当然是最高效的，但对于应审来说，它不满足要求，因为难以提供评审过的证据。 所以，更好的方式是将两者相结合，我们既能以一个类似线下评审的并行方式进行文档评审，同时评审的过程又能自动地留下大家的评审记录，并且将评审记录自动汇总，最终出具结果。

对于评审未通过的文档（参考上述第一类，此时文档已经是N条待办任务），留下评审未通过记录的同时，需要再次发起评审，直至完全通过评审要求。

 

第三类，“基线存在的唯一理由是为了变更”。

为什么这么说，大到一个项目，小到一个任务，如果我们在开始之初，就能确保不会有任何变化，那完全就不需要基线。存在基线的原因，恰好是因为在开发的过程中会有不断的变化，团队需要知道最初的需求是什么，过程中每一次变化是怎样。基线的存在对于甲乙双方都是一个保护作用。对于甲方客户来说，可以确保乙方不会轻易去修改他的原始需求，对于乙方来说，也可以防止甲方提完需求之后，中途随意增加、改变需求，从而导致整个项目延期。 所以，基线能清晰地反馈过程中的变化就够了，而不需要将每次变更后的基线内容全部保存下来。很多团队都存在这样的误区，将每一次基线的内容全部保存下来。后一次基线相对于前一次基线改变了什么，反而不够清晰。很多团队使用“高度概括”的文档变更历史记录来显示变更“详情”，实际上根本无法显示变更的真实内容，更别谈去追溯了，这就有些本末倒置了。

第四类，“搞清楚什么时候需要变更，比变更本身更重要”。

有些团队在什么时候需要变更上没有搞清楚。 当设计规范写下来之后，不管什么时候有改变，都要走变更评审流程，会让整个开发过程变得比较复杂且低效，且会降低变更的严肃性。最终的结果就是，如果所有的改变都需要走变更，每天都开变更评审会，没有人会认真对待评审会，也就相当于没有了变更评审会。 还有一些团队虽然明确了，设计冻结之后才需要变更，但是工具中无法很方便地知道是否冻结（如果使用线下的word、excel，每个人就更难明确，文档是否真的冻结了。大多数工具也无法清晰地标明这一点）。 即使工具中清晰地标明了冻结，还有一个问题，就是变更的颗粒度。如果设计规范本身的颗粒度比较粗，比如一个设计规范里面包含了20条需求，那么针对这个设计规范，它变更的概率接近于1（1-50%^20），同上，会面临着频繁的变更评审活动。 但是如果把这个设计规范拆分成20条需求（待办任务），那么其中可能18 个需求都是没有变化的，只有两个需要变化，这个时候的变更的影响范围就不会那么大，内容也没有那么多，评审起来的效率就更高了。而且由于设计规范的颗粒度足够小，因此变更请求方对于这个需求的变更就可以非常明确，变更的影响范围也可以非常明确。

评审人基于变更请求给出的意见，最终留下评审记录，决定变更是否最后通过。

     

审核编辑 ：李倩