48 lines
2.0 KiB
Markdown
48 lines
2.0 KiB
Markdown
---
|
||
title: "Delivery Traceability"
|
||
type: concept
|
||
tags: ["delivery", "traceability", "project-management", "audit"]
|
||
last_updated: 2026-04-25
|
||
---
|
||
|
||
## Definition
|
||
|
||
Delivery Traceability（交付可追溯性）是指从业务需求到代码发布全链路的可重建、可审计交付记录体系，使团队能在几分钟内重建"从需求到已发布代码"的完整路径，而非花费数小时。
|
||
|
||
## The Five Links
|
||
|
||
| 环节 | 关键问题 | 可追溯性价值 |
|
||
|------|----------|------------|
|
||
| **Jira Task** | 这个需求从哪里来？ | 需求来源记录 |
|
||
| **Branch** | 这段代码在哪个隔离环境开发？ | 隔离性保证 |
|
||
| **Commit** | 这个改动具体做了什么？ | 原子粒度的变更记录 |
|
||
| **Pull Request** | 谁审查了这次变更？ | Review 责任链 |
|
||
| **Release** | 这个功能何时上线？ | 发布时间线记录 |
|
||
|
||
## Two Modes of Traceability
|
||
|
||
### Prospective Traceability（前向追溯）
|
||
从 Jira 任务 → 代码 → 发布，确保需求被完整实现。用于：进度跟踪、变更影响分析。
|
||
|
||
### Retrospective Traceability（回溯追溯）
|
||
从已发布代码 → Jira 任务 → 需求来源，用于：事故溯源、审计合规、回滚决策。
|
||
|
||
## Traceability vs. Bureaucracy
|
||
|
||
[[Jira Workflow Steward]] 的核心观点：**Jira-linked commits 是质量工具，而非合规打勾**。
|
||
|
||
当开发者理解可追溯性的实际价值（review 加速、发布说明自动生成、事故 10 分钟内定位）时，遵循规范的阻力会显著降低。
|
||
|
||
## Success Metrics
|
||
|
||
- 从 Jira + Git 历史重建发布说明：< 10 分钟
|
||
- 定位引入特定行为的 ticket 和 commit：< 5 分钟
|
||
- 回滚操作：原子 commit 使回滚低风险
|
||
|
||
## Relationship to GitOps
|
||
|
||
Delivery Traceability 关注业务需求到代码交付的全链路，[[GitOps]] 关注基础设施声明到部署的自动化调和。两者共同构成完整的软件交付可追溯性体系。
|
||
|
||
## Sources
|
||
- [[project-management-jira-workflow-steward]]
|