經(jīng)常聽到一些團隊說，我們是想滿足ASPICE，但是ASPICE要求的文檔太多了，有沒有一種方法，既能讓我們的開發(fā)過程滿足ASPICE標(biāo)準(zhǔn)要求，同時又能減少開發(fā)過程文檔？

首先我們來分析這個問題。

既然我們想要減少開發(fā)過程文檔，那么首先就需要知道，1. ASPICE究竟要求了哪些開發(fā)過程文檔？

如果能找到這些最耗時的開發(fā)過程文檔，接下來我們可以考慮，2.是否能直接減少這些開發(fā)過程文檔？

直接減少開發(fā)過程文檔本身，相當(dāng)于在直接挑戰(zhàn)ASPICE框架，是很難說服評審師的，有很大的失敗風(fēng)險。我們換個角度，3.能不能讓開發(fā)過程文檔的準(zhǔn)備不那么耗時？

這篇文章，我們重點來回復(fù)問題1和3.

1. ASPICE究竟要求了哪些開發(fā)過程文檔？

基于我的經(jīng)驗，我把ASPICE中涉及的最重要（最難搞、最難整理、最難出具evidence……）的開發(fā)過程文檔，分為如下 4 類，如果能使如下4 類開發(fā)過程文檔的出具變得比較簡單，那ASPICE項目的評審時長可以縮短50%以上，項目開發(fā)效率也可以提高30%以上。

第1類是設(shè)計規(guī)范（Specification），所謂的設(shè)計規(guī)范指的是，需求文檔、架構(gòu)文檔、詳細(xì)設(shè)計文檔，測試用例文檔也可以放在這一類里面。一般來說這類文檔擁有嚴(yán)格的格式，每一家公司有所不同，但都大同小異。

第2類是評審文檔，包含了評審清單（checklist）、評審問題的記錄、以及評審問題的追蹤過程。

第3類是基線文檔，很多團隊的基線庫里面，存儲了N條基線，每條基線包含了一次開發(fā)過程的所有文檔，比如需求文檔、設(shè)計文檔、測試用例等。基線管理對很多團隊來說都是一個難點，一是沒搞清楚基線管理的底層邏輯，二是沒有找到合適的工具。有關(guān)基線管理，可以參考我上一篇文章《汽車行業(yè)如何做基線管理？》

第4類是變更文檔，包含了變更請求、變更影響分析、變更評審結(jié)果、變更執(zhí)行情況等。

3. 能不能讓開發(fā)過程文檔的準(zhǔn)備不那么耗時？

這里我先說一個大膽的結(jié)論：不要寫文檔！那文檔的準(zhǔn)備時間就是0了。

看到這里，有些同學(xué)可能要劃走了，“你們互聯(lián)網(wǎng)造車真是666，上來就直接不寫文檔，汽車行業(yè)用血的教訓(xùn)，ASPICE搞了幾十年，你們一上來就要顛覆它，6啊！“

這里我要對“不要寫文檔”作進一步的修飾：不要專門寫文檔，團隊成員應(yīng)該專注于項目推進，專注于解決一個個具體的任務(wù)，花更多時間來詳細(xì)描述任務(wù)，然后通過工具，來幫助自動生成文檔。

我以上述 4 類文檔來一一舉例，如何實現(xiàn)上述想法。

第一類，“設(shè)計規(guī)范不是寫完了就束之高閣的，設(shè)計規(guī)范就是待辦任務(wù)”。

這句話怎么理解？有些團隊把設(shè)計文檔寫地非常清晰，非常美觀，具有層次感，恨不得從最開始就把所有的細(xì)節(jié)都寫出來，他們寫完了一個 50 頁或100 頁的文檔。接下來他們需要基于這些 Specification 去安排他們的任務(wù)。這時候發(fā)現(xiàn)，Specification 太復(fù)雜了，太詳細(xì)了，使用的工具Word或其他類似Word的在線編輯器，也不適合安排任務(wù)，然后他們開始基于Specification，去某些任務(wù)跟蹤系統(tǒng)中創(chuàng)建新的任務(wù)。你瞧，這里面做了重復(fù)性的工作。

為什么設(shè)計文檔本身，不能直接作為待辦任務(wù)跟蹤呢？

所以一種常見的拉低效率的方式是先寫文檔，再基于文檔去重寫一遍任務(wù)，當(dāng)任務(wù)有更新的時候，又要反過來更新文檔。或者先更新文檔，再更新任務(wù)。如果不進行雙向更新，顯然不滿足ASPICE的一致性要求，如果更新，又將是一個巨大的工作量。

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

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

當(dāng)待辦任務(wù)寫完之后，按照待辦任務(wù)的組織架構(gòu)方式，直接生成設(shè)計文檔，甚至可以導(dǎo)出word格式的設(shè)計文檔。

第二類，“評審過程本身是簡單的，難的是應(yīng)審”。

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

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

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

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

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

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

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

審核編輯 ：李倩