敏捷開發介紹
今天想寫這個主題有幾點：
1. 簡介敏捷開發
2. 在帶 10 人團隊和 3 人團隊中，對於敏捷開發的心得
3. 最後給一些正在跑或是想要開始跑敏捷開發的團隊一些建議
敏捷開發是一種應對快速變化的需求的一種軟體開發能力
對於這個開發概念，有個對應的宣言，而根據概念和這些理念發展出了 Scrum 和 Kanban 主要兩個大框架 (各個組織裡面後來都會有各種的變形)。
聽過很多把敏捷開發用的很糟的團隊，大部分都是負責帶「敏捷開發」的人或是 Project Manager 把它當成要壓時程的擋箭牌，「敏捷開發」是 Agile Development 而不是 Fast Development，具體上來講這個開發概念跟 Release 功能的時間並沒有直接的關係，Agile 代表是有可以調整開發過程和市場反應的彈性，並不代表一個開發週期裡，塞滿一堆超過開發能量的功能。
接下來我想介紹 Scrum 這個框架，Scrum 這個框架裡主要由 3個角色、 3個產出和 5個會議組成
．角色：
1. Scrum master (How to deliver)
2. Project Owner (What to deliver)
3. Tech Lead (How to implement)
．產出：
1. User Story
2. Tasks
3. Story points
．會議：
1. Sprint Grooming
2. Sprint Planning
3. Sprint Kickoff
4. Sprint Start
5. Sprint Demo and Retro
Scrum 就是透過這幾個角色的互動和不同要素間的使用，確保團隊維持一個有效運作的機制。
在帶 10 人團隊和 3 人團隊中，對於敏捷開發的心得
1. Product Owner ( Project manager )，對於這套方法的認知即為重要，如果不能區分何為彈性，何為快速，團隊將會是一個災難，敏捷開發光是流程本身就是彈性的展示，許多 Product Owner 選擇想辦法讓開會加速，而不是省掉現階段不合適的會議，才會讓大家覺為敏捷開發只是一個為了有流程而創建的工作框作。對這點有疑問的人，可以試著不要任何框架，你還是會發現，最後還是會總結出跟敏捷開發差不多的工作流程。因為這套方法是演化、歸納出來的，並非為了創建而創建的。
2. 文件的重要。文件的重點不在於長，在於對精準、精鍊地記錄對問題的描述、假設和預期的 Acceptance Criteria。定義問題是讓團隊知道為什麼要做，這點說不明白，最直接的影響，就是團隊開發了一個月，不知道產品到底推進了什麼，好像做一堆東西但都看不到市場具體的推進，這裡會埋下互相不信任的點，最好的情況就是清楚闡明為什麼要做。提出假設和預期的產出，這裡的重點可以其它成員讓技術端來理解，有什麼假設是有認知不一致的，和提出可能更全面的解決方法，同時可以更準確的評估時間。
3. Engineer 必須即時地對不清楚的描述提出疑問，很多時候文件描述或是 UI 設計圖沒辦法詮釋所有流程，工程師必須盡可能的減少做下去後才在測試的時候，對於需求描述有模糊的認知後才提出來，要各個角色出來做確認，沒有什麼事情的討論是需要等到特定會議上才能提的。
最後給一些正在跑或是想要開始跑敏捷開發的團隊一些建議
循序漸進
對於敏捷開發裡面所需要的流程，應該是一個一個加上去的：
．發現開發和需求的確認頻率越來越高，拉一個sprint planning 的會
．發現開發的人開始多了，想要有個類比指標知道要產出不同等級的需求，開始估 story point
．開始發現 planning 時，還是很多事項需要跟不同 stack holder 確認，拉一個 sprint grooming 的會
相對地，當情況都開始不適用後，也該減少不必要的會。
記住，要毀掉一套方法最好的辦法就是讓它流於形式，而不去管背後的目的。
找到更多我的資訊可以到這 mhtsai
