本產品從2014年開始正式推行敏捷轉型，到2016年實現產品級敏捷，大概用了兩年時間。本文是根據我在中興通訊這兩年的經驗做的總結，見識比較膚淺，且大部分是靠回憶寫下來的，免不了存在一些不一致的地方。
一、 敏捷轉型方案
1 項目概況
-
產品用途：中國移動IPTN承載網絡傳輸設備
-
項目團隊：開發120人+測試30人
-
產品需求數（Feature）：約500條
-
用戶故事數（Userstory）：約3000條
-
新開發單板：10塊
-
新增修改代碼：約300W行
-
測試用例數：自動化7000+手工3000
-
研發週期（立項到設計定型）：約1年
2 轉型思路
-
研發過程遵循公司HPPD研發過程框架，結合CMMI過程域，推廣敏捷實踐
-
敏捷推進工作遵循從團隊級敏捷向項目級敏捷、產品級敏捷演進的思路
-
團隊級敏捷
-
定位於軟件開發團隊內部，團隊7-15人，涉及軟件開發與系統測試部
-
敏捷實踐範圍侷限在團隊範圍，團隊間實踐內容和能力水平差異性較大，團隊間協同工作能力弱
-
-
項目級敏捷
-
定位於PDT內研發組工作，以研發項目爲載體，涉及規劃部、軟件開發部、系統測試部、中試部等多個角色和團隊
-
敏捷實踐的範圍拓展到整個研發項目層面，適用於強項目組織的敏捷開發團隊，弱化或取消了部門
-
追求多角色、團隊協同工作能力，以提升項目研發質量和效率爲目的
-
-
產品級敏捷
-
定位於整個PDT團隊和HPPD產品研發全流程
-
敏捷實踐範圍涉及到PDT團隊各個領域
-
以市場需求驅動、高效內部成本和風險控制爲主線、以客戶價值實現爲中心的產品研發過程
-
-
3 組織結構調整
-
改變以前的矩陣式，每個團隊都由SM+PO+Team組成，形成特性團隊
-
SM：從開發經理、測試經理、SE或其他業務骨幹中產生
-
PO：一般是熟悉業務的技術骨幹，如SE
-
Team：含開發（軟件、邏輯、微碼）、測試
4 SM與PO的職責
-
SM職責：
-
引導各項Scrum活動
-
與團隊一起向PO承諾迭代的輸出物
-
跟蹤迭代內的任務進展，帶領團隊按時完成迭代任務目標
-
管理與其他團隊的依賴，團隊的外部協調、對外接口
-
幫助團隊移除工作中障礙
-
和團隊一起做績效考覈，聽取團隊的聲音，尊重團隊意見
-
關注團隊能力提升，包括團隊成員的業務技能和軟技能
-
-
PO職責：
-
維護Backlog，及時根據競爭對手、市場變化和客戶反饋調整列表
-
需求不明確時與產品級PO溝通
-
從客戶的使用場景中挖掘出對其最有價值的特性，並及時傳達到團隊
-
負責回答團隊關於測試場景的問題，讓測試場景儘可能地與客戶使用場景一致
-
PO參加每日立會，回答業務問題，但不干預管理工作
-
參加需求梳理會，負責回答團隊關於澄清需求的問題，確定userstory驗收標準
-
參加計劃會，和團隊共同確定每個團隊迭代輸出的內容
-
參加評審會，在團隊內驗收工作產品，最好請到真實用戶來驗收
-
參加回顧會，蒐集對產品方面的改進意見
-
5 敏捷框架
-
團隊級：系統方案完成到系統測試結束，主要是特性團隊
-
項目級：產品需求包確定到驗證階段結束，特性團隊+測試團隊
-
產品級：整個產品開發週期（運營與維護階段前），特性團隊+測試團隊+硬件組+中試組+生產組+電源+工藝結構
6 敏捷方案
-
應用項目：所有軟件、軟硬件系統項目
-
立項標準：
-
明確關鍵需求
-
明確發佈迭代週期或版本發佈里程碑
-
-
項目組成：強項目組織的敏捷開發團隊，弱化或取消了部門
-
交付條件：團隊級敏捷滿足系統測試準出條件（成果鑑定），項目級敏捷滿足驗證測試準出條件（設計定型），產品級敏捷滿足小批量生產驗證準出（生產定型）
7 敏捷模型
-
把產品的三個層級：產品級、項目級、團隊級的活動整合在一起。
二、 敏捷轉型實踐
1 每日站會
-
每天早上8:45準時開始，按迭代輪流組織
-
團隊輪流發言，站在看板前面，手上拿着故事卡講
-
SM收集需要在項目SOS站會上溝通的問題
2 SOS
-
角色
-
各特性團隊SM、QA、敏捷教練必須參加，PM視情況進行旁聽和補充
-
-
溝通內容
-
上次會議結束到現在，我們組做了什麼？
-
這次會議以後，我們組主要任務是什麼？
-
我們遇到了什麼困難，期望什麼樣的協助？
-
我們需要跨組解決的問題有哪些？
-
-
輸出
-
待解決的問題列表和當前狀態更新
-
好的建議和方法記錄
-
-
不做什麼
-
不在會上具體解決問題
-
無法快速定位的問題，確定跟進人和參與者，會後專題討論，項目增加一張故事卡跟蹤
-
複雜的技術和業務相關問題，提交給項目組，統一安排架構組討論解決
-
-
-
其他
-
每人1分鐘，總時間控制在20-30分鐘
-
鼓勵組間協作，鼓勵跨組溝通
-
3 需求澄清/梳理會
-
需求是可以分層次的，就像計劃可以分層次一樣
-
Epic/Feature/User Story是用於區分需求顆粒度的標籤
-
項目級PO與團隊級PO一起分析Feature
-
一起確定Feature的優先級、工作量、責任團隊、驗收準則
-
項目級PO確定下一迭代的Backlog
-
團隊PO將Feature拆分成US
4 迭代計劃會
-
PO在會前將Feature拆分US，確定驗收準則
-
PO講解US，團隊估算US工作量
-
團隊認領US，並拆分出Task
-
PO確定迭代內完成的Spring Backlog
5 迭代回顧會
-
原則：
-
每個人對自己的工作都已全力以赴，都充分考慮了當前的情況，施展了自己的技能，調用了可調用的資源。
-
|
聚焦 |
散焦 |
|
探索 |
而不是辯護 |
|
對話 |
而不是爭論 |
|
交流 |
而不是爭吵 |
|
理解 |
而不是防備 |
-
議程：
-
PO驗收團隊任務
-
PO與團隊一起驗收SprintBacklog中的US，驗收通過的關閉US
-
未完成的移出本迭代，並判斷在後續哪個迭代完成，阻塞問題移到阻塞區
-
-
團隊回顧總結
-
團隊成員在便籤紙上列出本迭代做的好的、需要改進的問題
-
SM將問題分類
-
團隊成員投票表決出三個需要保持的，三個需要改進的
-
團隊討論出三個需要改進的問題的改進措施
-
-
6 持續集成
-
入庫前的走查
-
入庫前，先完成靜態工具檢查，通過後由結對走查人走查代碼，走查通過後才合入代碼。
-
代碼合入日誌嚴格按照模板填寫：特性編號、影響分析、建議測試方法、修改人、走查人等信息。
-
-
每日架構組審查
-
架構組制定代碼走查統一模板
-
每日17:00-17:30，架構師抽查業務組當天提交的代碼，發現違反規則的提出整改意見，並錄入到相關業務組的Sprint Backlog中
-
架構組每月月底對各架構師代碼審查發現的問題進行分析彙總，對項目發佈月度報告。
-
-
CI持續集成：
-
每天晚上12點觸發Pclint、Klockwork、行覆蓋率、複雜度等檢測工具、全量構建、自動化冒煙測試，早上7點自動推送結果，空餘時間運行全量自動化測試
-
7 分層測試
-
測試分層
-
Story層，開發自測
-
Feature層，業務組負責自測、聯調，專業測試組負責系統測試
-
Epic層，專業測試組負責（方案測試）
-
-
測試策略制定
-
版本整體測試策略由版本經理和測試經理一起制定，包括版本計劃、測試時間、測試規劃，SM下發測試任務
-
-
新功能測試用例
-
開發自測用例、聯調用例由PO牽頭，輸出場景，測試工程師編寫用例，邀請規劃SE參與評審
-
系統測試用例，由專業測試組牽頭，邀請PO\工程\規劃\TSE參與討論工程場景和用例制定
-
-
測試流程
-
開發自測（自動化+手工）>聯調測試>自動化冒煙測試>專業組系統測試（自動化+手工）>中試部驗證》
-
8 DOD：
-
DOD：完成的定義，基於“隨時可向用戶發佈”的目標，制定的衡量團隊工作是否已經完成的定義，由團隊和PO協商並達成一致。
-
DOD的好處：
-
共同協商的完成定義，是團隊的自我承諾
-
清晰和明確的完成定義保證每次迭代是高質量的
-
DOD的關鍵點：
-
團隊自協商
-
基於交付對象
-
不斷改進
-
-
DOD分類：
-
每個環節都可以定義一個DOD，比如：需求DOD、開發DOD、CI DOD、測試DOD、計劃會DOD……
-
9 度量
-
度你所做，爲優而量！每個活動都可以定義相應的度量指標
-
儘量自動化度量，並展示
10 COP：
-
COP 實踐社區
-
COP的工作協議由COP成員討論得出
-
COP的運作要透明化，工作協議、活動紀要、產出物等要及時公佈
-
COP倡導以面對面溝通爲主，其他溝通方式爲輔
-
COP通過成員的定期回顧不斷的完善其運作機制
-
-
COP的角色
-
組長：對應COP的負責人，負責推動社區的發展和進步
-
專家：COP內獲得大家認可的，COP不是被組織任命，而是被大家推舉的，成爲COP專家一是靠自身的技術影響力，二靠對COP的貢獻
-
參與者：對相應技術領域感興趣的同事
-
-
COP的運作方式
-
COP活動在固定時間舉行，活動前，參與者把打算討論的議題和建議發給COP組長，或者組長主動收集
-
COP組可以創建活動日曆，向全員公開
-
員工在COP的貢獻積累爲“貢獻點數”，在績效考覈時參考
-
