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

首先我們來(lái)分析這個(gè)問(wèn)題。

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

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

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

這篇文章，我們重點(diǎn)來(lái)回復(fù)問(wèn)題1和3.

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

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

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

第2類是評(píng)審文檔，包含了評(píng)審清單（checklist）、評(píng)審問(wèn)題的記錄、以及評(píng)審問(wèn)題的追蹤過(guò)程。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

第二類，“評(píng)審過(guò)程本身是簡(jiǎn)單的，難的是應(yīng)審”。

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

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

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

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

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

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

評(píng)審人基于變更請(qǐng)求給出的意見，最終留下評(píng)審記錄，決定變更是否最后通過(guò)。

審核編輯 ：李倩