目錄
1.敏捷簡介
1.1 敏捷宣言
1.2 XP實踐洋蔥圖
1.3 SCRUM的過程圖
2.實施和管理敏捷項目
2.1 組建敏捷項目團隊
2.2 項目啟動—搭建項目環境
2.3 項目啟動－准備及制訂Product Backlog
2.4 用戶故事 User Story
2.5 划分迭代和開工會議
2.6 敏捷中的迭代實施過程
2.7 敏捷項目中程序員的一天
2.8 每日晨會（站立式會議）
2.9 迭代評估和回顧會議
2.10 測試和測試如何參與敏捷項目
3.小結
1.敏捷簡介
1.1 敏捷宣言
- 個體和交互 勝過 過程和工具
- 可以工作的軟件 勝過 面面俱到的文檔
- 客戶合作 勝過 合同談判
- 響應變化 勝過 遵循計划
1.2 XP實踐洋蔥圖
1.3 SCRUM的過程圖
2.實施和管理敏捷項目
2.1 組建敏捷項目團隊
敏捷項目團隊由三種角色組成
1、Product Owner—由系統分析人員擔任。負責收集和描述待開發產品的信息，並轉換成待開發列表。解釋和描述每一項任務的要求,項目開發過程中關注每個Story是否實現，解釋其要求細節。
2、開發團隊成員－由來自開發、測試、資料共同組成的多功能團隊，負責構建產品。
3、Scrum Master－由熟悉敏捷的成員，負責幫助和指導團隊按照敏捷方式操作。
除此之外，還有一個項目經理，負責整個團隊的管理。
2.2 項目啟動—搭建項目環境
1、搭建持續集成環境
敏捷項目需要維護一套唯一的持續集成環境，能夠實現自動的從配置庫獲取代碼、編譯、靜態檢查和測試。
持續集成環境搭建，可采用IC持續集成系統，聯系軟件工程部進行技術支持。
持續集成至少做到每天固定執行一次，也可根據配置庫代碼變化觸發執行。
2、搭建開發環境
包含項目的編譯等環境的配置等
3、搭建測試環境
尤其是自動化測試的環境，能夠為持續集成系統調用執行
2.3 項目啟動－准備及制訂Product Backlog
- Product Owner分析待開發需求任務列表，形成產品Product Backlog，並按照商業價值排序。
- Product Backlog是產品唯一的待開發任務列表（如示例），是對開發任務的初步簡要描述，並附帶工作量的初步估計。Backlog既可以包含新增需求、功能，也可以包含待解決的問題等（有點類似傳統的AR列表）
- Product Backlog隨項目進行，根據外部環境的變化，可能會不斷調整，但是已經在迭代內實施的任務項將不受影響。
- Product Backlog通常使用User Story形式分析描述。
2.4 用戶故事 User Story
- User Story- User Story是站在外部的用戶角度來描述系統所具有的功能/特性，並且此功能/特性能為客戶感知。
- User和Story的識別：
用戶Users-使用到待開發系統的任何角色（包含人、也包含其他軟件或程序），一般可以采用頭腦風暴形式識別所有的Users. -
Story識別及描述：
As a <Role>,I want <function>,so that<reason>
做為一個<XXX角色>,我希望<YYY功能>，以便<解決什么問題/原因>
User Story通常是最小的用戶感知粒度。
注意：
1、項目所有成員都可參與分析制作User Story（含開發、測試人員,資料人員也從使用資料的對象分析，形成資料User Story)，這時候並不需要太多的系統實現內部細節。
2、User Story分析結果記錄在《User Story模板》中，雖然敏捷可以記錄在白板、卡片等形式上，但在公司內部實施的特定環境下，用文檔記錄還是比較好的。
2.5 划分迭代和開工會議
敏捷計划和開工會議包含：
1、Product Owner向開發團隊介紹待開發任務Product Backlog,討論各項需求任務的目標和背景，提供所有成員深入理解需求的機會。
2、開發團隊集體從Product Backlog根據優先級，選擇任務，初步划分迭代，設定迭代周期（迭代周期通常是固定周期，比如1-4周都是常見的迭代周期）。划分迭代時，通常從Backlog的優先級開始，結合需要的工作量進行划分。
3、完成迭代划分后，啟動第一次迭代的分析工作,分解成任務，形成本迭代的Sprint Backlog. Backlog列舉任務的大小不同，可能分解為一到多個任務項Task.各Task也可以用User Story形式進行描述。這時候會涉及到部分的實現細節。
2.6 敏捷中的迭代實施過程
2.7 敏捷項目中程序員的一天
2.8 每日晨會（站立式會議）
- 15分鍾的站立式會議，通常在早上進行。
- 每個成員介紹三個事情：
從上次會議結束后，完成了哪些工作？
到下次會議前，將准備完成哪些工作？
工作中還存在哪些障礙？ - Product Owner和所有項目成員必須參與會議。
- 每日晨會后，項目經理負責更新每項任務的進展情況。
2.9 迭代評估和回顧會議
- 在每次迭代結束時，進行迭代評估，團隊展示他們所構造出的產品。
- 參加人員：所有項目成員，以及項目的客戶。
- 不需要准備PPT膠片材料，只需要如實的展示工作進展即可。
- 同時回顧當前做得好的和不足的，以便在下一個迭代中改進。
- 通常，迭代評估緊接召開下一個迭代的計划會議。
2.10 測試和測試如何參與敏捷項目
3.小結
本文簡單介紹了敏捷開發的基本概念，詳細介紹了在敏捷開發中使用的優秀實踐，這些實踐在實際開發中對提高開發效率保障項目質量有明顯的效果。此外本人使用敏捷約2年時間，在實施敏捷的時候遇到各種各樣的問題，這些困難有：項目情況特殊，客戶不配合；團隊技術、積極性層次差異；成員工作習慣不接受敏捷；工作壓力變大，讓人抵觸。這些困難在各個公司相信都有或多或少出現，但敏捷其實是一種思路，並不是一種規范，不是所有的實踐都用上才叫敏捷，所以可以根據公司的實際情況來制定符合公司情況的敏捷流程，最終目的還是提高工作效率，並更好的適應需求變化，提高項目質量。