敏捷開發培訓總結

前段時間參加了兩天敏捷開發管理培訓，收穫挺大，在這裏作一下總結。

理解敏捷

整個培訓過程當中一直穿插着敏捷軟件開發的原則進行講解，這裏摘錄給我感觸最深的幾個：

• 咱們最重要的目標，是經過持續不斷地及早交付有價值的軟件使客戶滿意，常常地交付可工做的軟件，相隔幾星期或一兩個月，傾向於較短的週期。
• 業務人員和開發人員必須相互合做，項目中的每一天都不例外。
• 團隊按期反思如何能提升成效，並依此調整自身的舉止表現。
• 激發個體的鬥志，以他們爲核心搭建項目。提供所需的環境和支援，輔以信任，從而達成目標。

敏捷流派主要有兩個：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能夠統計頁面的訪問次數，有了足夠的數據支撐以後就能夠把訪問次數少的頁面去掉，以此來精簡文檔，這樣留下來的文檔內容就是真正有用的。

• 業務部門的需求太多並且每一個都很是緊急，怎麼處理？ 業務部門拉一我的對需求按價值進行排序；需求收集例行化，主動收集，需求有必定的清晰度；回顧哪些需求不重要，作爲武器。