敏捷開發實踐之Scrum方法運用

摘要 :目前軟體開發除了強調產品質量,同時對產品能夠快速釋出並且迅速適應市場變化的要求也日益強烈。為適應這種開發環境和市場需求,傳統的軟體開發模式已被敏捷開發模式所替代。本文介紹敏捷軟體開發中的Scrum方法,並結合實際問題,分析Scrum方法在實踐中的運用。

 

關鍵詞 :敏捷開發;Scrum

 

產品質量和開發效率一直是軟體產品開發的關鍵。隨著科技和經濟的發展,軟體的市場環境和使用者需求不斷髮生變化,這對軟體產品的快速釋出提出很高的要求。傳統的瀑布模型、螺旋模型、原型模型等已不能適應越來越複雜和不斷變化的需求和市場環境。近年來,敏捷軟體開發逐步流行,並被廣泛認識、研究和使用。敏捷開發具有應對快速變化的市場和需求的能力,因此,它被越來越多的公司企業採用。用於敏捷軟體開發的方法有很多,其中Scrum方法是被廣泛應用的方法之一。

 

1.Scrum簡介

 

Scrum是一個增量的、迭代的開發過程,名稱來自英式橄欖球的爭球。Scrum的整個開發週期包括若干個小的迭代週期,每個小的迭代週期稱為一個衝刺(SPrint),每個衝刺的長度一般為2到4周。在Scrum中,使用產品訂單來管理產品或專案的需求,產品訂單是一個按照商業價值排序的需求列表,列表條目的體現形式通常為使用者故事。開發團隊總是先開發的是對客戶具有較高價值的需求。在每個衝刺中,開發團隊從產品訂單中挑選最有價值的需求進行開發。衝刺中挑選的需求經過計劃會議上的分析、討論和估算得到一個衝刺的任務列表,我們稱它為衝刺訂單。在每個迭代結束時,開發團隊將交付潛在可交付的產品增量。

 

Scrum的主要角色有:產品負責人、Scrum主管、開發團隊。Scrum的會議包括:計劃會議、評審會議、回顧會議、每日站立例會。Scrum的文件有:產品訂單、衝刺訂單、燃盡圖。Scrum方法的運作過程就是產品負責人、Scrum主管、開發團隊依據Scrum必需的文件,透過Scrum定義的會議方式展開的一輪一輪產品開發的迭代過程。

 

2.Scrum方法的實際運用

 

Scrum方法給出的是一個框架,各角色人員如何根據這個框架來實踐Scrum,尤其如何利用好每日站立例會、評審會議、回顧會議,是影響敏捷開發效果的關鍵因素。在Scrum方法的實際運用中,會遇到或多或少的一些具體問題。筆者根據以往自身敏捷開發專案的經驗,對這些問題作簡要的分析,並給出有效的解決辦法。

 

2.1每日站立例會

 

每日站立例會是Scrum主管和開發團隊成員必須參加的會議。它是除了面對面溝通之外,開發團隊成員的另一個有效的溝通交流方式。Scrum倡導的每日站立例會平均時間不超過巧分鐘,開發團隊的每個成員需要向Scrum主管回答三個問題:今天完成了哪些工作?明天打算做什麼?完成目標是否存在什麼障礙?

 

每日站立例會需要Scrum主管的有效組織。每日站立例會最常見的問題是,團隊成員之間陷入了具體技術問題的討論中,導致會議時間嚴重拖長,影響了會議的效率。還有一種情況是,一個成員彙報所遇到的障礙的時候,其他成員沒有認真聆聽,對一些共有的障礙或者有依賴性的問題沒有引起足夠的重視,導致大家都卡在同樣的問題裡,影響了開發的進度。

 

為使每日站立例會更加有效率,開發團隊的每個成員需要控制好自己的發言時間,一般在3分鐘左右。發言突出要點,簡明扼要,不要詳細論述具體技術問題。一旦發現團隊成員開始討論具體技術問題,Scrum主管應及時給與提醒,這樣可以有效地控制會議時間。為了使每個成員都清楚目前專案的狀況,尤其對可能影響完成目標的障礙有所瞭解,Scrum主管在每次例會結束之前把記錄下來的障礙向開發團隊總結一遍,讓大家心中有數,確保第二天的開發工作不受廣泛影響。這樣做也有助於Scrum主管在接下來的工作中有效地為團隊去除這些障礙。

 

