经常听到一些团队说，我们是想满足 ASPICE，但是 ASPICE 要求的文档太多了，有没有一种方法，既能让我们的开发过程满足 ASPICE 标准要求，同时又能减少开发过程文档？
ASPICE 究竟要求了哪些开发过程文档？
基于我的经验，我把 ASPICE 中涉及的最重要（最难搞、最难整理、最难出具 evidence）的开发过程文档，分为如下 4 类：
第 1 类是设计规范（Specification）
所谓的设计规范指的是，需求文档、架构文档、详细设计文档，测试用例文档也可以放在这一类里面。一般来说这类文档拥有严格的格式，每一家公司有所不同，但都大同小异。
第 2 类是评审文档
包含了评审清单（checklist）、评审问题的记录、以及评审问题的追踪过程。
第 3 类是基线文档
很多团队的基线库里面，存储了 N 条基线，每条基线包含了一次开发过程的所有文档，比如需求文档、设计文档、测试用例等。基线管理对很多团队来说都是一个难点。
第 4 类是变更文档
包含了变更请求、变更影响分析、变更评审结果、变更执行情况等。
如果能使这 4 类开发过程文档的出具变得比较简单，那 ASPICE 项目的评审时长可以缩短 50% 以上，项目开发效率也可以提高 30% 以上。
能不能让文档准备不那么耗时？
这里我先说一个大胆的结论：不要写文档！ 那文档的准备时间就是 0 了。
看到这里，有些同学可能要划走了。这里我要对 "不要写文档" 作进一步的修饰：不要专门写文档，团队成员应该专注于项目推进，专注于解决一个个具体的任务，花更多时间来详细描述任务，然后通过工具，来帮助自动生成文档。
第一类，"设计规范不是写完了就束之高阁的，设计规范就是待办任务"。
有些团队把设计文档写得非常清晰、非常美观，具有层次感，恨不得从最开始就把所有的细节都写出来。他们写完了一个 50 页或 100 页的文档。接下来他们需要基于这些 Specification 去安排他们的任务。这时候发现，Specification 太复杂了，使用的工具 Word 也不适合安排任务，然后他们开始基于 Specification 去某些任务跟踪系统中创建新的任务。你瞧，这里面做了重复性的工作。
为什么设计文档本身，不能直接作为待办任务跟踪呢？
另一种常见的耗时方式是，先去任务跟踪系统中创建任务，等到 ASPICE 评审老师要来评审时，再基于这些任务，去创建设计文档。此时任务在系统中已经非常繁杂了，结构性、追溯性的整理都非常麻烦，准备文档非常耗时，并且往往是为了准备文档而准备文档。
我们更推荐的方式是直接写待办任务，然后去丰富待办任务。
当待办任务写完之后，按照待办任务的组织架构方式，直接生成设计文档，甚至可以导出 Word 格式的设计文档。
第二类，"评审过程本身是简单的，难的是应审"。
相信做过 ASPICE 应审的同学都会深有感触。对于团队来说，评审一份设计规范是经常要做的行为，即便没有 ASPICE 要求，也会这样做，但是他们做的过程一般是直接进行线下讨论，讨论的过程中如果发现问题，当场就直接修改了。这种方式当然是最高效的，但对于应审来说，它不满足要求，因为难以提供评审过的证据。
所以，更好的方式是将两者相结合：我们既能以一个类似线下评审的并行方式进行文档评审，同时评审的过程又能自动地留下大家的评审记录，并且将评审记录自动汇总，最终出具结果。
对于评审未通过的文档（参考上述第一类，此时文档已经是N条待办任务），留下评审未通过记录的同时，需要再次发起评审，直至完全通过评审要求。
第三类，"基线存在的唯一理由是为了变更"。
为什么这么说？大到一个项目，小到一个任务，如果我们在开始之初，就能确保不会有任何变化，那完全就不需要基线。存在基线的原因，恰好是因为在开发的过程中会有不断的变化，团队需要知道最初的需求是什么，过程中每一次变化是怎样。
很多团队都存在这样的误区，将每一次基线的内容全部保存下来。后一次基线相对于前一次基线改变了什么，反而不够清晰。很多团队使用 "高度概括" 的文档变更历史记录来显示变更 "详情"，实际上根本无法显示变更的真实内容，更别谈去追溯了。
第四类，"搞清楚什么时候需要变更，比变更本身更重要"。
有些团队在什么时候需要变更上没有搞清楚。当设计规范写下来之后，不管什么时候有改变，都要走变更评审流程，会让整个开发过程变得比较复杂且低效，且会降低变更的严肃性。最终的结果就是，如果所有的改变都需要走变更，每天都开变更评审会，没有人会认真对待评审会。
还有一些团队虽然明确了，设计冻结之后才需要变更，但是工具中无法很方便地知道是否冻结。即使工具中清晰地标明了冻结，还有一个问题，就是变更的颗粒度。如果设计规范本身的颗粒度比较粗，比如一个设计规范里面包含了 20 条需求，那么针对这个设计规范，它变更的概率接近于 1。
但是如果把这个设计规范拆分成 20 条需求（待办任务），那么其中可能 18 个需求都是没有变化的，只有两个需要变化，这个时候的变更的影响范围就不会那么大，内容也没有那么多，评审起来的效率就更高了。
