一、    敏捷開發模式簡介

敏捷是近年來軟體研發領域很火的一個詞，採用敏捷開發模式的研發團隊是越來越多了，尤其是敏捷模式中的Scrum更是佼佼者大行其道，這表明敏捷模式確有其好處，能給企業帶來效率的提升和成本的降低。

讓我們看看大名鼎鼎的敏捷宣言，如下圖所示：

大家對這段敏捷宣言都有自己的理解，我理解的其核心觀點就是敏捷：能夠快速，靈活的對變化做出響應，能夠去掉繁文縟節，做到身輕如燕，專注於目標並在短期內產出成果物。

其實敏捷開發模式的提出和壯大也是被現實所迫。近年來軟體需求變化越來越迅速，如何快速響應這種變化及時推出滿足市場需要的產品是對軟體從業者的巨大考驗，而敏捷開發模式就是一種較好的解決方案，可謂是銀彈。

二、    Scrum簡介

Scrum很多研發團隊都在用了，Scrum是當前最流行的一種敏捷開發模式，原因我認為關鍵是該模式簡單明瞭，給出了具體的實踐方式，可操作性很強。

Scrum由一組迭代週期組成，每個迭代(sprint)為2-4周，在每個迭代中都依次有planning (計劃) , daily standup meeting(每日站會) , review(評審) 和retrospective (回顧)會議組成，由ScrumMaster (Scrum負責人)來召集這些會議，當然由團隊負責人擔任ScrumMaster也是比較常見的；有些團隊也採用成員輪流擔任ScrumMaster的方式，這樣可以增強每個團隊成員的主人翁和責任意識等。

三、    敏捷測試模式

敏捷開發模式大家都耳熟能詳了，但敏捷測試模式還是比較新穎的名詞，不能說是本人的創造，但本人在當初組建測試團隊時就有運用敏捷開發模式的想法，團隊成立後便著手實踐該模式並堅持至今，自認為是取得了良好的效果。

        當然肯定有人會反駁我的觀點，他們認為敏捷開發模式每個迭代都包括設計，開發和測試，無需單獨出來一個敏捷測試模式。這種觀點當然是正確的，但無論什麼模式都要應用到實際工作中去。我所在的公司測試部門是獨立的部門並獨立開展測試工作，不屬於某一具體的開發團隊，也就是說開發團隊並沒有人進行專門的測試工作，在職能架構上研發部和測試部也是並行獨立的。

        在這種情況下，測試團隊應該根據產品計劃合理的開展工作，採用敏捷測試模式就是一種不錯的選擇。

四、    Scrum在測試團隊的具體實踐

下面具體介紹下我所在的團隊的敏捷測試模式實踐。

我們採用的仍是業界流行的Scrum作為具體的敏捷測試模式，一般情況下每兩週一個sprint(衝刺，也就是迭代的意思)，每個迭代由計劃，每日站立，演示和總結共四類會議組成。

        在計劃會議中由ScrumMaster(ScrumMaster負責人，由部門負責人也就是本人兼任)根據產品計劃列出本迭代的backlog (待辦事項，有的地方也稱為User Story既使用者故事)，之後再將每個待辦事項細分為多個任務，每個任務都會指定具體的負責人和預估的花費時間，這個時間以小時為單位，一般最小單位為2小時，最大為16小時。太短的時間會導致任務過多，可通過整合到其他任務的方式處理；太長的時間則導致任務較粗放，難以把控進度情況和出現的問題。每個任務的預估時間不一定準確，這需要ScrumMaster的經驗或者採用團隊每個成員進行估算然後取平均值的做法來設定。需要注意的是：請把這個會議的時間控制在一小時內，經常見到這個會議超長的現象，主要原因是沒有提前計劃，在會議中才開始列出待辦事項，我認為待辦事項在開會前ScrumMaster就應該已經胸有成竹了，在這個會議中只需要把待辦事項具體分解為多個任務即可，甚至於有些待辦事項也提前分解好了，在這個會議中只是讓團隊成員認領任務或者直接分配給團隊成員即可。

        讓團隊成員自己認領任務還是進行分配需要根據團隊的具體情況進行處理，我所在的團隊一般情況下都是由ScrumMaster來分配的，因為自由認領的情況下很可能會出現一些任務大家去爭搶，一些任務沒人願意去認領的尷尬情況。當然分配任務也是根據每個團隊成員的所長和發展方向作為依據的。

       之後每個工作日早上上班一刻鐘後召開每日站會。站會，顧名思義，就是站著開會，這樣會議的時間不會太長，大家也能集中精力，會議一般控制在十分鐘以內。在這個會議中，每個團隊成員分別回答三個問題，這三個問題依次是：

1.上一個工作日做了什麼？

2.今天計劃做什麼？

3.遇到什麼問題或者困難或者說需要什麼幫助？

其他的就不要說了，如果真的需要花較多的時間，就應該另外安排時間進行。

在每日站會中，注意團隊成員是在彼此進行溝通和承諾，以便讓大家都對任務做到心中有數，而不要搞成是向ScrumMaster彙報工作，這兩者是不同的。

在開始實施Scrum的時候，強烈建議準備一個較大的白板和一些即時貼。在這個白板上先劃出4列，這4列的列名分別是：待辦事項，準備開始，進行中和已完成；再劃出橫行，可由團隊成員數加一來確定橫行的數目。在計劃會議中，就可以把確定的任務寫到即時貼中，一個任務用一張即時貼，可用A4紙打印出待辦事項的內容，待辦事項的格式可如下圖所示。

