論研發(fā)項目生產(chǎn)質(zhì)量低的原因分析和解決方案

姜成玲

（中國—東盟信息港股份有限公司，廣西 南寧 530200）

0 引言

本文在開展研發(fā)項目生產(chǎn)管理質(zhì)量的研究中，對公司中的度量數(shù)據(jù)進(jìn)行調(diào)查和分析，發(fā)現(xiàn)項目中存在的問題，將統(tǒng)計數(shù)據(jù)和計劃目標(biāo)的缺陷密度水平進(jìn)行對比。發(fā)現(xiàn)項目問題缺陷較少，能夠滿足目標(biāo)要求，但是仍然存在很多問題亟待改進(jìn)。企業(yè)的發(fā)展建設(shè)中，必須要對研發(fā)項目生產(chǎn)質(zhì)量問題進(jìn)行分析，確定原因所在，以提出針對性的解決方案與策略。

1 研發(fā)項目生產(chǎn)質(zhì)量分析

1.1 數(shù)據(jù)收集和分析

為進(jìn)一步提升企業(yè)項目生產(chǎn)質(zhì)量問題分析的水平，在研究中引入了EPG技術(shù)以擴(kuò)大數(shù)據(jù)收集范圍和數(shù)據(jù)收集量。以某公司兩個月的數(shù)據(jù)進(jìn)行統(tǒng)計分析，在數(shù)據(jù)篩選和分析中基于一定的原則執(zhí)行，項目和數(shù)據(jù)選擇中按照如下原則進(jìn)行：

（1）分別采用簡單測試配置和詳細(xì)測試兩種測試方式進(jìn)行測試，獲得的數(shù)據(jù)用于本研究。

（2）本研究中涉及的項目要求需求和設(shè)計評審過程穩(wěn)定。

（3）故事點數(shù)、測試用例數(shù)和線上bug等數(shù)據(jù)收集完整。

基于前面數(shù)據(jù)和項目篩選原則，結(jié)合相應(yīng)模型對研發(fā)項目生產(chǎn)質(zhì)量情況進(jìn)行評價，主要包括以下幾個模型：

簡單測試缺陷密度模型：

缺陷密度=0.2141+0.1461＊用例密度-0.05176＊開發(fā)平均行業(yè)經(jīng)驗

目前公司平均行業(yè)開發(fā)經(jīng)驗5.78年，行業(yè)經(jīng)驗需要在本領(lǐng)域內(nèi)進(jìn)行經(jīng)驗積累，也很難在短時間內(nèi)對開發(fā)平均行業(yè)經(jīng)驗進(jìn)行大幅度提升，對本因子暫不考慮改進(jìn)。測試用的密度：UCL=1.491，均值=0.638，標(biāo)準(zhǔn)差=0.256，1個故事點只有0.638個用例，用例密度不高，仍然有進(jìn)一步提升的空間，后期再對此進(jìn)行更進(jìn)一步的分析。

詳細(xì)測試缺陷密度模型：

缺陷密度詳細(xì)=0.4460-0.003130＊需求清晰度+0.02801＊測試人員平均行業(yè)經(jīng)驗

目前公司測試平均行業(yè)約2.99年，測試行業(yè)經(jīng)驗需要在本領(lǐng)域內(nèi)進(jìn)行經(jīng)驗積累，也很難在短時間內(nèi)對測試平均行業(yè)經(jīng)驗進(jìn)行大幅度提升，對本因子暫不考慮改進(jìn)。需求清晰度密度：UCL=113.18，均值=72.33，標(biāo)準(zhǔn)差=11.16，需求清晰度的均值不高，根據(jù)需求清晰度模型：需求清晰度=需求評審分值（65）+需求文檔分值（35），需求評審均值為15分，需求文檔規(guī)范性平均分?jǐn)?shù)為50分。EPG又對需求規(guī)范及需求評審做了進(jìn)一步的分析，分析如下圖1：

圖1 需求規(guī)范的I-MR控制圖

需求規(guī)范：UCL=84.64，均值=51.4，標(biāo)準(zhǔn)差=9.605，需求規(guī)范均值較低。

需求評審：UCL=31.95，均值=20.93，標(biāo)準(zhǔn)差=3.41。需求評審均值較低。

通過評價結(jié)果能夠看出，該公司當(dāng)中目前研發(fā)項目生產(chǎn)的需求規(guī)范均值較低，且需求評審均值也較低。因此需要對需求規(guī)范分?jǐn)?shù)及需求評審進(jìn)一步地提高，來降低缺陷密度。

圖2 需求評審的I-MR控制圖

1.2 數(shù)據(jù)分析初步結(jié)論

