作者 | 罗宇超
出品 | 汽车电子与软件
经常听到一些团队说，我们是想满足ASPICE，但是ASPICE要求的文档太多了，有没有一种方法，既能让我们的开发过程满足ASPICE标准要求，同时又能减少开发过程文档？
首先我们来分析这个问题。
既然我们想要减少开发过程文档，那么首先就需要知道， 1. ASPICE究竟要求了哪些开发过程文档？
如果能找到这些最耗时的开发过程文档，接下来我们可以考虑，2. 是否能直接减少这些开发过程文档？
直接减少开发过程文档本身，相当于在直接挑战ASPICE框架，是很难说服评审师的，有很大的失败风险。我们换个角度，3. 能不能让开发过程文档的准备不那么耗时？
这篇文章，我们重点来回复问题1和3.
基于我的经验，我把ASPICE中涉及的最重要（最难搞、最难整理、最难出具evidence……）的开发过程文档，分为如下 4 类，如果能使如下4 类开发过程文档的出具变得比较简单，那ASPICE项目的评审时长可以缩短50%以上，项目开发效率也可以提高30%以上。
第1类是设计规范（Specification），所谓的设计规范指的是，需求文档、架构文档、详细设计文档，测试用例文档也可以放在这一类里面。一般来说这类文档拥有严格的格式，每一家公司有所不同，但都大同小异。
第2类是评审文档，包含了评审清单（checklist）、评审问题的记录、以及评审问题的追踪过程。
第3类是基线文档，很多团队的基线库里面，存储了N条基线，每条基线包含了一次开发过程的所有文档，比如需求文档、设计文档、测试用例等。基线管理对很多团队来说都是一个难点，一是没搞清楚基线管理的底层逻辑，二是没有找到合适的工具。有关基线管理，可以参考我上一篇文章《汽车行业如何做基线管理？》
第4类是变更文档，包含了变更请求、变更影响分析、变更评审结果、变更执行情况等。
这里我先说一个大胆的结论：不要写文档！那文档的准备时间就是0了。
看到这里，有些同学可能要划走了，“你们互联网造车真是666，上来就直接不写文档，汽车行业用血的教训，ASPICE搞了几十年，你们一上来就要颠覆它，6啊！“
这里我要对“不要写文档”作进一步的修饰：不要专门写文档，团队成员应该专注于项目推进，专注于解决一个个具体的任务，花更多时间来详细描述任务，然后通过工具，来帮助自动生成文档。
我以上述 4 类文档来一一举例，如何实现上述想法。
这句话怎么理解？有些团队把设计文档写地非常清晰，非常美观，具有层次感，恨不得从最开始就把所有的细节都写出来，他们写完了一个 50 页或100 页的文档。接下来他们需要基于这些 Specification 去安排他们的任务。这时候发现，Specification 太复杂了，太详细了，使用的工具Word或其他类似Word的在线编辑器，也不适合安排任务，然后他们开始基于Specification，去某些任务跟踪系统中创建新的任务。你瞧，这里面做了重复性的工作。
为什么设计文档本身，不能直接作为待办任务跟踪呢？
所以一种常见的拉低效率的方式是先写文档，再基于文档去重写一遍任务，当任务有更新的时候，又要反过来更新文档。或者先更新文档，再更新任务。如果不进行双向更新，显然不满足ASPICE的一致性要求，如果更新，又将是一个巨大的工作量。
另一种常见的耗时方式是，先去任务跟踪系统中创建任务，等到ASPICE评审老师要来评审时，再基于这些任务，去创建设计文档。此时任务在系统中已经非常繁杂了，结构性、追溯性的整理都非常麻烦，准备文档非常耗时，并且往往是为了准备文档而准备文档。这也是很多团队觉得，ASPICE不能帮助改进开发流程，而只会增加工作量的最大原因。
我们更推荐的方式是直接写待办任务，然后去丰富待办任务。
当待办任务写完之后，按照待办任务的组织架构方式，直接生成设计文档，甚至可以导出word格式的设计文档。
