軟體開發生產力的評估不能僅依賴程式碼行數等簡單指標，因為這些指標忽略了程式碼的複雜度、開發環境以及工程師的智力投入等關鍵因素。功能點分析等更為先進的度量方法雖然考慮了軟體功能性，但仍存在主觀性和自動化困難等問題。因此，準確評估生產力需要結合多種指標，並深入理解專案的具體情況。此外，專案開發時間的估算也是一項複雜的任務，需要將專案分解成更小的子任務，並考慮到團隊協作、行政任務以及潛在的風險等因素。合理的專案規劃和時間管理能有效避免專案陷入危機模式，從而保障團隊的生產力和專案的順利進行。
軟體開發生產力的度量與評估
軟體開發的生產力評估是軟體工程中的重要課題。Watts S. Humphrey 的著作《A Discipline for Software Engineering》（Addison-Wesley Professional，1994 年）為我們提供了深入瞭解程式設計師生產力追蹤的寶貴見解。Humphrey 提出的個人軟體過程（Personal Software Process，PSP）是一種針對個人的軟體開發流程，透過一系列的表格、和程式來規範軟體開發。雖然 PSP 主要針對個人，但它為我們揭示了程式設計師在軟體開發過程中可能遇到的問題，並幫助他們更好地規劃下一個大型專案。
度量的必要性
預測團隊或個人在類別似專案中的生產力存在一個問題，即它僅適用於相似的專案。如果新專案與過去的專案有著顯著的不同，那麼過去的表現可能不是一個好的指標。由於專案在規模上差異很大，衡量整個專案的生產力可能無法提供足夠的資訊來預測未來的表現。因此，我們需要一種在專案層級以下的粒度級別上的度量系統（度量指標），以更好地評估團隊和團隊成員。理想的度量指標應該獨立於專案本身（團隊成員、所選擇的程式語言、使用的工具和其他相關活動及元件），以便在多個專案之間進行比較。
現有的度量指標及其問題
目前存在多種度量指標，但沒有一個是完美的，甚至沒有一個是非常好的。儘管如此，一個不完美的度量指標總比沒有好。因此，軟體工程師將繼續使用它們，直到出現更好的度量方法。本文將討論幾種常見的度量指標及其優缺點。
可執行檔大小度量指標
一種簡單的度量指標是透過最終系統中可執行檔的大小來衡量軟體系統的複雜度。其假設是複雜的專案會產生較大的可執行檔。
優點：
- 計算簡單，通常只需檢視目錄列表並計算一個或多個可執行檔的大小。
- 無需存取原始碼。
缺點：
- 可執行檔往往包含未初始化的資料，這些資料對檔案大小的貢獻與系統複雜度的關係不大。
- 函式庫函式增加了可執行檔的大小，但實際上降低了專案的複雜度。
- 該度量指標不獨立於程式語言。例如，組合語言程式通常比高階語言（HLL）程式更緊湊，但大多數人認為組合語言程式比等效的 HLL 程式更複雜。
- 該度量指標不獨立於 CPU。例如，針對 80x86 CPU 的可執行檔通常比針對 ARM（或其他 RISC）CPU 的相同程式編譯後更小。
// 一個簡單的可執行檔大小計算範例
#include <stdio.h>
#include <stdlib.h>
int main() {
// 假設計算當前目錄下所有可執行檔的大小
system("ls -l *.exe");
return 0;
}
內容解密：
上述 C 語言程式碼範例展示瞭如何使用 system 函式呼叫系統命令 ls -l *.exe 來列出當前目錄下所有副檔名為 .exe 的可執行檔及其大小。這裡主要使用了 stdio.h 和 stdlib.h 兩個標頭檔，分別用於輸入/輸出操作和標準函式庫函式。在這個例子中，我們利用了系統命令來完成檔案大小的計算，這反映了在某些情況下，藉助現有工具可以簡化任務。然而，這種方法的侷限性在於它依賴於特定的作業系統命令，不具備跨平台性。
機器指令度量指標
可執行檔大小度量指標的一個主要缺陷是，某些可執行檔格式包含了未初始化靜態變數的空間，這意味著對輸入原始檔的微小更改就可能大幅改變可執行檔的大小。解決這個問題的一種方法是隻計算原始檔中的機器指令（要麼是機器指令的大小（以位元組為單位），要麼是機器指令的總數）。雖然這個度量指標解決了未初始化靜態陣列的問題，但它仍然存在可執行檔大小度量指標的其他問題：它依賴於 CPU，它計算了不是由程式設計師編寫的程式碼（如函式庫程式碼），並且它依賴於程式語言。
程式碼行數度量指標
程式碼行數（LOC 或 KLOC，用於表示千行程式碼）是目前最常用的軟體度量指標。如其名稱所示，它是對專案中原始碼行數的計數。該度量指標具有一些優點，也有一些缺點。
優點：
- 無論使用何種程式語言，寫一行原始碼所需的大致時間是相同的。
- LOC 度量指標不受專案中使用函式庫例程（或其他程式碼重用）的影響（當然，前提是你不計入預先編寫的函式庫原始碼的行數）。
- LOC 度量指標獨立於 CPU。
缺點：
- 它不能很好地表明程式設計師完成了多少工作。VHLL 中的 100 行程式碼比 100 行組合語言程式碼完成的工作更多。
- 簡單地計算原始碼行數是最流行的使用 LOC 度量指標的方式。編寫一個行數統計程式相當簡單，大多數用於 Linux 等作業系統的字數統計程式都可以為你計算行數。
# 一個簡單的行數統計範例
def count_lines(file_path):
try:
with open(file_path, 'r') as file:
lines = file.readlines()
return len(lines)
except FileNotFoundError:
print(f"檔案 {file_path} 不存在。")
return None
# 使用範例
file_path = 'example.txt'
line_count = count_lines(file_path)
if line_count is not None:
print(f"檔案 {file_path} 有 {line_count} 行。")
內容解密：
上述 Python 程式碼範例定義了一個名為 count_lines 的函式，用於統計指設定檔案的行數。它首先嘗試開啟指定的檔案，並讀取所有行，然後傳回行數。如果檔案不存在，則捕捉 FileNotFoundError 例外並列印錯誤訊息。這裡主要使用了 Python 的檔案操作和例外處理機制。這種方法的優點是簡單直接，但需要注意檔案路徑和名稱的正確性，以及處理可能出現的例外情況，如檔案不存在等。
程式設計師生產力的度量指標探討
生產力指標的挑戰
在軟體開發領域，衡量程式設計師的生產力一直是一個具有挑戰性的課題。傳統的度量方法，如程式碼行數（Lines of Code, LOC）或陳述式計數（Statement Count），雖然簡單易用，但往往無法準確反映實際的生產力。
常見的度量指標及其侷限性
程式碼行數（LOC）
程式碼行數是最簡單直接的度量指標，但它存在多個問題：
- 忽略了程式碼的複雜度，簡單的資料宣告與複雜的布林運算式被同等對待。
- 計算空白行和註解，導致結果不準確。
陳述式計數（Statement Count）
陳述式計數比程式碼行數更為準確，因為它不計入空白行和註解。然而，它仍然存在以下問題：
- 假設每個陳述式所需的努力相同，忽略了陳述式之間的複雜度差異。
- 對程式語言的依賴性較強，不同語言的陳述式複雜度不同。
更為先進的度量方法
功能點分析（Function Point Analysis, FPA）
功能點分析是一種根據軟體功能性的度量方法，考慮了程式的輸入、輸出和基本運算。它的優點包括：
- 語言和系統獨立性。
- 關注軟體的功能性而非實作細節。
然而，FPA也有其缺點：
- 分析過程主觀，需要分析者對功能的複雜度進行判斷。
- 自動化困難，很難客觀地計算功能點數量。
McCabe 環形複雜度（Cyclomatic Complexity）
McCabe 環形複雜度是一種根據程式控制流程的度量指標，透過計算程式中的路徑數量來評估複雜度。它的優點包括：
- 客觀性，可以透過程式計算。
- 能夠反映程式的邏輯複雜度。
然而，它也存在一些問題：
- 忽略了程式的規模大小，將單一的
printf陳述式與一千個連續的printf陳述式視為相同。
其他度量指標
除了上述方法外，還有其他一些度量指標，如運算元數量、符記（Token）數量等。這些指標試圖從不同角度評估程式設計師的工作量。然而，每種指標都有其侷限性。
度量指標的問題
大多數度量指標都與程式碼數量有一定的關聯，但它們與實際的工作量或生產力之間的關係並不明確。更複雜的度量方法雖然理論上更為準確，但往往難以自動化和實際應用。
未來方向
為了更準確地評估程式設計師的生產力，需要開發更為先進和客觀的度量方法。未來的研究方向可能包括：
- 結合多種度量指標，建立更為全面的評估模型。
- 開發自動化的度量工具，降低評估成本和提高準確性。
內容解密：
本章節介紹了多種用於衡量程式設計師生產力的指標，包括程式碼行數、陳述式計數、功能點分析、McCabe 環形複雜度等。每種指標都有其優缺點，選擇合適的指標需要根據具體專案需求和目標進行評估。同時，也需要認識到這些指標的侷限性，並探索更為先進和客觀的評估方法。
@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle
title 軟體開發生產力度量與估算
package "系統架構" {
package "前端層" {
component [使用者介面] as ui
component [API 客戶端] as client
}
package "後端層" {
component [API 服務] as api
component [業務邏輯] as logic
component [資料存取] as dao
}
package "資料層" {
database [主資料庫] as db
database [快取] as cache
}
}
ui --> client : 使用者操作
client --> api : HTTP 請求
api --> logic : 處理邏輯
logic --> dao : 資料操作
dao --> db : 持久化
dao --> cache : 快取
note right of api
RESTful API
或 GraphQL
end note
@enduml此圖示說明瞭不同生產力指標之間的關係及其各自的優缺點。
軟體開發生產力的迷思與現實
軟體開發生產力（Productivity）是一個複雜且多導向的主題。傳統上，程式設計師的生產力常被簡化為單純的程式碼行數（Lines of Code, LOC），但這種衡量方式存在許多根本性的缺陷。
生產力指標的缺陷
大多數用於衡量程式設計師生產力的指標都存在一個共同的問題：它們試圖量化程式碼的某些物理屬性，卻忽略了真正重要的東西——撰寫程式碼所需的智力投入。這些指標假設投入更多工作就會產生更多或更複雜的程式碼，但事實並非總是如此。例如，一位優秀的程式設計師可能會花費大量時間重構程式碼，使其變得更簡潔、更易於維護。在這種情況下，更多的努力反而會減少程式碼的數量和複雜度。
此外，不同專案之間的程式碼行數很難直接比較。為裸機嵌入式裝置撰寫的10行程式碼與為SQL資料函式庫應用程式撰寫的10行程式碼，其價值和難度可能完全不同。同樣地，Windows裝置驅動程式的10行程式碼與Java Web Applet的10行程式碼，其複雜度和開發難度也可能有很大差異。
為何傳統指標失效
大多數衡量生產力的指標都未能考慮到專案的環境因素和學習曲線。它們只關注程式設計師產出了多少程式碼，而忽略了他們對專案整體的貢獻。例如，一位程式設計師可能只需一行程式碼（呼叫標準函式庫）就能完成某項任務，而另一位程式設計師可能需要寫幾百行自定義程式碼才能達到相同的效果。傳統指標可能會誤導地認為第二位程式設計師更具生產力。
正因為如此，即使是最複雜的軟體指標也存在根本性的缺陷。因此，選擇一個「更好的」指標往往並不能帶來明顯的改善。這也是為什麼LOC（程式碼行數）指標雖然眾所周知有缺陷，卻仍然被廣泛使用。它雖然是一個糟糕的指標，但並不比其他許多指標差，而且計算起來非常簡單，不需要額外的工具。
如何超越每天10行程式碼的限制
早期的軟體工程研究表明，一名程式設計師在大型專案中的平均日產出約為10行程式碼（經過除錯和檔案化）。這個數字看似很低，但它反映了整個專案生命週期中的平均生產力，而非單純的編碼速度。
在專案初期，程式設計師可能會快速產出大量的程式碼，但隨著專案推進，他們會花更多時間研究解決方案、測試、修復錯誤、重寫程式碼以及撰寫檔案。因此，隨著專案的發展，生產力會顯著下降。
提高生產力的關鍵不在於讓程式設計師寫出更多的程式碼，而在於減少除錯、測試、檔案編寫和重構所浪費的時間。軟體工程的一個重要目標就是最佳化開發流程，減少不必要的時間浪費。
如何估算開發時間
雖然生產力指標對管理階層來說很重要，但其真正的價值在於幫助預測未來專案的開發時間。過去的表現不能保證未來的結果，因此學會如何估算專案排程至關重要。
對於小型專案來說，估算開發時間相對容易，因為專案通常由單一工程師負責，主要受該工程師的能力和生產力影響。但對於中型或大型專案，估算開發時間就變得更加複雜，需要考慮更多因素。
與專案經理溝通，瞭解專案排程中的各種因素（如除錯、測試、檔案編寫等），對於準確估算開發時間至關重要。
2.8 專案開發時間估算的挑戰與實踐
專案開發時間的估算是軟體開發過程中最困難的任務之一。準確的估算不僅需要對專案內容有深入的瞭解，還需要考慮到團隊成員的生產力、行政任務以及可能出現的意外狀況。本章節將探討小專案、中型專案和大型專案的開發時間估算方法，並分析其中常見的問題。
2.8.1 小專案開發時間估算
小專案通常由單一開發者負責，因此其開發時間主要取決於該開發者的生產力和工作安排。估算小專案開發時間的第一步，是全面瞭解所有需要完成的工作。如果專案中有部分內容尚未定義，很可能會導致後續的時間估算出現巨大誤差。
在估算小專案的完成時間時，設計檔案（design documentation）是至關重要的。沒有詳細的設計檔案，就無法清楚知道專案由哪些子任務組成，以及每個子任務需要多少時間來完成。一旦將專案分解為適當大小的子任務（即清楚知道每個子任務需要多少時間完成），只需將所有子任務的時間相加，便能得到一個初步的估計值。
然而，人們在估算小專案時常犯的一個錯誤是，他們只將子任務的時間相加，而忽略了會議、電話、電子郵件和其他行政任務所佔用的時間。此外，測試時間以及修正和重新測試軟體缺陷的時間也需要被納入考量。由於很難預測軟體中會有多少缺陷，因此大多數專案經理會將初步估計值乘以2到4倍，以獲得更合理的預估時間。
def estimate_project_time(subtasks):
total_time = sum(subtask['time'] for subtask in subtasks)
# 考慮行政任務和測試時間，將總時間乘以2到4倍
adjusted_time = total_time * 3 # 假設乘以3倍作為調整
return adjusted_time
# 範例使用
subtasks = [
{'name': '設計', 'time': 5},
{'name': '開發', 'time': 10},
{'name': '測試', 'time': 3}
]
estimated_time = estimate_project_time(subtasks)
print(f"預估的專案總時間：{estimated_time} 天")
內容解密：
estimate_project_time函式接收一個包含多個子任務的列表，每個子任務包含名稱和預估時間。- 使用
sum函式將所有子任務的時間相加以獲得總時間。 - 將總時間乘以3倍，以考慮行政任務、測試和修正缺陷所需的額外時間。
- 最後傳回呼整後的預估時間。
2.8.2 中型及大型專案開發時間估算
中型和大型專案在概念上是由許多小專案組成，這些小專案由個別團隊成員負責，最終組合形成完整的結果。因此，估算大型專案的時間，第一步是將其分解為多個較小的子專案，分別對每個子專案進行估算，然後將這些估算結果加總。
然而，這種方法在實際應用中容易出現誤差。中型和大型專案會遇到許多小專案中不存在的問題，例如多名團隊成員之間的協調、人員變動、裝置和工具的取得等，都可能影響專案進度。
在進行中型和大型專案的時間估算時，通常需要進行四個步驟：
- 將專案分解為更小的子專案。
- 對每個子專案進行小專案式的時間估算。
- 增加整合測試和除錯所需的時間。
- 對總估算時間應用一個乘法因子，以考慮未預見的延誤。
2.8.3 專案開發時間估算中的常見問題
由於專案進度估算涉及預測未來，因此很少有人相信預估的時間表會完全準確。然而，軟體開發專案的時間估算通常尤其不準確。以下是一些常見的原因：
- 研究與開發專案：這類別專案涉及全新的工作，需要研究階段來分析問題並尋找解決方案，研究階段的時間很難預測。
- 管理階層有預設的時間表：行銷部門通常會決定產品的上市日期，管理階層再根據這個日期倒推專案的時間表，而未必考慮實際開發所需的時間。
- 重複專案的誤判：管理階層可能認為，如果團隊曾經做過類別似的專案，那麼第二次一定會更快。然而，實際情況並非總是如此。
- 資源限制：管理階層可能會設定嚴格的時間或資金限制，這迫使團隊成員在不現實的條件下承諾完成任務。
- 開發者過於樂觀：開發者可能會對自己的效率做出過於樂觀的估計，這些估計往往無法在實際執行中兌現。
2.9 危機模式專案管理
儘管專案團隊成員都有最佳的意願，但許多專案仍然會大幅落後於計畫進度，此時管理階層必須加快開發進度以趕上重要的里程碑。為了達成截止日期，工程師們往往被要求投入更多時間，以縮短實際交付日期。當這種情況發生時，專案就被認為處於「危機模式」。
危機模式的工程開發在短期內處理逼近的截止日期時可能有效，但整體而言，危機模式的效果並不理想，反而會降低生產力。因為大多數人在工作之外都有需要處理的事情，需要時間休息、放鬆，並讓大腦整理在長時間工作期間累積的問題。疲勞工作容易導致錯誤，而這些錯誤往往需要花費更多時間來修正。從長遠來看，放棄危機模式並堅持每週40小時的工作安排更為有效。
處理危機模式計畫的最佳方法是，在整個專案過程中設定多個里程碑，以產生一系列「小型危機」而非最後的「大危機」。每個月多投入一天或幾天長時間工作，遠比在專案結束時連續多個七天工作周來得更好。為了達到截止日期而工作一兩天16小時的工作日，不會對生活品質造成負面影響，也不會導致精疲力竭。
除了健康和生產力問題外，危機模式還可能引起排程、倫理和法律問題：
- 糟糕的排程可能會影響未來的專案。如果每週工作60小時，管理階層可能會假設未來的專案也可以在相同的實際時間內完成，並預期未來的專案也能達到相同的進度，而不會提供額外的補償。
- 在長期危機模式下運作的專案中，技術人員的流動率很高，進一步降低了團隊的生產力。
- 還有一個法律問題，即在沒有加班費的情況下投入大量額外工作時間。電子遊戲產業的幾起備受矚目的訴訟案件表明，工程師有權獲得加班費（他們不是薪資豁免員工）。即使公司能夠在訴訟中勝訴，有關工時報告、行政管理費用和工作排程的規定將會變得更加嚴格，從而導致生產力下降。
再次強調，如果能夠妥善管理，危機模式可以幫助達成某些截止日期。但最好的解決方案是制定更好的排程，以完全避免進入危機模式。
