經常聽到一些團隊說，我們是想滿足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，去某些任務跟蹤系統中創建新的任務。你瞧，這里面做了重復性的工作。

為什么設計文檔本身，不能直接作為待辦任務跟蹤呢？

所以一種常見的拉低效率的方式是先寫文檔，再基于文檔去重寫一遍任務，當任務有更新的時候，又要反過來更新文檔?；蛘呦雀挛臋n，再更新任務。如果不進行雙向更新，顯然不滿足ASPICE的一致性要求，如果更新，又將是一個巨大的工作量。

另一種常見的耗時方式是，先去任務跟蹤系統中創建任務，等到ASPICE評審老師要來評審時，再基于這些任務，去創建設計文檔。此時任務在系統中已經非常繁雜了，結構性、追溯性的整理都非常麻煩，準備文檔非常耗時，并且往往是為了準備文檔而準備文檔。這也是很多團隊覺得，ASPICE不能幫助改進開發流程，而只會增加工作量的最大原因。

我們更推薦的方式是直接寫待辦任務，然后去豐富待辦任務。

當待辦任務寫完之后，按照待辦任務的組織架構方式，直接生成設計文檔，甚至可以導出word格式的設計文檔。

第二類，“評審過程本身是簡單的，難的是應審”。

相信做過ASPICE應審的同學都會深有感觸。對于團隊來說，評審一份設計規范是經常要做的行為，即便沒有ASPICE要求，也會這樣做，但是他們做的過程一般是直接進行線下討論，討論的過程中如果發現問題，當場就直接修改了，這種方式當然是最高效的，但對于應審來說，它不滿足要求，因為難以提供評審過的證據。 所以，更好的方式是將兩者相結合，我們既能以一個類似線下評審的并行方式進行文檔評審，同時評審的過程又能自動地留下大家的評審記錄，并且將評審記錄自動匯總，最終出具結果。

對于評審未通過的文檔（參考上述第一類，此時文檔已經是N條待辦任務），留下評審未通過記錄的同時，需要再次發起評審，直至完全通過評審要求。

第三類，“基線存在的唯一理由是為了變更”。

為什么這么說，大到一個項目，小到一個任務，如果我們在開始之初，就能確保不會有任何變化，那完全就不需要基線。存在基線的原因，恰好是因為在開發的過程中會有不斷的變化，團隊需要知道最初的需求是什么，過程中每一次變化是怎樣?；€的存在對于甲乙雙方都是一個保護作用。對于甲方客戶來說，可以確保乙方不會輕易去修改他的原始需求，對于乙方來說，也可以防止甲方提完需求之后，中途隨意增加、改變需求，從而導致整個項目延期。 所以，基線能清晰地反饋過程中的變化就夠了，而不需要將每次變更后的基線內容全部保存下來。很多團隊都存在這樣的誤區，將每一次基線的內容全部保存下來。后一次基線相對于前一次基線改變了什么，反而不夠清晰。很多團隊使用“高度概括”的文檔變更歷史記錄來顯示變更“詳情”，實際上根本無法顯示變更的真實內容，更別談去追溯了，這就有些本末倒置了。

第四類，“搞清楚什么時候需要變更，比變更本身更重要”。

有些團隊在什么時候需要變更上沒有搞清楚。 當設計規范寫下來之后，不管什么時候有改變，都要走變更評審流程，會讓整個開發過程變得比較復雜且低效，且會降低變更的嚴肅性。最終的結果就是，如果所有的改變都需要走變更，每天都開變更評審會，沒有人會認真對待評審會，也就相當于沒有了變更評審會。 還有一些團隊雖然明確了，設計凍結之后才需要變更，但是工具中無法很方便地知道是否凍結（如果使用線下的word、excel，每個人就更難明確，文檔是否真的凍結了。大多數工具也無法清晰地標明這一點）。 即使工具中清晰地標明了凍結，還有一個問題，就是變更的顆粒度。如果設計規范本身的顆粒度比較粗，比如一個設計規范里面包含了20條需求，那么針對這個設計規范，它變更的概率接近于1（1-50%^20），同上，會面臨著頻繁的變更評審活動。 但是如果把這個設計規范拆分成20條需求（待辦任務），那么其中可能18 個需求都是沒有變化的，只有兩個需要變化，這個時候的變更的影響范圍就不會那么大，內容也沒有那么多，評審起來的效率就更高了。而且由于設計規范的顆粒度足夠小，因此變更請求方對于這個需求的變更就可以非常明確，變更的影響范圍也可以非常明確。

評審人基于變更請求給出的意見，最終留下評審記錄，決定變更是否最后通過。

審核編輯 ：李倩