AI考拉技術分享--Scrum入門

前言

互聯網時代，產品迭代速度快，傳統的瀑布流開發模型已經沒法知足產品快速開發的需求，敏捷開發的思想應運而生。
考拉技術團隊在CEO的大力推行下，一直沿用scrum開發模型，保證產品每週一次的迭代。今天咱們先來入個門，瞭解下scrum模型的基本內容。

1、傳統開發模型

在開始介紹scrum模型以前，咱們先來回顧下以前軟件開發模式。
起初，軟件開發最基礎的模型叫作瀑布模型（Waterfall Model）。瀑布模型式是最典型的預見性的方法，嚴格遵循預先計劃的需求分析、設計、編碼、集成、測試、維護的步驟順序進行。瀑布模型下的產品開發各部分都是獨立分開，各不干擾，通常適應於大型軟件。 但瀑布模型也存在不能在開發過程更改需求、沒法遇上變化迅速的市場，容易形成資源浪費等缺點。
在這個基礎上，引入敏捷開發模型對於小開發團隊來講是比較合適的。

2、scrum的簡介

敏捷開發是一種以人爲核心、迭代、按部就班的開發方法。

Scrum做爲敏捷的方法之一，用不斷迭代的框架方法來管理複雜產品的開發。

原詞來自於橄欖球中「帶球過人」。在橄欖球比賽的每次衝刺前，都將有一個計劃安排的過程，但衝刺開始後則由隊員在原計劃的基礎上隨機應發。

3、scrum的優點

靈活性、適應需求變化、更適合團隊比較小的狀況、每個迭代均有產出，容易學習。
Why choose Scrum？ 緣由以下 （敏捷宣言）：

1. 個體交互重於過程和工具；

2. 可用的軟件重於完備的文檔；

3. 客戶協做重於合同談判；

4. 響應變化重於遵循計劃。

概況地說，它適用於快速變化的市場，能夠根據客戶不斷更換的需求，調整產品的方向，按時交付客戶想要的產品。這在今天競爭激烈的市場來講，優先於競爭對手交付一個不完美但能不斷改進優化的產品是很是重要的。

4、scrum中3個關鍵角色

scrum團隊的成員由開發人員、測試人員以及其餘幫助研發的人組成：
核心團隊：

• Scrum Master——項目負責人，幫助團隊完成工做，組織平常會議和保障其餘工做展開；
• Team——開發人員，常常扮演多種角色，開發人員兼職測試，測試人員搬磚文案；
• Product Owner——產品負責人，肯定產品特性，提出產品亮點。
  scrum團隊的規模不宜過大，通常在3-9人爲佳。

  

5、scrum流程

1. 創建Product Backlog
   記錄已知需求並調整。
   在整個開發過程當中，Product Owner要不斷的把已知的全部需求記錄到這裏面來，任什麼時候間或步驟中產生的新需求都須要進行更新。scrum團隊老是先開發對需求方具備較高價值的需求。
   需求方爲了能更加清晰表達需求，可用user story描述需求。user story是從用戶/需求方的角度對產品的某個功能進行的簡短描述，具體格式以下：
   

   

   
   一個story的大小以及複雜度應以能在一個sprint中完成爲宜。若是user story橫跨了幾個sprint，那個就須要進行分解成若干個task（任務），每一個task的時間最好不要超過8小時.
2. Sprint Planning
   在scrum中，sprint定義爲產品的迭代週期。通常是1~6周。在一個sprint開始前，定義本次sprint要討論的backlo爲sprint backlog. 它是團隊在sprint要完成的任務。
   爲了肯定團隊內部任務以及具體分工，須要進行sprint planing，由Scrum Master決定需求，而後將任務拆分，估時，並完成分配。當任務分配以後，要記錄到sprint backlog中。在sprint中，scrum團隊從backlog中挑選最高優先級的需求進行開發。 在每次例會以後，由Scrum Master更新backlog。
