結束了一天的工作，拖著疲憊的身軀，坐在馬桶上，回顧一天的工作，發現有那麼多的不值得，明顯沒有價值貢獻的任務，卻幹了一大杯；明明可以好好工作，卻硬要表演得很忙似的；明明有機器幫我們幹活，卻硬著頭皮逐字逐句讀程式碼；明明別人家已經持續交付了，而我們依然覺得批次來一把更經濟實惠。哥很難，難的不是工作太辛苦，而是明明可以更簡單，卻硬要搞得很複雜，今天，我們試著扒一扒軟體研發過程中的常見誤區。

關注需求 vs 關注任務

在辦公室裡看得最多的場景，無非是每一個人都並行工作在很多事務上，忙至深夜。而“努力”的結果還是交付時間一而再、再而三地延期。事務性工作的本質還是任務驅動，關注在基本的開發任務，因為任務是片段的、部分的，缺乏產品需求及目標的整體性。個體上，雖然任務完成很多，但因為缺少與其他任務在產品需求層面的拉通，也難以保證產品需求交付的按期交付。這就像忙碌的倉鼠，雖然不停歇地在滾輪上奔跑，但依然在原地。

而軟體交付的本質，是持續、快速、高質量地交付有效價值。業務或產品需求才是有效價值的體現。需求來源於使用者問題和業務目標，可以從業務目標、業務場景、功能需求等幾個不同的維度分解需求，分解完後的需求，依然保持續其完整性、獨立性，可測可釋出，每一個需求的交付，都是一次假設驗證的過程，是業務價值創造的機會。

所以，在軟體交付協作中，透過精益交付看板視覺化需求流動，才能做到價值驅動；只有透過需求，以一個整體視角，視覺化“端到端”的價值流，才能做到在協作過程中的前後（職能）拉通。始於使用者問題的提出，終於使用者問題的解決。

所謂，Outcome over output，就是儘可能在最小化 output 的同時，最大化 outcome。output 是任務產出，outcome 是需求結果。站在老闆的角度，才不看你完成了幾個任務，他關心的是交付了多少特性需求。

【要訣】以需求為單位進行協作，更關注業務價值視角。透過精益交付看板視覺化需求交付過程。

流動效率 vs 資源效率

資源效率，指的是那種視人為資源，關注人效，製造區域性繁忙。然而區域性資源效率的提升，並不能使整體效率提升。這是為什麼呢？

因為，產品交付的整個過程，需要協同所有職能，包括（但不限於）業務、產品、開發、測試和運維。關注資源效率，一是軟體的交付取決長短板；二是每個職能進行區域性效率最佳化，容易形成效率豎井，即區域性來看，效率很高，產出了很多中間製品，豎井之間的交接形成了批次，整體效能並未得到任何改善。

以流動效率為核心，就是要以需求為流動單元，從使用者來，然後快速流向使用者，加速需求的 Time to market。流動效率的快慢直接決定了使用者響應、獲取反饋的效率。以流動效率為核心，必須拉通交付流程中的所有職能，打破組織壁壘。同時，聚焦流動效率，可以幫助組織即時暴露協作中的問題，如阻塞、等待等，這些問題可能是協作問題，也有可能是工程能力問題。

軟體研發過程中的主要問題，永遠都不是閒著的資源，而是閒著的需求。

做個不太恰當的比喻，關注資源效率的老闆是計時發薪，關注流動效率的老闆是計件發薪。你們老闆屬於哪一類呢？

【要訣】資源效率，是關注個人人效，關注人力的利用率，繁忙的區域性資源效率，並不能在整體上帶來流動效率的提升。

關注問題 vs 關注活動

殭屍式站會，指的是那種照搬方法論框架，追求形式主義的站會現象。這一現象，人們往往會面臨“站會是要站著開，還是坐著開？計劃會議需要分上下午兩場，還是集中在下午？”這樣的問題。過分關注活動的形式，而忽略了問題本身就是本末倒置。

方法論框架的目的是為了交流理解的需要，而不是生搬硬套，照本宣科。軟體專案協作，應該關注問題的解決，阻塞的移除，關注需求如何快速從前一道工序流動到下一道工序。專案協作中，應該關注：

當前有哪些阻塞

哪些到期應該交付，而不能交付的需求

依賴有哪些

交付的價值流中是否有中斷

當前交付過程中的瓶頸有哪些

我們建議的站會 6+1，是對協作中關注問題的一個指南。

