因字數過多，文章拆成上中下三篇
(上)篇包含：一、前言；二、Scrum名詞(Scrum角色、Scrum物件)
另外去年十月終於在 Hahow 上把這篇所有內容，附帶實際案例和相關文件，更新並整理成影片，如果讀者想要更完整更清晰的圖片輔助，非常歡迎來觀看我在 Hahow 上的影片哦！
一、前言
甚麼是敏捷開發？
甚麼是 Scrum？
敏捷開發怎麼實際應用？
如果您有以上問題，歡迎參考這篇『深入淺出「敏捷軟體開發：Scrum」』
筆者將協助完全沒有敏捷式開發相關知識的您，將敏捷開發所描述的理論以及方法，藉由筆者個人過去經驗，加上訪問其他應用敏捷開發人員的心得和文中提及的文章引用加以潤飾，除了協助各位快速理解之外，並了解如何真的能「落地」應用在軟體開發流程。
另外必須強調的是，這些經驗以及心得，相信可能多少會跟有使用過敏捷開發的讀者有些不同。在此也非常歡迎大家一起共同討論交流，畢竟不同的方式應用在不同的場景會得到不同的效果，不一定筆者描述的方式才是正確的，但只要符合精神，我們都是在應用敏捷開發。
首先以一句話概括敏捷開發：「一種應對快速變化需求的軟體開發能力」(引用自 Wiki)
進入正題前，有1篇文章、1句話和1個宣言要請各位讀者速讀初步了解。
第一、請閱讀「10分鐘讀懂 Scrum 與敏捷軟體開發入門／ Yves Lin」
因為正文內容很長，希望大家可以先速讀這一篇，能大致了解 Scrum 是甚麼，再讀本篇文章會比較容易理解。(如果想看更詳細的 Scrum名詞和流程解釋，可以查看 Scrum Primer(點擊即可)
第二、敏捷 ≠快
沒錯，請跟著我念「敏捷開發不代表開發流程會變快」。
敏捷開發方法是一個快速迭代的過程，每次的迭代都能讓團隊針對過去犯下的錯誤反饋進行更正，不像傳統「瀑布式開發(Waterfall)」一個流程完成才接著下一個流程，讓變動性大幅降低。
你可以說，敏捷開發讓開發團隊有著「快速調整的能力」，舉例來說：面對意外的事情可以短時間內解決，不影響開發流程；或者因應變動的需求，開發團隊能馬上修改產品，符合客戶需求等等。
第三、閱讀「敏捷軟體開發宣言」
請大家參考敏捷軟體開發宣言，敏捷開發講求的是「敏捷的精神」，只要遵守精神，不管方法流程如何變化，都是屬於敏捷開發，這個概念要請 Scrum Master 時常的提醒團隊成員，否則只會流於形式，反而降低應對變化需求的速度。
接下來將直接進入內文，我將會不時穿插上面引用的文章解說，所以非常建議大家先把上面的部分都先閱讀過，會更快進入「敏捷的世界」。
二、Scrum 名詞
在上面速度內容的基礎下，針對 Scrum 的各個名詞做更詳細的解說與補充，我會將每個內容分成敏捷開發理論以及個人實施過後的調整版本，讓敏捷式開發更容易地融合於現實軟體開發流程。以下列出本篇會講的名詞清單
(一)Scrum中的角色
- Development Team
- Product Owner
- Scrum Master
- Stakeholder
(二)Scrum中的物件
- Item
- Task
- Product Backlog
- Sprint Backlog
- Potentially Shippable Product Increment
- Burndown Chart
(一) Scrum 中的角色
1. Development Team：負責需求的軟體建置開發、部署
(1) 敏捷理論一：開發團隊成員不需有職能的分別，每個人沒有專業頭銜
(2) 敏捷理論二：團隊成員維持 5–9人(7+-2)
現實情況為，開發人員通常會分成前端工程師、後端工程師、數據工程師，甚至是測試工程師、深度學習工程師等等，而彼此工作基本上有時候很難做到跨職等的事情(例如前端工程師去做深度學習工程師的事情)。
因此在實際運行情況當中，建議開發團隊以不超過 3 個分類為主，每個分類至少保持 2-4人(因為當開發遇到問題時候，有 2個人的組合才可以互相討論，互相看到不同的盲點；不超過 4人便是不讓太多人降低了開發效率)，並至少有1位「資深級別」工程師(資深工程師較有經驗知道某些功能怎麼做，可以起到帶頭分配 Task 的工作，也能輔佐其他 Junior 工程師的問題)。
總人數維持在 5-9人(筆者認為 4-12人 其實也可以，主要還是看開發規模大小，當然如果超過這個數字就需要改變模式，至於為什麼要限制最大人數，其一是溝通效率，人越多溝通起來越複雜，其二是針對 Item 評分的估算，當人越多會越難去磨合出大家心中衡量的比例，這部分會在後續評分的活動詳細說明)，另外測試工程師建議拉出，並新增一個測試 Story 的流程(後續會提到怎麼實作)
2. Product Owner：負責決定軟體開發的功能
與理論中敘述的相同，如果你是乙方的角色，要站在客戶的立場理解需求(甲方當然就客戶自己為PO)，盡所能鉅細靡遺說明、定義使用者故事，並排列各待辦事項優先順序，優先順序通常以能達到最大效益為衡量指標，而這「最大效益」就要靠 PO 去定義，通常是客戶最在意的功能、畫面等等。
3. Scrum Master：負責提倡以及確保 Scrum 在團隊中順利進行
與理論中敘述的相同，尤其建議第一次實行或者少數有經驗人員的敏捷開發團隊，應當要堅持設置 Scrum Master 的角色，時時刻刻提倡敏捷精神，否則開發團隊會很容易忽略敏捷精神，會造成開發效率不升反降，以下舉幾個實際例子
(1) 有外在因素干擾 Sprint 的開發項目
舉例來說，常常客戶或者主管看到某些功能應該要修改，便會直接去尋找對應的工程師要求他們立即修正。當然我們會說敏捷強調的不是隨時回應變化嗎？但是這樣卻忽略了整個 Scrum 流程，因為每一位工程師所接收到最後的 Task 都是透過一連串的流程而來，在 PO 尚未確定任何更動是否也會影響他人，也未確定是否客戶真的要這樣修改的時候，就會造成 Scrum 的混亂。
(2) 缺乏互相交流溝通的情形
Scrum Master 必須要非常強調 Dev Team 的互相交流，尤其 Daily Scrum 壹定要要求確實執行，要鼓勵大家說出遇到的困難點（往往 Dev Team 的人都會說沒有，但幾乎肯定會有），有時候 Dev Team 他們在解的 Bug 可能會互相重複，還有某些 Bug 可能是 A成員不擅長，但是 B成員擅長的，這樣會加快整個開發速度
(3) Dev Team 沒有即時更新 Sprint Wall 上的資訊
記得提醒成員要時時刻刻更新 Sprint Wall 上的資訊 (下圖) ，這樣每個人才能彼此了解工作進度，如此透明化的 Sprint Wall 會節省部分彼此溝通的成本。
(4) …
上述幾個情況都會阻擋敏捷開發的流程，導致敏捷精神流失爾後效率降低，甚至使團隊懷疑敏捷方式為錯誤決定，因此 Scrum Master 如何及時解決這些狀況勢在必行。
4. Stakeholder : 利害關係人
這邊指的 Stakeholder 統稱 Scrum 成員以外，對於 Scrum 會有一定程度影響的人的統稱，例如：專案主管、客戶窗口、客戶老闆等等，雖然 Stakeholder 並不列在 Scrum 的正式角色之內，但其實他也一定程度上的影響了 Scrum 的導入與運行，如果他不懂「敏捷式開發」，那麼就很容易干預 Scrum 的推進，進而使 Scrum 的優勢無法發揮，因此，如果可以的話，最好讓 Stakeholder 都擁有敏捷思維。
(二) Scrum 中的物件
1. Item (物件) ：明確的羅列出待開發的項目
由 Product Owner 決定 Item 內容，並讓開發團隊自行拆解 Task 進行開發。
通常要進行功能開發的時候，要將規格功能遵守 As a < type of user >, I want < some goal > so that < some reason > 的格式進行撰寫
而待辦事項通常不僅僅只是開發內容，也包含了很多項目，當開發團隊在進行某樣新功能開發的時候，不外乎會進行構思架構、調查工作、實際執行、測試等等的幾個步驟，有時如果剛好碰到過去熟悉的部分，可以直接跳到實際執行，但如果遇到不熟悉的部分，就會在調查反覆了解當中花費比較多的時間，但這些也都應該要記錄下來。
補充更多部分：
針對 User Story ，筆者建議額外加上了幾個訊息讓觀看者更清楚，包含 Story Title(顧名思義)、Story ID(Story 專屬的 ID)、Sprint Number(屬於第幾個Sprint)、 Story Ref Number(代表這個 Story 其實是從某個 Story 功能繼續衍伸下來，但必須把功能進行更詳細拆分的時候，Story Ref Number 可以很快地知道前一步驟的Story是甚麼)、Product Owner、Story Point(後面有個步驟會進行評分)、Story Version(目前更動最新是第幾版)、Story Priority(優先順序(高中低))、故事描述、Acceptance Criteria(測試案例(包含：前置條件、操作步驟、預期產出等等))。(在筆者實行的敏捷開發內，其實有把UX設計環節融入，日後會額外寫一篇文章專門說明如何實際運作，會讓整體開發效率再往上提升)
在 Story ID 的命名上，如果有個代號會更清楚，EX: S01 (代表跟Search 有關的功能)、P01(與Payment有關的功能)、Search-B-01(加上B表示這個是後臺的功能) 等等，會讓大家在 User Story 觀看上更加輕鬆明朗
另外，User Story 所描繪的功能不能太大或太小，應當要適度讓開發團隊在 Sprint 期間可以完成至少3個以上，否則團隊沒有成就感；最大值筆者是掌握在7個，不讓團隊認為功能做不完。
當開發團隊成員如果不是全心全意一周40小時在 Scrum 上面時候，筆者會額外加一個「預估可用時間」讓開發團隊成員填寫，如此在規劃 Item 時候，對應到小時可以縮放要完成的 Item 大小。
最後，Item 在每一次 Sprint Meeting 當中會做所謂評分的動作，記得Item所描繪的內容，時間上盡量至少要花團隊1天，最多不超過團隊3天為主，團隊以及 PO 可藉著每次的 Sprint 慢慢抓到精準度。
2. Task (工作) ：羅列出開發人員該做甚麼事情以符合 Item 的需求
Development Team 自 Item 拆解出來的工作項目。（以下為Scrum Board)
(1) 敏捷理論一：Development Team 針對 Item 自行拆解所需的工作
(2) 敏捷理論二：針對 Task 部分，進行所謂的「可視化管理」，大部分都是準備一面牆，使用便條紙切割出「To do」、「Doing」、「Done」
補充理論不足的部分：
為了配了測試以及 Bug 部分，將可視化管理的 Sprint Wall 多增加了三個項目，分別是 Test Backlog (待測試項目，以Story為主)，Test In Progress，Test Done(Potentially Shippable Product Increment)，這三列定義專為測試人員測試的欄位，跟開發團隊的項目分開在畫面上會更加清楚明瞭。
Task 的內容必須涵蓋負責人(Owner)、工作內容(對應的Story)、預估工時(預估要花多少小時)、來自哪一個 Item舉例說明 A1-1-1 版面切分(8/)-Andy，A1–1 代表對應 Story “A1–1 Home Page” ；-1 代表是 Task ID；(8/) 前面代表預估時數，後面代表真的完成之後的花費時數；-Andy 代表負責人。
如果沒有牆壁的話，筆者推薦可以使用 Trello , leangoo。(因為很多工程師在程式碼整合、交付和部署都是使用 GitLab/Github，因此後續會再寫一篇文章說明，如何用 GitLab/GitHub 進行 Scrum，會讓工程師不需要跳轉平台重工)
3. Product Backlog (產品待辦清單)：放置未來待開發的 Item 清單
(1) 敏捷理論一：所有產品功能的 Item 清單都會先發到 Product Backlog 上，施工順序由上往下。
補充理論未提及部份：
依照筆者經驗會在每一次的 Sprint 結束之後，下一個 Sprint Meeting 前跟大家過一次未來會放入 Sprint Backlog 的清單；如果產品功能在待辦清單有大幅度變動時候，每一周會找資深工程師事先解釋了解可行性，才會進行待辦清單的更動。
而好的 Product Backlog 應該具備以下特性(引用scrumprimier的內容, 文中提及為DEEP四個性質，做了稍微的修改)
(1) 適當詳細：Detailed appropriately，意思就是在 Backlog 的 Item 並不是每個內容都有仔細地描述，在每次 Sprint Meeting 之前，筆者建議採用八二法則，只要共 20% 的有詳細描述即可(意即到開發團隊可以拆解出Task地步)，其他 80% 只要有大概的敘述即可(因為未來的變動)，通常這樣的數量對於開發團隊已經足夠。
(2) 估算過的：Estimated，代表撰寫的 Item 有詢問過相關人等去估算該 Item 大約要花多少的時間與成本完成，同時也估算重要性質，以利優先順序的排列。
(3) 持續更新：Emergent(雖然中文跟英文不太一樣，但認為翻譯持續更新比較能表達Emergent的意思)，要一直持續的更新 Item 內容，去因應每週甚至每日所接受到最新的需求，這樣交付下去的 Item 才會跟最終客戶期待的產品認知不會落差太大。
(4) 優先順序：Prioritized，產品負責人必須要去考慮如何安排 Item 的優先順序，必須要從不同的方向考量，包含商業價值、成本、和其他利害關係人的因素。
4. Sprint Backlog：放置本次 Sprint 要開發的 Item
(1) 敏捷理論：開發團隊在 Sprint 中會完成的項目
5. Potentially Shippable Product Increment：Sprint 結束後上線的功能
筆者作法是把 Tasks 都完成之後的該 Story，如果也經過測試工程師驗證完畢之後，會把它移動到 Done 的一個欄位，這個欄位也是這個名詞表達的意思，「可以上線部署的 Item」。
6. Burndown Chart：紀錄 Tasks 剩下的數量
與理論敘述的一樣，以 Task 的小時為主去畫出剩餘的時數和預估的時數，Burndown Chart 會讓團隊知道目前的開發進度，除了了解目標，隨著數字下降也能讓開發團隊有成就感。
