1.   
            首頁>項目團隊 > 正文

            如何評估項目團隊效率?

            2018-11-09    來源:搜狗測試zhuliren
                   互聯網產品為了快速了解,滿足用戶需求和完善用戶體驗,需要不斷迭代更新版本,不斷改進。版本迭代速度越快,再激烈的競爭中越具有優勢。
                   快速迭代,效率很重要。那么我們該如何評估項目團隊工作效率是好是壞,如何找出項目團隊中效率的問題能?首先,團隊主體構成由產品,開發,測試構成。每個環節在項目迭代過程中都占據重要地位,且相互影響,相互制約。雖然我們的角色是測試,但是只在測試的范疇內去討論如何提高效率顯然過于局限。因此,放眼整個項目評估各角色工作效率對項目整體效率提升意義更大。
                   那么該如何評估效率呢?
                   我們通過總結各角色經常發生的問題,并將問題轉化成可量化的指標去度量,再分析評估指標的變化趨勢來評估團隊整體效率。
                   開發層面常見問題:
                   開發提測delay嚴重,Bug來回來去修改不對,測試要多次驗證和回歸。
                   開發提測質量不高,Bug特別多
                   開發間溝通不暢,經常出現信息不同步或信息有誤導導致重構或返工情況
                   開發提交代碼隨意無約束經常計劃外重構
                   改動比較大的模塊提測晚,一輪后期發現大量Bug
                   建立指標:
                   千行bug率
                   用來評估開發代碼質量,bug率越低越好
                   bug修改輪數及比例分布
                   開發修改bug輪數越多,說明開發修改代碼質量不高或缺少自測
                   開發重構次數
                   一個版本內不應該有太多的代碼重構,大的重構一般控制在一個左右,同一個版本重構過多無論是質量還是時間都無法保證。
                   產品層面常見問題:
                   需求前期考慮不充分,導致后面需變較多,重復開發測試工作量巨大
                   需求,交互不詳細,測試過程中大量溝通確認,耗費時間
                   建立指標:
                   1.需變工作量占比
                   需求變更所帶來的工作量越大,項目越不可能按照既定計劃上線
                   2.需變時間軸
                   用來描述需求變更在整個項目周期內的分布情況,正常情況需變應該集中在項目前期,隨著項目的進行,越往后需變應該越少,到最終回歸階段不應該再有需變。如果需變集中在中后期,往往上線時間會delay。
                   有人會說,身為測試這么關注開發產品的問題干啥,你也改變不了。我想說首先大家是一個項目團隊,每個人都有義務指出配合團隊的問題,其次,團隊之間是相互影響的,只有上游團隊變好了,某些測試工作才能變輕松。在指出對方問題時如果帶著具體的實例,具體的數據,才能有說服力,對方才能夠信服和接受。
                   測試層面常見:
                   用例設計花費時間多,或者評審返工多
                   用例設計遺漏,后期發現導致重復回歸,延長上線時間
                   測試方法不足,部分Case執行耗時較多,例如場景構造,異常數據構造
                   工具應用比較少,手工測試比重大。測試時間變長
                   不可重現的Bug,導致花費大量時間重試或驗證
                   二輪測試執行時間比較長
                   測試范圍評估不準,臨近上線回歸發現bug,需要延長測試時間。
                   對需求理解有誤,報了部分無效bug,對開發和測試時間造成浪
                   人員能力和經驗不足,用例執行速度偏慢
                   建立指標:
                   每人用例設計時間及條數
                   用來評估測試人員用例設計方面的效率
                   用例設計評審及返工用時和占比
                   用例評審及返工時間越多,說明用例設計方法或對功能了解存在問題
                   測試各階段時間占比
                   用例執行時間或回歸執行時間的比例應該越少越好,比例越大說明在測試方法和    手段存在問題
                   不可重現Bug比例
                   不可重現的bug比例不應該太高,測試人員需要在如何重現問題及找到重現方面下功夫
                   Bug驗證工時占比
                   bug驗證時間多可能是bug過多或者驗證手段不足,效率低下
                   發現晚的Bug占比
                   應該盡可能的降低這個比例,并逐個問題分析原因找到解決方案。
                   至此我們定義了各團隊效率問題層面的指標,我們可以通過不同的迭代版本持續統計持續觀察,相應的問題解決后通過指標的變化來驗證效率是否提升。
            (本文于2016-04-22首次發布)


            分享到:

            免責聲明:
              1、項目經理人發布的所有資訊與文章是出于為業界傳遞更多信息之目的,并不意味著贊同其觀點或證實其描述。其原創性以及文中陳述文字和內容未經本站證實,對本文以及其中全部或者部分內容、文字的真實性、完整性、及時性本站不作任何保證或承諾,請瀏覽者僅作參考,并請自行核實相關內容。
              2、本站部分內容轉載于其他網站和媒體,版權歸原作者或原發布媒體所有。如文章涉及版權等問題,請聯系本站,我們將在兩個工作日內進行刪除或修改處理。敬請諒解!

            關于我們 聯系我們 版權聲明 隱私保護 投訴建議 卓橡資源

            Copyright ? 2021 項目經理人 版權所有 京ICP備17062359號-3 如轉載本站文章,請注明原作者和原發布媒體
            本著互聯網分享精神,本站部分內容轉載于其他網站和媒體,如稿件涉及版權等問題,請聯系本站進行刪除或修改處理
            客服電話:010-89506650 89504891 非工作時間可聯系:18701278071(微信) QQ在線:511524637
            新聞與原創文章投稿:tougao#cpmta.com 客服郵箱:info#cpmta.com(請將#換成@)
            項目經理人——我國項目經理職業發展門戶網站,隸屬卓橡公司

            天天爽夜夜爽人人爽曰AV_东京热TOKYO综合久久精品_国产亚洲观看视频在线_奇777超碰欧美日韩亚洲