如果依賴的 API 不就緒,其他團隊就沒辦法進行并行開發,他們需要真實 API 或模擬 API 才能繼續開發工作;
生產者團隊和消費者團隊都可以定義 API(通過 Swagger、Proto、WSDL,等等);
開發團隊采用看板開發模式(沒有 Sprint 或迭代);
開發人員正在編寫自動化測試;
API 模擬由 API 消費者團隊(而不是 API 生產者團隊)創建;
API 定義是穩定的,不會發生重大變更。如果發生次要的變更,需要在團隊之間傳達;
當真實 API 就緒時,可以立即用它們進行集成測試;
開發團隊可以使用該電子表格中的其他表格來實現更多的 API 模擬(例如加快構建速度、處理更多的故障場景,等等),但出于簡單起見,我們不把它們納入到這個模型。如果這些假設與你的開發流程相匹配,我們很愿意一起討論一下,并為你們創建合適的模型。
在關鍵路徑上使用 API 模擬
我們已經看到 API 模擬適用于有兩個開發團隊相互依賴的場景,對于需要多個團隊一起開發新產品或新功能的項目,也同樣適用。
通過 API 模擬來并行化開發工作——以簡單的兩個團隊為例
團隊 A 的新功能在發布到生產環境之前需要依賴團隊 B 的東西。
圖 2 給出了一個描述此種情況的甘特圖。團隊 B 在開發新功能,他們的 API 在第 20 天才能提供,團隊 A 開發的新功能在第 35 天就緒,然后開始做集成測試。最后,新功能在第 37 天部署到生產環境。
假設這兩個團隊決定采用 API 優先的開發模式,開始定義團隊之間的業務契約。他們定義系統之間的 API,并使用了 API 模擬,新功能在第 26 天部署到生產環境。對于這種場景,在團隊 B 的部分成員已經開始開發新功能的同時,其他成員和團隊 A 的部分成員在幾天內定義好系統的 API。通常,團隊 A 可以開始培訓如何使用 API 模擬,并在大概 4 天的時間里創建好模擬 API。團隊 A 有了模擬 API 就可以開發他們的新功能,并在開發完成之后與團隊 B 集成,這可能比使用真實 API 要多花一天時間,畢竟模擬 API 不可能完全精確地模擬真實系統,要與真實 API 順暢集成,需要做一些細小的改動。
要想加快速度,還有另一種選項,就是將模擬 API 外包給第三方供應商。如果模擬 API 外包出去,那么新功能就可以在第 20 天完成。
因為采用了 API 模擬和 API 優先的開發模式,我們加快了發版速度,可以在第 20 天發版,而不是第 37 天。
這樣團隊 A 就有了更多的喘息時間,因為他們在第 66 天就完成了開發工作,而不是第 70 天。如果其他團隊出了什么差錯,他們有更多的糾錯余地。
在看了更新過的項目計劃之后,團隊 B 意識到自己是離交付截止日期最近的。他們本來有 10 天時間(距離第 70 天),但現在只有 6 天(距離第 66 天)。他們決定開始與團隊 C 并行開發。在與團隊 B 溝通過后,團隊 C 意識到他們也可以與團隊 D 并行開發。這么看來,這個功能應該可以在第 30 天交付,而不是第 70 天。見圖 6。
圖 6:所有團隊都并行開發
值得一提的是,如果有必要,各個團隊使用模擬 API 的順序是可以調換的。例如,如果團隊 C 率先使用了模擬 API 并提前幾天交付功能,這樣就可以降低團隊 B 和團隊 A 的風險,為后續 API 定義的變動騰出了一些緩沖時間。
由于不可預見的復雜性,計劃的時間越長,里程碑延后的風險就越大——你可以盡早使用 API 模擬開始開發工作,將里程碑向左移,并盡早識別出關鍵風險。
盡管這個模型做了一些關鍵性的假設,但它所傳達的要點在于在采用 API 優先開發模式時如何通過 API 模擬來并行化團隊的開發工作。
Wojciech Bulaty專攻企業軟件開發和測試架構。他在寫作中融入了十多年的親身編程和領導經驗。他現在是 Traffic Parrot 團隊的一員,通過提供 API 模擬和服務虛擬化工具幫助微服務開發團隊加速交付、提高質量并縮短發布時間。你可以在推特上關注 Wojciech,也可以在LinkedIn上聯系他。