與一群國外的Dev一起工作是我從未有過的經歷，在陌生的國度，陌生的團隊，陌生的客戶，做著陌生的項目，對我而言，Everything is new。我們在客戶這里，仍然采用典型的敏捷方式：故事墻、站會、用戶故事、結對編程、持續集成、TDD甚至BDD……幾乎所有的敏捷實踐我們都會運用。在加入這個項目時，已經進行到第7個迭代，整個項目的框架已經比較成熟。我們的任務是盡快熟悉業務和整個技術框架，并為新的項目做好充分準備。在接近3周的時間內，我們都會和客戶以及美國Thoughtworks的同事們進行Pair，通過實際的開發來熟悉和了解業務與技術。然后，在剩下的兩周內為新項目做Inception。

項目是基于.NET Framework 4.0進行開發的，采用的技術包括C#, VB.NET, Ext Js, SQL Server 2008。IoC容器為Structure Map，NUnit作為單元測試框架，Moq作為Mock測試框架。我們使用了Jenkins(即Hudson)作為持續集成工具，使用了Thoughtworks的產品Twist作為回歸測試和集成測試工具，并使用了Powershell作為構建腳本，Git作為源代碼控制工具。

來到LA的第一周。除了第一天參加了幾次Meeting，了解了整個項目的情況尤其是業務邏輯之外，第二天就迅速進入團隊，開始結對編程。整個第一周，我完成了2個Bug Fix，同時，對Regression Test出現的問題進行了修復，并參與了一個Story的開發。在這一周，我并沒有Switch Pair，一直是和客戶這邊的一位Dev（名叫Andrew）進行合作。

回顧這一周的工作，我的感受如下：

1）業務邏輯的了解比技術更重要

作為一名Dev，可能首先會想到項目會使用什么技術，我對這些技術了解嗎？總之，會首先關注一切與技術有關的東西。在進入項目之前，我特別關注了這些內容，并抓緊一切時間為這些技術做儲備。當然，我們也希望了解業務邏輯，但由于前期準備時缺乏這方面的條件，我們所能了解的就是項目與Healthcare有關，項目內容有些接近CMS。然而，到了項目之后，我們才發現，技術并非決定你能否快速進入團隊，并開始開發和實現的關鍵。如果不了解業務邏輯，不明確領域術語，我們將很難進行溝通和交流。尤其對于現在這個項目，由于項目已經做了一部分。對領域的了解就更加重要了。對于一名有著多年經驗的Dev來講，其實技術并不會成為制約你進行項目開發的主要瓶頸。在這個項目中，有很多技術都不是我掌握的，但我們仍然可以快速進入開發活動。這是因為Pair Programming可以很好地完成知識共享和傳遞，我的Pair可以像Mentor一樣來帶領我迅速進入狀態。

2）交流是項目開發的根本

在國內做項目，交流或許也會成為障礙，但因為語言相同的緣故，我們往往將交流活動忽略了，似乎覺得這是順乎自然的事情。在這一周的工作中，我仿佛進入了另一個世界，耳邊充斥地都是自己難以理解的語言。雖然我有一定的英語基礎，但真正和這些母語為英語的Dev合作時，才發現我所掌握的英語單詞和語法都變得不夠用了。我的舌頭似乎也打結了，我很難理解Pair所要表達的意思，自己也很難向Pair表達我的意見。這就導致開發效率受到很大影響。即使任務已經完成，整個實現對我而言，仍然似是而非，還需要自己下來看Story的描述，看源代碼。例如，在我們項目中已經實現了比較好的Validation機制，但為了實現一個相對較小的Story，由于交流的問題，我們的實現被嚴重阻礙了。

此外，在我們項目中完全具備現場客戶的條件，因而交流更是成為重中之重。我們的BA團隊既有TW的，也有客戶的。他們都寫了很不錯的User Story。在我們實現這些User Story時，如有不明白之處，都需要盡快咨詢BA，通過交流消除歧義。而在實現之后，必須和BA做Show Case，以盡快獲得反饋。這一點非常重要，也是敏捷的核心價值觀體現。

