前言
網際網路時代，產品迭代速度快，傳統的瀑布流開發模型已經無法滿足產品快速開發的需求，敏捷開發的思想應運而生。
考拉技術團隊在CEO的大力推行下，一直沿用scrum開發模型，保證產品每週一次的迭代。今天我們先來入個門，瞭解下scrum模型的基本內容。
一、傳統開發模型
在開始介紹scrum模型之前，我們先來回顧下之前軟體開發模式。
起初，軟體開發最基礎的模型叫做瀑布模型（Waterfall Model）。瀑布模型式是最典型的預見性的方法，嚴格遵循預先計劃的需求分析、設計、編碼、整合、測試、維護的步驟順序進行。瀑布模型下的產品開發各部分都是獨立分開，各不干擾，一般適應於大型軟體。
但瀑布模型也存在不能在開發過程更改需求、無法趕上變化迅速的市場，容易造成資源浪費等缺點。
在這個基礎上，引入敏捷開發模型對於小開發團隊來說是比較合適的。
二、scrum的簡介
敏捷開發是一種以人為核心、迭代、循序漸進的開發方法。
Scrum作為敏捷的方法之一，用不斷迭代的框架方法來管理複雜產品的開發。
原詞來自於橄欖球中“帶球過人”。在橄欖球比賽的每次衝刺前，都將有一個計劃安排的過程，但衝刺開始後則由隊員在原計劃的基礎上隨機應發。
三、scrum的優勢
靈活性、適應需求變化、更適合團隊比較小的情況、每一個迭代均有產出，容易學習。
Why choose Scrum？ 原因如下 （敏捷宣言）：
-
個體互動重於過程和工具；
-
可用的軟體重於完備的文件；
-
客戶協作重於合同談判；
-
響應變化重於遵循計劃。
概況地說，它適用於快速變化的市場，可以根據客戶不斷更換的需求，調整產品的方向，按時交付客戶想要的產品。這在今天競爭激烈的市場來說，優先於競爭對手交付一個不完美但能不斷改進優化的產品是非常重要的。
四、scrum中3個關鍵角色
scrum團隊的成員由開發人員、測試人員以及其他幫助研發的人組成：
核心團隊：
- Scrum Master——專案負責人，幫助團隊完成工作，組織日常會議和保障其他工作展開；
- Team——開發人員，經常扮演多種角色，開發人員兼職測試，測試人員搬磚文案；
- Product Owner——產品負責人，確定產品特性，提出產品亮點。
scrum團隊的規模不宜過大，一般在3-9人為佳。
五、scrum流程
- 建立Product Backlog
記錄已知需求並調整。
在整個開發過程中，Product Owner要不斷的把已知的所有需求記錄到這裡面來，任何時間或步驟中產生的新需求都需要進行更新。scrum團隊總是先開發對需求方具有較高價值的需求。
需求方為了能更加清晰表達需求，可用user story描述需求。user story是從使用者/需求方的角度對產品的某個功能進行的簡短描述，具體格式如下：
一個story的大小以及複雜度應以能在一個sprint中完成為宜。如果user story橫跨了幾個sprint，那個就需要進行分解成若干個task（任務），每個task的時間最好不要超過8小時. - Sprint Planning
在scrum中，sprint定義為產品的迭代週期。一般是1~6周。在一個sprint開始前，定義本次sprint要討論的backlo為sprint backlog. 它是團隊在sprint要完成的任務。
為了確定團隊內部任務以及具體分工，需要進行sprint planing，由Scrum Master決定需求，然後將任務拆分，估時，並完成分配。當任務分配之後，要記錄到sprint backlog中。在sprint中，scrum團隊從backlog中挑選最高優先順序的需求進行開發。 在每次例會之後，由Scrum Master更新backlog。 - Daily Scrum
也稱為每日站會，一般不超過15min。參會的成員由核心團隊的成員組成，每個人只說3個問題：
今天完成了哪些任務？ 明天的任務是什麼？ 今天遇到了哪些問題？
每日站會的主要作用是update整個團隊的進度，會上成員提出的問題不進行詳細討論，會議後master對這些問題進行解決。 - Sprint Review
總結sprint的會議，在會議上會將本次sprint的新功能展示出來，並收取反饋，為下一次新的需求做準備。 - Retrospective Meeting
反思sprint的會議，目的是回顧sprint過程組內成員的表現。為了讓成員能夠更加真實反思自己的工作情況，安全的討論環境是必須的。在回顧會議上，主要做這三件事情：
good--如果我們可以重做同一個sprint，哪些做法是可以保留的？
could have done better--如果我們可以重做同一個sprint，哪些做法需要改變？
improvement--如何改進的具體想法？
六、scrum工具
-
任務板
任務板用視覺化方式展示，將一個sprint分為四個階段：
Product Backlog：按照需求的優先順序，將團隊在sprint中要進行的backlog放在該列；
To Do ：將當前sprint需要完成的任務放入該列；
In Progress：當團隊開發進行某個任務之後，便將任務對應的卡片放到該列中。如果該任務在該列中所處時間超過1天，則應該將任務拆分為更小的部分，並將新任務放到該列中，移出原有的任務。若一個新任務因某個障礙無法完成，master就會將其標記為障礙，用特定紅點標記。
Done：完成一個任務之後，便將任務放到該列。繼續開始下一個任務。
看板（kanban）開發方法作為一種敏捷方式，在改善協助，優化管理、提高交付速度、質量以及靈活性方面有顯著作用。下篇文章會著重講述kanban開發模型在技術團隊中的應用。
-
燃盡圖
sprint的開發時間需要團隊跟進，燃盡圖可以幫助團隊評估sprint開發任務的時間以及效率。
燃盡圖是以圖表展示隨著時間的減少工作量的完成情況。燃盡圖的橫軸表示整個Sprint 的總時間，縱軸表示 Sprint 中所有的任務，其單位可以是小時，人天等。 為了更好表示任務開發情況，團隊每天要更新燃盡圖，並且要根據燃盡圖中任務的完成情況對任務進行調整：如果燃盡圖一直是上升狀態，或當 Sprint 進行一段時間之後，Sprint 燃盡圖上的Y值仍然與 Sprint 剛開始時相差無幾，就說明這個 Sprint 中的 Story 過多，要拿掉一些 Story 以保證這個 Sprint 能順利完成。 如果Sprint 燃盡圖下降得很快，例如 Sprint 剛過半時Y值已經接近0了，則說明這個 Sprint 分配的任務太少，還要多加一些任務進來。
為了方便管理燃盡圖，在設計燃盡圖的時候，從簡出發。
-
Jira
作為敏捷團隊用來管理開發專案流程以及進展的工具，Jira提供了豐富的功能，方便開發團隊對開發中的問題進行記錄跟蹤，並通過視覺化圖表展現出來。當團隊進行一次sprint時，Jira會幫你記錄任務的完成狀態，團隊的分工情況以及完成情況。，支援將任務簡化，把開發時間分配到每個具體任務中，在規定的時間內完成任務。這與敏捷開發的思想不謀而合。
七、結束語
儘管scrum很美好很輕量，但是這種模型不一定適用於所有的企業。為了保持產品的快速優化，團隊在進行敏捷開發模式的同時，還應該注重敏捷開發過程的不斷優化。敏捷的出發點是為了提高工作效率，以人為本。沒有誰的敏捷之路是一帆風順，不斷優化，小步快跑的方式才是敏捷可行的路。