3. Daily Scrum
   也稱爲每日站會，通常不超過15min。參會的成員由核心團隊的成員組成，每一個人只說3個問題：
   今天完成了哪些任務？ 明天的任務是什麼？ 今天遇到了哪些問題？
   每日站會的主要做用是update整個團隊的進度，會上成員提出的問題不進行詳細討論，會議後master對這些問題進行解決。
4. Sprint Review
   總結sprint的會議，在會議上會將本次sprint的新功能展現出來，並收取反饋，爲下一次新的需求作準備。
5. Retrospective Meeting
   反思sprint的會議，目的是回顧sprint過程組內成員的表現。爲了讓成員可以更加真實反思本身的工做狀況，安全的討論環境是必須的。在回顧會議上，主要作這三件事情：
   good--若是咱們能夠重作同一個sprint，哪些作法是能夠保留的？
   could have done better--若是咱們能夠重作同一個sprint，哪些作法須要改變？
   improvement--如何改進的具體想法？

6、scrum工具

1. 任務板
   任務板用可視化方式展現，將一個sprint分爲四個階段：
   Product Backlog：按照需求的優先級，將團隊在sprint中要進行的backlog放在該列；
   To Do ：將當前sprint須要完成的任務放入該列；
   In Progress：當團隊開發進行某個任務以後，便將任務對應的卡片放到該列中。若是該任務在該列中所處時間超過1天，則應該將任務拆分爲更小的部分，並將新任務放到該列中，移出原有的任務。若一個新任務因某個障礙沒法完成，master就會將其標記爲障礙，用特定紅點標記。
   Done：完成一個任務以後，便將任務放到該列。繼續開始下一個任務。
   看板（kanban）開發方法做爲一種敏捷方式，在改善協助，優化管理、提升交付速度、質量以及靈活性方面有顯著做用。下篇文章會着重講述kanban開發模型在技術團隊中的應用。
   

   

2. 燃盡圖
   sprint的開發時間須要團隊跟進，燃盡圖能夠幫助團隊評估sprint開發任務的時間以及效率。
   燃盡圖是以圖表展現隨着時間的減小工做量的完成狀況。燃盡圖的橫軸表示整個Sprint 的總時間，縱軸表示 Sprint 中全部的任務，其單位能夠是小時，人天等。 爲了更好表示任務開發狀況，團隊天天要更新燃盡圖，而且要根據燃盡圖中任務的完成狀況對任務進行調整：若是燃盡圖一直是上升狀態，或當 Sprint 進行一段時間以後，Sprint 燃盡圖上的Y值仍然與 Sprint 剛開始時相差無幾，就說明這個 Sprint 中的 Story 過多，要拿掉一些 Story 以保證這個 Sprint 能順利完成。 若是Sprint 燃盡圖降低得很快，例如 Sprint 剛過半時Y值已經接近0了，則說明這個 Sprint 分配的任務太少，還要多加一些任務進來。
   爲了方便管理燃盡圖，在設計燃盡圖的時候，從簡出發。
   

   

3. Jira
   做爲敏捷團隊用來管理開發項目流程以及進展的工具，Jira提供了豐富的功能，方便開發團隊對開發中的問題進行記錄跟蹤，並經過可視化圖表展示出來。當團隊進行一次sprint時，Jira會幫你記錄任務的完成狀態，團隊的分工狀況以及完成狀況。，支持將任務簡化，把開發時間分配到每一個具體任務中，在規定的時間內完成任務。這與敏捷開發的思想不謀而合。

7、結束語

儘管scrum很美好很輕量，可是這種模型不必定適用於全部的企業。爲了保持產品的快速優化，團隊在進行敏捷開發模式的同時，還應該注重敏捷開發過程的不斷優化。敏捷的出發點是爲了提升工做效率，以人爲本。沒有誰的敏捷之路是一路順風，不斷優化，小步快跑的方式纔是敏捷可行的路。