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

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

了解團(tuán)隊(duì)

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

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

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

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

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

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

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

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

有時(shí)間可以整體過一下卡墻(Story Wall)，看下項(xiàng)目工作到哪個(gè)階段和狀態(tài)。很難有足夠的時(shí)間細(xì)致的看完所有的故事卡，需要整體有一個(gè)印象即可，但是需要注意的是有些跨功能需求很重要但沒有在故事卡上表現(xiàn)，因?yàn)榭绻δ苄枨笫且恍┕餐摹⒛J(rèn)的需求，例如對(duì)表單進(jìn)行驗(yàn)證、分頁等，如果不注意這一點(diǎn)在開卡時(shí)可能會(huì)忽略，但是QA測試中會(huì)覆蓋相應(yīng)需求。

其他了解項(xiàng)目業(yè)務(wù)的方式還有閱讀項(xiàng)目Inception(啟動(dòng))報(bào)告和Wiki文檔(如果有的話)，Inception 報(bào)告的信息來自于Inception期間從客戶得來的第一手資料。有時(shí)候會(huì)覺得有些很奇怪的需求(比如使用奇怪的存儲(chǔ)媒介Excel而不是數(shù)據(jù)庫，用戶業(yè)務(wù)人員需要直接修改資料等)，但是往往是因?yàn)橐恍┘榷ū尘跋峦讌f(xié)的產(chǎn)物，這樣就能理解前任維護(hù)者的真實(shí)意圖了。

了解項(xiàng)目架構(gòu)

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

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

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

例如：

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

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

通過查看代碼倉庫中的配置文件可以很容易解項(xiàng)目的依賴情況，因?yàn)橐?guī)范的項(xiàng)目都會(huì)把第三方依賴的信息放到配置文件中，便于根據(jù)不同的環(huán)境切換，不會(huì)硬編碼到業(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圖也稱實(shí)體-關(guān)系圖，關(guān)系型數(shù)據(jù)庫的靈魂在數(shù)據(jù)模式之間的關(guān)系，通過這種方式達(dá)到數(shù)據(jù)的完整性、一致性、正確性。為了降低冗余和提高一致性就需要合理的拆分多個(gè)數(shù)據(jù)表。如果數(shù)據(jù)庫比較大就很難理解實(shí)體之間的關(guān)系。因?yàn)槲覀兛梢允褂脤?shí)體-關(guān)系圖來表現(xiàn)數(shù)據(jù)庫的關(guān)系結(jié)構(gòu)，一般來說實(shí)體-關(guān)系圖也會(huì)畫出屬性，但是如果屬性較多或者想重點(diǎn)體現(xiàn)關(guān)系我們可以也可以省略屬性。

 

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

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

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

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

再談了解代碼

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

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

有一些項(xiàng)目會(huì)有一個(gè)技術(shù)債務(wù)清單或者圖表，了解下技術(shù)債務(wù)能避開一些重復(fù)的工作，因?yàn)橛幸恍┐a可能會(huì)被重構(gòu)或棄用，我們沒有必要再在這些代碼之上做修改。

了解DevOps

項(xiàng)目中DeveOps的Check list

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

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

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

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

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

了解項(xiàng)目進(jìn)展

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

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

這些時(shí)間點(diǎn)串起來基本上就是一個(gè)項(xiàng)目的Flight plan。

在項(xiàng)目管理中，干系人管理作為很重要的一部分，因?yàn)榭蛻舴酵豢赡苤粫?huì)接觸一個(gè)人。聲音大的、要求多的不一定最終拍板，經(jīng)常不出現(xiàn)的也有可能是能做出重要決定的人。但對(duì)dev來說如果需要和客戶其他系統(tǒng)對(duì)接，更重要的是找到以下幾類人：

• 技術(shù)對(duì)接人
• UAT或上線驗(yàn)收的人

總結(jié)

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