2.3 業務回補期：應對第一次Deadline

當團隊成員能正常地開發業務邏輯時，我們的關注點就變成了：應對第一次Deadline。在這個階段里，業務開發雖然已經進入正軌，但是可能存在一定的進度落后。于是在優先級上變成了業務第一、技術第二。

這是一個價值證明的階段，也是調配落后的進度與先進生產力的時期。畢竟欠下的債（業務）總是要還的。如果在上一個階段中，我們花費了大量的時間在概念證明上，那么必須在這個階段償還這些時間。

在項目開發的過程中，人員能力不足也是大部分項目都會遇到的問題。就好像帶兵打仗，老兵并不會一直待著，總有走的時候。而隨著團隊的規模不斷擴大，會不斷添加新的成員。若是這些新成員的能力不提升，或者提升比較慢，就會影響項目的進度。

此外，由于內部技術的問題已經解決了，內部的業務已經步入正軌，我們開始關注于第三方系統集成，并著手準備應用的測試和第一次上線。

2.3.1 追補業務

當技術不再是問題時，關注點便在業務上。雖然技術是業務價值的實現方式，但是業務才是賺錢的直接證明。如果業務無法存活下去，那么技術就無法證明其價值。

如果因為先前的概念驗證導致一定的進度落后，那么在適當的時候，我們還會臨時性地后置部分的技術需求，以用于按時完成業務。比如在必要的時候，單元測試、UI測試都可以適當地減少，直到業務平衡之后，再回來填補測試。每當這個時候，總會有人為此感到困惑和不理解。

先進的架構，并不一定會為業務帶來價值；先進的技術，也并不一定會為業務帶來價值。這就是為什么每當我們采用新的架構和技術時，總需要通過一系列的會議來討論新的架構是否能夠帶來更多的價值。新的架構和技術帶來的往往是一些架構上的可能性，它節省的往往是開發時間。而實施這些新的架構，也會花費一定的開發時間，因此需要適當地計算收益，以實現業務的最大價值。如此一來，利益相關者才會考慮架構的價值。在大多數時候，業務人員考慮的是業務價值，進度是他們考慮的第一因素。

2.3.2 測試：實踐測試策略

在編寫業務代碼的過程中，還要不斷面臨測試上的壓力。

在敏捷項目里，測試人員真正開始測試，是在項目進行一段時間后才開始的。一方面，前后端之間的聯調可能沒有完全準備好，無法進行完整的測試。另一方面，可測試的業務內容相對比較少，部分功能可能無法完整地串聯起來。隨后，便一直在項目中進行日常的功能測試。在上線前，才會進行一次相關的、完整的回歸測試。

對于瀑布型項目而言，一個項目的測試和其他項目的測試并沒有太大區別。只是在新的項目中，往往也需要大量地準備、熟悉項目、編寫測試案例等，才能進入測試的流程。因此，測試人員往往在上線前的幾周里才開始進行大規模的測試。

日常的測試，除了帶來更穩定的功能，還給開發人員帶來bug，這些bug會進一步地影響項目的進度。隨著上線時間的逼近，bug數量在不斷增加，甚至可能會出現一些混亂的場面——測試人員在不斷地提bug，而開發人員需要不斷地完善新業務，導致出現一些矛盾。

對于一個前后端分離的項目，在平時的開發里已經進行了大量的聯調，基本可以應對上線。只是我們在設計架構時考慮的一些情況，可能會在這個階段里出現；一些尚未考慮的情況，可能也會在這個階段里出現。諸如：

◎ 沒有進行集成第三方測試，無法驗證業務的完整性。

◎ 沒有準備好一個穩定的測試環境，以提供給測試人員進行測試。

◎ 沒有接近真實的數據，以驗證一些極端條件是否會出錯。

……

每出現一個導致測試不完整的情況，都相當于一個風險問題。

此外，在這個時期和上個時期里，開發人員編寫的自動化測試（單元測試、UI測試等）的覆蓋率比較低——大量的時間被花費在相關業務功能的實現上。盡管如此，我們還需要嘗試在這個時期里，定下一個覆蓋率的基值，比如30%，先從0開始，然后在下一個階段里進入更高的數值——就當前而言，它不能變得更差了。這樣在后期，我們才有機會進一步提升代碼的質量。

這一系列的混亂會隨著項目的進行被不斷地改進。

2.3.3 上線準備

在追補業務的過程中，我們在另外一方面著手準備了應用的上線事宜。當第三方依賴已經準備好時，便可以著手準備與上線相關的事宜。小公司要購買相應的服務器，大公司要申請相應的資源、審批流程，等等。

