总体思路与核心要素
用 GitLab 做进度跟踪，建议以 Issues（议题） 承载工作项，用 Milestones（里程碑） 对齐版本目标，用 Issue Boards（看板） 可视化流程，用 Labels（标签） 标识状态与责任，用 Time Tracking（工时） 记录估算与消耗，用 Merge Requests（合并请求） 把关质量，用 Roadmap（路线图） 展示发布节奏。这样可以在同一平台内完成计划、执行、度量与复盘，减少信息分散与沟通成本。
操作步骤
- 规划与拆解
- 创建 Milestones 表示阶段或版本目标（如：v1.2、Sprint 24），设置 标题、描述、开始/截止日期；里程碑可属于 项目 或 群组，并可与 Releases 联动，便于以版本维度跟踪进度。
- 将需求拆为 Issues，填写 标题、描述、Assignee（负责人）、Due date（截止日期），并分配到对应 Milestone；用 Labels 标识模块/优先级/状态（如：待准入、待认领、Doing、待Review、待关闭、developer:姓名、reviewer:姓名）。
- 执行与协作
- 在看板中推进卡片（列即阶段），如：Open → 待准入 → 待认领 → Doing → 待Review → 待关闭 → Closed。
- 开发完成后创建 Merge Request（MR） 并关联到对应 Issue（在 MR 描述中使用 #IssueID），指派 Assignee 与 Reviewer；评论中使用 /assign 快速指派。
- 度量与发布
- 在 Issues → Milestones → 里程碑详情 查看按状态汇总的 Issues 与 Merge Requests，直观看到未开始/进行中/已完成与待合并/已合并等分布。
- 里程碑完成后，合并至目标分支，关闭相关 Issues，并在 Roadmap 中滚动规划下一期目标。
看板与标签设计示例
| 列/阶段 |
说明 |
常用操作与标签 |
| Open |
新提出的问题 |
评审后移动到“待准入”；必要时补充 Due date |
| 待准入 |
等待产品/架构确认 |
确认后移到“待认领”；补充 Milestone |
| 待认领 |
等待成员领取 |
成员打上 developer:姓名 标签并自领 |
| Doing |
开发中 |
指派 Assignee；在评论用 /estimate 8h、/spend 4h 记录工时 |
| 待Review |
等待代码评审 |
打上 reviewer:姓名；创建 MR 并关联 Issue |
| 待关闭 |
等待上线/验证 |
上线验证通过后移到“Closed” |
| Closed |
已完成 |
归档，必要时复盘 |
- 工时记录：在 Issue 描述或评论中使用 /estimate（估算）与 /spend（实际耗时），在右侧面板查看 Time tracking 与完成度。
- 快速指派：在评论中使用 /assign @username 即可指派负责人。
度量与可视化
- 里程碑进度页：进入 Plan → Milestones → 选择里程碑，在 Issues 与 Merge Requests 页签下分别查看 Unstarted/Ongoing/Completed 与 Work in progress/Waiting for merge/Rejected/Merged 的分布，便于把控阶段瓶颈与发布就绪度。
- 路线图：在 Roadmap 以时间线方式展示多个 Milestones，用于版本节奏与跨项目对齐。
- 列表与看板筛选：在 Issues/MR 列表 与 Issue Boards 中按 Milestone 过滤；支持特殊筛选 None（未分配）/Any（已分配），便于定位未规划或跨项目工作。
最佳实践与注意事项
- 统一工作项类型：常规任务用 Issue，重大故障可用 Incident 类型，便于单独统计与响应流程。
- 权限与可见性：创建/编辑 Milestones 需至少 Reporter 角色；Group Milestones 可被群组内所有项目共享，适合多项目协同版本。
- 质量门禁：将 MR 与 Issue 强关联，要求通过评审与必要的 CI 检查后再合并，避免“进度先行、质量后补”。
- 度量驱动改进：定期查看 里程碑详情 的分布，识别长期“待Review/Waiting for merge”的阻塞点，优化评审与发布节奏。