我們不建議照搬哪個方法論的框架，如站會是要站著開，還是坐著開？計劃會議需要分上下午，還是一個下午？過分強調活動的樣式，就是形式主義。方法論框架的目的是為了交流理解的需要，而不是生搬硬套，照本宣科。

一切不以解決問題為目的的形式主義都是耍流氓。

【要訣】站會 6+1。

跨職能團隊 vs 單一職能團隊

以需求價值驅動，流動效率為核心，意味著在協作過程中，必須以業務驅動，拉通從業務、產品，到開發和測試的各個職能，跨職能協同。單一職能的團隊，容易形成職能豎井，導致各個職能在區域性繁忙，但是整體系統協作效率低下。

我們假設團隊內部的溝通效率始終大於跨團隊溝通的效率，透過組建跨職能團隊，可以有效提升在協作中的等待問題，讓整個團隊關注在需求的交付上，而不是任務的完成。跨職能團隊可以是實體團隊，如果沒有條件，組建虛擬的跨職能團隊也是一個非常不錯的嘗試。

【要訣】可以虛擬組建跨職能團隊，拉通從業務、產品，到開發和測試的各個職能，跨職能協同。

程式碼掃描 vs 程式碼評審

人們過分強調程式碼評審（Code Review）的作用，而忽視了自動化程式碼掃描的能力。程式碼評審本身並不能直接提升程式碼質量，程式碼評審是社交化程式設計的一種手段，旨在程式碼評審中，形成促進團隊內部知識共享，提高團隊整體水平，確保團隊統一規範。其本身是員工程式設計技能培養的一種手段。

程式碼掃描，可以自動化地完成程式碼質量的檢查，藉助技術手段，促進程式碼的高可見性，如程式碼的重複度、複雜度、扇入扇出依賴度、領域語言識別等等，這遠比人工的檢查效率高出許多。同時，結合靜態程式碼掃描和規約掃描，把一般性的問題可以快速識別出來，如格式問題、基本的語法錯誤、潛在的記憶體問題等等；而對於一些記憶體問題及效能問題，也可以透過動態檢查的手段來檢查，如 C/C++中，常用 Valgrind，llvm-clang，efence 等等小工具就可以完成相應的動態檢查。

對於 Java 開發者而言，Java 開發手冊是一個不錯的手段，同時，雲效程式碼管理工具，內建程式碼安全掃描等功能，可以抓出程式碼的大部分安全問題。

【要訣】程式碼評審是開發者能力培養的手段、而非質量守護手段。藉助程式碼規約，透過程式碼掃描完成程式碼質量檢查。

持續釋出 vs 批次釋出

持續釋出，就是持續地釋出，即持續、快速、可靠地釋出軟體。持續釋出，有助於問題的快速發現，同樣，持續釋出有助於工程效能問題的發現，需要做到持續釋出，意味著：

需要建立統一規範的釋出流程，以工具手段，將流程內建在工具上，防止過多的人工參與引入不必要的問題和安全風險。

建立自動、完善的質量守護體系。

自動化的部署手段，部署儘量做到無人工介入，如採取 Docker 映象方式，程式碼與配置分離，一次構建多次部署。

持續釋出意味著持續獲得反饋，每天的工作有反饋。更多的反饋和持續改進的機會，有助於質量及工程效率的提升。基於雲的一站式程式碼託管和持續釋出系統，可以快速發現，即時反饋。讓線上釋出協同成為可能。

批次釋出意味著大爆炸式整合，問題集中爆發，傳統的以瀑布或大迭代方式的開發方式，一般都是批次的釋出方式，在當前業務不確定性如此強，變化如此快的大環境下，這種批次的釋出越來越不受待見。

【要訣】建立統一發布流程和規範，透過工具或雲原生技術實現一次構建多次部署。

自動測試  vs 人工驗證

持續釋出的效率，在很大程度上受制於質量驗證的效率，人工驗證的方式，完全依賴於人工驗證的速度，對於網際網路多端多環境的開發方式，人工驗證的手段完全跟不上工程效率的需要。採用自動化的迴歸的方式，讓開發者每次提交都能快速獲得反饋，安全放心，有信心。

常見的自動化測試手段可以用於基於 Robot Framework, Cucumber 等工具進行介面的自動化測試，服務間呼叫的契約測試，流量回放等等。

這樣，有了自動化的迴歸手段，開發者提交程式碼，自動觸發持續整合系統的迴歸驗證，在第一時間就能獲得反饋，有問題快速進行定位修改，再提交，再回歸。

【要訣】自動化迴歸，自動化測試，持續反饋。

下圖為基於雲效構建的 DevOps 協作示例：