從以上的數(shù)據(jù)分析結(jié)果看，簡單測試中測試用例的密度對缺陷密度有很重要的影響。而詳細(xì)測試中需求的清晰度與系統(tǒng)缺陷呈負(fù)相關(guān)，需求越清晰缺陷密度越小，系統(tǒng)質(zhì)量將越高[1]。且研究的公司中研發(fā)項目生產(chǎn)的需求規(guī)范均值較低，且需求評審均值較低。因此，本文希望就需求規(guī)范較低及需求評審均值較低的原因進(jìn)行分析，并就如何提升項目用例密度及需求清晰度展開研究。

2 研發(fā)項目生產(chǎn)質(zhì)量低原因分析

根據(jù)前面數(shù)據(jù)分析的結(jié)論，跟缺陷密度相關(guān)的關(guān)鍵因素主要包括：需求清晰度和用例密度，下面將從這兩個維度進(jìn)行分析。

2.1 用例密度

對簡單測試軟件質(zhì)量影響的主要因素是用例的密度，EPG對符合條件的6個17個版本項目進(jìn)行分析，目前用例均值為0.638。

公司用例密度模型：用例密度=checklist檢查點/故事點，檢查點數(shù)包括：公共用例及關(guān)鍵用例。關(guān)鍵用例是每次迭代中涉及主流程的用例，目前關(guān)鍵用例在每次需求中均進(jìn)行了完整的輸入和評審，提升空間較小。公共用例包括產(chǎn)品管理辦法中通用模塊的用例、通用經(jīng)驗形成的用例及線上bug用例。

目前公司公共用例共有107條，涉及功能模塊10個，涉及2個應(yīng)用場景，移動端和桌面端，移動端用例數(shù)占整體用例15個。

EPG又對近2個月發(fā)生的28個線上bug所屬責(zé)任人進(jìn)行了訪談，匯總了產(chǎn)生線上bug原因。共發(fā)現(xiàn)28個線上bug，11%是由客戶提出的優(yōu)化性bug，14%是因為測試環(huán)境與線上環(huán)境不一致引起的bug，75%的原因是因測試用例未涉而導(dǎo)致測試遺漏bug?，F(xiàn)有公共因測試用例未涉及的線上bug占比75%，占比較高[2]。

EPG對用例密度低的原因進(jìn)行分析發(fā)現(xiàn)：

①很多項目將功能點作為測試用例，并未引入測試公共測試用例。②公用測試用例只涉及app端和web端，且模塊類型少。③原有公共用例未對常出現(xiàn)的bug進(jìn)行匯總整理。④公用用例未根據(jù)項目的發(fā)展情況做定期的更新維護(hù)。⑤每次迭代未對已經(jīng)出現(xiàn)過的線上bug的再次回歸。

根據(jù)以上分析結(jié)果，EPG建議增加測試用例密度，引入公共用例庫和線上bug用例庫，并定期對用例進(jìn)行更新和完善。

2.2 需求清晰度

根據(jù)模型可知詳細(xì)測試軟件質(zhì)量影響的主要因素是需求清晰度，需求清晰度又與需求規(guī)范程度及需求評審質(zhì)量有關(guān)，公司需求清晰度模型：需求清晰度（100）=需求規(guī)范（65）+需求評審（35）。

EPG對需求規(guī)范和需求評審與缺陷密度進(jìn)行了進(jìn)一步的相關(guān)性分析。根據(jù)相關(guān)性分析可見R2=0.5678，需求規(guī)范與缺陷密度顯著相關(guān)，需求越規(guī)范缺陷密度則會越低。根據(jù)相關(guān)性分析可見R2=0.3104，需求評審與缺陷密度顯著相關(guān)，需求評審越高缺陷密度則會越低[3]。

對某公司2個月的需求清晰度數(shù)值進(jìn)行分析，發(fā)現(xiàn)公司需求清晰度均值72.3分，需求規(guī)范均值50分，需求評審均值15分。

EPG進(jìn)一步對項目組成員抽樣訪談，樣本總數(shù)為20個人，然后根據(jù)訪談人員問題進(jìn)行分類匯總。統(tǒng)計結(jié)果顯示逆向場景未體現(xiàn)問題占11%；需求前后不一致，端與端不一致問題占11%；違反撰寫不二性問題占14%；未體現(xiàn)需求優(yōu)先級問題占16%；設(shè)計未體現(xiàn)交互設(shè)計占23%。 其中設(shè)計為體現(xiàn)交互問題占比較高，未按照產(chǎn)品需求規(guī)范編寫占41%。表達(dá)不清晰問題占12%，業(yè)務(wù)流程邏輯不清晰問題占13%，未覆蓋前端人員需求占17%，評審有遺留問題未閉環(huán)占20%，場景考慮不全占28%。其中需求覆蓋不全、場景覆蓋不全，需求、問題未閉環(huán)占比較高。

