產品經理,Scrum Master,交互設計師鐵三角

　　備注1.：迭代時間：是以團隊開始進行迭代計劃(包括Story的劃分)到迭代發布; 迭代投入比是對團隊用于迭代研發的工作量投入的衡量.

　　備注2:6月7月之間,技術部對Hades進行了系統重構,將Hades后臺分別與淘寶貸款和阿里貸款的前臺進行了融合; 組織結構也進行了部分調整.

　　備注3: 目前,整個技術部團隊的Story劃分, 進入迭代研發的Story的規?？刂圃?a href='http://www.kjueaiud.com/ceshi/ruanjianceshikaifajishu/' target='_blank'>開發1-2人天. 在整個迭代開發結束后,1天內完成測試上線. 整個迭代周期兩個星期.每周2，4是發布日.可以按Story進行發布,也可按照迭代進行發布. 一般頻率是一個迭代兩次發布.

　　備注4: 各個團隊保持主干開發. 重點模塊結對編程.

　　備注5: 團隊的質量目標：1.代碼檢視10個/KLOC 2. 自測和自動化測試的共同語句覆蓋是80% 3. 靜態檢查MAJOR以及以上等級告警清零.4.圈復雜度 5.代碼重復率3%以內.

　　團隊投入迭代研發投入比的分析

　　1. 團隊的迭代開發投入比例: 團隊投入迭代開發的時間占比分析：

　　查看大圖

　　從圖看出：1.在淘寶貸款,阿里貸款,產品概念階段的實踐嘗試取得了不錯的效果,使得淘寶貸款和阿里貸款團隊投入迭代開發的時間比得到了提升

　　簡單講,前期通過SM,交互設計師,產品經理在進入迭代前期介入需求分析,SM和交互設計師并行同時對口產品經理,通過原型的方式來更好的闡釋需求.

　　2.客戶線和帳務系統團隊迭代開發投入比基本保持穩定,其中帳務系統有小幅的提升.

　　2.團隊的迭代測試投入比例：團隊投入迭代測試的時間占比分析：

　　查看大圖

　　1.淘寶貸款,阿里貸款,客戶線的測試同學在迭代測試投入比提升上均非常明顯; 帳務系統的測試投入比保持相對穩定.

　　說明,從業務交付的角度上看~7月份開發和測試團隊實體化后, 目前的開發和測試的融合越來越有效,使得團隊更聚焦于業務交付. 并且測試隊伍的效率有了明顯的提升~在這里不得不贊賞測試團隊所付出的努力~此時，也期望各團隊的負責人能給測試同學的個人成長也提供足夠的空間~

　　迭代開發生產率分析：

　　查看大圖

　　查看大圖

　　結合以上的團隊完成的Story個數和代碼行規模,分析團隊的開發生產率如下,供團隊參考：

　　1. 阿里貸款,帳務系統團隊在11月份,開發同學的開發生產率相比7月份,保持相對穩定.

　　2. 從Story個數和代碼行來看, 客戶線的開發效率提升明顯.且測試投入迭代研發的比例提升非常明顯.

　　3. 淘寶貸款的11月份的開發生產率：按照團隊完成的Story個數來統計,團隊保持基本的穩定,略有下降,按照代碼行統計,比7月份要下降.從數據來看,淘寶貸款團隊進行了很多的重構工作.

　　針對淘寶貸款和阿里貸款的團隊研發投入增加,但團隊開發生產率卻基本保持穩定的情況 (按理說,團隊投入迭代研發的比例增加,生產率應該相應的提升才對), 那么團隊相比以前,我們多爭取出來的這部分時間,現在都用在什么地方.對此,特地對淘寶貸款和阿里貸款的PM和測試負責人進行些訪談：

　　淘寶貸款：

　　1.11月份團隊進行很多重構的方案設計和探討。優化現有的產品設計.

　　2. 團隊成員反思現有的自動化方案,并嘗試優化. 另外由于產品的重構,導致需要的自動化測試需要修正

　　3. 人數從之前的開發和測試10人左右擴張到現在近20人,產品種類也增加了, 相互之間的協同比以前要多,管理成本增加了.

　　訪談淘寶貸款PM

　　11月份,老員工新員工融入. 并將老員工抽離出來進行獨立的重構設計,新員工投入業務開發.

　　11月份的一些小發布的研發工作量未統計進來.

　　阿里貸款：阿里貸款團隊投入迭代研發的比例也比上半年要高出平均20%.但生產率與以前相比較, 相對穩定~

　　測試訪談:

　　1. 目前, 團隊處理了比以往更多的插入的業務方臨時任務,比如數據訂正

　　2. 開發人員投入到自測等質量保證活動比以前多.

　　3. 測試投入比例提高原因：Story開發轉測質量提升, 測試執行效率提升,

　　阿里貸款PM:

　　1. 配合SVN遷移臨時性工作.

　　2.協助業務方處理了大量的數據訂正

　　3. 需求的臨時變更投入了很多反復的需求串講和反串講.

　　4.阿里貸款渠道外包迭代三的研發度量數據126LOC/人天的說明：1.研發效率未統計雙休加班的工作投入2.本身開發效率高

　　隨著團隊的迭代研發投入時間增加，使得團隊有了更多機動的時間,如何主動合理的分配這部分的時間,使得團隊的戰斗力更強.個人建議,對現有產品的重構優化,建立自動化測試的基礎，增加自測和代碼檢視等質量保證活動是個不錯的選擇.若長期用于處理更多的需求臨時變更和數據訂正,這將會使團隊陷入被動的狀態.

　　PS: 1.迭代投入比是個非常好用的度量項 2. 產品經理, Scrum Master，交互設計師鐵三角,產品概念階段的有效合作對團隊效率提升明顯 3. 綜合Story個數,代碼行來衡量團隊工作量, 相比單純的Story個數或者代碼行要合理的多· 4.客戶線的開發效率提升過程則復雜的多，有時間細細到來 5.推薦Marty Cagan《卓越產品經理》

原文轉自：http://www.kjueaiud.com