研究表明，相較於傳統辦公室環境，遠程工作團隊的效率更高。這引出了一個問題：遠程軟件工程師的效率提升到了什麼程度？
想要了解遠程工作如何影響團隊表現的管理人員可能會設定一些關鍵績效指標。但是，並不是所有的KPI都適用：像代碼行數、工作時間和修復的錯誤這類數據可能會誤導對生產力的判斷。這些不成熟的指標衡量的是錯誤的方面，很容易被操作，而且它們無法提供任何有助於個人或團隊提升表現的真實或可操作的洞見。
選擇正確的指標來衡量是關鍵，這樣才能確保軟件開發項目按計劃順利進行，同時不破壞團隊的士氣。通過提供合適的工具來賦能開發人員高效工作，這就是將KPI融入業務運作的理由。
爲什麼 KPI 在軟件開發中很重要？
在軟件開發中，採用KPI旨在確保與業務目標和目的保持一致。但是，調查表明，有90%的組織仍然靠直覺來設立有效的工作流程，尤其是在執行策略、衡量和規劃成功方面，他們遇到了挑戰。
爲了避免依賴直覺而導致的效率和執行問題，企業應該設置清晰的目標和高級策略來衡量軟件開發過程的生產力和效率的關鍵績效指標（KPI），並確保這些KPI與他們目標的質量相匹配。
在制定這些KPI時，技術管理者需要問自己一些問題：
- 期望達到什麼樣的結果？什麼因素會影響這個結果？
- 這個結果爲什麼對公司很重要？
- 可以採取哪些措施來評估這些結果？
- 哪個技術團隊將對業務活動的成功負責？
- 在達到期望結果之前，多久需要檢查一次進度、生產力和績效？
爲了確保KPI與軟件開發項目正確對齊，可以採用SMART技巧，意味着KPI應該是：
- 具體的
- 可測量的
- 可達成的
- 相關的
- 有時間限制的
通過引入更好的規劃機制並在組織的不同層面納入KPI，組織將能夠：
- 增加投資回報率、減少成本和加班、優化工作負載管理，並找出需要改進的領域；
- 全面瞭解軟件產品開發的所有流程、資源和環境；
- 通過識別低效率、障礙和其他導致失敗的因素並找到解決方法來進行改進；
- 提供具體的量化工具，以評估開發團隊在完成項目目標方面的效率；
- 確保短期和長期目標按時、在預算內完成；
- 根據反饋調整KPI，並根據項目需求進行定製；
- 區分用於監控績效目標的高級KPI和專注於部門成功的低級KPI。
軟件關鍵性能指標類型
軟件開發的關鍵績效指標（KPI）有五種主要類型：
- 形式代碼指標：這些指標用來評價代碼的質量，確保團隊內部不同開發者寫出來的代碼風格和質量是一致的。常見的指標包括代碼的總行數、代碼的路徑長度以及代碼複雜度等。
- 生產力指標：這類指標評估開發者在項目開發過程中投入的時間和努力。常用的指標有項目從開始到結束的時間、處理任務的週期和項目進度的快慢。
- 測試指標：這些指標通過測試的全面性，比如代碼測試覆蓋率、自動化測試的比例或是生產階段的缺陷數量，來衡量產品質量的好壞。
- 運營指標：包括平均故障間隔時間（MTBF）和平均恢復時間（MTTR），用來分析軟件的穩定性和維護效率。
- 客戶滿意度指標：通過淨推薦值（NPS）、客戶滿意度得分（CSAT）和客戶努力得分（CES）等指標，幫助公司瞭解客戶對軟件的滿意程度。
關鍵的理念是，指標是用來指導而非直接衡量的工具。通過設定具體的指標，可以預測和改善團隊的表現。
要讓開發團隊保持正確的發展方向，就需要利用這些關鍵的績效指標。
交付時間
這一KPI有助於描繪出開發過程的趨勢圖，並評估把一個想法轉換成成品需要多少時間。通過創建交付時間分佈圖來估計從概念到完成的整個過程需要多長時間。
這種交付時間分佈圖對於改善工作流程十分有用。明白在何時何地設定目標可以幫助穩定工作流程並提高預測性，爲組織帶來新的機會。
效果圖截取自：PingCode
週期時間
指的是一個缺陷、功能或任務從開始到結束所需的時間。這可以更詳細地反映出團隊的工作速度和效率。根據問題的類型，比如是缺陷修復還是新功能開發，可以有不同的週期時間分類。
使用項目管理工具，比如JIRA，可以追蹤週期時間，即從任務開始到完成的整個過程。週期時間可以揭示工作流程中的任何瓶頸、障礙或問題，並幫助設定合理的期望值，確保其他團隊的問題能被開發團隊有效解決。
計算週期時間的方法是用結束日期減去開始日期。這個公式有助於比較不同任務的週期時間，讓軟件開發團隊更清楚地理解在各個任務上的時間投入。
效果圖截取自：PingCode
累積流動
累積流動圖是一種顯示所有正在進行、待處理和已完成任務的視覺工具。通過不同的顏色，它展示了任務在項目的不同階段的分佈情況，比如“已確認”、“項目已批准”、“任務正在進行中”、“工作即將完成”、“調整中”、“項目準備就緒”和“任務已完成”等。
這種圖表涵蓋了工作流的三個關鍵方面：工作的吞吐量（即完成的工作量）、任務完成所需的週期時間以及正在進行的工作量。累積流動圖能幫助跟蹤開發團隊的工作產出，確保他們對其持續的表現負責。
效果圖截取自：PingCode
流動效率
流動效率是衡量等待工作完成所需時間的指標。它通過比較剩餘時間和正在進行的工作量來揭示效率低下的地方，指出哪些地方的工作沒有按計劃進行。改進流動效率意味着減少等待時間，從而改善項目管理和工作分配。要計算流動效率，只需將投入開發的時間除以整個週期的時間。
衝刺燃盡
衝刺燃盡圖是敏捷Scrum方法中的一個關鍵指標，它展示了項目中剩餘的工作量以及時間進度。通過在圖表的y軸上標記尚未完成的工作量，在x軸上標記時間，可以觀察團隊的工作進度是否符合計劃，以及項目的規劃是否準確。
它還可以幫助你更有效地計劃你的衝刺，將工作分配成細小的部分，以避免你的團隊過度勞累。
這段內容講述瞭如何通過將工作劃分爲更小的部分來更有效地規劃衝刺，以此避免團隊成員過度工作。
效果圖截取自：PingCode
速度
速度這一指標反映了軟件開發者在一定時間內完成了多少具備交付價值的工作。根據一個開發者博客的補充，交付價值通常指的是那些已經完成並且準備好發佈或測試的功能的數量。
速度是通過故事點數或功能票證來衡量的，它能夠幫助進行以下幾方面的工作：
- 設置交付工作的預期。
- 對即將到來的衝刺進行現實的預測。
- 確定團隊是否遇到了障礙，這通常表現爲速度的下降。
- 檢查通過改變某個流程是否能夠獲得更好的結果，即速度是否保持穩定或有所增加。
- 識別在衝刺計劃過程中可能未曾考慮到的挑戰。
要計算軟件開發團隊的工作速度，瞭解他們的平均速度至關重要。比如，如果一個團隊在第一輪衝刺中完成了80個故事點，在第二輪和第三輪分別完成了90個和130個故事點。
效果圖截取自：PingCode
這三次衝刺的平均故事點數是100，這個數字可以用來估算團隊完成項目所需的平均時間。例如，在實際的軟件開發中，如果一個項目需要完成500個故事點，那麼團隊可能需要進行五輪衝刺來完成所有開發工作。一般來說，更高的速度表示團隊的生產力和表現更好。
如果你發現團隊的速度指標每週波動很大，這可能意味着有些問題阻礙了開發者的績效。如果速度與平均值相比有明顯偏差，這可能是一個警示，表明流程中可能出現了問題。那麼，問題在哪裏，應該怎麼解決呢？
以下是一些建議，幫助你測量和理解速度：
- 如果經過多次衝刺後，速度沒有變化，考慮將其他因素納入考量；
- 對於即將進行的軟件開發，可以使用過去三次衝刺的平均速度來做出預測；
- 如果任務的增加或減少，速度的計算方式可能需要調整。
MTBF（平均故障間隔時間）和MTTR（平均修復時間）
軟件故障是難以避免的，軟件開發中兩個重要的指標是平均故障間隔時間（MTBF）和平均修復時間（MTTR），它們衡量的是軟件在發生故障後恢復的能力。
MTBF是指兩次故障之間的平均時間，通過將軟件的總正常運行時間除以故障發生的次數來計算。而MTTR是指修復軟件故障所需的平均時間，同樣是通過將總修復時間除以故障次數來計算。這兩個指標可以幫助評價軟件開發團隊的整體效率和表現。
代碼變動
在軟件發佈前，確保產品穩定性極爲重要。代碼變動指標通過追蹤一定時間內添加、編輯或刪除的代碼行數來幫助公司監控開發生命週期和軟件工程師的工作質量，特別是識別哪些開發階段最不穩定。
通過分析代碼變化來發現問題，比如哪些修改引發了大量變動，可以避免發佈不穩定的代碼。
代碼覆蓋率
在軟件開發的整個生命週期中，代碼的質量扮演着至關重要的角色。代碼覆蓋率是一個評估軟件測試質量的重要工具，它幫助軟件工程團隊評價測試驅動開發的實踐效果、分析整體的代碼質量，以及在測試執行期間實際運行了多少代碼行。如果沒有這個關鍵績效指標（KPI），就幾乎無法有效地進行生命週期管理和數字產品的測試。
代碼覆蓋率的計算可以檢測哪些代碼行被測試執行過，從而幫助識別錯誤和需要調試的地方。計算公式是：CCP = (A/B)*100，這裏的A是在測試中執行的代碼行數，B是系統中總的代碼行數。
開放請求
開放請求（或稱爲未處理的拉取請求）是衡量團隊協作效率的一個指標。拉取請求是開發人員請求團隊其他成員審查代碼更改或提供反饋的一種方式。
如果這些請求沒有得到及時的處理，就會保持“開放”狀態，這可能會阻礙項目的其他部分或某個衝刺的進展。定期檢查未處理的拉取請求可以幫助發現功能交付過程中的瓶頸，從而爲代碼審查過程分配更多的時間或資源。
吞吐量
吞吐量是衡量團隊總體工作成果的指標，包括了所有準備好測試和發佈的功能、任務、缺陷或其他小事項的總數。這個指標通常在一定的時間段內測量，比如一週或一個月，並且會持續跟蹤，讓你能夠看到團隊的工作是否保持一致。
測量吞吐量的目的是檢查工作成果是否符合你的目標。如果你的目標是解決軟件中的缺陷，那麼你應該能看到一個健康的解決缺陷票據的比例。如果你的焦點是增加新功能，那麼完成的新功能票據應該會多於瑣事和缺陷票據。通過參考這些票據來精確測量吞吐量，可以幫助軟件開發者更高效地工作。
隨着遠程工作成爲新常態，選擇能夠真正幫助軟件工程團隊改善和達成開發目標的正確關鍵績效指標（KPI）變得至關重要。同時，確保這些KPI與項目相關且易於理解、可執行、可測量、可見，並且及時，也同樣重要。
避免過度管理的KPI和建議
設立KPI並努力達成它們會給軟件開發團隊帶來額外的壓力。過度管理開發人員可能會創造出一個不利於團隊成長的環境。以下是一些建議，可以幫助避免這種情況：
- 儘量減少在開發過程中的干預
- 管理關鍵績效指標，而不是每個小任務
- 信任你的團隊
- 鼓勵開發人員獨立做決策
- 定期賦予團隊成員比你感覺舒適的更多責任
軟件開發的KPI對於整個編程過程至關重要，因爲它們幫助管理層評估和排序目標及團隊目標。這些指標分爲四個主要類別：開發團隊的生產力、軟件性能、缺陷管理、以及可用性和用戶體驗。這些類別根據其關注的特定領域分類，每一類都提供了項目整體狀況的重要視角。對所有相關方來說，瞭解各種KPI、它們的應用以及計算方法是非常關鍵的。