軟件開發(fā)項目管理-文庫吧資料
2025-04-19 02:04本頁面
【正文】 量不達標等方面，常見風險如下：目標以及需求不明確為了市場競爭或內(nèi)部管理決策的需要，業(yè)務(wù)部門提出的需求往往要求的時間比較緊迫，需求的提出大多停留在幾張紙或口頭的傳達上，沒有正式的業(yè)務(wù)需求文檔，在沒有明確的需求范圍的情況下，有時為了迎合業(yè)務(wù)部門的口味匆匆開工，過程中用戶不斷地提出新的想法，技術(shù)人員開始疲于奔命和應(yīng)付，很難保證項目的進度和質(zhì)量，也難以取得業(yè)務(wù)部門的認可。需求凍結(jié)。開發(fā)人員修改代碼中的相關(guān)部分。相關(guān)人員接收到確認的需求變更后，需求分析人員修改需求說明書和UserCase的相關(guān)內(nèi)容。確定變更的負責人。需求變更的決策應(yīng)由項目管理者做出。針對接收到的需求變更的要求，召集相關(guān)人員討論該需求變更的合理性、可行性，實施的代價以及對項目的影響。需求變更的提出者可以是項目中的任何人包括產(chǎn)品經(jīng)理、市場人員、開發(fā)人員、測試人員等。將以UserCase作為需求基準線，在UserCase確認之后的任何需求改變，都需要走需求變更流程。通過制定需求變更的流程，確保項目中的需求變更有效地進行，實現(xiàn)上述的目標。變更處于有效的管理中。積極發(fā)現(xiàn)引起變更的因素，促使變更盡可能早的出現(xiàn)，減低變更帶來的風險。 對待需求變更的正確態(tài)度：需求變更是不可避免的。 代碼審核者把CodeReview中發(fā)現(xiàn)的有價值的問題更新到代碼審核規(guī)范的文檔中，對于特別值得提醒的問題可群發(fā)給所有技術(shù)人員。 代碼編寫者根據(jù)“代碼審核報告”給出的修改意見，修改好代碼，有不清楚的地方可積極向代碼審核者提出。代碼需要檢查Bug。 代碼編寫者和代碼審核者坐在一起，由代碼編寫者按照UseCase依次講解自己負責的代碼和相關(guān)邏輯，代碼審核者在此過程中可以隨時提出自己的疑問，同時積極發(fā)現(xiàn)隱藏的bug，對這些bug記錄在案。CodeReview一般可按以下步驟實施： 檢查開發(fā)者的代碼實現(xiàn)是否遵循了編碼規(guī)范。CodeReview CodeReview是保證項目中代碼質(zhì)量非常重要的一個環(huán)節(jié)，在這一環(huán)控制不嚴往往是測試后出現(xiàn)大量bug的主因，有時甚至導致返工；關(guān)于CodeReview執(zhí)行，首先應(yīng)有編碼規(guī)范和代碼審查規(guī)范。那些差異較大的，與人員探討其中的緣由。對開發(fā)人員估算的時間進行確認。 模塊分配完成后，開發(fā)人員評估自己負責開發(fā)的模塊所需要的時間。 B、技術(shù)難度較大的模塊由技術(shù)水平比較高的人負責。分配模塊的時為確保開發(fā)的速度和質(zhì)量，基本原則如下：A、類似的模塊由同一人負責開發(fā)，比如用戶信息的增刪改應(yīng)由同一開發(fā)者負責。召集所有開發(fā)人員，討論模塊的分配和開發(fā)時間估算。對于這樣的難點，開發(fā)者沒有相關(guān)的代碼可以參考，自己也沒有經(jīng)驗，所以需要投入學習時間用于研究解決。開發(fā)人員的技術(shù)水平和對項目所在應(yīng)用的熟悉程度(包括對框架和應(yīng)用的熟悉程度)。常見問題開發(fā)時間的估算 制定項目計劃時，需要估算每個任務(wù)所需的時間，其中主要是開發(fā)任務(wù)中模塊的分配和時間估算，在公司現(xiàn)有的技術(shù)框架
公司管理相關(guān)推薦
鄂ICP備17016276號-1