現今以敏捷(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）
