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

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

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

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

1）業(yè)務(wù)邏輯的了解比技術(shù)更重要

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

2）交流是項目開發(fā)的根本

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

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

3）好的習(xí)慣很重要

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

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

4）學(xué)會尋求幫助

每個人所掌握的知識總是有限的。或許你的能力足夠讓你解決任何問題，但考慮成本問題，若能適當(dāng)?shù)貙で髱椭慵饶軌蚩焖偻瓿扇蝿?wù)，同樣能夠?qū)W到你希望學(xué)到的知識。即使尋求幫助后，沒有得到你所期望的結(jié)果，至少說明，我們可以拒絕某些選項，這同樣可以節(jié)約時間成本。最關(guān)鍵的一點需要時刻記住，我們是一個Team。

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

5）知識分享

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

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

Thoughtworks