IT項目管理-項目復(fù)盤

申請免費試用、咨詢電話：400-8352-114

項目計劃方面(PP)
　　1.通過流總數(shù)來定義用例的復(fù)雜度很難準確，且發(fā)現(xiàn)很多時候用例本身也偏大，但又很難去拆分它為幾個子用例。（項目估算）
　　后期對小版本采用專家法，對大版本采用功能點法估算，并進行功能點估算培訓(xùn)。對于基于用例估算的時候需要考慮到對于復(fù)雜用例必須要考慮拆分出擴展用例或子用例。另外基本流，擴展流的粒度和編寫原則要進一步細化，現(xiàn)在還存在就是一條流描述了多條業(yè)務(wù)規(guī)則，或者是本來可以一條流描述的寫軟件需求的時候拆分為多條描述。
　　2.估算沒有通知到測試人員參與（項目估算）
　　測試的工作量和軟件產(chǎn)品本身的規(guī)模是相關(guān)的，我們知道首先需求的規(guī)模和測試用例的規(guī)模之間根據(jù)歷史經(jīng)驗數(shù)據(jù)可以得出一個換算比例關(guān)系。所以根據(jù)軟件需求規(guī)?？梢缘贸鰷y試規(guī)模，根據(jù)測試規(guī)模/測試生產(chǎn)率后可以得到測試的工作量。因此估算需要通知到測試人員，進行測試設(shè)計和測試執(zhí)行工作量估算。
　　3.估算的新模板很多參數(shù)和指標具體含義項目成員不熟悉（項目估算）
　　包括COPQ,COGQ，以及評審，返工，設(shè)計開發(fā)等工作量是如何估算出來的參與估算的項目成員并不是特別清楚。很多流程和規(guī)則都固化到了Excel模板中，雖然估算的過程簡單了，但是成員并沒有真正了解估算的流程和原理。
　　4.周例會沒有和項目成員共同分析和確認風(fēng)險以及風(fēng)險參數(shù)
　　周例會需要共同分析本周發(fā)生的問題，這塊BA做的好，設(shè)計開發(fā)很少提問題。周例會需要共同對已有的風(fēng)險進行跟蹤，并識別新風(fēng)險。項目需要組織專門的風(fēng)險管理培訓(xùn)，項目管理很多時候就是對風(fēng)險的管理
　　5.不是所有的成員都參加了項目主計劃的評審獲取項目承諾
　　個別設(shè)計開發(fā)人員沒有全部參加項目主計劃內(nèi)部評審，項目成員不清楚總體情況。這跟項目團隊的異地化開發(fā)協(xié)調(diào)也有一定關(guān)系，但是我們?nèi)匀粡娬{(diào)所有成員都應(yīng)該參加項目計劃的評審，并進行承諾，這樣團隊成員可以將自我項目任務(wù)和團隊項目目標很好的匹配。
　　6.項目成員不清楚項目自定義過程和作用
　　項目自定義過程是IPM過程域的一個重要內(nèi)容，需要對其作用了解清楚。過程裁剪的方法，原則，裁剪和項目特征之間的關(guān)系等都需要有個大致的了解。不是簡單的為了進度而裁剪掉過程，評審，集成測試等重要過程裁剪掉了往往項目質(zhì)量和進度更加無法保障。
　　7.項目在一些技術(shù)方案和實現(xiàn)方式選擇上面沒有形成規(guī)范做法
　　CMMI三級DAR過程域強調(diào)了項目的分析和決策，如何通過DAR來指導(dǎo)項目識別，分析，選擇技術(shù)方案需要考慮。
　　8.WBS分解計劃階段沒有包含風(fēng)險計劃分解結(jié)果
　　項目的風(fēng)險管理過程從項目一啟動就已經(jīng)開始，在項目計劃階段應(yīng)該包括了風(fēng)險的識別，風(fēng)險的分析，風(fēng)險的應(yīng)對措施和計劃等很多內(nèi)容。對于最終采取的風(fēng)險應(yīng)對措施和計劃應(yīng)該有專門的WBS摘要計劃和具體的風(fēng)險應(yīng)對任務(wù)和活動。
　　項目跟蹤和監(jiān)控方面(PMC)
　　1.項目周報很難體現(xiàn)項目總體進度
　　項目周報的形式需要進行改善，項目的開發(fā)模式需要更加的體現(xiàn)增量和迭代開發(fā)。這樣跟蹤的時候可以按照功能點或需求特征點進行跟蹤，根據(jù)冒煙測試的情況來使項目進度真正可視。在這一塊可以引入停車場圖更加直觀的項目進度展現(xiàn)方式。 　　2.集成測試比預(yù)期進度延后3天左右
　　再次強調(diào)敏捷開發(fā)中持續(xù)集成和每日構(gòu)建的概念，這個版本在這里吃虧較多，持續(xù)集成的一個重要作用就是保證測試的迭代，提前發(fā)現(xiàn)結(jié)隊任務(wù)問題，避免設(shè)計嚴重泄露。
　　3.問題分析和跟蹤機制不完善
　　因為經(jīng)常最多的就是聽到這個問題解決了沒有，在誰哪里，為什么這樣解決，這種解決方式有問題等詞語，說明整個問題解決和跟蹤機制還有待改進。組織有組織級別的資產(chǎn)庫和經(jīng)驗庫，項目也需要有項目級的問題和經(jīng)驗收集管理庫。
　　4.設(shè)計人員對開發(fā)輸出的Review力度還要加強
　　在團隊本身不穩(wěn)定或團隊成員新老交替的時候，應(yīng)該多采用以師帶徒的模式，這個時候師傅要加強代碼的Review工作，通過Review代碼來盡早的發(fā)展開發(fā)質(zhì)量問題，發(fā)現(xiàn)新員工技能存在的欠缺點，后續(xù)好開展有針對性的培訓(xùn)。
　　5.項目經(jīng)理不能每周準確跟蹤到進度情況
　　還是說到設(shè)計這塊，由于沒有持續(xù)集成，每周功能點也沒有集成到151上來，項目經(jīng)理這塊很難確切跟蹤到準確進度情況，所以這塊建立在對設(shè)計完全信任上。
　　6.架構(gòu)如何跟蹤設(shè)計是否按照架構(gòu)思路執(zhí)行問題
　　如何保證設(shè)計和架構(gòu)的一致性？這塊架構(gòu)要考慮下，后期如何加強控制。這也是我們IT項目管理中強調(diào)概念完整性的一個重要內(nèi)容，首先需求本身不能出現(xiàn)偏差，其次架構(gòu)和總體設(shè)計和需求匹配，設(shè)計的思路要能夠嚴格貫徹執(zhí)行。
　　7.任務(wù)承諾和執(zhí)行的問題
　　PMS任務(wù)周四提出可以延后兩天，周五提出需要延期的只能延后一天。但任務(wù)延期必須有明確的原因。項目經(jīng)理口頭或郵件的非PMS任務(wù)請大家一定注意，你承諾了在某個時間點能夠搞定的要確保在時間點搞定。
　　驗證和確認相關(guān)(VER&VAL)
　　1.測試人員的測試用例模板存在問題
　　測試一個重要環(huán)節(jié)是分支分析和測試數(shù)據(jù)的準備，這塊還要考慮后續(xù)改進方法。
　　2.測試人員對業(yè)務(wù)的理解程度問題
　　這塊對測試業(yè)務(wù)培訓(xùn)較少，測試對業(yè)務(wù)理解深度還要加強，測試有需求要盡早提出來，項目組這邊會多安排BA給測試進行培訓(xùn)
　　3.測試用例本身的質(zhì)量問題
　　測試用例本身的質(zhì)量涉及到兩方面的內(nèi)容，一個是測試用例的編寫方法，一個是測試人員對業(yè)務(wù)的理解程度。測試用例要能夠全面覆蓋到軟件需求的內(nèi)容，包括非功能性方面的軟件需求。測試用例一定要能夠很好的體現(xiàn)流程，體現(xiàn)數(shù)據(jù)準備，體現(xiàn)數(shù)據(jù)在流程中處理完成后我們分析出的期望結(jié)果。測試數(shù)據(jù)，輸入，期望輸出必不可少。
　　4.通過評審的效果和質(zhì)量問題
　　對于需求和架構(gòu)的同行評審效果較好，能夠發(fā)現(xiàn)大部分問題。但對于設(shè)計和編碼的同行評審后期進度緊張，進行的不是特別好，評審的時間點也較后，很難提前發(fā)現(xiàn)設(shè)計和編碼問題。同時我們看到在需求和設(shè)計階段，我們評審重點都在功能性需求上面，對于系統(tǒng)的易用性，可擴展性，性能等方面的非功能性需求考慮較少。