待辦事項的優先順序越高，則應該貼在越靠上的行的待辦事項列中，之後將任務即時貼都貼在白板的待辦事項行對應的準備開始列中。

在開每日站會的時候，團隊成員都面對白板圍成一個半圓。當團隊成員說完其上個工作日完成了什麼和今天準備做什麼之後，就可以分別移動對應的任務即時貼從進行中到已完成和從準備開始到進行中了，如下圖所示。

這裡如果第三個問題的答案是肯定形式的（遇到問題或者困難等），則可能無需移動即時貼了，也就是說遇到路障了，則可以在對應的即時貼中特別標註下原因，ScrumMaster和團隊相關的其他成員此時應該對路障高度關注，搞清楚原因並試圖給出解決方案，如果需要較長時間才能找到原因或者給出解決方案，則需要另外安排時間，不要佔用過多的會議時間。

當迭代進行了一段時間，大家都對Scrum有了比較深入的理解後，就可以用更方便的電子白板來取代白板和即時貼了，常見的有https://www.pivotaltracker.com，這個比較方便靈活，微軟的TFS也自帶了Scrum，支援中文，使用起來很方便。不過使用電子白板後，可能就不是所有人都站著開會了，我們是ScrumMaster坐在電腦前移動卡片，其他團隊成員站在其周圍形成一個半圓。還有的團隊是到會議室去開每日站會，大家都是坐著的，不過此時大家都知道這個會議不會開太長時間的，就不必要拘泥於必須要站著的形式了。

一般來說一個Scrum團隊的成員數應在5-9人之間，如果團隊成員多於9人，建議將其拆分為兩個小的Scrum團隊分別實施各自的Scrum。

到了迭代結束的那天，可以在下午召開演示和回顧會議，我們一般將這兩個會議放在一起召開，當然一定是先演示後回顧。

有人要問了，研發有產出可以演示和評審，測試演示什麼呢？這個問題問得好。我們是有需要演示的就演示，沒有就不演示。主要是對新的測試方法和技術的演示，比如某個成員採用了一種新的測試用例設計方式，那就可以讓其演示下具體的設計和編寫思路和做法；又比如某個成員掌握了一種新的自動化測試技術或者方法，也可以演示下整個過程，還可以讓成員分享自己的經驗等等。演示會增強演示者的自信心，同時團隊中的其他成員得到了寶貴的經驗和學習的機會。

這個會議的時間控制在一小時以內，會議時間太長了大家都有疲憊感，所以演示者在會議召開前可以適當準備下，比如製作一個簡單的PPT，準備好要演示的環境等。

最後的回顧會議其實就是總結會議，對本迭代進行回顧總結，目的就是CMM中所說的最高級別持續改進：保持做得好的，改進做得不夠好的。這個會議最多半小時就足夠了。可以採用給每個成員發放一張卡片，正面寫出本迭代自己認為做得好的至少三個方面，反面寫出本迭代自己認為做得不夠好的至少三個方面。在開始階段，大家都能寫出很多，但當迭代了多次後，可能大家寫不出來了或者寫的和以前的迭代的內容差不多，這時候可採取針對本迭代內的每個待辦事項逐一進行回顧和總結，這樣更具有針對性。如果大家還是實在寫不出來做得不夠好的，那可能說明團隊確實很優秀了，那也可以往後減少甚至不用開總結會議了。

ScrumMaster收集大家的卡片並將其在白板中列出，如果總計做得好的或者做得不夠好的數量超過三個，則可以用舉手投票的方式選中得票數最多的前三個，之後對做得不夠好的前三個，需要大家分別討論下解決方案，最後由ScrumMaster整理出最終的解決方案並指定解決方案的跟進負責人，這樣到下個迭代開總結會議的時候再來看看上個迭代的這三項，看看究竟有無改進，長期堅持下去，必定能使團隊朝著更好的方向發展起到好的作用。

五、    總結

總得來說，採用敏捷模式開展測試工作，使得每個團隊成員都非常清楚自己的目標和當前工作狀態，每日站會使得大家能夠有效溝通並儘快得知和解決出現的問題，同時報告自己的工作進度也無形中產生了一種壓力，避免了有些員工前幾天比較懶散，到了最後幾天才匆忙趕工的情況；報告當天的工作計劃也是一種承諾，會督促團隊成員儘量按時完成任務。迭代的方式使得團隊成員對自己的工作有了強烈的節奏感，這種節奏感我認為對於工作效率的提升是至關重要的，因為團隊成員清楚的知道自己每天應該做什麼同時也知道團隊中的其他成員正在做什麼，大家都為同一個目標而努力，到了迭代結束的日子大家進行演示和總結，這樣會促進彼此的成長和團隊凝聚力，使其不斷的持續改進，長期堅持下去，這樣的團隊必定是一個戰鬥力很強工作效率很高的團隊。

參考文獻

• www.baidu.com
• www.mountaingoatsoftware.com/scrum
• www.scrumalliance.org
• www.controlchaos.com

作者簡介

北京理工大學軟體工程碩士畢業，有十多年的軟體開發/測試和團隊管理經驗。對軟體質量管理，軟體測試有豐富經驗，擅長Web和移動App的自動化測試和介面測試等。