敏捷項目管理，POLYV來支招

本文主要介紹POLYV半年來的敏捷項目管理實踐經驗，融合了以往十多年研發過程管理經驗，採起了雙班車制度，有效推動客戶高商業價值的需求落地；同時也介紹了PM工具箱，確保研發過程的風險控制，讓客戶價值獲得落地。

POLYV產品線

從官網幫助中心入手，簡單把產品線分爲：點播、直播兩大類，還提供API、SDK技術支持，並擁有國家專利級別的Playsafe®視頻版權保護技術及三套CDN加速，致力爲用戶提供穩定、安全、快速的企業級雲視頻服務。

爲了確保客戶商業價值的收益轉化，在項目管理中，既沒有采用繁重的CMMI成熟度，也沒有生搬硬套的敏捷宣言，而是根據團隊特性制定規則，圍繞客戶商業價值高的需求，進行快速迭代、過程風險控制、交付反饋，把資源合理化利用，作恰到好處的質量標準。

PM敏捷體系介紹

爲了確保客戶商業價值的收益轉化，在項目管理中，既沒有采用繁重的CMMI成熟度，也沒有生搬硬套的敏捷宣言，而是根據團隊特性制定規則，圍繞客戶商業價值高的需求，進行快速迭代、過程風險控制、交付反饋，把資源合理化利用，作恰到好處的質量標準。

項目管理中經典的戴明環PDCA實踐：

P（Plan） --計劃，肯定方針和目標，肯定活動計劃；

D（Do） --執行，實地去作，實現計劃中的內容；

C（Check）--檢查，總結執行計劃的結果，注意效果，找出問題；

A（Action）--行動，對總結檢查的結果進行處理，成功的經驗加以確定並適當推廣、標準化；失敗的教訓加以總結，以避免重現，未解決的問題放到下一個PDCA循環。

業界通用的敏捷方案

Scrum

Scrum是一種敏捷軟件開發的方法學，用於迭代式增量軟件開發過程。Scrum在英語是橄欖球運動中列陣爭球的意思。

極限編程（XP）

極限編程（eXtreme Programming），是一種全新的、輕量級的、靈巧的軟件開發方法，是一種軟件工程方法學。它強調程序設計團隊與業務專家之間的緊密協做、面對面的溝通（比書面的文檔更有效）、頻繁交付新的軟件版本、緊湊而自我組織型的團隊、可以很好的適應需求變化的代碼編寫和團隊組織方法，更注重軟件開發中人的做用。

看板

看板管理，是豐田生產模式中的重要概念，指爲了達到JIT(Just in Time, 及時生產)方式控制現場生產流程的一種工具。幾乎每一個學習豐田TPS（Toyota Production System）的企業都會不自覺的把看板看成第一個引入的模式，由於它直觀有效。

PM敏捷管理架構

POLYV的PM管理所採用的框架，是精益和敏捷軟件開發三種不一樣風格的輕度重疊，在此基礎上根據團隊業務特性優化造成。

PM管理職責

產品經理和項目經理有本質區別的，毫不是等同。

簡單來講，產品經理把客戶的商業價值需求，轉化爲研發可理解的任務，這也是艱難的過程，如何表述可研發，可測試性；

而項目經理盡一切整合研發資源，把高商業價值的任務推動落地，關注過程管理，風險控制，雖然在敏捷開發中沒有定義項目經理，但確是很重要角色，敏捷開發要因地制宜，不能照搬來水土不服，適合團隊特性定製的纔是硬道理。

項目經理會更加專業業務和教練兩個方向，不斷探索。不管敏捷Scurm，XP，仍是看板，都只是形式、流程，客戶的關鍵商業價值目標要把握，從需求到運營階段落到實處，簡潔用六個字歸納職責：管什麼，怎麼管，PM管理職責的要點有：

• 根據產品的質量等級定義和相應測試策略，在過程當中跟蹤、反饋商業價值高優先級需求的研發過程落地狀況
• 項目計劃跟蹤執行，打通產品、市場、研發、測試、運維生產線的溝通，識別風險和解決團隊所遇到的問題，區分輕重緩急，組織和協調項目中各項活動，基於要事第一的原則推進解決問題
• 服務於產品、研發、測試、運營團隊，使項目順利地、有品質的交付， 並提供研發過程質量數據分析

那麼不一樣段次的PM，將圍繞管理職責展開不一樣層次的工做，這就是PM的相關成熟度定義。

