敏捷開發模式下如何快速提升產品質量

隨着敏捷開發模式逐漸走入大衆視野,它開始逐步取代了傳統的瀑布式開發模式,被越來越多的研發項目團隊採用。敏捷開發採用快速迭代,快速發佈可用版本的方法,持續輸出、持續改進。不同於傳統的軟件開發模式,敏捷開發模式有着自己鮮明的價值和方法。 但即使實踐了敏捷,我們可能還會發現,Bug並沒有消失。

 

 

面對這些Bug的出現,團隊成員常常會產生這樣的疑惑:

 

 

  • 爲什麼明明進行了很多輪的測試,但軟件正式上線還是會出現很多Bug?

  • 爲什麼這麼明顯的Bug,上線之前就沒有測試出來?

  • 這些Bug,是不是因爲測試人員工作不到位造成的?

 

 

但實際上,測試人員並不能決定軟件質量的好壞。尤其在團隊選擇敏捷開發模式下,敏捷測試部分也同以往的軟件測試流程有所不同。這對測試人員提出了新的要求,帶來了新的挑戰。那麼如何平衡敏捷的快速迭代開發和解決Bug的矛盾呢?

 

 

一、爲團隊設立專職QA

 

 

敏捷團隊中的敏捷測試人員通常被稱爲質量分析師、SET、測試工程師、QA Lead,在敏捷團隊,大多數人也會把QA當作一個獨立的角色使之與其他團隊成員區分開來。那麼QA之間又有什麼不同呢?通常QA可以分爲三類:業務側、技術側、DevOps側,這三者形成了QA的三個維度。敏捷團隊中的QA可能具備其中的一個或者是這三類中所有的技能。

 

 

大多數人也會把QA當作一個獨立的角色使之與其他團隊成員區分開來。我認爲這是一個過時的概念。QA和開發人員的區別在於思維方式的不同。

業務側QA:他們幫助團隊更清晰地瞭解整個項目的業務問題。通過 QA把客戶需求轉化爲驗收測試用例,幫助沒有技術背景的客戶和沒有業務視角的程序員打破維度不同的職業壁壘。在用戶故事開始之前,敏捷團隊QA需要和程序員一起結對討論用戶需求,幫助團隊瞭解更多的業務信息。在此期間,他們會督促軟件開發工程師來寫驗收測試,以確保用戶故事能夠及時被測試。

技術側QA:通常在敏捷團隊中,技術側QA都需要有過硬的專業技術,他們甚至和程序員沒有任何技術上的差距。他們可以利用豐富的自動化測試知識實現TDD,協助團隊爲項目選擇合適的測試框架,爲團隊提供一個良好的測試策略,確保產品質量。

DevOps側QA:在敏捷團隊中,DevOps側QA需要根據迭代節奏和持續交付的原則,幫助團隊構建持續集成的測試流水線,以便每次出現問題後都能及時得到反饋並解決。幫助團隊以良好的狀態高質量地完成持續交付。DevOps方向的QA會通過設置一些腳本來幫助團隊成員能夠更方便地在本地執行測試,例如代碼掃描、單元測試、組件測試和功能測試,並推進團隊實現自動化測試的開發與執行。

這三類QA的共同目標,都在於幫助團隊在敏捷開發的每個迭代週期都能夠更加註重交付給客戶的有效價值,並且確保交付給客戶的產品質量。敏捷團隊中的QA會扮演多種角色,但是他們最終的目的都是爲了幫助團隊能夠實現更快更好的交付業務價值。

 

 

二、構建質量驅動型團隊

 

 

除了在敏捷團隊中加入QA,把握三大不同的業務方向,在敏捷過程中,有效的項目監管和控制是至關重要的。而軟件的質量也取決於每一個團隊成員,通過團隊間的充分合作,要做到團隊整體對質量負責。

 

 

1、確保信息透明

 

 

需要讓團隊成員知曉團隊的共同目標,每次交付產品的服務對象和用戶需求和質量目標是什麼。包括短期目標和長期目標,包括業務動態、發展戰略、用戶反饋、工作中心、持續改進的狀態、項目進度、團隊壓力等各個方面,信息透明能夠打破團隊成員間的業務邊界,更好地融入團隊,彼此協作,這是一個敏捷團隊健康與否的重要標誌之一。

 

 

2、建立及時反饋機制

 

 

在敏捷團隊中,軟件質量的基礎在於團隊是否能夠真正實現持續測試、持續交付、持續集成、及時反饋。這就需要團隊建立一個健康向上的合作機制,並不斷優化反饋渠道,一個良好和諧的反饋機制可以促進團隊的健康發展,有助於構建質量驅動型團隊。

 

 

3、認真對待Sprint回顧會議

 

 

Sprint回顧會議是敏捷軟件開發中非常重要的一環,但有些團隊的回顧會議流於形式,並沒有帶來什麼效果。Sprint回顧會議是團隊檢視自身並創建下一個Sprint的機會。Sprint回顧會議的目的在於:

 

 

  • 回顧前一個Sprint中的情況;

  • 找出並加以排序做得好的和潛在需要改進的主要方面;

  • Scrum Master制定改進團隊工作方式的計劃。

 

 

在Sprint回顧會議中,最需要保持開放的氛圍,團隊成員彼此信任,並樂於接受新的想法、觀念,最終形成一個質量驅動的高效率團隊。

 

 

4、打造全員學習的團隊氛圍

 

 

敏捷方法論並不能取代生產力,不同技術水平的開發人員,最終交付的軟件質量是不同的,因爲我們沒有辦法讓開發人員完成他能力範圍之外的工作。敏捷開發僅僅是一種開發模式,它不是銀彈,敏捷不能解決問題,只能讓問題暴露的更早。如果團隊不能解決技術問題。就不能完成持續的高質量交付。因此,構建學習型團隊,讓團隊成員養成不斷學習的習慣。這樣能夠幫助團隊從根本上提升研發水平,降低開發成本、提高開發效率並提升產品質量。

項目團隊整體對軟件質量負責是敏捷開發的基本原則,但要真正做到這點,並非易事。需要我們在研發過程中,明確總體的質量目標,並且確保團隊所有成員理解清楚各自需要爲哪部分的質量負責,在研發項目的全生命週期,需要引入專業的QA人員來站在更高維度對整體質量做把控,需要多職能角色的合作,取長補短,能力互補。同時也要注重團隊建設,組建學習型的健康團隊。

 

 

 
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章