前段時間參加了兩天敏捷開發管理培訓，收獲挺大，在這里做一下總結。
理解敏捷##
整個培訓過程中一直穿插着敏捷軟件開發的原則進行講解，這里摘錄給我感觸最深的幾個：
- 我們最重要的目標，是通過持續不斷地及早交付有價值的軟件使客戶滿意，經常地交付可工作的軟件，相隔幾星期或一兩個月，傾向於較短的周期。
- 業務人員和開發人員必須相互合作，項目中的每一天都不例外。
- 團隊定期反思如何能提高成效，並依此調整自身的舉止表現。
- 激發個體的斗志，以他們為核心搭建項目。提供所需的環境和支援，輔以信任，從而達成目標。
敏捷流派主要有兩個：Scrum 和 極限編程。Scrum側重項目協作流程，極限編程側重提高編程效率的技術實踐。兩者應該相輔相成。這里着重講講Scrum。
團隊與角色##
Scrum中有Product Owner、Team、Scrum Master三類角色。一個好的Scrum團隊以下特點：
- 通常5~9人；
- 跨職能，跨模塊人員構成；
- 成員應全職投入；
- 團隊自組織管理；
- 迭代內保持團隊成員穩定。
做好一個Product Owner要點如下：
- 定義產品功能；
- 定義產品發布的日期和功能；
- 對產品的投入產出比負責；
- 根據市場情況對需求排列優先級；
- 如果需要，在每個迭代合理調整產品特性及其優先級；
- 介紹或拒絕開發團隊的工作成果。
Scrum Master要引導團隊自己去找答案，而不是做一個發號司令的人，做好一個Scrum Master要點如下：
- Scrum正常運作的守護者；
- 激發團隊創造力；
- 改善開發團隊的外部環境；
- 輔導團隊提升運作效率；
- 排除團隊遇到的困難；
- 保持團隊緊密合作；
Team就是團隊中的開發、測試或ui設計人員。
需求管理##
Scrum通過編寫用戶故事來管理需求，好的用戶故事的原則如下：
- Independent獨立的；
- Negotiable：可討論的；
- Valuable：對用戶或客戶有價值的；
- Estimatable：可估計的；
- Small：小的；
- Testable：可測試的。
之后要進行工作量估算，Product Owner(業務人員)必須在場梳理需求，每個項目成員針對用戶故事的疑問向Product Owner提問，所有人弄清楚需求后開始。
大家先找一個參照需求，確定它的工作量，然后其他的需求就按照這個參照需求來估計，這種相對估計法確保每個人估計出來的工作量是一致的。
使用撲克牌，大家同時給出需求的估計值（而不是輪流進行），估值最高和最低的必須分別給出原因，這樣做的好處讓大家都獨立思考。通過多輪估值讓所有人了解需求，並估算出一個較為合理的工作量。
Scrum中的各項活動##
簡單來說，划分如下
項目計划|
Sprint0|
Sprint1|
Sprint2|
Sprint3|
項目總結|
按一個迭代周期來說，主要划分如下：迭代計划和評審一般要占用兩個小時，而站立會議一般15分鍾。
迭代計划1|
迭代計划2|
站立會議|
...|
站立會議|
迭代評審|
迭代回顧|
Spint0要做一些准備活動，如高層的業務流程圖、初始的用戶故事列表、測試策略、發布計划、團隊建設、技術架構的選擇、設計UI的風格等。
站立會議###
晨會的要點：
- 輪流發言，持Token者才可以發言；
- 不討論深入細節；
- 不是對領導匯報，讓團隊中每個人都了解你的發言；
- 不能單獨討論，自發的有序的進行發言；
- 時間在15分鍾以內。
站立晨會的三個經典問題：昨天我完成了哪些工作；明天我打算做什么；完成我的目標是否存在什么障礙。
站立晨會的目的不是為了讓大家都回答那三個問題，而是讓團隊圍繞這三個問題，制定當天的工作計划並暴露問題。
迭代驗收和回顧###
迭代驗收會議，通過演示可工作的軟件檢查需求是否滿足客戶要求；迭代驗收的好處：
- 通過演示可工作的軟件來確認項目的進度，具有真實性；
- 能盡早獲得用戶對產品的反饋，使產品更貼近客戶需求。
- 收集反饋。
迭代回顧會議，目的是分享好的經驗和發現改進點，促進團隊不斷進步，迭代回顧的好處：
- 激勵團隊成員；
- 幫助團隊挖掘優秀經驗並繼承；
- 避免團隊犯重復的錯誤；
- 營造團隊自主改進的氛圍。
利用敏捷改進現有工作##
即使不使用敏捷方式開發，也可以利用它的一些好的想法和實踐可以用來提升目前的工作效率。
- 比如敏捷開發中如何調動團隊積極性，讓每個人看到的是團隊目標，而不是個人目標。
- 比如經常地交付可工作的軟件：以此提高軟件開發的質量和可交付性。
- 比如借鑒敏捷中設定Sprint(沖刺)的開發過程，調動開發人員的積極性以及明確每個開發階段的目的性。
其他問題##
-
需求文檔 或者 使用說明文檔 寫了100多頁，但是寫完之后基本沒人看，這樣的問題應該很普遍，該如何解決？
把Word文檔遷移到Wiki上，大文檔切細分成一個個獨立的Wiki頁面，Wiki可以統計頁面的訪問次數，有了足夠的數據支撐之后就可以把訪問次數少的頁面去掉，以此來精簡文檔，這樣留下來的文檔內容就是真正有用的。 -
業務部門的需求太多而且每個都非常緊急，怎么處理？
業務部門拉一個人對需求按價值進行排序；需求收集例行化，主動收集，需求有一定的清晰度；回顧哪些需求不重要，做為武器。