3）好的習慣很重要

第一周，和我Pair的Andrew是來自客戶的一位實習生。他剛從大學畢業，進入項目大約三個月時間。在大學期間，他只學習了C++，對.NET、Javascript以及CI等內容都不熟悉。換言之，他現在所掌握的所有技術，都是在項目中學到的。雖然是這樣一個Intern，但我發現他已經具備了非常良好的編碼素質。在開始一個Story時，他會首先在Twist編寫Regrssion Test Sceinario。而在實現代碼時，也會嘗試著通過Unit Test來驅動實現。在提交代碼時，會合理地運用Git命令。例如在開發前，會通過Git Status檢查當前狀態，看是否有變更。在Commit時，如果發現提交的內容有沖突，他會非常慎重地處理Merge。編寫代碼時，會嚴格遵循我們制定的編碼規范。雖然，他在開發方面的經驗還有很多欠缺，但無疑已經有了一個好的開始。我想，通過這個項目的鍛煉，在Thoughtworkers的言傳身教下，只要他愿意繼續努力，應該會有一個很好的發展前景。

同時，對于團隊而言，這樣良好的編碼習慣，就像所謂的“童子軍軍規”一般影響這團隊的每個人，我們欠下的Technical Debt就會少很多，這對于后期的維護、修改以及將來后續的開發，都有非常大的幫助。

4）學會尋求幫助

每個人所掌握的知識總是有限的。或許你的能力足夠讓你解決任何問題，但考慮成本問題，若能適當地尋求幫助，你既能夠快速完成任務，同樣能夠學到你希望學到的知識。即使尋求幫助后，沒有得到你所期望的結果，至少說明，我們可以拒絕某些選項，這同樣可以節約時間成本。最關鍵的一點需要時刻記住，我們是一個Team。

在第一周的Story開發中，由于我和Andrew都對Validation的機制不太熟悉。我們嘗試了多種方法，希望解決問題，但都不奏效，這樣反復的嘗試已經耽擱了大約一天的時間。后來，我們主動找到另一位Thoughtworker-Eric，他已經在項目呆了較長時間。了解我們的問題后，Eric僅用了不到10分鐘的時間就解決了這個問題。事實上，這個問題的解決方案需要一個小技巧，在Label中設定我們事先指定的CSSClass，就可以顯示那些Validation Message。

5）知識分享

毫無疑問，只有充分的知識分享，才能有效發揮團隊的作用。尤其對于新加入團隊的成員，如果沒有足夠好的知識分享，或者團隊的老成員不具備這方面的意識，將自己擁有的知識傳遞給新成員，新成員就很難融入團隊，也很難快速地貢獻自己的Effort。在知識分享的過程中，通過Meeting和Session，或者閱讀文檔的方式當然是有效的。但事實上，即使你參加一天的Session，或閱讀一天的文檔，都不如和你的Pair實際做一個Story，對知識的分享來得更好。根據我自己的經驗，所謂Session或文檔的方式，更適合介紹一些領域背景知識，或宏觀的系統架構。細節知識必須在實踐過程中獲得。這時，Pair Programming就顯得非常重要了。

在選擇自己的Pair時，也需要針對實際情況做出調整。例如與新手Pair的必須是相對有經驗的Dev（當然也可以和QA或BA結對）。另外，也需要適當地Switch Pair。在這個項目中，我就體會到這一點的重要性。第一周的3天時間，和我Pair的都是Andrew。雖然他已經進入項目三個多月，但畢竟還缺乏一定的經驗。而我作為項目新人，更是很多內容都不了解。這樣的Pair組合，效果可想而知。在這個過程中，本來我們應該進行Switch，但因為Story的關系，其他Pair也有自己的任務，這個Switch活動就被推遲到了第二周。事實上，在第二周的第一天，我和Eric合作，效果就非常好。整個Velocity得到了較大的提高。

Thoughtworks