建站
咨詢
售后
建站咨詢
新聞中心
軟件研發(fā)過程中如何讓工作變得更簡單高效?事務性工作應該更關注需求還是更關注任務?是持續(xù)發(fā)布還是批量發(fā)布?本文將從七個方面聊一聊軟件研發(fā)過程中常見的誤區(qū)及正確姿勢，分享研發(fā)過程中的那些 Dos 和 Dont's。
創(chuàng)新互聯(lián)公司公司2013年成立，先為鎮(zhèn)雄等服務建站，鎮(zhèn)雄等地企業(yè)，進行企業(yè)商務咨詢服務。為鎮(zhèn)雄企業(yè)網站制作PC+手機+微官網三網同步一站式服務解決您的所有建站問題。
結束了一天的工作，拖著疲憊的身軀，坐在馬桶上，回顧一天的工作，發(fā)現有那么多的不值得，明顯沒有價值貢獻的任務，卻干了一大杯;明明可以好好工作，卻硬要表演得很忙似的;明明有機器幫我們干活，卻硬著頭皮逐字逐句讀代碼;明明別人家已經持續(xù)交付了，而我們依然覺得批量來一把更經濟實惠。哥很難，難的不是工作太辛苦，而是明明可以更簡單，卻硬要搞得很復雜，今天，我們試著扒一扒軟件研發(fā)過程中的常見誤區(qū)。
關注需求 vs 關注任務
在辦公室里看得最多的場景，無非是每一個人都并行工作在很多事務上，忙至深夜。而“努力”的結果還是交付時間一而再、再而三地延期。事務性工作的本質還是任務驅動，關注在基本的開發(fā)任務，因為任務是片段的、部分的，缺乏產品需求及目標的整體性。個體上，雖然任務完成很多，但因為缺少與其他任務在產品需求層面的拉通，也難以保證產品需求交付的按期交付。這就像忙碌的倉鼠，雖然不停歇地在滾輪上奔跑，但依然在原地。
而軟件交付的本質，是持續(xù)、快速、高質量地交付有效價值。業(yè)務或產品需求才是有效價值的體現。需求來源于用戶問題和業(yè)務目標，可以從業(yè)務目標、業(yè)務場景、功能需求等幾個不同的維度分解需求，分解完后的需求，依然保持續(xù)其完整性、獨立性，可測可發(fā)布，每一個需求的交付，都是一次假設驗證的過程，是業(yè)務價值創(chuàng)造的機會。
所以，在軟件交付協(xié)作中，通過精益交付看板可視化需求流動，才能做到價值驅動;只有通過需求，以一個整體視角，可視化“端到端”的價值流，才能做到在協(xié)作過程中的前后(職能)拉通。始于用戶問題的提出，終于用戶問題的解決。
所謂，Outcome over output，就是盡可能在最小化 output 的同時，最大化 outcome。output 是任務產出，outcome 是需求結果。站在老板的角度，才不看你完成了幾個任務，他關心的是交付了多少特性需求。
【要訣】以需求為單位進行協(xié)作，更關注業(yè)務價值視角。通過精益交付看板可視化需求交付過程。
流動效率 vs 資源效率
資源效率，指的是那種視人為資源，關注人效，制造局部繁忙。然而局部資源效率的提升，并不能使整體效率提升。這是為什么呢?
因為，產品交付的整個過程，需要協(xié)同所有職能，包括(但不限于)業(yè)務、產品、開發(fā)、測試和運維。關注資源效率，一是軟件的交付取決長短板;二是每個職能進行局部效率優(yōu)化，容易形成效率豎井，即局部來看，效率很高，產出了很多中間制品，豎井之間的交接形成了批量，整體效能并未得到任何改善。
以流動效率為核心，就是要以需求為流動單元，從用戶來，然后快速流向用戶，加速需求的 Time to market。流動效率的快慢直接決定了用戶響應、獲取反饋的效率。以流動效率為核心，必須拉通交付流程中的所有職能，打破組織壁壘。同時，聚焦流動效率，可以幫助組織即時暴露協(xié)作中的問題，如阻塞、等待等，這些問題可能是協(xié)作問題，也有可能是工程能力問題。
軟件研發(fā)過程中的主要問題，永遠都不是閑著的資源，而是閑著的需求。
做個不太恰當的比喻，關注資源效率的老板是計時發(fā)薪，關注流動效率的老板是計件發(fā)薪。你們老板屬于哪一類呢?
【要訣】資源效率，是關注個人人效，關注人力的利用率，繁忙的局部資源效率，并不能在整體上帶來流動效率的提升。
關注問題 vs 關注活動
僵尸式站會，指的是那種照搬方法論框架，追求形式主義的站會現象。這一現象，人們往往會面臨“站會是要站著開，還是坐著開?計劃會議需要分上下午兩場，還是集中在下午?”這樣的問題。過分關注活動的形式，而忽略了問題本身就是本末倒置。
方法論框架的目的是為了交流理解的需要，而不是生搬硬套，照本宣科。軟件項目協(xié)作，應該關注問題的解決，阻塞的移除，關注需求如何快速從前一道工序流動到下一道工序。項目協(xié)作中，應該關注：
- 當前有哪些阻塞
- 哪些到期應該交付，而不能交付的需求
- 依賴有哪些
- 交付的價值流中是否有中斷
- 當前交付過程中的瓶頸有哪些
我們建議的站會 6+1，是對協(xié)作中關注問題的一個指南。
我們不建議照搬哪個方法論的框架，如站會是要站著開，還是坐著開?計劃會議需要分上下午，還是一個下午?過分強調活動的樣式，就是形式主義。方法論框架的目的是為了交流理解的需要，而不是生搬硬套，照本宣科。
一切不以解決問題為目的的形式主義都是耍流氓。
【要訣】站會 6+1。
跨職能團隊 vs 單一職能團隊
以需求價值驅動，流動效率為核心，意味著在協(xié)作過程中，必須以業(yè)務驅動，拉通從業(yè)務、產品，到開發(fā)和測試的各個職能，跨職能協(xié)同。單一職能的團隊，容易形成職能豎井，導致各個職能在局部繁忙，但是整體系統(tǒng)協(xié)作效率低下。
我們假設團隊內部的溝通效率始終大于跨團隊溝通的效率，通過組建跨職能團隊，可以有效提升在協(xié)作中的等待問題，讓整個團隊關注在需求的交付上，而不是任務的完成?？缏毮軋F隊可以是實體團隊，如果沒有條件，組建虛擬的跨職能團隊也是一個非常不錯的嘗試。
【要訣】可以虛擬組建跨職能團隊，拉通從業(yè)務、產品，到開發(fā)和測試的各個職能，跨職能協(xié)同。
代碼掃描 vs 代碼評審
人們過分強調代碼評審(Code Review)的作用，而忽視了自動化代碼掃描的能力。代碼評審本身并不能直接提升代碼質量，代碼評審是社交化編程的一種手段，旨在代碼評審中，形成促進團隊內部知識共享，提高團隊整體水平，確保團隊統(tǒng)一規(guī)范。其本身是員工編程技能培養(yǎng)的一種手段。
圖片來源于互聯(lián)網
代碼掃描，可以自動化地完成代碼質量的檢查，借助技術手段，促進代碼的高可見性，如代碼的重復度、復雜度、扇入扇出依賴度、領域語言識別等等，這遠比人工的檢查效率高出許多。同時，結合靜態(tài)代碼掃描和規(guī)約掃描，把一般性的問題可以快速識別出來，如格式問題、基本的語法錯誤、潛在的內存問題等等;而對于一些內存問題及性能問題，也可以通過動態(tài)檢查的手段來檢查，如 C/C++中，常用 Valgrind，llvm-clang，efence 等等小工具就可以完成相應的動態(tài)檢查。
對于 Java 開發(fā)者而言，Java 開發(fā)手冊是一個不錯的手段，同時，云效代碼管理工具，內置代碼安全掃描等功能，可以抓出代碼的大部分安全問題。
【要訣】代碼評審是開發(fā)者能力培養(yǎng)的手段、而非質量守護手段。借助代碼規(guī)約，通過代碼掃描完成代碼質量檢查。
持續(xù)發(fā)布 vs 批量發(fā)布
持續(xù)發(fā)布，就是持續(xù)地發(fā)布，即持續(xù)、快速、可靠地發(fā)布軟件。持續(xù)發(fā)布，有助于問題的快速發(fā)現，同樣，持續(xù)發(fā)布有助于工程效能問題的發(fā)現，需要做到持續(xù)發(fā)布，意味著：
- 需要建立統(tǒng)一規(guī)范的發(fā)布流程，以工具手段，將流程內建在工具上，防止過多的人工參與引入不必要的問題和安全風險。
- 建立自動、完善的質量守護體系。
- 自動化的部署手段，部署盡量做到無人工介入，如采取 Docker 鏡像方式，代碼與配置分離，一次構建多次部署。
持續(xù)發(fā)布意味著持續(xù)獲得反饋，每天的工作有反饋。更多的反饋和持續(xù)改進的機會，有助于質量及工程效率的提升?；谠频囊徽臼酱a托管和持續(xù)發(fā)布系統(tǒng)，可以快速發(fā)現，即時反饋。讓在線發(fā)布協(xié)同成為可能。
批量發(fā)布意味著大爆炸式集成，問題集中爆發(fā)，傳統(tǒng)的以瀑布或大迭代方式的開發(fā)方式，一般都是批量的發(fā)布方式，在當前業(yè)務不確定性如此強，變化如此快的大環(huán)境下，這種批量的發(fā)布越來越不受待見。
【要訣】建立統(tǒng)一發(fā)布流程和規(guī)范，通過工具或云原生技術實現一次構建多次部署。
自動測試 vs 人工驗證
持續(xù)發(fā)布的效率，在很大程度上受制于質量驗證的效率，人工驗證的方式，完全依賴于人工驗證的速度，對于互聯(lián)網多端多環(huán)境的開發(fā)方式，人工驗證的手段完全跟不上工程效率的需要。采用自動化的回歸的方式，讓開發(fā)者每次提交都能快速獲得反饋，安全放心，有信心。
常見的自動化測試手段可以用于基于 Robot Framework, Cucumber 等工具進行接口的自動化測試，服務間調用的契約測試，流量回放等等。
這樣，有了自動化的回歸手段，開發(fā)者提交代碼，自動觸發(fā)持續(xù)集成系統(tǒng)的回歸驗證，在第一時間就能獲得反饋，有問題快速進行定位修改，再提交，再回歸。
【要訣】自動化回歸，自動化測試，持續(xù)反饋。
下圖為基于云效構建的 DevOps 協(xié)作示例：
網站欄目：軟件研發(fā)的這些誤區(qū)，你中了嗎？
路徑分享：http://www.5511xx.com/article/ccejpgc.html
