TL;DR：Nesma 是荷蘭軟體度量協會，主推「功能點分析（FPA）」——不看程式碼行數、只數軟體對使用者做了幾件事，來量一套系統多大。它跟 IFPUG 幾乎同源（同一套 ISO 血統），但多了 estimated / indicative 兩種「早期快速估」層級，很適合需求還沒定死時抓規模。想在敏捷開發裡量「功能大小」而不是「主觀點數」，Nesma 跟 COSMIC 是兩個正經選項。這篇講清楚它是什麼、跟 IFPUG / COSMIC / story points 的差別，以及對一個 2026 年的開發者到底還有沒有用。
📌 目錄
- Nesma 是什麼？先別跟那堆同名公司搞混
- 功能點到底在數什麼？資料功能 + 交易功能
- Nesma 的三種計數層級：detailed / estimated / indicative
- Nesma vs IFPUG vs COSMIC：一張表看懂
- 功能點 vs 敏捷 Story Points：不是同一種東西
- 我踩過的認知坑
- 2026 年，這套東西對開發者還有用嗎？
- ❓ 常見問題
- 🔗 延伸資源
🧠 Nesma 是什麼？先別跟那堆同名公司搞混
第一次看到「Nesma」這個字，我自己也查了一輪才確定講的是哪個。因為叫 Nesma 的東西一堆：沙烏地阿拉伯有個叫 Nesma Holding 的大集團、還有 Nesma Airlines 航空公司、美國新英格蘭有個彈簧沖壓協會也縮寫成 NESMA。
這篇要講的是軟體工程領域的那個 Nesma——原名 Netherlands Software Metrics Association（荷蘭軟體度量協會），現在官網 nesma.org 定位是「敏捷功能性軟體規模量測與客觀度量」。它從 1989 年就在做這件事，主推的核心方法叫 FPA（Function Point Analysis，功能點分析），並且是 ISO/IEC 24570 這條國際標準的來源。
一句話定義它在幹嘛：用一套客觀規則，量出一套軟體「有多大」，量的單位是「功能點（Function Point）」，而不是程式碼行數、也不是工時。
為什麼要量「功能大小」而不是「行數」？因為行數會騙人。同一個功能，用 Java 寫跟用 Python 寫行數差好幾倍；一個資淺工程師寫 500 行，資深的可能 80 行搞定同一件事。如果你用行數當生產力指標，等於在獎勵寫爛 code。 功能點想解決的就是這件事：不管你用什麼語言、誰寫的，只要對使用者呈現的功能一樣多，規模就一樣。
⚙️ 功能點到底在數什麼？資料功能 + 交易功能
功能點分析的核心觀念很簡單：站在使用者的角度，數這套系統「存了哪些資料」跟「能做哪些操作」。 拆成兩大類：
1. 資料功能（Data Functions） —— 系統維護或參照了哪些邏輯資料群組。
| 類型 | 全名 | 白話 |
|---|---|---|
| ILF | Internal Logical File | 系統自己維護的資料，例如「訂單」「會員」這種你自己 CRUD 的資料表群 |
| EIF | External Interface File | 系統只讀不寫、來自別的系統的資料，例如串接的第三方匯率表 |
| 類型 | 全名 | 白話 |
|---|---|---|
| EI | External Input | 資料進來：新增訂單、改密碼、送出表單 |
| EO | External Output | 資料出去且有加工：月營收報表、含計算的統計圖 |
| EQ | External Inquiry | 純查詢、不加工：搜尋、查明細、下拉選單帶資料 |
用一個具體例子感受一下：你要做一個「線上請假系統」。
- 「請假單」「員工」「假別設定」→ 3 個 ILF
- 串 HR 系統拉組織架構 → 1 個 EIF
- 送出請假、主管簽核、取消請假 → 3 個 EI
- 產月度請假統計報表 → 1 個 EO
- 查自己的請假紀錄、查剩餘天數 → 2 個 EQ
整個計數流程長這樣：
📏 Nesma 的三種計數層級：detailed / estimated / indicative
這是 Nesma 跟純 IFPUG 最實用的差異。Nesma 定義了三種精細度的計數方式，讓你依「手上資訊多完整」選一種，不用永遠都做最精細的那套：
| 層級 | 需要的資訊 | 準度 | 適用時機 |
|---|---|---|---|
| Detailed（詳細） | 每個功能都辨識 + 評複雜度 | 最高 | 需求規格完整、要簽約報價 |
| Estimated（估算） | 辨識所有功能，但複雜度用預設值 | 中高 | 需求大致成形、要抓個譜 |
| Indicative（指示性） | 只數資料功能（ILF/EIF）數量 | 低但快 | 專案最早期、只有粗略構想 |
值得一提的是：Nesma 這套「早期快速估」的方法後來被 IFPUG 正式收編，成為 IFPUG 官方的「High-level FPA（HLFPA）」方法。所以你可以把 Nesma 理解成在 IFPUG 標準之上，補了一層「需求還沒完整時也能估」的實務工具。
⚖️ Nesma vs IFPUG vs COSMIC：一張表看懂
功能性規模量測（Functional Size Measurement）符合 ISO 標準的主流有這三家，常常被搞混。直接上對照表：
| 維度 | Nesma | IFPUG | COSMIC |
|---|---|---|---|
| ISO 標準 | ISO/IEC 24570 | ISO/IEC 20926 | ISO/IEC 19761 |
| 起源 | 荷蘭，1989 | 美國，1970s 末 | 2000 年後，較新 |
| 跟 IFPUG 關係 | 幾乎同源，2004 起指南高度一致 | 本尊 | 獨立設計、觀念不同 |
| 計數對象 | 資料功能 + 交易功能 | 資料功能 + 交易功能 | 資料移動（Entry/Exit/Read/Write） |
| 早期快速估 | ✓ 內建三層級 | △ 後來收編 Nesma 的 HLFPA | ✓ 天生支援不完整需求 |
| 從 User Story 直接數 | △ 較難 | ✗ 不行 | ✓ 可以 |
| 適合分層/現代架構 | △ | △ 設計時代較早 | ✓ 為多層架構設計 |
| 學習成本 | 中 | 中高（文件最厚） | 較低（約 IFPUG 的 1/3 頁數） |
- Nesma 跟 IFPUG 本質上是「近親」。 自 IFPUG CPM 4.2（2004）起，兩者的 FPA 指南幾乎一樣。差別在 Nesma 多了那套早期估算層級。
- COSMIC 是「另一個流派」。 它不數 ILF/EIF/EI/EO/EQ，而是數「資料群組的移動次數」——每一次 Entry / Exit / Read / Write 算 1 個 CFP。它天生為現代分層架構跟不完整需求設計，所以敏捷圈更愛。
- 要在敏捷/user story 環境量功能大小，COSMIC 通常是首選；要跟舊有基準庫（如 ISBSG）對接、或做企業級傳統專案估算，Nesma/IFPUG 的資料更厚。
🎯 功能點 vs 敏捷 Story Points：不是同一種東西
這是我自己一開始也搞混、最值得講清楚的一點。我原本以為功能點跟 story point 是競爭關係、二選一——後來才發現它們量的根本不是同一個東西。
| 面向 | 功能點（Function Point） | Story Point |
|---|---|---|
| 量的是 | 功能大小（客觀規模） | 相對工作量（主觀難度感受） |
| 依據 | 使用者需求 + 標準規則 | 團隊的經驗與共識 |
| 跨團隊可比 | ✓ 高度可比 | ✗ 各團隊尺度不同 |
| 波動範圍 | 不同人數同一套系統，通常差 <5% | 團隊之間差異可達 400% |
| 用途 | 簽約、報價、跨組織基準比較 | 團隊內衝刺規劃、速度追蹤 |
這不是說 story point 沒用——它在團隊內部的衝刺規劃很好用，因為它反映的是「這個團隊做這件事有多費力」。但正因為它綁在特定團隊的手感上，你不能拿 A 團隊的 story point 去跟 B 團隊比，也不能拿它去對外報價或簽約。 功能點的價值就在這裡：它是個跨團隊、跨語言、可簽約的客觀規模單位。
一個實務上的組合拳是：用功能點做對外/跨組織的規模與生產力基準，用 story point 做團隊內部的衝刺規劃。 兩者各司其職。
🕳️ 我踩過的認知坑
寫這篇之前，我自己對這套東西有幾個誤解，這裡誠實列出來：
坑一：以為功能點是「過時的瀑布式產物」
我一開始的直覺是：功能點分析聽起來就很 1990 年代、很「先寫完整規格再開工」，跟現在敏捷開發格格不入。查下去才發現，Nesma 官網現在的定位直接掛「Agile Functional Software Sizing」，而且 COSMIC 這一支還特別強調能從不完整需求、直接從 user story 去數。所以「功能點 = 瀑布式」是我自己的刻板印象，不是事實。
坑二：把 Nesma 跟 IFPUG 當成兩套要選邊站的對手
實際上這兩家從 1990 年就密切合作定義共同標準，2004 年後指南幾乎一致，Nesma 的早期估算法還被 IFPUG 收編。它們是近親、不是對手。真正觀念不同、要選邊的是 COSMIC。
坑三：以為「數功能點」一定要專人專證、很重
detailed 那套確實需要訓練跟經驗。但 Nesma 的 indicative（荷蘭法）只要數「有幾個邏輯資料檔」就能吐出粗估——這件事一個懂系統的工程師花十分鐘就能做。它不是只有大企業養一組估算師才能碰的東西，你在專案啟動會議上就能拿來當個粗略的規模 sanity check。
🔮 2026 年，這套東西對開發者還有用嗎？
老實說，如果你是在小型新創、產品需求天天變、只在乎團隊速度——那你大概一輩子用 story point 就夠了，不太會碰功能點。
但有幾個場景，功能點（Nesma/IFPUG/COSMIC）仍然是正解：
- 對外報價與簽約：接案、外包、政府標案，要一個「客觀、可稽核、跟語言無關」的規模數字時，story point 沒辦法簽約，功能點可以。
- 跨團隊/跨組織生產力比較：大型組織想比較不同團隊的產出，需要一個統一尺度，功能點是少數能做到的。
- 早期規模 sanity check：專案還沒動工，只想抓個譜「這大概是 50 人天還是 500 人天」，Nesma 的 indicative 估算十分鐘給你一個數字。
- AI 輔助自動估算的輸入：這幾年有研究在做「從需求文件自動數功能點」「用機器學習估功能大小」。功能點因為規則明確、波動小，反而比 story point 更適合當 AI 自動化的量測對象。
❓ 常見問題
Q1：Nesma 跟 IFPUG 到底該選哪個？
如果你要對接 ISBSG 這類國際基準資料庫，或做傳統企業專案估算，兩者幾乎通用，Nesma 多了早期估算層級更實用。真正要跟它們比較、且做敏捷/user story 的話，考慮 COSMIC。
Q2：功能點可以取代 story point 嗎？
不能，也不該。它們量的是不同東西：功能點量「功能大小」（客觀），story point 量「工作量」（主觀相對）。功能點用於對外報價/跨團隊比較，story point 用於團隊內衝刺規劃，通常搭配使用。
Q3：算功能點一定要專業認證嗎？
detailed 精算需要訓練與經驗。但 Nesma 的 indicative「荷蘭法」只需數邏輯資料檔數量，一個熟悉系統的工程師就能做粗估，不需要證照。
Q4：功能點在敏捷開發裡還有意義嗎？
有。Nesma 官網現在的定位就是敏捷功能性規模量測；COSMIC 更是設計成能從 user story 直接量測。功能點在敏捷裡的角色是「跨團隊可比的客觀規模」，補 story point 無法對外比較的短板。
Q5：功能點跟程式碼行數（LOC）差在哪？
行數受語言、寫法、工程師習慣影響很大，用它當生產力指標等於獎勵寫囉唆的 code。功能點量的是「對使用者呈現的功能量」，跟實作語言無關，所以能公平比較不同技術棧的專案。
🔗 延伸資源
- Nesma 官方網站 —— FPA 指南、白皮書、免費文件的第一手來源
- Nesma on sizing whitepaper part 1: FPA（PDF） —— 官方對 FPA 的完整說明
- Function point — Wikipedia —— 功能點的歷史與各方法脈絡
- COSMIC Sizing：IFPUG vs COSMIC —— 兩大流派的取捨分析
- LedaMC：Function Points、SNAP、COSMIC、Nesma、SFP 全解 —— 各種軟體度量方法的對照導覽