敏捷開發實踐之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。