如果項目依賴于第三方服務和平臺，并且他們的上線周期與我們的上線時間接近。那么，這個時候與他們聯合進行調試就是一種挑戰。特別是上線日期臨近時，如果遇上Bug，那么就需要反反復復地修改和測試。

與此同時，需要根據部署架構練習相關的技術實踐。若是計劃使用服務端渲染，那么我們需要準備好與Node.js相關的線上調試環境，并讓團隊擁有基本的調錯（debug）能力。若是計劃使用Docker，那么也需要不斷嘗試練習與DevOps相關的技能——哪怕是公司內部擁有相關的DevOps，開發人員也需要擁有基本的能力，才能應對線上的問題。

總之，我們需要在上線前準備好所有相關的內容。

2.3.4 第一次部署：驗證部署架構

無論怎樣，第一次部署都會比較痛苦。哪怕在我們有了其他項目經驗之后，一旦一段時間內沒有經歷過新應用的部署，就有可能出現問題——通常是一些配置問題，比如某個軟件升級，導致之前的配置出錯。哪怕使用Docker這樣的工具，也可能出現一些意想不到的情況。應對這些情況的最好方式是，如果能提前嘗試使用上線流程，那么就提前走上線流程。

對于前端項目來說，部署并不是一個痛苦的事情。大部分應用只是單純的靜態文件，可以直接打包交給后端人員上線，也可以結合Docker進行自動化部署。若是帶有服務端渲染的前端應用，部署會稍微麻煩一些，還需要配套對應的進程管理、服務監控等一系列的工具。

不管怎樣，在第一次上線之后，我們實現了從0到1的階段。有了這一次的經驗，往后基本不會出現太多的問題——但是仍有可能出現問題。

2.3.5 提升團隊能力

受團隊能力影響，越是進度困難的時候，越需要提升團隊的能力。它可以避免我們陷入一個誤區，即我們因為能力不足而加班，卻沒有時間提升能力，又進一步導致加班。一旦團隊里出現這樣的問題，我們就不得不正視這個問題。盡管能力可以通過個人的練習得來，但是通過參與項目的方式來提升能力，則是一種更高速、有效的方式。

提升團隊能力的方式有很多，但是受限于業務進度，我們需要選擇一種合適的方式，在時間有限的情況下發揮出更好的效果。在項目實施的過程中，相關能力的提升方式如圖2-2所示。

日常培訓的過程如下：

（1）通過進入日常開發之前的培訓、閱讀文檔等一系列的方式，來幫助他們培養基本的能力。

（2）進入開發后，則通過代碼檢視、代碼規范及原則等一系列的方式，來幫助他們寫出符合需求的代碼。

（3）在項目開發過程中，我們可能會通過結對編程的方式，來幫助他們更好地成長。

如圖2-2所示，在這個階段里，我們提升能力的目標是，讓每個人在完成功能的同時，還要保證質量。

1．技術分享（Sessions）

能力提升有多種方式，其中使用得最多的招式便是技術分享。繼續按照是和否的分法，我們依舊可以將其分為兩類：

◎ 項目相關的技術分享。它所圍繞的是項目所使用到的技術。

◎ 非項目相關的技術分享。做一些項目相關的技術棧，或者完全以項目為主的技術分享。

對于非項目相關的技術分享來說，主要目的在于，知道有這樣一件事，以及它能做些什么。對于絕大部分的人來說，僅僅是聽半小時、一小時的分享，是不可能掌握相關的技能的。整個分享結束，掌握得最好的人，便是那個做技術分享的人。因此，就結果而言，做分享的人是最能學到東西的。我們也往往會將相關的分享，交給團隊的新人來做。

當我們做一個技術分享的時候，必然需要準備一系列的資料，還要反復加工相關的東西，這樣才能向其他人介紹相關的技術。如果團隊中有技術經驗豐富的人，就能指出講述過程中的一些錯誤。做分享也能加深雙方的印象。此外，技術分享還能幫助新人練習一系列非技術相關的技能，諸如表達、資料搜集，等等。

如果想在項目內制定分享的機制，需要人人都進行技術分享，那么就要有相應的鼓勵政策。此外，需要注意時間和地點的選擇。若是分享可以在上班時間完成，就應該在上班時間完成。否則，團隊中的大部分人會覺得這是一種累贅，覺得分享是一個不好的事情。

