史上最全 | 華爲敏捷管理經驗全覆盤

1、背景

近30年來，企業面對的商業環境瞬息萬變，移動、社交、物聯網、雲計算、大數據、AI等蓬勃發展，傳統研發模式愈來愈沒法適應快速變化的市場需求，爲了應對這些挑戰，華爲的研發模式也在不斷變遷、優化，從90年代初游擊隊式開發，到2000年引入IPD-CMMI，轉變爲集團軍做戰模式，到2008年通過敏捷思潮的洗禮，開啓了「班長的戰爭」這一全新模式，造成了 「敏捷+ DevOps」相融合的、獨特的華爲敏捷研發模式。經過這種獨特的敏捷模式，擁有8萬華爲研發人員的研發體系，行走在時代的前沿，在電信運營商、企業、終端和雲計算等領域構築了行業領先的解決方案優點。

2、敏捷、DevOps方法論介紹

敏捷開發模式，遵循萬物生長的客觀規律，經過不斷迭代的增量式開發，確保可運行的軟件逐步生長壯大，並儘早得到客戶的反饋，及時開展優化。

DevOps理念是在開發流程和組織結構上，打破部門牆。經過端到端全自動化的持續交付流水線工具鏈，將市場、開發、運維等環節高度協同起來，並不斷提高Ops環節的自動化能力，解放人力，聚焦於業務開發實現上。

3、華爲敏捷項目管理實踐

華爲敏捷項目管理，融合了敏捷、DevOps思想，不只僅是開發階段的敏捷，而是打通市場、交付、運維、運營的端到端敏捷。在實踐中經過運維自動化，將Scrum敏捷團隊開發的產品快速上線，並經過及時的運營，反饋給敏捷團隊進行方向調整。

一、華爲敏捷項目管理流程以下

敏捷開發流程可劃分爲準備、計劃、開發、反饋四個階段。

二、準備階段

○ 按照模塊/服務組建全功能團隊，團隊包括PD（產品經理）、Scrum Master、UE（UCD工程師、美工/視覺）、SE（系統工程師）、開發、測試、運維、運營。每個團隊人數控制在6-12人。這須要配合系統解耦，模塊足夠小，或者採用微服務架構。

○ 選擇合適的敏捷項目管理工具。軟件開發服務團隊採用DevCloud on DevCloud的開發自用模式，可建立Scrum流程項目或精簡流程項目（精簡流程項目是比敏捷模式更簡潔的模式，適合小、微團隊和個體開發者）。

三、計劃階段

PD是本階段的核心角色。需求從線上反饋、線下訪談、友商分析、頭腦風暴等渠道進入產品Backlog後，需求優先級由PD實時刷新、按期評審，確保「作正確的事」：

○ PD對產品Backlog中Epic和Feature進行優先級分層排序，選擇優先級高的特性肯定發佈計劃。

○ 在每一個Spring啓動前，按照優先級排序的Story制定迭代計劃。

四、開發階段

Scrum Master是本階段的核心角色，需保證整個團隊高質高效「正確的作事」：

○ 基於迭代故事牆（看板），各個全功能團隊開展每日站立會議，將進展和求助錄入Story討論區，早會討論內容經過站內消息和郵件等實時通知責任人。

○ 開發人員提交代碼時，發起同行評審。以後由Scrum Master進行代碼審覈，確認沒有問題後合入版本主幹。

○ 天天定時執行自動化靜態代碼檢查任務，檢查編碼安全（如未授信訪問）、編碼問題（如空指針引用）、圈複雜度、重複率、編程風格，問題清零才容許構建出包。

○ 經過雲端自動化的持續交付流水線，實現持續構建、持續部署（包括腳本自動下發、比對）、持續測試（功能、接口、性能、可靠性等實現100%自動化）、持續發佈、持續監控，可將Ops端手工操做的時間縮短到20%內，全功能團隊能夠聚焦於業務交付上，顯著提高效率和產品質量。

代碼提交時按照規範備註Story ID，便可將代碼關聯到對應需求上。建立測試用例和缺陷時，也需關聯需求，這樣就實現了「需求-代碼-用例-缺陷」的雙向追溯。

五、反饋階段

反饋階段主要開展驗收和回顧活動。

○ 召開ShowCase會議，由PD進行驗收，確保產品功能與需求一致。

○ 轉測試迴歸不經過問題，需由Scrum Master輔導問題責任人進行回溯，並召開整個團隊的質量回溯會議。會議重點在於分析問題根因，並識別出管理、流程、技術、工具上可落地的改進點。這些改進點每個都必須符合Smart原則，是可落地、可執行的，不能出現大話空話套話。並且這些問題都要求最晚在下一個迭代中，執行落地，以免問題再次出現。

○ 經過迭代需求統計報表和燃盡圖，查看需求交付進展。

○ 迭代遺留缺陷報告呈現每一個模塊/服務質量狀況，並設置質量門禁。單服務遺留嚴重及以上級別問題，或者總遺留DI值（遺留缺陷密度）>x分，則服務質量不達標，不容許發佈。

重點提一下質量回溯會議，對應于敏捷迭代回顧會議，是華爲持續改進的實踐瑰寶。其要義是塑造整個團隊對事不對人、敢於直面問題、只要有方法有措施下次改進再也不重犯錯的「從泥坑裏爬起來就是聖人」的文化氛圍。

下方是一個華爲的開發者活動，掃碼當即生成你的2018年度開發者報告，感興趣的能夠試試。