2.2評審會議

 

在每一個衝刺的尾聲需要進行一次評審會議,產品負責人、Scrum主管、開發團隊必須參加評審會議。評審會議的目的是讓開發團隊向產品負責人展示在該衝刺完成的功能,回答與會人員對展示的疑問並記錄所期望的修改。評審會議程式一般不超過4個小時,開發團隊準備的評審展示內容一般不超過1個小時。評審會議包含階段性驗收的意味,如何才能在有限的展示時間內,得到產品負責人的積極認可和有效反饋,是在會議準備階段和會議進行過程中必須注意的問題。

 

在會議準備階段,開發團隊應該按照本次衝刺的衝刺訂單,組織產品功能的展示點,形成清晰簡要的PPT文件。在會議現場最好能進行線上實際的功能展示,所以會議前開發團隊要準備好工作站和裝置等。同時開發團隊還需要把能展現產品功能效果的圖、表、日誌等資料提前儲存下來,以防突發情況導致現場展示失敗時無內容可展示。在會議開始時,Scrum主管和開發團隊需要確保所有人員對產品和該衝刺的目標有所瞭解,如果有人對此不清楚,則先用幾分鐘進行描述。然後,開發團隊按照準備好的PPT文件,逐個介紹這次衝刺實現的結果,並且展示其功能效果。在展示的過程中,開發團隊應該把重點放在“我們做了什麼”,而不是“我們怎麼做的”。這樣可以讓產品負責人對產品目前的功能狀況有直觀的瞭解,而不是陷入到技術細節之中。如果產品負責人想改變某些功能,Scrum主管把這個需求新增到產品訂單中,留待以後的衝刺解決。

 

2.3回顧會議

 

回顧會議是在每個衝刺結束之後進行的,通常在評審會議後進行,它透過總結本次衝刺的實踐經驗,為團隊指出日後改進的方面,避免團隊重犯相同的錯誤。Scrum主管、開發團隊必須參加回顧會議。回顧會議是Scrum方法中很重要的會議,利用好回顧會議,可以有效地提高團隊的生產力。回顧會議需要鼓勵團隊成員積極參與,集思廣益,否則,這個會議就會流於形式,達不到預期的效果。

 

在實際應用中,回顧會議的形式可以採取頭腦風暴法模式。會議開始時,Scrum主管先給團隊成員總結上次衝刺的回顧會議確定的改進內容的執行結果。然後,Scrum主管給每個成員發一張即時貼便籤,讓他們自己思考,回顧本次衝刺中團隊做得好和做得不好且需要改進的地方，各選三點意見寫在便籤上,然後把便籤貼在白板上。等所有成員都把寫好的便籤貼在白板上後,Scrum主管和團隊成員一起逐條討論便籤上的意見,充分理解團隊成員的想法。討論過程中,Scrum主管對相似的意見進行合併,對有依賴相關性的問題進行梳理。回顧會議結束後,Scrum主管就可以得到本次衝刺做得好的地方和需要改進的內容。那些需要改進的內容供下次衝刺的回顧會議進行效果跟蹤。

 

3.小結

 

Scrum方法是敏捷開發的一個框架,它並沒有規定具體的實踐方法。Scrum提倡靈活,遵循敏捷開發以人為本的原則,這需要軟體專案管理人員根據企業文化、管理模式、開發團隊的經驗等因素,選擇合適的方案。 下面給大家推薦一款備受好評的敏捷開發軟體  CORNERSTONE  提供了包括任務/需求/測試管理、迭代規劃、缺陷追蹤、報表統計、團隊協作 、WIKI、共享檔案和日曆等功能模組 ,20人以下團隊可免費使用,點選即可免費註冊 CORNERSTONE 。