在ThoughWorks有一句流傳甚廣的話 —— “在ThoughtWorks需要有擁抱隨時變化的心態“，因為我們踐行敏捷、我們有各種各樣的客戶，而商機稍縱即逝。作為普通的dev，非常明顯的感受是不會像其他互聯網公司一樣長期待在一個固定的項目，有足夠的時間了解項目的上下文和背景。我們的項目周期足夠短，甚至有時候幾周都算很正常，項目的頻繁切換對dev的要求就是需要快速了解一個新的項目。

這是我在ThoughtWorks幾年間一直思考的一個問題，如何快速熟悉一個新的敏捷項目。下面就是我一直積攢的自己的經驗，寫給我的新同事，以及任何正在實施敏捷軟件項目的讀者。文中提到的諸多名詞術語，都是基于ThoughtWorks日常的項目和團隊活動，默認讀者對于敏捷開發流程和不同角色有普遍認知。對于ThoughtWorks的開發模式感興趣的人，也可以參考肖然的這篇《ThoughtWorks的敏捷開發》。文中還會提及具體的技術和工具，比如Spring、Gradle或者Webpack，只作為具體的示例而已，對于本文主旨并無任何影響。如果有任何疑問，請留言，我會盡我所能給與解答。

了解團隊

工作之前覺得項目上的“事”應該更重要，隨著工作的時間越長，越能體會“人”對項目成功的決定作用更大。雖然有時候我們調侃某某項目“坑”還是“不坑”，但是實際上了項目才知道，一個項目“坑”還是“不坑”取決于誰來做這個項目，因此我把這段放到了最前面。

站會應該是第一次接觸到團隊幾乎所有人最好的機會，在第一次站會的時候就應該去了解團隊里面的所有的角色，以便在后面的工作中找到合適的人去開卡(Kick off)、Desk Check、關卡(Sign off)，需要注意不是所有的項目都有“全明星陣容”，往往有時候很多角色是兼任的，例如PM兼BA(Business Analyst，業務分析師)，BA兼UX等。

可以主動詢問是否項目中有相關的On Boarding的Check List 快速了解一個這個團隊的工作方式，每個項目的工作習慣有一定的差異，工作中On Boarding的文檔可以快速了解這些，例如需要怎么開卡、是否需要做Desk Check，提交代碼時的Comment規范是怎樣的。

另外，主動尋找一個合適的人一起Pair，一起Pair來了解一個新的項目在ThoughtWorks是非常常規的操作，在剛到項目會給新人一些時間設置環境，熟悉代碼，這個時候能熟練地老手一起Pair幾天可以說事半功倍。

還有一個重要的Tip就是，學會快速記住其他人的名字，這會讓你更方便的融入團隊和得到尊重。

了解業務

作為一個dev需要對業務整體的了解才能對單個故事卡有足夠的理解，否則單個故事卡就是橫看成嶺側成峰了。當然很直觀的做法就是去找BA聊聊業務，不過在找BA之前比較好的建議是先找QA要一下測試或者UAT(User Acceptance Testing，用戶驗收測試)環境的地址和賬號，作為一個普通用戶的角色使用一遍，這樣會從用戶的角度有一個初步的認識。

在和BA過業務的時，BA 會把原型圖拿出來，這個時候再結合之前自己對應用使用的印象來了解業務背后的邏輯。因為應不是所有的業務邏輯都能在原型圖上得到體現，在實現過程中也會對當初的設計做一些小的調整。還有就是結合現有的功能看原型圖，可以知道哪些已經開發完成哪些還在開發中，這樣后面在自己開發過程中可以參考已經實現了的功能或代碼。關于原型圖另外一個Tip就是很多項目為了保持項目風格統一，會給出一個Style Guide來指定一個基本的樣式規則，例如間距、字體、顏色等。

有時間可以整體過一下卡墻(Story Wall)，看下項目工作到哪個階段和狀態。很難有足夠的時間細致的看完所有的故事卡，需要整體有一個印象即可，但是需要注意的是有些跨功能需求很重要但沒有在故事卡上表現，因為跨功能需求是一些共同的、默認的需求，例如對表單進行驗證、分頁等，如果不注意這一點在開卡時可能會忽略，但是QA測試中會覆蓋相應需求。

其他了解項目業務的方式還有閱讀項目Inception(啟動)報告和Wiki文檔(如果有的話)，Inception 報告的信息來自于Inception期間從客戶得來的第一手資料。有時候會覺得有些很奇怪的需求(比如使用奇怪的存儲媒介Excel而不是數據庫，用戶業務人員需要直接修改資料等)，但是往往是因為一些既定背景下妥協的產物，這樣就能理解前任維護者的真實意圖了。

了解項目架構

工程師習慣往往是第一時間打開代碼，但是隨著項目越來越規范化，一般來說都會被分成多個代碼倉庫。如果直接讀代碼有時候會很難整理理解項目的結構。如果項目提供了一些架構圖、流程圖可以拿來參考，如果沒有我們也可以通過一些方法了解了解項目的架構然后嘗試自己畫一些圖形來幫助自己了解項目。