PM成熟度

基於PM管理職責，把PM成熟度分爲六段：

從第一段至第六段，都是圍繞：管什麼，怎麼管的職責，那麼爲了更好地盡職盡責，作PM還得有技術活三板斧：懂項目、懂業務、懂人。

PM三板斧絕活

• 懂項目

項目管理中，最經典的鐵三角：

時間、成本、範圍：三者之間要造成一個閉環管理，相互關聯、制約、提高、促進，作到三者缺一不可的高效平衡：就像一個等邊三角形，爲了保持平衡性，其中任何一邊有變更，另外兩條邊也會隨之發生適應性變化。而質量是三角形中心的核心元素，也是項目三角形的「眼睛」，項目三角形的任何一個邊發生變化都會影響項目質量，項目質量與三個邊也相互約束。

所謂質量，是指產品上市後給社會帶來的損失。-田口玄一

任何一方的尺寸不合適，都會影響最終交付商業價值的質量，當目標的偏離值小於公差範圍，那就是離目標值越近，這個損失就越小。

• 懂業務
• 有開發經驗的人員，不論作PM，仍是測試，都有優點
• 從高商業價值的業務角度出發，引導產品、研發團隊和參與規劃、定義項目，提煉出項目，化被動爲主動
• 推進全員清楚地知道爲何立項這個項目，明白幫助客戶實現的商業價值
• 掌握業務領域相關知識，還包括對實現其業務需求的產品方案的瞭解，知道使用哪些技術棧來實現，以及對技術實現過程當中的難點和重點須要有清晰的把握
• 使用風險工具集，分析業務進度卡頓的地方，給相關負責人作決策分析帶來依據

• 懂人

懂人並非說具有讀心術的技能，而是掌握團隊成員的技能優缺點，以及對事情把握的判斷深淺程度，基於歷史數據篩選分析，識別研發過程風險，可以根據成員特性，找出解決風險的策略，推動實施。

除了懂項目、懂業務、懂人，PM絕活還有很多，好比這些軟技能：

Scrum敏捷過程管理

項目管理並不能直接提高產品質量，一樣投入再多測試也不能提高產品質量，產品在轉化爲研發任務的製造過程當中已經決定了質量。

項目管理有一個很重要的觀點：事前預防、事中控制、過後分析。

制定Scurm敏捷過程管理框架，也是爲了貫徹這個觀點，打通從需求階段出發、研發階段、發佈階段、運營階段環節，把控過程反饋、識別風險，調整計劃，作好擁抱變化，把質量誤差控制到最小可接受範圍，實現客戶的商業價值需求落地。

概覽：雙班車制

在整個敏捷迭代週期中，分爲：快速班車和版本班車。

例如：三週迭代中，每週均可以發佈來自市場、客戶迫切需求，剩下的按照版本班車的迭代步伐進行。這樣子的好處，在確保客戶高商業價值需求獲得實現的同時，也快速把版本需求迭代前行，更好爲客戶服務，體現價值。

需求階段

關注點：以交付價值爲導向，推動高商業價值需求進入研發池。

Sprint會議前

• PM參與產品需求評估，識別客戶高商業價值的需求，轉化爲研發迭代任務
• 組織參與當前迭代的研發成員提供有效可用工時，而且錄入系統以供評估分析
• 組織上一次迭代總結會議，提供QA數據（工做效率統計、質量維度數據）分析過程問題

Sprint會議中

• 組織評估研發、測試任務工時，消除需求、工時含混性
• 推進產品、研發、測試相關人員將商業價值高的需求放入研發池
• 根據定版的迭代任務，定義質量等級，協助測試指定驗收準則

研發階段

關注點：透明化、可視化、儘早暴露問題

平常站立會

• 組織團隊成員自發參與每日晨會，分享信息，提出路障
• 燃盡圖問題反饋、風險識別、各端進度反饋；
• 會後重大問題跟蹤、反饋

平常風險控制

平常問題反饋：

• 重大問題、任務調整，拉上產品人員一塊兒討論決定
• 平常運營客戶問題識別風險，推進研發、測試解決

任務調整：

• 保持原有飽和度，工時緊張的狀況下，插入新任務，則移出優先級低的
• 超過原計劃，必須插隊的任務，也沒有考慮移出的，則項目週期會發生延長變化的可能性

風險評估：

• 根據產品的質量等級定義和相應測試策略，跟蹤反饋商業價值高優先級需求的研發過程落地狀況
• 提供風險識別，打通產品、市場、研發、測試、運維生產線的溝通，解決要事第一的優先級