通常開啟技術分享的人是項目的技術負責人。在項目啟動階段，介紹一系列與項目相關的內容和知識。對于這種類型的分享，一般在時間長度上控制在30～60分鐘之間。除了介紹理論，還需要配合實踐示例，以加深大家的印象。

2．工作坊（Workshop）

對于聽的人而言，聽別人講與技術相關的內容，哪怕再有興趣，一段時間后，我們也會忘得一干二凈——這大抵是人的本能吧。平時工作中用不到的內容，我們早晚會忘記的。如果覺得一個技術有用，需要用更有效的方式來學習和練習技術，例如工作坊（Workshop）。

工作坊是一個以練習為主，以理論為輔的掌握新技術的方式。它在介紹新技術的過程中，會設計與之配套的大量練習。參加工作坊的人，都需要參與到這些練習中，以掌握相關的技能。由于這些練習是現場進行，它能讓參與者相互進行溝通和交流。在練習過程中，若是遇到一些問題，也能互相幫助，快速解決遇到的問題。正因為如此，與私下的個人練習相比，它能更快速地掌握相關的技能。

與工作坊相似的，還有一個名為Bootcamp的練習事件。它適用于復雜的、抽象的技術，如面向對象和設計模式。工作坊著重于讓參與的人掌握一門技術；而Bootcamp則只能幫我們技術入門。

3．面向新人的結對編程

結對編程，是現代軟件工程一直在尋找的一種有效的知識傳遞方式。結對編程存在多種模式：

（1）Navigator-Driver（領航員-駕駛員式）。Navigator關注如何實現功能，Driver則負責實現。并且由Navigator告訴Driver如何實現相關的代碼。

（2）Ping-Pong模式。常見于TDD開發模式，由A編寫某個功能，B實現測試，隨后調反過來，由B編寫功能，由A實現測試。

（3）鍵鼠模式。即編程時，由一方掌握鼠標，一方掌握鍵盤。這種模式的主要目的是，幫助新人快速熟悉使用編輯器的快捷鍵。

對于新人而言，我們往往會采用Navigator-Driver的模式來進行結對編程。過程中，只提供相應的思路，由項目中的新人來實現相應的業務。而作為一個經驗豐富的程序員，我們除了指導他/她更好地使用工具，諸如如何更好地使用IDE和Git命令等。我們還需要觀察新人在過程中犯的錯誤，有些錯誤，我們可以直接指出來，并幫助其改正；有些錯誤，則是等他犯了之后，幫助其解決問題，以積累經驗——有些錯誤若是不犯，可能并不會意識到有錯誤。

4．對內輸出和對外輸出

輸出是最好的輸入方式。在輸出的過程中，需要重新梳理知識體系，也因此輸出變成了一個輸入的過程。這種重新輸入的輸出，可以分為對內輸出和對外輸出。

對內輸出。我們前面提到的技術分享、工作坊、結對編程等，都是一些對內輸出的形式，它可以加快新技術在團隊和組織內部的實施。

對外輸出。這部分內容便是我們在日常的技術社區里經常看到的各式各樣的技術團隊的輸出方式。在國內，越來越多的公司和企業，都在進行對外輸出和分享，比如撰寫某項技術在公司的實踐、某些新框架的試用，等等。對外輸出的目的有兩個：

（1）練習技術上的技能，提升相應的軟技能。

（2）擴大團隊的影響力，以便未來招聘到更多人才。

輸出方式多種多樣，有翻譯、寫作、開源項目、技術分享等。我們既可以翻譯技術文章，也可以翻譯技術書籍，還可以撰寫團隊相關的技術文章、技術書籍。諸如360奇舞團的相關開發框架和技術周刊，餓了么團隊開源的前端組件庫，廣發證券團隊翻譯的Angular相關書籍等，這些都是很好的對外輸出示例。

5．其他

此外，一旦內部沒有資深的人可以對我們進行培訓的時候，我們便需要考慮使用外部力量來提升我們，即外部培訓。由于筆者并沒有遇到內部無法消化的問題，對于外部培訓的了解并沒有那么深刻。從筆者的角度來看，如果只是為了學習新技術，那么可以嘗試在團隊中一起學習和練習。在學習和練習的過程中尋找專業的人士、搜索相關的資料，以更細致地掌握相關的內容。

不得不提及的一點是，以上幾種方式，都是筆者在ThoughtWorks經歷的一些提升方式。在不同的公司里，也會有各自不同的提升方式，總體上存在一定的差異。但是，大體上并不會有太大的偏差，只是有的公司不一定有這么全面的培訓體系。