敏捷項目管理

爲何要用敏捷？現在，項目管理的步伐愈來愈快。項目管理須要更靈活、更積極地，響應客戶的需求。使用敏捷項目管理方法，項目經理能夠在不影響價值、質量和商業規則的前提下實現全部目。

1.項目管理的目標與策略

1.1 目標

主要目標：在預算和時間範圍內交付符合客戶須要的高質量的軟件產品

其餘目標：提升團隊成員能力得到度量數據以改進流程和提供可預測性

1.2 策略

項目成功的關鍵：

• 準確的需求分析——功能
• 優雅的設計，簡潔的編碼——質量
• 全面的測試，自動化構建和持續集成——可靠性
• 透明、可控、可持續、可預測的⽣產過程——項目管理

1.2.1 需求分析 —功能

將需求轉化成功能：用例（ RUP），用戶故事（敏捷）。

1.2.2 領域建模 —理解業務領域

如何實現領域建模：

• 發現業務領域中的本質抽象和共同機制
• 發現領域概念的類型層次結構和組成層次結構
• 實現業務邏輯和業務規則。

1.2.3 設計與編碼 —質量

如何保證代碼質量：

• 設計要優雅，編碼要簡潔
• 領域驅動設計
• OO原則、設計模式、重構
• 簡單性、一致性、靈活性、擴展性的對立統一

1.2.4 TDD

測試先行、自動化構建與持續集成保證項目的可靠性。

• 測試先行，測試用例要作到全面測試
• 自動化構建，自動化構建工具要作到自動測試
• 持續集成，持續集成工具要作到頻繁測試

測試先行：

• 測試先行爲產品代碼提供實現目標和驗收標準
• 測試先行保證有一套全面的測試集伴隨產品代碼終身
• 測試先行保證系統在各類異常條件下的表現符合預期測
• 試先行保證修改和重構產品代碼不會破壞現有功能
• 測試先行爲程序員提供信心、勇氣和成就感

工具： Concordion,JUnit, Mockito, DBUnit, Fitnesse, Selenium, jsUnit，這些工具能夠幫助咱們作到測試驅動開發。

1.2.5自動化構建

• 自動化構建減輕重複性的機械勞動
• 自動化構建保證測試100%執行
• 自動化構建能夠自動編譯、打包、部署和驗收測試
• 自動化構建保證構建的過程和結果可重複

• 自動化構建可方便切換操做系統、中間件和數據庫

  工具： Maven, Ant, Gradle，這些工具能夠幫咱們作自動化構建。

1.2.6 持續集成

• 持續集成保證頻繁運行全套測試
• 持續集成能夠在任什麼時候間交付可靠可靠產品
• 持續集成在構建失敗時及時通知正確的人

工具： Jenkins, Hudson, Continuum，這些工具能夠幫咱們作到持續集成。

1.2.7 質量度量和設計評審

開發人員的七宗罪	設計評審
複雜性	是否實現了預期功能
重複	是否適合總體架構
缺少單元測試	是否安全、可靠、高效
不符合編碼規範	是否足夠簡單、清晰、可讀
註釋不足或太多	是否易於擴展
潛在的Bug	是否測試了各類邊界條件
意大利麪條式設計	可否提煉通用概念和邏輯

工具： Sonar能夠幫咱們作代碼評審，管理代碼質量。

2 敏捷項目管理

2.1 敏捷宣言

• 個體和交互 賽過 過程和工具
• 能夠工做的軟件 賽過 面面俱到的文檔
• 客戶合做 賽過 合同談判

• 響應變化 賽過 遵循計劃

  雖然右項也有價值，但咱們認爲左項更有價值。

2.2 項目的敏捷開發方法

• 敏捷團隊做爲一個總體工做，團隊全部成員對項目擁有共同責任.
• 按短迭代週期工做，固定四周一個迭代，毫不延長.
• 每次迭代交付一些成果，每次迭代實現一批用戶故事，交付客戶使用.
• 關注業務優先級的功能，優先實現具備高業務價值的用戶故事.
• 進行檢查和調整，每次迭代根據上次迭代得到的新知識進行調整.

2.3 估計故事規模

• 用故事點估計用戶故事的規模
• 以某個衆所周知的功能作參照系
• 用波多那契數列1,2,3,5,8,13表示故事點超出13點的故事要拆分爲多個更小的故事

估計方法：規劃撲克由開發團隊估計故事規模，客戶表明不干涉。

2.4 排定故事優先級

根據業務價值和風險設定用戶故事優先級：

• 高價值高風險
• 高價值低風險
• 低價值低風險
• 低價值高風險

由客戶表明或產品經理負責排定優先級

2.5 進度安排

2.5.1 發佈規劃

1.肯定滿意條件 2.估計用戶故事規模 3.選擇迭代週期長度  4.估計速度 5.肯定用戶故事優先級 6.選擇用戶故事和發佈週期

2.5.2 迭代規劃

1.調整優先級 2.肯定目標速度 3.肯定迭代目標 4.選擇用戶故事  5.把用戶故事分解爲任務 6.對任務進行估計

2.5.3 每日例會

1.天天固定的時間進行 2.限時15分鐘左右 3.每一個人站立進行每一個人回答三個問題:1.昨天作了什麼？ 2.今天打算作什麼？ 3.存在什麼問題？

2.6 跟蹤與交流

2.6.1 看板

2.6.2 圖表與度量

• 速度圖——每一個迭代完成的故事點
• 迭代燃盡圖——迭代中天天剩餘的故事點
• 發佈燃盡圖——發佈中每一個迭代剩餘的故事點
• 故事/Bug比例
• 開發人員生產力

從下圖能夠看出每週實現的用戶故事

2.6.3 展現成果

• 天天向團隊展現已完成的成果
• 確保每一個人理解每一個功能的實現
• 糾正誤差，提供改進意見
• 防止「各人自掃門前雪」
• 讓我的成果變成團隊資產

以上是以前培訓的一些東西，整理一下分享給你們。