如何提高團隊的研發(fā)效率呢？
研發(fā)效率是在現(xiàn)代企業(yè)都關(guān)注的，注意是因為靠譜的工程師是有限的，而且軟件工程師的人力成本較高，時間成本更高。在大多數(shù)情況下，軟件工程是一個團隊活動，通過協(xié)作實現(xiàn)突破。好的想法從不匱乏，但高速執(zhí)行卻不那么容易。高效團隊會習慣于更高的標準。當研發(fā)速度停滯時，人們會創(chuàng)造性地尋找重建高速產(chǎn)出的方法，但是如果長時間停滯，也會造成人員的流失。
如何提升研發(fā)效率呢？或者說，研發(fā)速度是否可控呢？
高效的目標——方向
速度是位移和時間的函數(shù)，很多時候，位移方向的目標更容易被忽視。然而，項目失敗的最常見原因是團隊構(gòu)建了錯誤的東西。“繞樹三匝，何枝可依?！?，實際上，方向錯了，停止就是進步。
確定方向本身就是很困難的事，例如預(yù)測產(chǎn)品或市場匹配度等。通常需要關(guān)注客戶的聲音，成功不是提供一個特性，而是學習如何解決客戶的問題。理想情況下，我們希望傾聽客戶的意見，滿足他們的需求，同時只發(fā)布他們最感興趣的那20% 。
即使那些所謂具具遠見的創(chuàng)新者，也很難預(yù)測客戶到底需要什么。由于在選擇方向時需要一些猜測，因此系統(tǒng)的靈活性和可擴展性就變得至關(guān)重要。靈活性可能表現(xiàn)為開放性，最大限度地提高試驗的速度，減少對給定計劃的承諾，快速發(fā)展的產(chǎn)品，以及在決策中區(qū)分可逆和不可逆的功能特性。盡管，可擴展性使犯錯的代價比想象的要低，而“time to market”則肯定是昂貴的。
高效的感知——度量
有很多人嘗試直接觀察軟件團隊的研發(fā)效率，但眾所周知，這樣的測量是非常困難的。為了彌補這一缺陷，企業(yè)會使用員工參與度來調(diào)查與研發(fā)效率相關(guān)的問題。這樣的調(diào)查往往局限于對員工參與度和與公司目標一致性的高層次衡量，這也是OKR模式的輔助手段。利用這些調(diào)查來決定是否實現(xiàn)了高速迭代，詢問工程師實際花費了多少時間來設(shè)計和編寫代碼，工具是否充分，過程是否有效，以及技術(shù)債務(wù)的影響等。
在著手進行這類問題的調(diào)查之前，一般會承諾根據(jù)調(diào)查結(jié)果采取行動，以便這些行動對目前的調(diào)查和今后對這類調(diào)查的答復(fù)產(chǎn)生積極影響。
高效的組織——自治
可擴展性可以通過自治團隊來改進，這些團隊圍繞著有良好邊界的特定責任區(qū)形成高度的內(nèi)部凝聚力。團隊所負責的服務(wù)彼此公開API; 在理想情況下，不存在跨團隊溝通，因為與業(yè)務(wù)邏輯交互所需的全部都是API，而業(yè)務(wù)邏輯是業(yè)務(wù)團隊的責任。
服務(wù)的實現(xiàn)細節(jié)通常是不共享的，并且不存在對遠程服務(wù)所依賴的數(shù)據(jù)存儲進行私有訪問。即使服務(wù)需要不前向兼容，API的新舊版本仍然通常會在重疊的一段時間內(nèi)可用，因此業(yè)務(wù)可以在舊版本被棄用之前進行遷移。
服務(wù)的擁有者可以按照團隊自己的速度發(fā)展并發(fā)布變更，獨立于可能發(fā)生的其他變更，并在時間上與其脫鉤。這就是所謂的“無許可創(chuàng)新”。然而，確定責任領(lǐng)域之間的接口是具有挑戰(zhàn)性的，這些接口會不可避免地隨著時間的推移而演變，完美的自治永遠是虛幻的。
一組軟件服務(wù)不斷進化，就像一個鮮活的生命。發(fā)布新的接口，整個服務(wù)可能分離或合并，單個服務(wù)可能經(jīng)歷重大的重新設(shè)計或被棄用。理想情況下，內(nèi)部團隊擁有高度的自治，在組織結(jié)構(gòu)上與“高內(nèi)聚、低耦合”的軟件設(shè)計原則相一致。
基于康威定律，這些團隊提供的服務(wù)應(yīng)該是獨立的。理想條件下，不需要對所依賴的服務(wù)進行任何更改，任何團隊就可以實現(xiàn)80% 的任務(wù)。在剩下的20% 中，通過特定的接口實現(xiàn)。
在符合研發(fā)路線圖的情況下，服務(wù)擁有者會同意那些有意義的變更，但是在路線圖上的優(yōu)先級較低。這時，業(yè)務(wù)方可能會提供一個“援助團隊”來實現(xiàn)所請求的更改。援助團隊由來自業(yè)務(wù)團隊的開發(fā)人員組成，這些工程師臨時加入擁有服務(wù)的團隊。設(shè)計、測試、編碼和發(fā)布都需要服務(wù)擁有者的逐步批準; 當完成更改后，援助人員將返回到他們原來的團隊。這個方式的一個附加價值是交叉授粉，在團隊之間缺乏溝通的情況下尤其有效。
高效的方式——敏捷
產(chǎn)品開發(fā)的敏捷方法可以迭代和速度之間做平衡。
即使在需求快速變化的世界里，團隊井然有序的積壓工作也是可以的，只要最新版本用于sprint即可。團隊明確承諾從待辦列表中完成一系列任務(wù)，而作為回報，則是團隊獲得了一個不可中斷的受保護時間窗口，這是一個盡可能快速工作的沖刺。在完成這個不間斷、無波動的幸福周期之后，sprint 的成果將展示團隊履行的承諾。
在下一個 sprint 計劃會議繼續(xù)之前，團隊將進行回顧。這是一個內(nèi)省會議，其中團隊評估其達到的速度，并確定在隨后的sprint中提高速度的方法。一個誠實的回顧，建立在信任和自我意識的基礎(chǔ)之上，可以找出在進入下一個sprint之前如何“提高研發(fā)效率”。
高效的條件——專注
專注是實現(xiàn)高效研發(fā)的必要條件。
團隊希望專注于解決客戶的問題，高速實現(xiàn)所責任的業(yè)務(wù)邏輯。他們不希望不能控制自己的團隊?？煽康幕A(chǔ)架構(gòu)和基礎(chǔ)設(shè)施是無許可創(chuàng)新的助推器，更是是軟件架構(gòu)轉(zhuǎn)變的推動者。勿在浮沙筑高臺，不為繁華易匠心。
高效的土壤——文化
一個高效團隊注重培養(yǎng)一種文化，這種文化鼓勵團隊成員高效交付成果。這是一種自我強化，具有高效文化的團隊往往能夠吸引到高手。重要的是，要假定團隊成員是有才華的，與使命保持一致，并且希望高效工作。文化中對研發(fā)效率產(chǎn)生積極影響的方面包括: 多樣性和包容性、謙遜、信任、樂于學習、愿意帶著“緊迫感和重點”前進、自主性以及集體承諾取得成果的意愿等等。
高效的實現(xiàn)——工具
為了實現(xiàn)高效研發(fā)，有必要投資那些使工程師能夠高速工作的系統(tǒng)，并最大限度地將他們的時間花費在自己的責任領(lǐng)域。顯而易見，出發(fā)點是構(gòu)建、集成和部署代碼的工具和過程，以及那些在代碼發(fā)布后用來運營的工具和過程，確保代碼滿足可用性、可靠性、性能和安全性的要求。
雖然基于服務(wù)的體系結(jié)構(gòu)可能帶來自治性的好處，但跨服務(wù)邊界的故障可能更難排查。如果日志采集、傳輸、監(jiān)控、報警和問題跟蹤在各個服務(wù)之間都是通用的，那么就會很有幫助?？捎^測性的能力應(yīng)能夠進行分布式跟蹤，便于精確檢測關(guān)鍵信號和指標，并逐步細化排出空間，從而精確找到問題的根本原因。
高效的實驗——試錯
為了提高創(chuàng)新速度，需要積極尋求降低實驗成本，以便能夠做更多的實驗。高實驗率可以促進更頻繁糾錯。但實際上，高比率的實驗可以被看作是大量丟棄的想法、文檔垃圾、死代碼和失敗，造成資源的大量浪費。
成功的團隊擁抱失敗，是指做出的大多數(shù)錯誤選擇是容易逆轉(zhuǎn)的。失敗，如果處理得當，可能是一個成長的機會。錯誤并不是必要的罪惡，是做新事物的必然結(jié)果，可以被看作是有價值的。
但是，我們客觀地認識到了自己的錯誤么？！
小結(jié)
盡管大家都覺得軟件工程越來越重要，但是太多的軟件項目最終還是偏離了目標，并且超出了預(yù)算。有效的交付需要對所要的東西有一個完美的視野，同時要朝著那個視野堅定地前進，對所有的干擾視而不見，這可能是一個長期存在的誤區(qū)。提高研發(fā)效率的一個更可靠路徑是優(yōu)化研發(fā)速度，提倡高效文化，開放的實驗和學習，自治而敏捷的組織，不忘初心。
【關(guān)聯(lián)閱讀】