對以上需求不規(guī)范及需求評審均值低， EPG又進(jìn)一步對其原因進(jìn)行分析，主要包括以下幾點：①生命周期覆蓋不全：未涉及運維和客服人員的需求；未能覆蓋市場前端，產(chǎn)品和市場前端存在脫節(jié)。②規(guī)范場景不夠豐富：規(guī)范僅僅覆蓋桌面及移動端，共性提煉有待進(jìn)一步豐富。③缺乏有效管控手段：管控手段更多是定性手段；精細(xì)管控手段確實無法保障規(guī)范的有效執(zhí)行。④未能形成價值閉環(huán)：需求沒有定義價值預(yù)期；需求實現(xiàn)后沒有進(jìn)行價值回顧。⑤端到端模板管控缺失：從原型設(shè)計、UI設(shè)計、代碼實現(xiàn)及測試等端到端模板化管控，避免失真[4]。

從以上分析結(jié)果可以看出，一方面，在項目中引入并采用公共用例庫及線上bug用例庫增加用例的密度可以提高缺陷密度，從而提高軟件的質(zhì)量；另一方面，提高需求的清晰度，通過制定完善產(chǎn)品需求規(guī)范，完整的流程規(guī)范，并對公司產(chǎn)品人員進(jìn)行產(chǎn)品知識的定期培訓(xùn)，來提升產(chǎn)品人員的技能，提高需求的清晰度。

3 研發(fā)項目生產(chǎn)質(zhì)量低的解決方案與應(yīng)對策略

3.1 引入公共用例及線上bug用例庫提高測試用例的密度

①根據(jù)產(chǎn)品規(guī)范補充完善公共用例庫。②公共用例庫中引入bug類的用例。③分析總結(jié)線上bug，建立各個項目組線上bug用例庫。④針對公共用例庫進(jìn)行季度更新補充機(jī)制，線上用例庫進(jìn)行月度更新補充機(jī)制。⑤對測試人員進(jìn)行培訓(xùn)和宣貫。

3.2 完善現(xiàn)有產(chǎn)品管理辦法，并進(jìn)行推廣

公司根據(jù)現(xiàn)有規(guī)范存在的問題，對《中國東信產(chǎn)品管理辦法V1.0》進(jìn)行修訂，修訂方面如下：

全生命周期管理：規(guī)范產(chǎn)品管理14項標(biāo)準(zhǔn)環(huán)節(jié)，統(tǒng)一文檔模板、統(tǒng)一設(shè)計及開發(fā)原件庫、統(tǒng)一操作標(biāo)準(zhǔn)，環(huán)環(huán)相扣，確保信息在各環(huán)境不出現(xiàn)衰減，實現(xiàn)產(chǎn)品全過程規(guī)范化、流程化、模板化高質(zhì)量輸出[5]。

全業(yè)務(wù)場景覆蓋：梳理公司現(xiàn)有及潛在的業(yè)務(wù)場景，針對性進(jìn)行UI設(shè)計規(guī)范完善，覆蓋公司四大類產(chǎn)品以及桌面、移動端、小程序、大屏、資訊等多種展示方式。

端到端模板管控：流程起始，產(chǎn)品經(jīng)理按照模板輸出標(biāo)準(zhǔn)原型圖，途徑UI設(shè)計、前端界面開發(fā)、QA驗證等環(huán)節(jié)，使用Axure模板等工具確保各環(huán)節(jié)信息傳遞不失真，最終由產(chǎn)品經(jīng)理進(jìn)行驗收，形成流程閉環(huán)。產(chǎn)品經(jīng)理為產(chǎn)品標(biāo)準(zhǔn)執(zhí)行的第一責(zé)任人。

需求價值閉環(huán)管理：建立基于價值的閉環(huán)的需求管理機(jī)制，讓每個需求提出人有序、公平地提出需求，將有限的研發(fā)資源投入到對公司最有利的需求上，實現(xiàn)公司利益最大化。

4 結(jié)語

企業(yè)的新產(chǎn)品研發(fā)管理，是一個包括戰(zhàn)略規(guī)劃（新產(chǎn)品策略形成、制定）和戰(zhàn)略實施（包括新產(chǎn)品項目評價、控制）的過程。依據(jù)企業(yè)的文化、特殊核心競爭能力，分析產(chǎn)業(yè)環(huán)境及競爭者動態(tài)，所有的產(chǎn)品開發(fā)，我們認(rèn)為都是獨立的項目，整合管理的概念及資訊、技術(shù)，構(gòu)建一個優(yōu)質(zhì)的新產(chǎn)品開發(fā)支持及監(jiān)測系統(tǒng)，提供項目人員便利、豐富、即時及多層面的信息，并控制新產(chǎn)品研發(fā)質(zhì)量、進(jìn)度、成本及相關(guān)工程文件管理，在提升新產(chǎn)品的質(zhì)量、掌握新產(chǎn)品的成本及開發(fā)費用之同時，可以縮短新產(chǎn)品上市的時間。