因為專題需要而用到了scrum敏捷式開發

scrum其實跟很多公司常用的瀑布式開發有很大的差異，最大的差異應該就是少了很多的文件製作，這其實就省了不少時間，雖然各有優缺點就是。之前寫過像是軟體規格書，光寫這個規格書就花了好幾天的時間 拿來換算成寫code的時間都可以在多寫幾個功能出來了。

scrum的角色大致上分成三種（來自wiki)

1. ‘Scrum Master’ 是Scrum教練和團隊帶頭人，確保團隊合理的運作Scrum，並幫助團隊移除實施中的障礙；
2. 產品負責人（Product Owner），確定產品的方向和願景，定義產品發布的內容、優先順序及交付時間，為產品ROI負責；
3. 開發團隊（Team），一個跨職能的小團隊，人數3-9人，團隊擁有交付可用軟體需要的各種技能。

第一個scrum master 就有點類似領導者leader的角色，來管理整個團隊。

而product Owner角色就像是客戶，要很清楚的知道這個產品做好出來要有什麼樣的功能或是使用方式等等（假設這個專案就是接客戶的by case的 那這角色就真的是客戶）

而第三個team就很簡單 就是所有人拉

scrum開發很重視的就是速度，他不像一般開發要一開始就把所有的東西規格書文件都寫好才開始動工，scrum有點類似且戰且走的方式，每一個週期開會就決定接下來我們要幹嘛，然後透過這種方式慢慢的勾勒出產品的形狀出來，所以scrum會議都要求不要太長，因為也沒這麼多東西值得討論。開會就只是討論說接下來的一次週期(可能3 5天之類的)每個人打算要做甚麼工作，或是你上次沒完成的遇到了甚麼問題需要幫忙，然後就可以畫burn down chart了。

燃盡圖（burn down chart）是一個公開展示的圖表，顯示當前衝刺中未完成的任務數目，或在衝刺訂單上未完成的訂單項的數目。不要把燃盡圖與掙值圖相混淆。A burn down chart could be flat for most of the period covered by a sprint and yet the project could still be on schedule.

下圖就是我們的burn down chart

 

就一直反覆週期直到結束為止，scrum最著名的就是用便利貼來標示 TODO  Doing 跟done 就像是這篇文章一開始的那張圖一樣，而便利貼上面的數字是代表這項工作(task)要花多久完成，單位可能是天、小時之類的都可以，不過盡量不要太長，太長就應該再把它拆得更細一點。

而其實我們專案測試過一次scrum，發現其實有些應該要注意的事項就是scrum其實比較適合整個team的實力都差不多的時候來用似乎會比較有效XD 因為透過圖表大家可以很清楚的知道別人在做甚麼且做了多少了。所以實力要是差太多的話其實會給弱的人造成一個很大的壓力感覺都沒啥在做事情。且我個人認為其實SCRUM開發用在開發新產品上好像還是有他的弱點在的感覺，畢竟是且戰且走的方式，我覺得多多少少還是要定一些規格文件出來會比較好一點，畢竟product owner有時候會是客戶有時候不是，規格通常都是owner在講的。

不過這邊其實我們當時執行scrum最成功的地方是在產品快完成時最後debug跟整合時候，只有有人發現bug就直接丟上去，不用一直找人開會討論問說有沒有人要修。只要有人有空就可以自己去todo拉喜歡的下來做。這樣可以很快速的知道有哪些問題還沒處理，且也不會跟別人修到相同的bug。

我們後來不是用便利貼在跑，那實在太號工了，我們後來在trello這網站上跑scrum就很方便，且我們玩比較刺激就是兩小時為一週期的scrum持續48小時。所以你晚上要是睡太多或是手腳太慢，就會看到早上起床莫名的被ASSIGN了一大堆工作在那邊等你完成。

因為跑這兩小時周期的scrum 有讓我們後來整合階段快速超多的。下面就是我們兩小時周期的結圖 我改天再傳比較完整的 這份好像有點怪怪的..