經(jīng)常聽(tīng)到一些團(tuán)隊(duì)說(shuō),我們是想滿足ASPICE,但是ASPICE要求的文檔太多了,有沒(méi)有一種方法,既能讓我們的開(kāi)發(fā)過(guò)程滿足ASPICE標(biāo)準(zhǔn)要求,同時(shí)又能減少開(kāi)發(fā)過(guò)程文檔?
首先我們來(lái)分析這個(gè)問(wèn)題。
既然我們想要減少開(kāi)發(fā)過(guò)程文檔,那么首先就需要知道,1. ASPICE究竟要求了哪些開(kāi)發(fā)過(guò)程文檔?
如果能找到這些最耗時(shí)的開(kāi)發(fā)過(guò)程文檔,接下來(lái)我們可以考慮,2.是否能直接減少這些開(kāi)發(fā)過(guò)程文檔?
直接減少開(kāi)發(fā)過(guò)程文檔本身,相當(dāng)于在直接挑戰(zhàn)ASPICE框架,是很難說(shuō)服評(píng)審師的,有很大的失敗風(fēng)險(xiǎn)。我們換個(gè)角度,3.能不能讓開(kāi)發(fā)過(guò)程文檔的準(zhǔn)備不那么耗時(shí)?
這篇文章,我們重點(diǎn)來(lái)回復(fù)問(wèn)題1和3.
1. ASPICE究竟要求了哪些開(kāi)發(fā)過(guò)程文檔?
基于我的經(jīng)驗(yàn),我把ASPICE中涉及的最重要(最難搞、最難整理、最難出具evidence……)的開(kāi)發(fā)過(guò)程文檔,分為如下 4 類(lèi),如果能使如下4 類(lèi)開(kāi)發(fā)過(guò)程文檔的出具變得比較簡(jiǎn)單,那ASPICE項(xiàng)目的評(píng)審時(shí)長(zhǎng)可以縮短50%以上,項(xiàng)目開(kāi)發(fā)效率也可以提高30%以上。
第1類(lèi)是設(shè)計(jì)規(guī)范(Specification),所謂的設(shè)計(jì)規(guī)范指的是,需求文檔、架構(gòu)文檔、詳細(xì)設(shè)計(jì)文檔,測(cè)試用例文檔也可以放在這一類(lèi)里面。一般來(lái)說(shuō)這類(lèi)文檔擁有嚴(yán)格的格式,每一家公司有所不同,但都大同小異。
第2類(lèi)是評(píng)審文檔,包含了評(píng)審清單(checklist)、評(píng)審問(wèn)題的記錄、以及評(píng)審問(wèn)題的追蹤過(guò)程。
第3類(lèi)是基線文檔,很多團(tuán)隊(duì)的基線庫(kù)里面,存儲(chǔ)了N條基線,每條基線包含了一次開(kāi)發(fā)過(guò)程的所有文檔,比如需求文檔、設(shè)計(jì)文檔、測(cè)試用例等?;€管理對(duì)很多團(tuán)隊(duì)來(lái)說(shuō)都是一個(gè)難點(diǎn),一是沒(méi)搞清楚基線管理的底層邏輯,二是沒(méi)有找到合適的工具。有關(guān)基線管理,可以參考我上一篇文章《汽車(chē)行業(yè)如何做基線管理?》
第4類(lèi)是變更文檔,包含了變更請(qǐng)求、變更影響分析、變更評(píng)審結(jié)果、變更執(zhí)行情況等。
3. 能不能讓開(kāi)發(fā)過(guò)程文檔的準(zhǔn)備不那么耗時(shí)?
這里我先說(shuō)一個(gè)大膽的結(jié)論:不要寫(xiě)文檔!那文檔的準(zhǔn)備時(shí)間就是0了。
看到這里,有些同學(xué)可能要?jiǎng)澴吡?,“你們互?lián)網(wǎng)造車(chē)真是666,上來(lái)就直接不寫(xiě)文檔,汽車(chē)行業(yè)用血的教訓(xùn),ASPICE搞了幾十年,你們一上來(lái)就要顛覆它,6?。 ?/p>
這里我要對(duì)“不要寫(xiě)文檔”作進(jìn)一步的修飾:不要專(zhuān)門(mén)寫(xiě)文檔,團(tuán)隊(duì)成員應(yīng)該專(zhuān)注于項(xiàng)目推進(jìn),專(zhuān)注于解決一個(gè)個(gè)具體的任務(wù),花更多時(shí)間來(lái)詳細(xì)描述任務(wù),然后通過(guò)工具,來(lái)幫助自動(dòng)生成文檔。
我以上述 4 類(lèi)文檔來(lái)一一舉例,如何實(shí)現(xiàn)上述想法。
第一類(lèi),“設(shè)計(jì)規(guī)范不是寫(xiě)完了就束之高閣的,設(shè)計(jì)規(guī)范就是待辦任務(wù)”。
這句話怎么理解?有些團(tuán)隊(duì)把設(shè)計(jì)文檔寫(xiě)地非常清晰,非常美觀,具有層次感,恨不得從最開(kāi)始就把所有的細(xì)節(jié)都寫(xiě)出來(lái),他們寫(xiě)完了一個(gè) 50 頁(yè)或100 頁(yè)的文檔。接下來(lái)他們需要基于這些 Specification 去安排他們的任務(wù)。這時(shí)候發(fā)現(xiàn),Specification 太復(fù)雜了,太詳細(xì)了,使用的工具Word或其他類(lèi)似Word的在線編輯器,也不適合安排任務(wù),然后他們開(kāi)始基于Specification,去某些任務(wù)跟蹤系統(tǒng)中創(chuàng)建新的任務(wù)。你瞧,這里面做了重復(fù)性的工作。
為什么設(shè)計(jì)文檔本身,不能直接作為待辦任務(wù)跟蹤呢?
所以一種常見(jiàn)的拉低效率的方式是先寫(xiě)文檔,再基于文檔去重寫(xiě)一遍任務(wù),當(dāng)任務(wù)有更新的時(shí)候,又要反過(guò)來(lái)更新文檔。或者先更新文檔,再更新任務(wù)。如果不進(jìn)行雙向更新,顯然不滿足ASPICE的一致性要求,如果更新,又將是一個(gè)巨大的工作量。
另一種常見(jiàn)的耗時(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)開(kāi)發(fā)流程,而只會(huì)增加工作量的最大原因。
我們更推薦的方式是直接寫(xiě)待辦任務(wù),然后去豐富待辦任務(wù)。
當(dāng)待辦任務(wù)寫(xiě)完之后,按照待辦任務(wù)的組織架構(gòu)方式,直接生成設(shè)計(jì)文檔,甚至可以導(dǎo)出word格式的設(shè)計(jì)文檔。
第二類(lèi),“評(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è)類(lèi)似線下評(píng)審的并行方式進(jìn)行文檔評(píng)審,同時(shí)評(píng)審的過(guò)程又能自動(dòng)地留下大家的評(píng)審記錄,并且將評(píng)審記錄自動(dòng)匯總,最終出具結(jié)果。
對(duì)于評(píng)審未通過(guò)的文檔(參考上述第一類(lèi),此時(shí)文檔已經(jīng)是N條待辦任務(wù)),留下評(píng)審未通過(guò)記錄的同時(shí),需要再次發(fā)起評(píng)審,直至完全通過(guò)評(píng)審要求。
第三類(lèi),“基線存在的唯一理由是為了變更”。
為什么這么說(shuō),大到一個(gè)項(xiàng)目,小到一個(gè)任務(wù),如果我們?cè)陂_(kāi)始之初,就能確保不會(huì)有任何變化,那完全就不需要基線。存在基線的原因,恰好是因?yàn)樵陂_(kāi)發(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)容,更別談去追溯了,這就有些本末倒置了。
第四類(lèi),“搞清楚什么時(shí)候需要變更,比變更本身更重要”。
有些團(tuán)隊(duì)在什么時(shí)候需要變更上沒(méi)有搞清楚。 當(dāng)設(shè)計(jì)規(guī)范寫(xiě)下來(lái)之后,不管什么時(shí)候有改變,都要走變更評(píng)審流程,會(huì)讓整個(gè)開(kāi)發(fā)過(guò)程變得比較復(fù)雜且低效,且會(huì)降低變更的嚴(yán)肅性。最終的結(jié)果就是,如果所有的改變都需要走變更,每天都開(kāi)變更評(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)求給出的意見(jiàn),最終留下評(píng)審記錄,決定變更是否最后通過(guò)。
審核編輯 :李倩
-
框架
+關(guān)注
關(guān)注
0文章
404瀏覽量
17904 -
文檔
+關(guān)注
關(guān)注
0文章
48瀏覽量
12197 -
編輯器
+關(guān)注
關(guān)注
1文章
822瀏覽量
32061
原文標(biāo)題:如何既滿足ASPICE要求,又減少開(kāi)發(fā)過(guò)程文檔
文章出處:【微信號(hào):阿寶1990,微信公眾號(hào):阿寶1990】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。
發(fā)布評(píng)論請(qǐng)先 登錄
集中于車(chē)身開(kāi)發(fā)過(guò)程的數(shù)據(jù)管理技術(shù)研究
Stages研發(fā)過(guò)程可視化建模和管理平臺(tái)
嵌入式系統(tǒng)開(kāi)發(fā)過(guò)程簡(jiǎn)化
有沒(méi)有例程開(kāi)發(fā)過(guò)程的視頻或者文檔資料呢?求分享
nodemcu的開(kāi)發(fā)過(guò)程是怎樣的
MOSFET較小的柵極電阻可以減少開(kāi)通損耗嗎?
基于PPC8270的BSP開(kāi)發(fā)過(guò)程

基于DSPs的系統(tǒng)開(kāi)發(fā)過(guò)程

軟件開(kāi)發(fā)過(guò)程中需要的十三類(lèi)文檔
ASPICE實(shí)施的點(diǎn)滴經(jīng)驗(yàn)分享
如何讀懂FPGA開(kāi)發(fā)過(guò)程中的Vivado時(shí)序報(bào)告?

Android校園應(yīng)用開(kāi)發(fā)過(guò)程

ASIC芯片開(kāi)發(fā)過(guò)程
Stages—研發(fā)過(guò)程可視化建模和管理平臺(tái)

評(píng)論