本文主要介紹polyv半年來的敏捷專案管理實踐經驗，融合了以往十多年研發過程管理經驗，採取了雙班車制度，有效推進客戶高商業價值的需求落地；同時也介紹了pm工具箱，確保研發過程的風險控制，讓客戶價值得到落地。
\n\n
為了確保客戶商業價值的收益轉化，在專案管理中，既沒有採用繁重的cmmi成熟度，也沒有生搬硬套的敏捷宣言，而是根據團隊特性制定規則，圍繞客戶商業價值高的需求，進行快速迭代、過程風險控制、交付反饋，把資源合理化利用，做恰到好處的質量標準。
\n專案管理中經典的戴明環pdca實踐：
\n\np（plan） --計畫，確定方針和目標，確定活動計畫；
\nd（do） --執行，實地去做，實現計畫中的內容；
\nc（check）–檢查，總結執行計畫的結果，注意效果，找出問題；
\na（action）–行動，對總結檢查的結果進行處理，成功的經驗加以肯定並適當推廣、標準化；失敗的教訓加以總結，以免重現，未解決的問題放到下乙個pdca迴圈。
\n\n\n
scrum是一種敏捷軟體開發的方法學，用於迭代式增量軟體開發過程。scrum在英語是橄欖球運動中列陣爭球的意思。
\n\n\n
極限程式設計（extreme programming），是一種全新的、輕量級的、靈巧的軟體開發方法，是一種軟體工程方法學。它強調程式設計團隊與業務專家之間的緊密協作、面對面的溝通（比書面的文件更有效）、頻繁交付新的軟體版本、緊湊而自我組織型的團隊、能夠很好的適應需求變化的**編寫和團隊組織方法，更注重軟體開發中人的作用。
\n\n\n
看板管理，是豐田生產模式中的重要概念，指為了達到jit(just in time, 及時生產)方式控制現場生產流程的一種工具。幾乎每個學習豐田tps（toyota production system）的企業都會不自覺的把看板當作第乙個引入的模式，因為它直觀有效。
\n\n\n
polyv的pm管理所採用的框架，是精益和敏捷軟體開發三種不同風格的輕度重疊，在此基礎上根據團隊業務特性優化形成。
\n\n\n
產品經理和專案經理有本質區別的，絕不是等同。
\n簡單來說，產品經理把客戶的商業價值需求，轉化為研發可理解的任務，這也是艱難的過程，如何表述可研發，可測試性；
\n而專案經理盡一切整合研發資源，把高商業價值的任務推進落地，關注過程管理，風險控制，雖然在敏捷開發中沒有定義專案經理，但確是很重要角色，敏捷開發要因地制宜，不能照搬來水土不服，適合團隊特性定製的才是硬道理。
\n專案經理會更加專業業務和教練兩個方向，不斷探索。無論敏捷scurm，xp，還是看板，都只是形式、流程，客戶的關鍵商業價值目標要把握，從需求到運營階段落到實處，簡潔用六個字概括職責：管什麼，怎麼管，pm管理職責的要點有：
\n\n
那麼不同段次的pm，將圍繞管理職責展開不同層次的工作，這就是pm的相關成熟度定義。
\n\n
基於pm管理職責，把pm成熟度分為六段：
\n\n從第一段至第六段，都是圍繞：管什麼，怎麼管的職責，那麼為了更好地盡職盡責，做pm還得有技術活三板斧：懂專案、懂業務、懂人。
\n\n
\n專案管理中，最經典的鐵三角：
\n\n時間、成本、範圍：三者之間要形成乙個閉環管理，相互關聯、制約、提公升、促進，做到三者缺一不可的高效平衡：就像乙個等邊三角形，為了保持平衡性，其中任何一邊有變動，另外兩條邊也會隨之發生適應性變化。而質量是三角形中心的核心元素，也是專案三角形的「眼睛」，專案三角形的任何乙個邊發生變化都會影響專案質量，專案質量與三個邊也相互約束。
\n
\n\n所謂質量，是指產品上市後給社會帶來的損失。-田口玄一
\n
任何一方的尺寸不合適，都會影響最終交付商業價值的質量，當目標的偏離值小於公差範圍，那就是離目標值越近，這個損失就越小。
\n\n
懂人並不是說具備讀心術的技能，而是掌握團隊成員的技能優缺點，以及對事情把握的判斷深淺程度，基於歷史資料篩選分析，識別研發過程風險，能夠根據成員特性，找出解決風險的策略，推進實施。
\n除了懂專案、懂業務、懂人，pm絕活還有不少，比如這些軟技能：
\n\n\n
專案管理並不能直接提公升產品質量，同樣投入再多測試也不能提公升產品質量，產品在轉化為研發任務的製造過程中已經決定了質量。
\n
\n\n專案管理有乙個很重要的觀點：事前預防、事中控制、事後分析。
\n
制定scurm敏捷過程管理框架，也是為了貫徹這個觀點，打通從需求階段出發、研發階段、發布階段、運營階段環節，把控過程反饋、識別風險，調整計畫，做好擁抱變化，把質量偏差控制到最小可接受範圍，實現客戶的商業價值需求落地。
\n\n\n
在整個敏捷迭代週期中，分為：快速班車和版本班車。
\n例如：三周迭代中，每週都可以發布來自市場、客戶迫切需求，剩下的按照版本班車的迭代步伐進行。這樣子的好處，在確保客戶高商業價值需求得到實現的同時，也快速把版本需求迭代前行，更好為客戶服務，體現價值。
\n\n\n
關注點：以交付價值為導向，推進高商業價值需求進入研發池。
\n\n
\n\n\n
\n\n\n
關注點：透明化、視覺化、盡早暴露問題
\n\n
\n\n
日常問題反饋：
\n\n
任務調整：
\n\n
風險評估：
\n\n
燃盡圖風險反饋
\n\n
\n信心指數反饋
\n\n
\n倒計時
\n\n\n
關注點：現地現物
\n\n
\n\n\n\n
\n\n\n
關注點：持續改善
\n\n
\n\n\n
在敏捷迭代過程中，不同角色的關注重點不同，分為需求看板和敏捷看板。
\n\n
產品人員無需關心研發任務細節，僅關注大的方面，需求總體進度如何，缺點是對細節不了解，需要進一步檢視敏捷看板，以及跟pm溝通。
\n\n\n
作為實施敏捷pm框架的核心人員，pm關注全域性：需求、研發任務進度詳情，包括各類開發型別任務進度、bug進度等等。
\n\n\n
實際就是pm看板，隱藏了需求部分，將關注點落到具體研發任務上。
\n\n\n
pm工具箱常備檢查表，從業務風險、技術風險、過程風險提供基礎檢查點，可以根據每次sprint總結的問題反饋，轉化為新的風險關注點，補充到檢查表中，以下從工具箱提取部分列舉
\n\n
\n\n
\n\n
\n\n
通過收集過程資料，從四個維度來評估專案質量，包括：專案完成率、bug生產率、燃盡圖健康率、團隊生產效率：
\n\n下面列舉一下簡化的指標
\n\n
\n\n
\n\n\n
\n\n\n
\n\n
\n\水因地而製流，兵因敵而制勝。
\n故兵無常勢，水無常形；能因敵而制勝者，謂之神。-《孫子兵法》
\n
敏捷專案管理
敏捷專案管理 apm 由jim highsmith所著的一書敏捷專案管理，試圖擴大敏捷技術為乙個整體。敏捷專案管理 引入敏捷專案管理步驟同pmi所採用的專案管理步驟結合 調整傳統鐵三角強調價值和質量，建立敏捷三角。傳統鐵三角 範圍 成本 進度 敏捷三角 價值 質量 制約因素 成本 進度 範圍 敏捷鐵...
敏捷專案管理
敏捷開發遵循軟體客觀規律，不斷的進行迭代增量開發，最終交付復合客戶價值的產品。敏捷宣言 敏捷開發原則 敏捷包括三個層次 精益七大浪費 技術債務 變化無法一次性 一開始製作大而全的計畫易造成浪費 應根據迭代積累的經驗和需求變化的情況對計畫不斷調整和細化 多層次反饋 敏捷軟體開發是以短週期迭代為核心，包...
05 敏捷專案管理 敏捷專案管理模式筆記
00.在敏捷圈內，流程被指責為靜止的 常規的和難以改變的。就流程本身而言，不應該是負面的，它必須同企業目標聯絡起來。如果目標是重複性的製造，那麼常規性流程是完全合理的 而如果目標是可靠的創新，則流程架構必須是有組織的 靈活的和容易適應的。支援構想 探索 自律的團隊 支援自我組織 自律的團隊 根據專案...