今年年初加入了一個新創團隊後，第一次接觸到了敏捷開發Scrum，開始被這種神奇的開發模式吸引到，除了能夠非常清楚的自己的工作規劃外，也能夠知道其他人所要做的事情以及整個團隊的進度，讓資訊透明化外，也能夠提醒自己進度上是不是有落後，以此來提昇整個團隊的效率。

也因此，為了能夠更加了解Scrum的觀念外，也希望能把這種模式帶到自己的生活中，就寫了這篇自己讀完這本「敏捷與Scrum軟體開發速成」的想法以及自己在團隊裡參與Scrum的心得。

什麼是敏捷開發？

提到敏捷開發，首先就要提到他是為什麼而誕生的，這就不得不提到瀑布式開發法

瀑布方法

顧名思義，整個開發流程是線型順序流程的，就像是瀑布一樣，從需求搜集、設計、編寫程式，到最後的測試，每個步驟都需要依序進行。

那這個開發流程到底有什麼問題呢，雖然瀑布開發能夠更容易的規劃整個開發流程、時間安排，但是對於不確定性高的軟體開發而言，這顯然不會是一個好的方法。

原因是瀑布開發過於完美話，他假設了每個步驟結束後，不會又有新的東西要改，但是實際上呢，可能客戶今天說A功能，下星期又發現B功能比較好，當上一個步驟有變動的時候，不就又要重新跑一次整個開發流程。

因此，我們需要一種新的開發流程，可以彈性的更改開發流程，也能夠即時的與客戶需求保持同步，避免掉一些不必要的錯誤發生。

什麼是Scrum？

那回到標題，Scrum簡單來說是一種迭代式增量軟體開發的過程所套用的框架，我自己的理解有點像團隊運行的一個規格書或是框架，大家必須要依照裡面的規則走。而Scrum裡面的規則其實相當彈性，只要把握幾個核心概念，就可以使用Scrum。

將產品切分

首先要解決的就是現行順序的開發流程所導致的問題，在 Scrum 中，會把工作時間切成一個一個小區塊，稱之為一個 sprint，一個 sprint 大約是2個星期左右，在每個 sprint 開始前，團隊必須要先定義出這個 sprint 需要完成的哪些東西，而每一樣東西可能只是產品的一小部分。

藉由這樣，我們透過每個 sprint 完成產品的一部分，並且測試，當有發生問題時，需要改的也就只是這個一小部分而已，而不會到整個產品都設計完實作完了才發現有問題。

此外，這樣的方式也有助於跟客戶保持同步，藉由每個 sprint 的成品 demo 個客戶看，可以更佳提早的知道這些功能是不是客戶真的需要的，避免整個開發完了才發現重點錯了。

例行站會

為了保持整個團隊的共同以及資訊透明化，在 sprint 中，每天都會需要一個10分鐘的會議，主要是跟團隊說你昨天做了什麼，今天要做什麼，以及有沒有碰到什麼問題，這樣不僅能讓團隊知道目前的進度外，也可以避免到了要 demo 的時候才發現有東西卡住了。會叫站會的原因也就是開會時大家都要站著，以此避免會議過長。

Sprint 預備會議

在 sprint 中，planning 會議是最重要的，planning 做的就是在每一次的 sprint 開始前，團隊需要規劃在這兩個禮拜應該要完成的目標，而為了完成目標，會將目標分成一個一個的任務，並且透過費氏數列的方式來安排每一項任務的大小，這邊的大小指的是完成這份任務所需要花的時間或是不確定性，當一個任務的大小超過一定程度的時候，就必須要再將這個任務切分。而每個人都會分配到大小總量差不多的任務，並且用這個來估計工時。

Sprint 回顧會議

這個會議主要是在 sprint 結束時，團隊會根據這個 sprint 的完成度或是一些團隊意見的討論，並且再下個 sprint 開始時進行改善，而 scrum 中有一種圖叫做燃盡圖，是用來顯示在這個 sprint 中，團隊成員的時間花費的線型圖，可以用來評估這個 sprint 是不是順暢的在進行。

結論

以上就是我所理解的 scrum 的一些基礎原則，其實還有很多細節其實是沒有提到的，像是怎麼好的評估任務點數，以及對工程來說的一些開發原則，可能等有空再來寫一篇 scrum 的進階內容。

我自己是很喜歡 scrum 中所強調的一句話，「feature是變動的，工時是固定的」，也就是在每個 sprint 中，每個人所分配到的任務點數是固定的，如果一個任務在評估時低估了，那在 sprint 中，則會是將優先級比較低的任務時間移過來，而不是增加工時來完成所有任務。這種概念也讓我在日常生活中可以更好的安排時間。