注：本文來自文章作者@熊志男 的投稿。伯樂線上也歡迎其他朋友投稿，如果您有新浪微博，請投稿時記得留下哦~
2012年11月3日下午，外面滂沱大雨使得氣溫驟然下降，在中國科技會展中心的一間會議室裡，卻被熱烈的氣氛包圍著。嘉賓們和參會者的大腦高速運轉產生的熱量，在室內空調熱力配合下，使得屋內顯得很熱。
我也在積極思考“敏捷”這兩個字的含義，努力著在以往的測試實踐和學習經驗中尋找相關的體會。我希望通過向嘉賓提問更多的問題，來獲取更多的知識。
我想起我頭腦中也產生過一下幾種對於敏捷測試的態度：
一、敏捷崇拜者，因為敏捷是新技術思想，所以和其他的新技術崇拜一樣，當時年輕的心總想學習先進的新的知識來超越自我。
二、旁觀者，經過對於敏捷的初淺認識和測試實踐，發現敏捷並沒有真正出現在我的實際工作中。而且，敏捷是一種應用在整個開發流程中的思想模式，那麼只有在敏捷開發流程中的測試才可稱之為“敏捷測試”。那麼單獨的“敏捷測試”應該是個偽命題了。而且我又適應了現在的工作，無法改變開發的流程，那麼敏捷與我無關了？
三、敏捷反感者，當然這不是我自己的想法，但是我可以清楚得感覺到一些合作過的同事、同行是持這種態度。他們已經適應了現有的流程，對於敏捷的第一印象“敏捷就是沒有詳細的文件”，那怎麼行，我們需求從哪裡獲取？測試用例描述不細緻，我們測試執行參考什麼？流程如何控制？其實我不清楚他們是害怕還是不願去接受新鮮事物。
在參加這種技術交流時，常常感覺很恥於說出自己沒有什麼敏捷的經歷。好像這就證明我能力有限，所經歷的公司水平有限一樣。我想無論是否是我低估了自己和自己所處的環境。還是要面對自己，才能夠成長進步。
那麼記憶中與敏捷沾邊的工作，就是2009年在廣聯達公司的測試工作。印象最深的幾點：
一、測試用例簡化，以往的花了很長時間編寫的測試用例，除了在第一輪測試時候會參考執行以外，作用非常有限，而且維護困難，每次例會討論用例維護的方案總是不了了之。用例簡化後，針對每個功能點列出簡要的測試點在QC中，而不去寫詳細的用例。在每一輪的測試過程中都會去維護增加新的測試點。
二、測試提前，區別以往等待開發人員給出正式版本後再進行測試。而是，在得到需求的第一時刻，列出相應的測試點併發給開發人員確認，在與開發的溝通過程中得到對於需求的統一認識。然後在開發做完每一個新功能時，一個測試和一個開發坐在開發的工位上按照測試點，逐一在本機上驗證。這樣就不用從伺服器上等到正式版本再測試了。
三、組織結構，拆散原來獨立的測試部和開發部，根據產品、功能、地區版本劃分，開發和測試以大概2：1的比例組成一個團隊，當然由於需求人手緊張，所以一個需求人員會同時參與幾個團隊的工作。這樣轉變了原來開發與測試的對立局面。
四、每日站會，其實當時對於每天早上開會有些反感，也許是因為還沒有真正體會到他的意義。
如果說敏捷中的測試必然都是需要自動化的，那麼我們當時的自動化測試只是應用於冒煙測試和基本功能驗證。無論是不是完全意義上的敏捷，還是有所收穫的。記得後來曾經參加其他公司的面試，說起敏捷經歷，我還會拿出此段經歷來充數，汗！
那麼回到現在的測試專案中，是否可以按照敏捷的思想來施行呢？會起到什麼作用？解決什麼問題？
從賀炘老師的PPT中看出，分析現在專案是否適合敏捷可以從以下幾點來看：
1.專案特點
那麼我們的專案是離岸的測試專案，作為開發的客戶是在美國，在專案特徵上我們無法實現開發和測試結合的團隊結構。而且由於時差問題，我們發出的問題只能在第二天得到答覆，就無法實現敏捷所要求的及時反饋和溝通。
2.支援環境
正因為我們是獨立的專案，在自主性上比較強，採取何種形式的測試流程和方式，不會太受制於人。另外我們的自動化迴歸測試一直在比較穩定得執行。以此來說，是屬於比較適合的。
3.人員素質
我們的專案一直以來秉承著建立一個小而強的團隊的原則，僅有的5個測試人員，從業務水平、程式碼能力、測試能力方面來說，都是能夠獨當一面的。
那麼是無法做到敏捷了？敏捷的真諦是什麼？是一定要符合幾個關鍵字嗎？還是一種解決問題的思路呢？
今天的會議中嘉賓們對於敏捷的意義探討有幾點：快速的價值交付、更加透明和有效的溝通、減少專案中的不必要的時間浪費。
回過頭來，這不正是我們專案中存在的問題嗎？
不得不說我們有很多人已經非常習慣於這個功利社會的遊戲規則，也許一個人推動敏捷測試、推動探索測試、推動自動測試，真正目的是為了績效、薪資和升遷。我們不能否認這是錯的，但是如果解決了不了實際問題，反而由此產生的很多問題會給這些優秀的思想和技術臉上抹黑。還是在以後的專案中，踏踏實實學習，小心翼翼實踐吧，共勉！