時光匆匆，算上實習期來ThoughtWorks工作已近一年。如果技術方面來看，我提升的主要是廣度。但是從敏捷實踐角度來看，我正在也將繼續朝深度上提升。
敏捷這個詞，大學期間或多或少聽過，大體的印象是軟件工程學的一些術語，之後在項目中才開始慢慢實踐。我前後經歷過三四個項目，雖然每個項目待的時間不長，但是卻又想能夠和不同的團隊，面對不同的客戶，也有幸能夠在不同的國家體會不同文化下的敏捷實踐的標準。
由於敏捷包含的方面很多，作爲Developer的我，也會主要從Developer的角度，結合自己的想法來談自己在這一年對敏捷的認識。此文不是軟文，只是自己閒時的一點紀錄。不喜求輕噴。
開發驅動測試(DDT)
加入TW，很長一段時間我一直都抱有這個想法。當時雖然已經在項目上工作，在Code Review的壓力下也會偶爾用開發驅動測試(DDT)。因爲別人告訴我不寫測試的程序員不是好程序員，這個句式怎麼聽起來和不想當將軍的士兵不是好士兵一個道理。聽起來是很多道理，但是真正實施的時候呢，我開始犯難了。
測試的痛點在哪裏？我常這樣問自己，其實我有時也不知道痛點再哪裏，只是不太會寫。爲什麼不會寫？因爲我連怎麼實現都不知道，怎麼會寫？通過這樣反推過來也就是隻有知道怎麼實現，才知道怎麼寫測試。這個觀點對嗎？
只有知道怎麼實現，纔會知道怎麼寫測試。寫測試有點作秀的嫌疑
這是我曾經的觀點，先別批評我邏輯性或者對測試的理解有多差，因爲這是我過去的想法。如果我現在來看這句話的話，我會套用那句很通用的 It depends。肯定有人會反駁，那到底取決於什麼呢。
以我現在的認知來看，我之所以不知道在實現之前怎麼寫測試，往往是由於要測試的對象本身很大，很雜，一個方法要管的事情太多了，所以我不知道怎麼測試。其實回過頭來想想，當一個東西連測試都很難寫的時候，是不是意味着我所要測試的函數做了太多的事情了呢。
- 重構裏的術語來講，自己對類或者方法的設計不太合理，導致要測試的內容過多而不知從何下手。
- 另外一種角度來看，如果一個測試很難描述出測試對象的時候，爲什麼不可以多增加幾個測試，循序漸進的去添加測試。
- 如果以上兩種情況你都不屬於，很不幸有可能你在動手之前應該查一下，確保自己清楚這個被測對象的職責，代碼上基本的實現思路。
當然對於某些情況，我確實可以先寫測試再寫實現。例如一個簡單的計算器的加法，測試中我知道給函數兩個輸入值，我期望能夠輸出某種結果。在這種情形下我知道怎麼寫測試因爲要測試的對象足夠簡單，負責的事情足夠清楚。這種有結果輸出的測試也是相對簡單的。這時候我甚至完全不用操心別人究竟怎麼實現的，我只需要用強有力的測試來驗證結果即可。
知已知彼，百戰不怠。你之所以知道怎麼用測試驅動開發，因爲你在測試之前已經在心中將這個函數設計和實現了一遍。如果你和我一樣達不到這種境界，那可能就是對這塊知識瞭解確實太少，意味着你該自己補補了。
測試的價值
測試到底有沒有價值，得看你是怎麼理解價值的。從科學的角度來看，肯定會有人用實驗來證明寫測試能夠減少Bug發生率，雖然前期寫測試花費時間，但在後期卻能夠節約時間。這種最常見的來證明敏捷實踐標準的理論數見不鮮，但是有時卻很難是剛入門的人信服。
從我經歷過的項目來看，有測試或者沒測試的項目都有接觸過。對測試的價值也有自己的認識。先不管別人的研究結果如果，單從開發人員開發時間來考慮，測試的確會花費更多時間，相當於你要寫兩份代碼，一份實現，一份保證已實現的功能不被後期修改破壞掉。當然測試的確可以提高產品質量。
什麼時候我不會寫測試，雖然我信奉測試是產品質量的保障，但是有時我不一定會寫測試：
- 交付週期過短的項目，並且是在沒有引入測試的項目基礎上開發。這種項目在國內客戶中比較常見，多半是對原來的項目增加一個模塊，並且之前的代碼沒有測試。這類項目的特點是週期短，功能相對較少。敏捷實踐是敏捷實踐，但是沒必要固執的和自己死磕。因爲也許客戶並不在乎你有沒有測試，只在乎產品能不能按期上線。
- 功能變化過快的互聯網產品。一些初創型公司在做產品時往往信奉
天下武功，唯快不破，特別是公司人手不夠，功能較多，並且在每兩週一次的迭代中功能變化過大的時候，維護測試變顯得有點複雜。當然並不意味着任何的測試都是多餘的。這裏有個測試力度的問題，具體得靠自己的把握。
什麼時候我會在項目中引入測試呢？
- 項目週期相對較長，客戶經濟上有能力承擔多幾個開發者帶來的成本；
- 如果是在客戶原有系統上開發，之前的系統就有一套測試體系，無疑我們在增加代碼的時候應該增加測試。而且儘量沿用之前已經構建好的一整套測試體系。
- 一個從零開始的項目，並且有可能建立長期合作的客戶。這是TW的核心競爭力，卓越軟件質量的前提。客戶不提，我們自己也應該做到。
寫測試是一種好習慣，至少作爲一個合格的程序員，應該寫測試。如果你是一個Github上代碼貢獻的活躍者，在爲自己寫代碼的時候，請儘量爲自己的代碼加上測試。Travis就是這樣一個免費的提供CI服務的平臺，如果你想爲自己的代碼加上測試但是又不想自己去搭建CI，可以試試Travis。
迴歸正題，測試的價值在於你多看重軟件質量。測試有時會消耗一定的時間，但是有測試保障的軟件在質量上的確可以提高好幾個層次。是否寫測試則需要結合你自己的項目實際情況以及客戶本身而定。
如果你經歷過國內客戶和國外客戶，那麼你應該能夠體會到他們對於軟件質量的不同態度。當然所有人肯定都希望軟件交付質量最高，時間最短。但是當兩者需要權衡的時候，國內客戶比較在乎的會是進度，國外客戶比較在乎的是質量。所以質量和進度之間需要找到一個平衡點。
從國內外客戶的差異，其實也可以聯想到國內外軟件開發者的差異。到美國這邊與美國這邊的同事辦公之後發現，這邊的同事對於測試的重視程度要遠遠高於國內的同事(不是黑ThoughtWorks China的同事們)。You can not do anything when you write test. Test first，這是美國這邊一位senior的同事和我pair的時候說的。自己曾經那些不好的編程習慣到了這邊是應該好好改改了。
在美國這邊工作曾經有幾天我對項目上的測試有點質疑了，因爲有些地方實在測的太細，幾乎是想用測試覆蓋掉每一行代碼，並且有些代碼還被多個測試覆蓋。後來偶然的聊天中，同事告訴我 I think I don't write so much meaningful tests in our code, some tests seems to be useless. And Jered is more experienced，雖然這是一種謙虛的說法。但是這卻告訴我，寫好測試才能真正體現測試的價值。
我姑且稱那些永遠不會fail，或者基本沒有測任何有意義的東西的測試爲殭屍測試，這種測試太多了直接影響整個測試的可閱讀性。好的測試應該可以通過函數命名，測試輸出結果的判斷來提供文檔的功能。所以不要用數量來堆砌測試，努力寫好測試是關鍵。
敏捷團隊角色
敏捷開發中很重要的一部分是團隊角色。一個敏捷團隊主要有應用開發工程師(Dev)，業務分析師(BA)，質量保障工程師(QA)等。在項目的Story估點之時，除了有BA和QA的參與，Dev的參與也是很重要的部分。BA和QA主要從業務上評估，Dev主要從技術上評估，這種多人蔘與過的估點纔是有意義的。
同樣一個Story制定的時候產品設計效果圖和可驗證的Scenario是很重要的。Scenario的制定其實考察的是BA/QA對業務以及實際使用場景的考驗。這一點我在Mobile端體會尤其明顯。因爲Mobile端更重交互，對於用戶可能有的行爲，制定驗收標準是就應該考慮清楚。所以這時候BA不僅僅承擔一個業務分析的角色，還承擔着用戶的角色。
Dev和BA溝通Story的時候最簡單的情形是以用戶爲媒介。無論業務分析還是開發實現，最終都是爲了給終端用戶一個具有某種功能的產品。
有時我會想如果讓Dev轉型當BA，那這個BA一定很能瞭解功能的實現者。後來發現這種想法本身存在一定的問題，因爲不管這個BA懂不懂具體的實現，BA/QA應該懂的是用戶，應該懂得是平臺特性以及用戶特性。無論是Mobile和Web，抑或是Android和IOS，無論是敏捷團隊的何種角色，你都得嘗試去了解這個平臺的特性，瞭解終端用戶，才能夠做出更好的決策。
結語
作爲ThoughtWorks諮詢師，我們應該知道公司的核心競爭力是什麼，我們也更應該嘗試去影響客戶，給客戶帶來價值。也希望新的一年裏自己能夠在敏捷實踐上做得更好，能夠幫助客戶，影響客戶。
We think disruptively to deliver technology to address our clients’ toughest challenges, all while seeking to revolutionize the IT industry and create positive social change.