前言
在正式開始之前，我們先知道什麼是【瀑布式開發】，這也是一般專案團隊最常用的開發方式。
如圖所示，每隔階段定義的十分清楚，要執行的項目明確。就像瀑布一樣，一路向下前行。實際在開發的時候，成員也都樂於這樣的模式，因為不會遇到模糊不清的時候(Ex 需求不知道是什麼就要進行開發… = =)。這在專案管理上是相對容易的，過程不會遲疑，檢視最後的成果是不是有達成目標就行。
但是，弊端也顯而易見。執行專案時，總是會有意外、風險、市場變化…，這些都是不可被預測的，而當專案是瀑布式開發，對於以上的變因，應對過慢，就很容易導致專案失敗！
瀑布式開發，強調的是「工具」、「流程」。
敏捷式開發，強調的是「個人」、「互動」、「變化」。
敏捷式開發
簡介
《敏捷軟體開發宣言》 裡頭說：
- 個人與互動 重於 流程與工具
- 可用的軟體 重於 詳盡的文件
- 與客戶合作 重於 合約協商
- 回應變化 重於 遵循計畫
從中知道，敏捷式開發注重的是溝通、成果、合作與變化。
「變」是唯一不變的事情
Scrum框架
我們耳熟能詳的 Scrum 就是實現敏捷開發的其中一種方式，也是最被廣泛運用的框架。
為達到相對短的開發週期，可能會抓大概 2 - 4 周，依據產品和團隊的不同，週期也會不同。而這個週期稱之為「Sprint」。
每一個 Sprint 中，會有四個會議：
- 規劃：決定要完成哪些項目
- 每日站立：每日花費10-15mins 同步資訊 (昨日完成、今日預計完成、是否遇到阻礙)
- 審查：展示成果，取得回饋、新需求
- 回顧：回顧衝刺的過程，是否有地方要改進
角色
- 產品負責人 (Product Owner)
代表客戶的意願，並確保團隊在做從業務角度來說正確的事情。編寫 User story，排出優先級，並放入 代辦清單(backlog)。他決定每一次 sprint 要完成哪些任務，讓整個團隊價值最大化。監督開發的節奏，從而保障產品的品質。
- Scrum主管 (Scrum Master)
主要的工作是去除影響團隊達成 sprint 目標的障礙，是規則的執行者。
- 開發團隊 (Dev Team)
負責交付產品的團隊。
結語
沒有一定比較好的 development，還是要依照專案需求、公司文化…來做選擇。各有各的優勢在，不過在快速變化的商業環境和技術環境中，迎接變化能力強的敏捷式開發原則，的確是可以滿足現況。
祝福大家都不要碰到四不像的敏捷開發😆