敏捷代表快速響應，快速行動。敏捷開發的最高目標：通過儘早持續交付有價值的軟件來滿足客戶的要求；盡最大可能減少不必要的工作。瞭解了敏捷開發就不得不瞭解Scrum，文章中進行了簡單的描述。
敏捷開發
1. 什麼是敏捷開發（Agile Development）？
a) 敏捷開發以**用戶的需求**進化爲核心，採用**迭代、循序漸進**的方法進行軟件開發。
b) 在敏捷開發中，軟件項目在構建初期被切分成多個子項目，各個子項目的成果都經過測試，具備可
視、可集成和可運行使用的特徵。換言之，就是把一個大項目分爲多個相互聯繫，但也可獨立運行的小
項目，並分別完成，在此過程中軟件一直處於可使用狀態。
簡單的說，敏捷開發並不追求前期完美的設計、完美編碼、而是力求在較短的週期內開發出產品的核心
功能，儘早發佈可用的版本，然後在後續的生產週期內，按照需求不斷迭代升級，完善產品。
2. 敏捷開發特徵
-
迭代式開發（主體是時間週期）
項目按照時間週期進行迭代，比如A功能優先級比較高，則在第一個迭代週期內優先 開發A功能，並上線。第二個迭代週期開發B功能。 -
增量開發（主體是功能模塊）
指的是軟件的每個版本，都會新增一個用戶可以感知的完整功能。也就是按照新增 功能來劃分迭代。增量開發加上迭代開發，纔算是真正的敏捷開發。 -
開發團隊和用戶反饋推動產品開發
敏捷開發提倡用戶參與到產品或項目開發的整個流程當中，通過用戶反饋使得產品 更加符合用戶頻繁變動的需求。 -
持續集成
採用敏捷開發的產品在產品初期會上線基本功能，之後的功能是根據收集到的用戶 反饋進行開發的，實現功能模塊的持續集成。 -
開發團隊自我管理
要求團隊成員高效交流，以此來提高產品，項目的開發效率，開發質量。
3. 爲什麼要使用敏捷開發
- 3.1 覆蓋快速變化的市場，用戶需求，快速響應變化需求：在用戶需求不斷變化的情況下能夠保證軟件開發質量，把大的週期變成小週期。
- 3.2 早期交付，大大降低成本
- 3.3 及時瞭解市場需求，降低產品不適用的風險。
4. 如何進行每一次迭代
雖然敏捷開發將軟件開發分成多個迭代，但是也要求，每次迭代都是一個完整的軟件開發週期，必須按照軟件工程的方法論，進行正規的流程管理。
每一次迭代都要依次完成五個步驟：
1) 需求分析（requirements analysis）
2) 設計（design）
3) 編碼（coding）
4) 測試（testing）
5）部署和評估（deployment / evaluation）
瞭解了敏捷開發，接下來我們需要了解幾個概念：
Scrum
字面意思是橄欖球運動員並列在一起相互快速爭球，
Scrum 是通過團隊合作把項目一步步的推進，這樣的開發方式稱爲Scrum 敏捷開發。
Scrum目的是爲了提高軟件開發效率，小步快跑，快速的把已知的需求進行迭代產出，
爲客戶創造最優先可見的價值。
Scrum敏捷開發管理是最爲常用的敏捷開發工具之一，其包含的內容：
-
三大角色
Product Owner 產品負責人 Scrum Master 敏捷實施負責人 Team Members 敏捷團隊 -
三大物件
Product Backlog 產品需求庫 Sprint Backlog 迭代需求庫 Burndown Chart 燃盡圖 -
四大會議
Daily standup 日常站立式會議 Sprint Plan 迭代規劃 Sprint Review 迭代評審 Sprint Retrospective 迭代回顧 -
其他
Story Epic - 史詩故事集 Story Theme - 主題故事集 User Story - 用戶故事 Task- 任務 Sprint - 迭代/衝刺
下面進行詳細的解釋
1. scrum中有三個重要的角色;
-
產品經理（product owner）
負責確定產品特性，同時產品經理會提出產品亮點。
-
scrum master
是整個團隊的負責人，負責幫助團隊盡其所能完成工作，組織日常會議和保障其他工作。
-
Scrum team團隊成員
是由開發人員、測試人員、文案以及其他幫助研發的人組成。
Scrum來實施敏捷開發，整個項目會被分解成不同的小部分。每一個小部分都是有plan,build test review 構成。從而得到幾個增量式版本，稱爲Sprint（衝刺）。
在Scrum中有三種常用的可視化文檔：
-
1 product Backlog
產品需求列表或者產品需求庫，用來收集產品所有的用戶故事，並按照需求本身對用戶故事的大概寫法進行詳細的描述。
-
2 Sprint Backlog
產品經理會先從衆多用戶故事（user stories）中篩選出優先項，並把它們列入產品開發列表中，需求列表會隨着每次的Sprint迭代和更改。
-
3 Burndown Chart (燃盡圖)
用以展示整個Sprint代辦列表的進度。當燃盡圖曲線接近於0時，也就意味着這次sprint即將完工→XY軸組成，Y一般代表剩餘的工作量或剩餘的UserStory 數等，X代表當前迭代的時間段。
補充；
User stories(用戶故事）：是一種表達產品需求的語言格式。
格式爲：作爲一名----用戶，我需要----功能，所以---能夠。產品經理通過用戶故事來了解需求的細節，
爲Scrum團隊合理制定任務優先級。最優項的用戶故事將進入Sprint代辦列表（sprint backlog),剩下的
繼續評估優先級，交到下次Sprint中。
3. Scrum方法中有三種不同形式的會議：
-
sprint計劃會議
是產品經理 Scrum Master 和開發團隊碰頭的會議。用於討論用戶故事並估算任務量。 -
Daily Scrum 每日例會
也就是我們熟知的站會（standup meeting),整個團隊會簡述工作進度，並且討論是否 有任務需要擱置或是加派人手。 -
Sprint 回顧會議
在Sprint接近尾聲時，會進行Sprint 回顧會議，此時研發團隊會向產品經理演示開發 好的功能。，然後整個團隊討論是否有需要改進的地方。
Scrum之Epic 的概念和使用場景
Epic 有史詩故事級的意思，是一個比較大的User Story，在敏捷開發工具Scrum中，Epic顧名思義爲史詩故事集，一個比較大的User Story，裏面可包含很多小的Story。主要應用場景如下:
一個獨立的模塊：一個模塊裏會有很多小的Story，放在一個Epic裏可保證這些小的用戶故事的相關
性，方便上下文的理解，這種情況一般可以把一個模塊建設成一個Epic。
相關故事組合的故事集：在梳理User Story時，如果存在一些先後循序和很強的干係關聯性，可以
把這些用戶故事放在一個Epic裏，以便在研發這些故事時不影響正常的依賴關係。
第三方集成相關的需求故事：在模塊或者功能開發中，會遇到很多和第三方API或者SDK進行集成，
這個時候可以把系統本身的需求和第三集成的需求放在一起合成一個Epic。
Scrum工作流程：
1 首先產品經理把那些需要上線的產品特性，做成產品需求列表（Backlog），然後由產品經理甄選出最優項，準備交給整個團隊討論。
2 召開Sprint 規劃會議（Sprint planning）：研發團隊、產品經理和Scrum Master 討論用戶故事優先項。並且決定下次sprint要研發的需求項。
3 根據sprint 規劃會議制定Sprint 需求列表（sprint backlog），這個列表就是指經過團隊討論後的用戶故事，用於下次的sprint,會議結束後，整個研發團隊和產品經理必須要對每個用戶故事有深刻的理解。
4 研發團隊要在一到三週的時間裏開發完成Sprint 列表中的需求。在sprint期間，每日站會用於團隊來交流他們做完了什麼，正在做什麼，以及遇到的問題。
Sprint的產出是一個可以發佈的產品版本。是否可發佈由產品經理來決定。也可以在發佈前增加新的功能。
5 在Sprint結束時會舉行sprint回顧會議，由研發團隊向產品經理做案例演示，同時團隊可以一起反思工作中可以改進的地方。
敏捷開發工具——JIRA，下次接着聊。