現今以敏捷(Agile)為開發精神的世界裡,傳統的KPI (Key Performance Indicators)已不再是衡量軟體開發生產力的最佳指標了。以下是重新定義出來評估軟體團隊績效、產出以及團隊士氣的衡量標準。
文/Anna Frazzetto 譯/葉庭筠
軟體開發生產力的量測以及追蹤團隊績效,可不是數一數寫幾行程式碼或工作幾小時那麼簡單。就如任何技術或創意工作一樣,軟體工程團隊的效率都不能僅就產出的數量而評量。工作品質及團隊協同合作對生產力不但有立即效應,且影響久遠。
此外,以傳統KPI來衡量新式軟體開發方式的生產力不見得恰當,如:敏捷開發的疊代(iterative)以及不斷推進的特性,會使評量顯得高流動性且相互關聯牽絆。
[CIO都在讀: 打造彈性組織 迎接未來挑戰 ]
解決辦法就是調整KPI內涵,以適應向前運作的動能、不斷擴展的團隊,以及當代軟體開發最重要的敏捷性。如果計算程式碼行數無法真實衡量生產力,那麼軟體開發需要如何評估?如果工作時數難以反映scrum進展多少,那什麼是正確的進度量測值?
不妨考量KPI以外的這些因素,來幫助我們更有效了解和衡量軟體團隊的工作進度及成效,並在整個產品生命周期裏,以更合理而可預測的步調,達到持續改善的最終KPI目標。
一、問題解決
現今軟體開發是一個高度策略性及創意性的過程。每一疊代(iteration)都能帶進新的觀點、新考量,以及客戶新加入的需求。軟體部門有多少資源來解決這些問題?
可以使用Issue提出 / 解決率來評估的KPI ─ issue(問題/議題)多頻繁被提出?軟體開發團隊能否有效管理?這並不是為了去計算軟體團隊開了多少正式環境問題的Issue。需要關切的重點是品質提升趨勢方面的事:團隊解決Issue的效率高不高?如果Issue開了很久卻沒解決,表示這個團隊無法有效解決問題。如果Issue(不論多寡)在出現後都能很快解決,則該團隊在有創意地解決問題上就得高分,表示他們的協同合作很成功。
二、速度
雖然講到預算及時程限制,敏捷式開發專案並不好預測,但團隊仍然須持續往關鍵終點邁進。了解他們多快達成目標就是一個重要的生產力評估指標。傳統的瀑布式(Waterfall)專案時程設定里程碑的作法,並不適用於講求彈性、疊代(iterative)式的敏捷專案,但還是有可能量測它的進度和速度。在敏捷專案中,速度是看每一次衝刺(sprint)中團隊完成了多少用戶需求(user stories)。重要的不是個人完成多少任務,而是一個團隊完成多少用戶需求(是指使用者需要或想要的功能)。衡量每次sprint完成的用戶需求,就會得到軟體開發團隊邁向終點及上線日的行進速率。
三、工作流程(workflow)的穩定度
軟體團隊工作流程穩定度是一個重要的KPI,因為工作流程的穩定度有助於提升可預測性。若是所有sprint之間的工作流程忽快忽慢,就會很難預測接下來的步驟及最終結果。工作流程穩定顯示出團隊和專案按計畫進行,有能力管理工作量。
[ 加入 CIO Taiwan 官方 LINE 與 FB ,與全球CIO同步獲取精華見解 ]
工作流程的穩定度並非單一個衡量標準,而是多個量測值綜合起來的KPI,用以觀察團隊工作穩不穩定,包括:
- 進行中的工作 — 已啟動但還未完成的工作項目。
- 周期循環(cycle) 時間 — 一件任務從開始到完成所費時間。
- 吞吐量(Throughput) — 每單位時間完成的工作項目。
綜合分析這些工作流程可以更全面的觀點了解團隊運作。如果團隊作業穩定,他們的產出和進度就會更穩定,而其軟體正式上線的預測也更可信。
四、團隊士氣
雖然士氣很少被視為一種衡量標準,但卻是每項KPI的關鍵因素,因為它影響了每位團隊成員的投入和創造性。若團隊成員以他們的工作為傲、覺得被尊重、被充分告知、有權採取行動、了解專案宗旨,那麼他們會更樂於貢獻,也會做出更好、更創新的軟體。
[CIO都在讀: 五項熱門IT職涯趨勢 ]
企業可以簡單地透過與團隊互動聯繫來衡量士氣。例如,了解每次sprint就能一瞥員工對團隊溝通、團隊合作、壓力的感受、甚至工作的尊榮感及樂趣。若他們好幾次sprint中沒什麼尊榮感,就有必要進一步探究。為什麼團隊成員感到挫折?是否有品質、壓力或管理問題需要解決?若能更全面了解團隊士氣,就能開啟重要對話的大門。這些對話或許能給管理者更充分資訊,以改善團隊投入及協同合作。
和所有前述KPI一樣,士氣也不是一個單一、簡單的衡量標準,需要一長段時間廣泛、綜合性的趨勢評估。和敏捷本身精神一樣,軟體開發的KPI會隨著每一次疊代評估而愈來愈好、也更清晰而具體。好消息是一組合適的KPI,不會讓團隊先盛後衰,而是協助團隊在高、低潮之間取得平衡。
(本文授權非營利轉載,請註明出處:CIO Taiwan)