燃盡圖風險反饋

• 曲線居高不下：看看哪裏出問題，誰能夠幫忙解決？
• 曲線降低太快：是否路障消除、任務評估不許確，實際更加樂觀，可否加快測試，
• 警戒：前鬆後緊，前面圖形樂觀，後面爆發風險

信心指數反饋

• 根據已知風險點評估當前團隊信心，是否可以順利消除路障，達成目標

倒計時

• 項目距離交付的緊迫感，全員聚焦時間可用，關注當前總體進展

發佈階段

關注點：現地現物

驗收機制

• 組織全員參與BugBash大掃除

• 組織產品相關人員參與客戶價值驗收

發佈過程

• 協助研發、測試人員制定checklist，用於線上檢查
• 組織測試參與需求覆蓋線上確認，明確發佈階段關注重點

運營階段

關注點：持續改善

• 收集技術支持反饋當前發佈版本的情況，客戶商業價值實現的反饋程度,快速響應推進解決
• 團隊全員參與，總結當前版本迭代遇到的問題，造成有效措施落地執行，避免重現

PM工具箱

迭代看板

在敏捷迭代過程當中，不一樣角色的關注重點不一樣，分爲需求看板和敏捷看板。

需求看板

產品人員無需關心研發任務細節，僅關注大的方面，需求整體進度如何，缺點是對細節不瞭解，須要進一步查看敏捷看板，以及跟PM溝通。

PM看板

做爲實施敏捷PM框架的核心人員，PM關注全局：需求、研發任務進度詳情，包括各種開發類型任務進度、bug進度等等。

研發看板

實際就是PM看板，隱藏了需求部分，將關注點落到具體研發任務上。

風險檢查表

PM工具箱常備檢查表，從業務風險、技術風險、過程風險提供基礎檢查點，能夠根據每次Sprint總結的問題反饋，轉化爲新的風險關注點，補充到檢查表中，如下從工具箱提取部分列舉

業務風險檢查表

• 產品商業價值定義不清晰
• 需求不清晰，完成產品定義含混的部分比指望須要更多的時間
• 與競爭對手搶時間，犧牲了質量定義

技術風險檢查表

• 開發自測不充分
• 功能點可測試性差
• 代碼設計複雜
• 使用不熟悉的技術，沒有額外的調研時間
• CodeReview不充分

過程風險檢查表

• 士氣低下，溝通不到位
• 客戶商業價值需求，信息傳遞不一致
• 任務估算樂觀過分，未留夠緩衝時間，例如平常會議、學習分享
• 進度更新不及時，致使項目整體進度看似沒進展
• 新增任務沒有通知PM、測試，需求覆蓋不完整
• 人員負責多個項目，上下文切換成本高，致使項目進展有拖延
• 設備不到位，開發環境出問題

數據分析

經過收集過程數據，從四個維度來評估項目質量，包括：項目完成率、Bug生產率、燃盡圖健康率、團隊生產效率：

下面列舉一下簡化的指標

項目完成率

• 整體完成率=迭代總完成工做量/迭代總工做量
• 計劃完成率=完成計劃工做量/計劃工做量

Bug生產率

• bug生產率=迭代新增bug工做量/迭代總完成工做量
• bug分佈階段：需求、開發、測試
• bug分佈模塊

燃盡圖健康率

• 卡頓出現持續時長，佔比整體時間
• 開發過程當中，任務變動的統計

團隊工做效率

• 我的工做效率完成百分比
• 團隊工做效率完成百分比
• 統計我的開發速率

總結

水因地而制流，兵因敵而制勝。 故兵無常勢，水無常形；能因敵而制勝者，謂之神。-《孫子兵法》

項目管理無章法，就談不上圍繞客戶商業價值高的需求，進行快速迭代、過程風險控制、交付反饋，把資源合理化利用，作恰到好處的質量標準，而整個研發過程當中，除了客戶商業價值，人也是活動中的重要因素之一。咱們的核心成員曾分別服務於網易、騰訊、搜狐、優酷等互聯網巨頭企業，踩過許多坑，有至關豐富的解決問題的經驗，犯錯不懼怕，關鍵是自省機制很重要，再也不犯一樣的錯誤，確保過程質量風險透明反饋、資源分配合理，質量恰到好處，客戶價值獲得實現。

微信公衆號：樂少黑板報