互聯網開發如何保證後台交付質量，聯調效率？

01-04

作為iOS客戶端開發人員，後台介面質量低下，聯調效率低的令人髮指，上線質量也差，趕腳都快成了後台測試人員
1、一天忙忙叨叨的，都在瞎忙，剛開發完，介面變了；剛準備測一下，服務掛了；都提測了，還在改邏輯，所謂的介面完成就是有這個介面了，至於能否跑通，估計自己都不知道
2、後台確實很複雜，介面組、業務邏輯組、數據組、有時還要涉及到平台組等3、4個團隊，伺服器也分為線上、線下、staging等等，並且同一時間在伺服器上部署代碼分支有限，簡單說就是超複雜，聯調通了趕腳都應去買彩票
3、也嘗試過一些方法，如後台開發完成，客戶端再開發，但實際上很多需求都是前後台並行開發。另有一些新想法，還沒實施，如後台各團隊要有單測，交付完成標準是單測通過等等，組織大了，問題也多了
想請教各位大神，是否遇到類似問題，如何解決的，請不吝賜教，多謝！！！

先說答案：

上真正的敏捷開發流程，而不是各種裝 X 的偽敏捷。

想請教各位大神，是否遇到類似問題，如何解決的，請不吝賜教，多謝！！！

這類現象和問題在中國的軟體江湖上其實是很常見的，因為國內一直流行的大多是偽敏捷（我估計至少佔八成以上）。

解決這些問題的第一步：

根因分析

在 CMMI、XP 中這個實踐叫 Root Cause Analysis，在太極敏捷中叫（畫）因果圖。

後台介面質量低下，聯調效率低的令人髮指，上線質量也差，趕腳都快成了後台測試人員

出現這種現象，不要告訴我這是敏捷開發。顯然整個開發流程都沒理順嘛，這是手忙腳亂的偽敏捷（Pseudo Agile）開發。

整個系統的首席架構獅、QA 都 shi 哪去了？

並且同一時間在伺服器上部署代碼分支有限

難道用的是 CI？

也嘗試過一些方法，如後台開發完成，客戶端再開發，但實際上很多需求都是前後台並行開發。

沒有特殊情況，當然是前後端並行開發啰。前者是種比較愚笨的開發流程。

另有一些新想法，還沒實施，如後台各團隊要有單測，交付完成標準是單測通過等等

單測（class testing）難道不是起碼的要求？

不知你說的單測的具體含義。一般來說，把小粒度的單測通過作為 subsystem 的交付標準是錯誤的，起碼要通過子系統的功能測試（或冒煙測試）。

一天忙忙叨叨的，都在瞎忙，剛開發完，介面變了

前後端之間的重要介面怎麼能隨便說改就改呢？沒有專人負責協調這件事？

關鍵介面的設計至少應該穩定一小段時間吧，比如在一個迭代內，或一周。

介面的設計這麼脆弱，是不是設計能力的問題？

「但實際上很多需求都是前後台並行開發」

本來就是這樣的。所以分成一堆人做app一堆人做server是不正確的，正確的是按照feature分，這個feature只要涉及到app和server那就都由他來做。這樣從一開始app和server就是一起測試的，再也不需要那個傻逼的聯調階段了。

1. 開測試伺服器，先測試，後上線。這樣可以保證上線質量。

2. 介面文檔一定要寫清楚，包括各種用例和時序圖。有改動，先改文檔，再改代碼。

3. 介面文檔雙方確認以後，應該儘快在測試伺服器上實現，不需要實現業務細節，只要保證介面交互的正確就可以了，然後客戶端就可以通過測試伺服器來測試了。

不是IOS程序員，做的是手機晶元程序，負責幾個模塊。只是想說，design，coding，PC上驗證，target上驗證，硬體驗證都自己做。這樣溝通成本低，效率高。

涉及到介面，確如知友所訴，要寫文檔，要review。修改需求要修改文檔，最重要的是要持續跟進提需求的人的反饋，每次做的修改做好後可以私下裡跟他們確認。自己提出的需求也時常跟進確認修改。

每個人對系統的理解都有差異，有介面就有矛盾，多sync，不限於方式。

希望有幫助。

接觸過前後端聯調的業務一段時間，感覺題主這個case當中，遇到的坑主要在team之間的溝通環節。所以提幾點從溝通角度解決問題的建議。

1. 能省則省，盡量省掉溝通，能按feature開發盡量按feature開發，就像輪子哥說的，同一個feature涉及到前後端的部分都交由一個人來做，但是這種方案對人的要求比較高，而且可能會受到公司架構的阻撓，在有些以產品為維度劃分team的公司不太容易實現。

2. 投入開發之前做好需求優先順序、各個需求時間節點的確認，責任到人，然後郵件分享，這個應該是產品的事了

3. 一塊測試，這也是我想吐槽的一點，能聯調為什麼不能聯合測試？划出專門的測試時間and測試溝通渠道，比如群，確定feature優先順序之後，一個版本做完馬上扔測試伺服器上，測出問題，馬上在群里溝通解決，提高效率。

希望可以幫到題主

你覺得後台坑的同時後台也覺得你坑的概率是96%

服務端單元測試 + 持續化集成是很有效的手段。

並行開發的時候客戶端mock協議介面完全可以脫離服務端開發。

不過所有的項目管理理論和開發流程都是輔助的，主要還是人得靠譜！！

問題出一兩次可以溝通解決，總是掉鏈子就是人的問題了，不是項目管理的問題。

那時的話就兩個字兒，換人。

同意:

&> 服務端單元測試 + 持續化集成是很有效的手段。

並行開發是不可避免的. 像樓上輪子哥說的整個end-to-end feature由一個人/team完成, 是比較理想的狀況, 但實際執行尤其是公司里感覺比較難, 畢竟每人/team有不同的專長. 個人實際經歷覺得, 實際項目裡面除非團隊裡面的人都有足夠的全棧能力, 否則這個操作方式要保證質量還是比較難的.

可以考慮由客戶端給他們寫介面自動化測試, 也就是一個測試完成先於feature完成, feature完成的評判標準是通過之前寫好的測試case. 這後面兩條就是最基本的agile的概念.

不過嘛, agile的實際執行也是有很多不同情況的.

強制在開發正式程序前增加一個流程：每個服務提供方需要先開發一個模擬程序（實現所有介面正常流程及主要異常流程，具體邏輯不實現），一般介面數不多的話（不要超過30個）用不了多少時間，半天到一天時間足夠，然後相互用模擬程序跑通所有介面。然後嘛，各自干各自的活，用模擬程序代替真是程序調試、聯調。最後直接扔給測試，誰的模塊出問題了誰去加班，早幹完活的早回家。這些個模擬程序做好了以後也可以搞成自動化測試的一部分。

其實可以這樣做:跟後台對接的前台代碼(一般是網路相關的底層代碼)，由後台人員開發，你只要調他的介面就行了。

you can you up～