研發(fā)過程的問題及改進機會

1、研發(fā)流程改進草稿Agenda 目前存在的問題 改進機會 實施計劃 瀑布式軟件開發(fā)流程和關(guān)鍵節(jié)點ScopeMilestoneResource立項Req analyzeReq sign off需求Code, UTFeature hand over to test開發(fā) Test entry criteria Fun & Reg & Sys test Test exit criteria 測試Demo驗收Hotfix plan & schedule維護我們的問題項目立項與計劃中的不足 項目范圍，內(nèi)容的計劃和資源安排不夠正式和嚴格 項目各個角色（需求，開發(fā)，測試）工作量和時間的預估不充分 各個關(guān)鍵節(jié)點的

2、設(shè)定和截止期限不明確 項目進行過程中的狀態(tài)更新和監(jiān)督松散，不透明 項目進行過程的突發(fā)情況的應(yīng)變和處理預案不夠 項目經(jīng)理的權(quán)力和責任沒有明確， 執(zhí)行不夠嚴格需求方面的不足 一句話需求，不夠詳細和具體 需求宣講不到位，通知不及時 需求隨時改動，沒有影響評估和審核流程 產(chǎn)品經(jīng)理對每個需求的實現(xiàn)驗沒有最終驗收，或者驗收不夠正式開發(fā)階段的不足 開發(fā)環(huán)節(jié)的關(guān)鍵時間節(jié)點計劃，監(jiān)控透明度不高 代碼評審，單元測試，集成聯(lián)調(diào)執(zhí)行情況沒人知道 轉(zhuǎn)測時間不準，質(zhì)量不高，遇到阻塞性問題是常態(tài) 整體代碼質(zhì)量不高，bug偏多，修bug重開/激活率高 開發(fā)人員質(zhì)量意識不強，或者無暇顧及，對測試非常依賴測試方面的不足 測試準入

3、和準出標準不嚴格 測試環(huán)境問題復雜費時 測試進度及結(jié)果的不夠透明及時 按照真實用戶使用場景的測試較弱維護方面的不足 沒有專門的維護團隊 做動車的時間，資源，進度，方面的控制松散 動車項目或者緊急項目的需求，范圍，方案等都沒有走正規(guī)的評審和審核，過程較亂，質(zhì)量也難把握?？偨Y(jié)與改進方面的不足 缺乏定期部門或者團隊的回顧與總結(jié)，做的不到位的一直不到位，沒有整改機會和方案。 缺乏對部門整體能力的評審與改進計劃，項目為導向，不是流程規(guī)范為導向。團隊成熟度不高 部門技術(shù)，業(yè)務(wù)培訓，知識分享比較弱改進機會項目立項與計劃中的改進機會 項目范圍，內(nèi)容的計劃和資源項目立項的時候項目負責人召集所有相關(guān)人員開一個項目

4、kick off會議，明確時間，資源，milestone和計劃 項目各個角色（需求，開發(fā)，測試）時間的合理預估各方根據(jù)項目定的范圍和需求來預估所需時間 各個關(guān)鍵節(jié)點的設(shè)定和截止期限不明確項目范圍和需求確定后，不能隨意更改，要更改需要走更改審批流程，經(jīng)各方重新評估同意，確定后的時間節(jié)點需要嚴格遵守項目立項與計劃中的改進機會 項目進行過程中的狀態(tài)更新和監(jiān)督項目日會，周會，或者報告，確保各方狀態(tài)的透明，一致，問題及時提出，風險及時辨別并制定相應(yīng)預案。 項目進行過程的突發(fā)情況的應(yīng)變和處理預案項目時間中，預留變更和突發(fā)問題的處理時間，不能把所有時間都排滿。 項目經(jīng)理的權(quán)力和責任沒有明確， 執(zhí)行不夠嚴格明

5、確項目經(jīng)理在項目中的權(quán)力和責任，各方需要尊重項目經(jīng)理對項目的控制。任何的更改，異常，人員調(diào)度需要項目經(jīng)理全權(quán)負責。需求階段的改進機會 一句話需求，不夠詳細和具體需求最終需要通過開發(fā)和測試人員的評審，并sign off之后才算合格的完成了一個需求 需求宣講和凍結(jié)沒有項目組所有角色知曉和確認需求宣講開發(fā)和測試必須參加，確保各方理解透徹一致 需求隨時改動，沒有影響評估和審核流程需求已經(jīng)做完提交測試，或者正在做的過程中需要更改的，需要走需求更改流程，各方一起討論，評估了影響并有相應(yīng)對策之后才能批準更改并進入當前項目。 產(chǎn)品經(jīng)理對每個需求的實現(xiàn)驗沒有最終驗收，或者驗收不夠正式項目結(jié)束之前，相應(yīng)的產(chǎn)品經(jīng)理

6、需要對各自的需求實現(xiàn)進行驗收開發(fā)階段的改進機會 開發(fā)環(huán)節(jié)的關(guān)鍵時間節(jié)點計劃，監(jiān)控透明度不高開發(fā)需要向項目成員說明開發(fā)計劃，轉(zhuǎn)測計劃，及各關(guān)鍵節(jié)點，并堅守這些節(jié)點 代碼評審，單元測試，集成聯(lián)調(diào)執(zhí)行情況正規(guī)化，嚴格化，做單元測試，聯(lián)調(diào)，代碼評審，轉(zhuǎn)測的時候需要提交相關(guān)文檔或者報告 轉(zhuǎn)測時間不準與質(zhì)量不高，遇到阻塞性問題是常態(tài)轉(zhuǎn)測前，開發(fā)需要在開發(fā)環(huán)境做好聯(lián)調(diào)，不是光自己的代碼運行沒問題需要制定轉(zhuǎn)測相關(guān)的標準 整體代碼質(zhì)量不高，bug偏多，修bug重開/激活率高需要保證開發(fā)人員的時間寫code，UT，review等加強業(yè)務(wù)和技術(shù)方面的培訓和指導 開發(fā)人員質(zhì)量意識不強，或者無暇顧及，對測試非常依賴加強

7、引導，扭轉(zhuǎn)思想，灌輸好的質(zhì)量是開發(fā)做出來的思維。測試方面改進機會 測試準入和準出標準不嚴格制定并嚴格執(zhí)行測試準入標準，測試退回標準 測試環(huán)境問題復雜費時自動化部署環(huán)境工具及模板 測試進度及結(jié)果的透明度不夠制定統(tǒng)一的測試模板，測試風險反饋信息，提高測試狀況透明度制定針對每個項目/需求的質(zhì)量報告 按照真實用戶使用場景的測試較弱學習用戶使用場景，了解。多去現(xiàn)場了解軟件使用中加強培訓，增加了解全流程的人員，不能只掌握自己測試的一塊業(yè)務(wù)維護方面的改進機會 組建專門的維護團隊，負責線上問題處理的計劃，跟蹤，處理和分析。 需要對線上問題進行總結(jié)，歸納，對數(shù)據(jù)進行分析，分類并在團隊分享，避免重復問題再犯。 管理動車項目常態(tài)化，流程化，正規(guī)化?？偨Y(jié)與回顧改進機會 定期以團隊為單位，對好的，不好的經(jīng)驗和問題進行回顧，好的繼續(xù)堅持，不好的提