敏捷式開發好簡單。什麼是 Scrum ?

 ．先來一個初步的範例：

-講師上臺去授課，並在每次的課堂中得到回饋又納入充實自己，再準備下次的授課。

．初步認識講師實例後，我們來看看 Scrum 的架構。

-專案需求發生，對應內容制定「各人」開發計劃，並每週匯報專案會議

-待完成成品後，展示結果，並重新檢討，承接下一個專案需求。

．接著我們套入專案例子，強化架構認知

-Scrum的特色在透過每一個固定週期的Sprint去和業主(或是PM、老闆..等)，針對現在作的功能作交付驗收的動作，在作出來功能不符合想像(或是需求)可以快速修正，這樣的概念上看似簡單，但與看板最大不同的是Scrum導入了制度、權重以及角色的概念。

接下來會先針對名詞 與 其中參與角色 說明：

1. Development Team(即Dev Team，可以稱作開發團)：也就是主要著手開發的任務團隊，人數可以約6人左右，建議是可以叫一份大PIZZA可以一人分到一片的人數為上限，除了各司其職之外，更要相互支援，是一個生死與共的團隊。



2. Product Owner(PO，類似PM的角色，專職的產品負責人)：產品的重要核心，決定每一次開發權重的角色，也是需要和所有的專案利害關係人(steakholder)斡旋的要角，基本上可以稱作是PM無誤了。



3. ScrumMaster(SM，類似教練的角色)：在Scrum的各流各派中，有人認為她是Team leader的角色，也有人認為他也是PM的角色，但總之他所要專注的事情為維繫Scrum的制度運行，確保團隊在Scrum的範疇裡繼續Run，例如常常會遇到一些老闆不必要的會議或是強加的需求，SM就有責任維繫團隊的規則和產出去進行協調，通常包含了以上三者就是一個Scrum Team了!



4. Steakholder(專案的利害關係人)：可以是你的老闆，也可以是你的業主，通常有能力決定產品走向和需求的人，會出嘴的都可以稱作Steakholder







資料來源：http://www.agilenutshell.com/scrum



5.Sprint：定期產出的週期，1-4週



6.Product > Feature(功能卡) > Task : 這是一種將產品由大到小的拆解，例如我們的產品是要建置一個咖啡店官網，我們可以想像她是張Product大卡片，其中Feature就可以是一個中型的卡片來包含了官網具備的功能，例如產品介紹、分店位置、現上點餐..等等。而Task就是以技術為單為最小的拆解囉，也是我們在跑Scrum裡最重要的視覺化物件，通常Feature的寫法可以透過前面介紹過的User Story來作撰寫會比較恰當。







7.Product Backlog(產品需求清單)：完成產品需要的清單



8.Sprint Backlog(Sprint清單)：每周Sprint要完成的事情，這中間PO要決定完成的先後順序，所以保持頭腦清醒很重要的!



接下來在流程的部分作介紹，每一項專案下來之後PO會先和Steakholder談好了產品和功能的UserStory(kick-off meeting)，也就是有了Feature的UserStory之後，就可以透過Scrum Planning meeting來作切分，主要是挑選在這次的Sprint要完成的項目，並把他切割成Task。



另外最重要的一點是把透過團隊共識，把每一個UserStory切出StoryPoint，點數可以使用天數來作評估比較具體，例如作出線上點餐需要8天，那其中每一個Task如加入購物車、結帳、建立商品清單..等等這些項目，也必須切割出StoryPoint，當然總合不能超過8點。



每一張Task的卡片上都必須記載著人名、點數後，最後把這一次Sprint要開發的Task蒐集貼在ScrumBoard板上，就可以開始進行開發作業囉，建議一張Feature不要超過13點，若是超過表示他還可以在細切。



接下來他的ScrumBoard就比較簡單，只有Undo(待做)，Doing(正在作)和Done(作完)，當從Undo移動到 Doing的時候記得一定要確認卡片上有沒有填寫名字，也就是一定要有人認養才可以移動到Doing，接下來就是每天記錄與扣點的動作，當扣成0表示該功能已經完成，而移動到Done前PO一定也要完成驗收才可以移動。









接下來的流程就是每天透過Daily Scrum Meeting，讓團隊的人來講解昨天作了什麼，今天要作什麼，有沒有遇到什麼困難，並且規定在meeting前，每個人要針對有記載自己名字的卡片(也就是負責的開發功能)去作扣點，例如分店地圖位置功能為八點的話，就代表團隊有共識這功能八天可以開發完成，而負責的人就必須依照自己實際的開發進度來作扣點，最後PO要針對這些總扣點的點數去化作Burndown chart。





如上圖，首先橫軸是這次Sprint的天數，縱軸是點數，假設我們一周擁有五個工作天，團隊有六人，所以一個Sprint如果是3周的話，就會有5x6x3=90點，這時候我們就會有一個比較的基準，若是這一個Sprint切出來的點數為120點，表示120/3(周)在除以5天，就可以知道一天至少要扣掉八點，才有辦法把這些點數燃燒為0(但團隊只有六個人...所以表示這樣有超出負荷的嫌疑，以此類推)，所以透過每天的Meeting，很容易就可以追蹤這次的開發進度是否有落後的趨勢，若每天都忠實記錄開發扣點的狀況的話，可以明顯的看到若是線的走勢漂浮在基準線上方的話，那開發的進度就會有風險產生囉。



另外透過每一次的Sprint結束後，就可以去和Steakholder進行確認，也就是階段階段驗收的方式，來確保開發主軸沒有偏離，並帶給團隊中快速從經驗學習反應和自我管理。



而在每一次Sprint結束前，到下一次Planning meeting前，團隊也必須開啟一次review回顧會議，來檢討這個Sprint的狀況，確保未來不再發生。

參考：

https://progressbar.tw/posts/69