結束了一天的工做，拖着疲憊的身軀，坐在馬桶上，回顧一天的工做，發現有那麼多的不值得，明顯沒有價值貢獻的任務，卻幹了一大杯；明明能夠好好工做，卻硬要表演得很忙似的；明明有機器幫咱們幹活，卻硬着頭皮逐字逐句讀代碼；明明別人家已經持續交付了，而咱們依然以爲批量來一把更經濟實惠。哥很難，難的不是工做太辛苦，而是明明能夠更簡單，卻硬要搞得很複雜，今天，咱們試着扒一扒軟件研發過程當中的常見誤區。編程
關注需求 vs 關注任務
在辦公室裏看得最多的場景，無非是每個人都並行工做在不少事務上，忙至深夜。而「努力」的結果仍是交付時間一而再、再而三地延期。事務性工做的本質仍是任務驅動，關注在基本的開發任務，由於任務是片斷的、部分的，缺少產品需求及目標的總體性。個體上，雖然任務完成不少，但由於缺乏與其餘任務在產品需求層面的拉通，也難以保證產品需求交付的定期交付。這就像忙碌的倉鼠，雖然不停歇地在滾輪上奔跑，但依然在原地。安全
而軟件交付的本質，是持續、快速、高質量地交付有效價值。業務或產品需求才是有效價值的體現。需求來源於用戶問題和業務目標，能夠從業務目標、業務場景、功能需求等幾個不一樣的維度分解需求，分解完後的需求，依然保持續其完整性、獨立性，可測可發佈，每個需求的交付，都是一次假設驗證的過程，是業務價值創造的機會。框架
因此，在軟件交付協做中，經過精益交付看板可視化需求流動，才能作到價值驅動；只有經過需求，以一個總體視角，可視化「端到端」的價值流，才能作到在協做過程當中的先後（職能）拉通。始於用戶問題的提出，終於用戶問題的解決。運維
所謂，Outcome over output，就是儘量在最小化 output 的同時，最大化 outcome。output 是任務產出，outcome 是需求結果。站在老闆的角度，纔不看你完成了幾個任務，他關心的是交付了多少特性需求。工具
【要訣】以需求爲單位進行協做，更關注業務價值視角。經過精益交付看板可視化需求交付過程。性能
流動效率 vs 資源效率
資源效率，指的是那種視人爲資源，關注人效，製造局部繁忙。然而局部資源效率的提高，並不能使總體效率提高。這是爲何呢？測試
由於，產品交付的整個過程，須要協同全部職能，包括（但不限於）業務、產品、開發、測試和運維。關注資源效率，一是軟件的交付取決長短板；二是每一個職能進行局部效率優化，容易造成效率豎井，即局部來看，效率很高，產出了不少中間製品，豎井之間的交接造成了批量，總體效能並未獲得任何改善。優化
image.pngblog
以流動效率爲核心，就是要以需求爲流動單元，從用戶來，而後快速流向用戶，加速需求的 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 協做示例：