2. 历史项目数据收集：确定数据源与字段定义
成本估算参数调优的起点，是系统性地收集历史项目数据。数据的质量直接决定了后续特征工程与模型调优的上限。本节将指导你如何确定数据源、定义核心字段，并建立可复用的数据采集规范。
2.1 常见数据源对比与选型
不同团队使用的项目管理工具各异，常见的数据源包括 Jira、Redmine、Excel 以及自研系统。下表从数据完整性、可扩展性和采集成本三个维度进行对比：
| 数据源 | 数据完整性 | 可扩展性 | 采集成本 | 适用场景 |
|---|---|---|---|---|
| Jira | 高（字段丰富，支持自定义） | 高（REST API，插件生态） | 中（需 API 开发） | 中大型团队，敏捷开发 |
| Redmine | 中（基础字段齐全） | 中（REST API，插件有限） | 低（开源，可直连数据库） | 中小团队，预算有限 |
| Excel / CSV | 低（依赖人工维护） | 低（手动合并，易出错） | 低（无需开发） | 初创团队，历史遗留数据 |
| 自研系统 | 高（按需设计） | 高（完全可控） | 高（需定制开发） | 大型企业，长期积累 |
选型建议： 优先选择支持 API 的数据源（如 Jira），以便实现自动化采集与增量更新。对于 Excel 数据，建议在采集后立即转换为结构化存储（如 SQLite 或 CSV），避免后续版本混乱。
2.2 核心数据字段定义
为了支撑成本估算参数调优，每个历史项目记录至少需要包含以下五个核心字段。字段定义必须清晰、无歧义，并统一度量单位。
- 项目ID：唯一标识符，用于关联不同数据源中的同一项目。建议使用字符串类型，如“PROJ-2024-001”。
- 规模：衡量项目工作量的量化指标。常用单位包括：功能点（FP）、代码行数（LOC）、故事点（Story Points）。必须明确记录单位。
- 复杂度：描述项目技术难度与业务逻辑的复杂程度。建议采用等级制：低（1）、中（2）、高（3）、极高（4）。
- 工期：项目从启动到交付的实际日历天数。注意排除非工作日（如周末、法定假日），或单独记录“人天”与“日历天”两个字段。
- 成本：项目实际总投入，通常以货币单位（如人民币元）记录。应包含人力成本、外包成本、工具与基础设施成本。
字段定义示例（JSON Schema）：
{
"project_id": "string",
"scale": {
"value": "number",
"unit": "string" // "FP" | "LOC" | "StoryPoints"
},
"complexity": {
"level": "integer", // 1-4
"description": "string"
},
"duration_days": "integer",
"cost_cny": "number"
}2.3 数据采集流程与质量检查
确定数据源和字段定义后，需要建立标准化的采集流程。下图展示了从原始数据到可用数据集的完整链路：
2.4 数据质量检查清单
在将数据送入特征工程管线之前，必须执行以下质量检查。建议将检查结果记录在数据字典中，作为元数据的一部分。
- 完整性检查：核心字段（项目ID、规模、成本）不允许为空。缺失率超过 5% 的字段需标记并评估是否可用。
- 一致性检查：同一项目的规模单位必须统一；复杂度等级必须在 1-4 范围内；成本不能为负数。
- 异常值检测：使用箱线图或 Z-score 识别极端值。例如，工期超过均值 3 个标准差的项目需人工复核。
- 重复记录检查：按项目ID去重。若存在重复，保留最近更新的一条记录，并记录重复次数。
常见陷阱： 不要直接使用 Excel 中的“工期”字段，它可能包含非工作日。建议在采集时同步获取项目的“开始日期”和“结束日期”，由程序计算实际日历天数，避免人工统计误差。
2.5 数据存储与版本管理
历史数据是不断增长的资产。建议采用以下存储策略：
- 原始层（Raw）：保留从数据源采集的原始数据，不做任何修改。用于追溯和重新清洗。
- 清洗层（Cleaned）：经过字段映射、去重、补缺后的标准数据集。这是特征工程的主要输入。
- 特征层（Feature）：经过特征工程处理后的数据，直接用于模型训练。
每次数据更新时，使用时间戳或版本号（如 v2024-12-01）标记数据集，确保实验可复现。