Anna Frazzetto
與所有技術(shù)性或創(chuàng)造性工作一樣,軟件工程團隊的效率是不能以數(shù)量來衡量的。如果僅衡量軟件開發(fā)的生產(chǎn)力和跟蹤團隊的績效,那么只需要簡單地計算一下代碼行數(shù)或工作時間即可。工作的質(zhì)量和團隊的協(xié)作會對生產(chǎn)力產(chǎn)生直接和持久的影響。軟件開發(fā)效率正變得日益靈活且相互之間具有千絲萬縷的聯(lián)系,加之敏捷性的不斷增強,傳統(tǒng)的關(guān)鍵績效指標(KPI)如今已經(jīng)失效。
為了適應(yīng)發(fā)展趨勢,我們需要重新考慮KPI,擴大團隊并重新定義當前大多數(shù)軟件開發(fā)所需要的敏捷性。如果生產(chǎn)效率不再以代碼的多少進行衡量,那么我們應(yīng)當以什么進行衡量呢?如果計時指標很難有效衡量一個Scrum(Scrum 是迭代式增量軟件開發(fā)過程,通常用于敏捷軟件開發(fā)。Scrum 包括一系列實踐和預(yù)定義角色的過程骨架。)的進展情況,那么正確的衡量指標又是什么呢?
下列這些KPI 方案或許可以幫助我們更好地了解和衡量軟件團隊的進展和效率。我們要在整個產(chǎn)品生命周期中以一種可接受和可預(yù)測的速度不斷進行改進以實現(xiàn)KPI 的終極目標。
軟件開發(fā)如今兼具了高度的戰(zhàn)略性和高度的創(chuàng)造性。每次迭代都會帶來新的洞察力、新的注意事項和新的客戶需求。那么軟件團隊是如何高效地解決這些問題的呢?
這需要一個能夠評估出現(xiàn)/ 解決率的KPI,即問題出現(xiàn)的頻率以及軟件開發(fā)團隊如何高效地管理它們。這已經(jīng)不再是簡單地以團隊出現(xiàn)了多少生產(chǎn)問題進行衡量了。新的指標應(yīng)當與質(zhì)量掛鉤,即團隊如何高效地解決了這些問題。如果問題長期沒有解決,那么團隊應(yīng)當致力于解決這些問題。如果問題在出現(xiàn)時就能夠被及時解決,那么團隊在問題解決環(huán)節(jié)將會得到很高的評分,這也意味著團隊在協(xié)作方面非常成功。
盡管敏捷項目很難通過預(yù)算和時間進行評估,但是團隊仍在朝著關(guān)鍵的最終目標而努力。實現(xiàn)這些目標的速度是衡量生產(chǎn)效率的一個重要指標。適合類似瀑布式時間表的里程碑可能并不適合靈活多變的敏捷性,不過它們?nèi)钥梢杂脕碓u估進展和速度。在敏捷性方面,速度可以用于評估每一個Sprint(Sprint 指Scrum 團隊完成一定數(shù)量工作所需的短暫、固定的周期。通常為15-30天),看看團隊解決了多少用戶問題。這一衡量方法并不是以個人完成了多少任務(wù)而論,而是看團隊解決了多少用戶問題(即用戶想要的東西)。在衡量每一個解決用戶問題的Sprint 當中,我們可以用一個進度值來展現(xiàn)軟件開發(fā)團隊的完成和交付速度。
軟件團隊的工作流在穩(wěn)定性方面如何?由于穩(wěn)定的工作流可以增強預(yù)測性,因此這是一個重要的KPI。如果跨Sprint 的工作流不穩(wěn)定,那么用戶將難以預(yù)測下一步工作和最終交付情況。穩(wěn)定的工作流可以證明團隊和項目正在步入正軌,并且能夠有效管理工作負載。
工作流的穩(wěn)定性并不是一個簡單的指標,而是一個包含了多個方面的KPI。用戶需要查看多個指標才能評估團隊的穩(wěn)定情況。例如:
· 正在進行的工作——已開始但尚未完成的項目數(shù)。
· 周期時間——任務(wù)從開始到完成需要多長時間。
· 效率——已完成的項目/ 時間單位。
對這些工作流的指標進行分析可以獲得一張團隊運作效率的整體圖。如果團隊工作穩(wěn)定,那么他們的產(chǎn)出和進度將會更加準確,對可發(fā)布產(chǎn)品的預(yù)測也將變得更加可靠。
很少有人會把團隊士氣當成一個衡量指標,但是士氣也是影響每個KPI 的一個重要因素,因為它們會影響到每名團隊成員的努力程度和創(chuàng)造力。如果團隊成員對自己的工作有自豪感,知道珍惜,有自主決策權(quán),并且能夠理解項目的目標,那么他們將會成為優(yōu)秀的貢獻者。他們開發(fā)的軟件也會變得更好,更具創(chuàng)新性。
公司只需要深入到團隊當中就可以評估出團隊的士氣情況。例如, 對每個sprint 進行觀察就不難發(fā)現(xiàn)員工對溝通、團隊合作、壓力的感覺,甚至是他們在工作中的自豪感和樂趣。如果在多個sprint 中,員工的自豪感都很低,那么公司可以展開更深層次的調(diào)查。例如,為什么團隊成員感到沮喪?是否存在需要解決的質(zhì)量、壓力或管理問題?全面了解團隊士氣的一個重要舉措是展開更為深入的談話。談話可以促進理解,提高團隊成員的參與度和協(xié)作能力。
與所有的KPI 一樣,士氣也不是一個簡單的一次性指標,其要求在一段時間內(nèi)進行廣泛的全面評估。與敏捷本身一樣,每次迭代評估都讓軟件開發(fā)中的KPI 變得更加好用。正確的KPI 并不是以高壓手段全力壓榨本已承受壓力且疲憊的團隊,而是幫助對高點和低點進行平衡,從而實現(xiàn)均衡發(fā)展。
本文作者Anna Frazzetto為Harvey Nash / NashTechGlobal 公司的首席數(shù)字技術(shù)官兼技術(shù)解決方案總裁,主要負責領(lǐng)導(dǎo)企業(yè)在北美和亞太地區(qū)擴展大數(shù)據(jù)、云計算、社交和移動技術(shù)中的數(shù)字功能與資源。
原文網(wǎng)址https://www.cio.com/article/3572371/4-softwaredevelopment-kpis-that-matter-today.html