使用C4模型表現項目架構和依賴關系

C4模型是一種層層遞進展開的方式來描述項目結構(系統-容器-組件-類)，避免把在繪制圖形的時候把不同層級的實體放到一起，造成架構圖看起來非常混亂。為了表達項目依賴關系，我們可以系統一級(即以每個系統為單位);表達自身項目架構，用容器這一級。

例如：

(圖片來自：https://c4model.com/#examples)

這個例子中虛線外部可以表達為系統之間的依賴關系，虛線內部為當前系統展開的各個組成部分。如果很復雜可以畫在兩個圖中表現，當然系統中的每個部分可以進一步放大。

通過查看代碼倉庫中的配置文件可以很容易解項目的依賴情況，因為規范的項目都會把第三方依賴的信息放到配置文件中，便于根據不同的環境切換，不會硬編碼到業務代碼中。

考慮技術架構需要考慮：

• 技術棧和第三方包依賴
• 依賴服務的調用關系
• 認證和授權服務

使用E-R模型表現數據庫關系結構

E-R圖也稱實體-關系圖，關系型數據庫的靈魂在數據模式之間的關系，通過這種方式達到數據的完整性、一致性、正確性。為了降低冗余和提高一致性就需要合理的拆分多個數據表。如果數據庫比較大就很難理解實體之間的關系。因為我們可以使用實體-關系圖來表現數據庫的關系結構，一般來說實體-關系圖也會畫出屬性，但是如果屬性較多或者想重點體現關系我們可以也可以省略屬性。

 

圖片來自：https://www.aliyun.com/jiaocheng/1112566.html

使用時序圖表現關鍵邏輯

如果遇到單個業務流程比較復雜，例如下單流程。前后端可能會發生多次API的調用情況，這種情況下使用UML的時序圖就非常清晰了。

(圖片無對應項目，僅作為案例展示)

再談了解代碼

閱讀代碼時除了查看通常的代碼邏輯之外，還要最好著重看下項目的配置相關的代碼。例如Spring boot中使用@Config注解下的類，每個項目的不同點通常在這里，如果不清楚一些Bean的配置方式，往往會被一些簡單的問題坑到。通常來說一些攔截器、過濾器都會放到配置相關的代碼附近。對全局的配置多一些了解就可以避開一些奇怪的問題。

另外項目中的打包流程也很值得一看，比如gradle的build文件，前端的webpack相關的腳本。

有一些項目會有一個技術債務清單或者圖表，了解下技術債務能避開一些重復的工作，因為有一些代碼可能會被重構或棄用，我們沒有必要再在這些代碼之上做修改。

了解DevOps

項目中DeveOps的Check list

項目中的DeveOps工作很瑣碎，但是如果了解這些信息，對上線、調試都有很多幫助，這里不一一展開，只是提供了一個清單說明一般的項目都會有那些DeveOps相關的內容。

• Dev、QA、UAT、Prod等多環境
• CI/CD
• 代碼倉庫
• Artificts 的存儲
• 密匙管理
• 部署腳本
• 安全掃描工具
• Findbugs
• Sonarqube
• 定時任務
• 備份
• 日志

使用網絡拓撲圖表現部署情況

當我們遇到一些線上問題，想要進行調試，或者準備上線的時候。需要知道網絡和服務器相關的情況，這個時候可以通過網絡拓撲圖來描述應用的部署情況。

(圖片來自：https://aws.amazon.com/getting-started/projects/deploy-nodejs-web-app/)

了解項目進展

我把了解項目這部分放到了最后，因為在團隊中有PM和Teach Lead 對項目整理方面更為關心。但隨著對項目的熟悉，知道一些項目管理方面的情況也必不可少，至少了解一些重要的時間點很必要。

• Release 時間 – 顧名思義，上線發布的時間
• UAT 時間 – 上線前在UAT環境做準備的時間
• Code freeze 時間 – 鎖定代碼或者創建新的分支不再提交新的功能，但是可以繼續修改缺陷
• Show case 時間 – 給客戶演示階段性成果的時間

這些時間點串起來基本上就是一個項目的Flight plan。

在項目管理中，干系人管理作為很重要的一部分，因為客戶方往往不可能只會接觸一個人。聲音大的、要求多的不一定最終拍板，經常不出現的也有可能是能做出重要決定的人。但對dev來說如果需要和客戶其他系統對接，更重要的是找到以下幾類人：

• 技術對接人
• UAT或上線驗收的人

總結

這篇文章基本上屬于Check List 類型的“水”文，但是還是決定發出來。交付時間就是實打實的金錢，如果做到讓新成員快速上手非常重要的還是要團隊的敏捷實踐做的足夠好、代碼足夠規范、文檔足夠完善。盡量避免在人員的切換上帶來的上下文丟失，團隊交流也不能只是口口相傳，更不能讓某些關鍵的信息成為“單點故障”，應該及時的傳遞到整個團隊。