終於有時間可以好好寫一下，這幾年跑 SCRUM 的一些經驗與心得。

由於要覆蓋的面相比較廣，目前預計是利用 3篇文章來分享。

第一篇會簡單介紹一下 Scrum / Agile 的源起與概念

第二篇則是具體解說，一個完整的 scrum 應該怎麼來實踐

第三篇，則是針對我這幾年在台灣軟體開發團隊的經驗，因應台灣軟體公司的生態所演化出的一種變形的 scrum/sprint 跑法

要提到 Scrum，就不能不提到 Agile（敏捷式開發）與傳統的 Waterfall（瀑布式開發）

亞洲地區更常見的隕石式開發不會涉略，因為這個沒什麼好討論的 XD

Agile vs Waterfall

傳統的軟體開發，基本上遵照著傳統的工程建造流程，先有產品的分析報告，然後從商業面向的產品需求(PRD)，展開到軟體需求的工程需求（SRS），接著再由設計團隊產出產品整體設計文件（SDD），然後再進行完整的產品開發。

接著進行產品的完整測試流程，通過測試後交付並上線，然後後續就是維護。

不難看出這樣的模型有幾個特性：

以上幾個特性，如果在硬體產業，或是在一般的土木工程來說可能沒什麼問題，畢竟實體的東西，只要一開模/開工下去就真的很難改變，所以這個模型的重點在於事前的仔細規劃與完整的設計，完成後只需要少量的定期維護就能夠長期的使用。

但是在軟體產業，這幾個特性就會變成缺點。

畢竟軟體的修改成本太低（相對於硬體），加上市場變化很快。所以基本上產品還沒上線需求就變了是很常見的狀況（甚至這幾年有越來越快的趨勢）

或是產品想要長期在市場上經營的話，不斷地適應以及配合市場需求與變化也是一個重大的挑戰。

這時候反應慢，開發週期長的瀑布式開發就暴露出了嚴重的缺點。所以，這時候因應這樣的特性所提出來的敏捷式開發（其實不只在軟體產業，很多需要因應市場快速變化以及長期經營的產業都或多或少在往這個方向發展）

f:id:mouseface99:20191223173827p:plain

Agile

敏捷式開發提出的四大價值：

不是說右邊的就不重要，只是相對於右邊，左邊的價值更重要與更需要被重視（這一點常被誤解）

比方說 可用的軟體：重於詳盡的文件，不是說文件不重要，而是說與其花太多時間在寫更完善的文件，還不如把可用的軟體做好

因應 Agile 的精神，套用到了軟體開發的領域，就有了幾種方法論，其中目前最多人使用的就是所謂的 Scrum

這邊目前不會詳細展開 Scrum process 裡面的細節，這部分下一篇會提到。

這邊主要提一下 Scrum 的一些特性，以及如何對應到 Agile 的核心價值。

Scrum 的核心在於把一件大的事情切分成很多的小事情，然後依據每一個短期的當前利益來決定最重要的事情先做。

具體來說就是把完整產品的每一項功能，切分成多個 User Story 然後都放到 Product backlog 中。

但是每一次 Sprint 都只會從中取出當前市場價值最高的部分來實作，並且實作完後就能有一個能上線的產品

然後透過不斷的迭代更新，慢慢完善/或是改變產品的整體功能。

個人與互動：
透過 Sprint planning / review / retrospective meeting 與每天的 Daily standup 來確保團隊內的溝通順暢（而不是只透過文件溝通）
可用的軟體：
每一個迭代結束後，基本上都能產出一份能上線的產品
（雖然可能不完整，但是是能上線的）
與客戶合作：
每次迭代的 planning meeting 都能即時的與客服討論產品當前最重要的市場價值，決定目前要先做的項目
回應變化：
由於每一次迭代的週期很短(2~4 週)，所以市場/客戶的需求改變，都能夠盡可能地在 2~4 週內進行反應，而不需要像 Waterfall 一樣從頭進行完整的計畫/設計/執行/驗收冗長的開發週期

最後，這邊可能也要提醒一下

Scrum 聽起來雖然很吸引人，感覺也是好處多多。但是其實並不是所有的產業/產品/團隊特性都適合

或是說也不是一套方法就能夠完美適用於所有的團隊，或多或少都需要因為產品/團隊特性去做調整與修正，才能達到最大的效益。

一昧的盲目追求或是盲從的導入一些似懂非懂的流程與 activity，很多時候只是會讓團隊更沒效率。

這部分會在第三篇， Scrum/Sprint 的變形跑法的時候討論這部分。