作者?|?羅宇超
出品?|?汽車電子與軟件
經常聽到一些團隊說，我們是想滿足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格式的設計文檔。
