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

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

了解團(tuán)隊

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

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

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

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

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

了解業(yè)務(wù)

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

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

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

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

了解項目架構(gòu)

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

使用C4模型表現(xiàn)項目架構(gòu)和依賴關(guān)系

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

例如：

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

這個例子中虛線外部可以表達(dá)為系統(tǒng)之間的依賴關(guān)系，虛線內(nèi)部為當(dāng)前系統(tǒng)展開的各個組成部分。如果很復(fù)雜可以畫在兩個圖中表現(xiàn)，當(dāng)然系統(tǒng)中的每個部分可以進(jìn)一步放大。

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

考慮技術(shù)架構(gòu)需要考慮：

• 技術(shù)棧和第三方包依賴
• 依賴服務(wù)的調(diào)用關(guān)系
• 認(rèn)證和授權(quán)服務(wù)

使用E-R模型表現(xiàn)數(shù)據(jù)庫關(guān)系結(jié)構(gòu)

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

 

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

使用時序圖表現(xiàn)關(guān)鍵邏輯

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

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

再談了解代碼

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

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

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

了解DevOps

項目中DeveOps的Check list

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

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

使用網(wǎng)絡(luò)拓?fù)鋱D表現(xiàn)部署情況

當(dāng)我們遇到一些線上問題，想要進(jìn)行調(diào)試，或者準(zhǔn)備上線的時候。需要知道網(wǎng)絡(luò)和服務(wù)器相關(guān)的情況，這個時候可以通過網(wǎng)絡(luò)拓?fù)鋱D來描述應(yīng)用的部署情況。

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

了解項目進(jìn)展

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

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

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

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

• 技術(shù)對接人
• UAT或上線驗收的人

總結(jié)

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