您的软件开发生命周期数据模板
您的软件开发生命周期数据模板
- 建议收集的属性
- SDLC 核心追踪活动
- Azure DevOps 详细提取指南
软件开发生命周期属性
| 名称 | 描述 | ||
|---|---|---|---|
|
Event 时间
EventTime
|
指示开发项的特定活动或事件发生的精确时间戳。 | ||
|
描述
Event Time 记录了开发生命周期中每个活动的日期和时间。此 timestamp 是按时间顺序排列 event 并计算活动间持续时间的基本时间要素。 在分析中,此属性对于计算所有基于时间的指标(包括周期时间、处理时间和等待时间)至关重要。它能够创建按时间排序的 event log,这是进行任何 Process Mining 分析的必需输入。它用于诊断延迟、衡量相对于 SLA 的绩效以及跟踪长期趋势。
为何重要
此时间戳提供了事件的时间顺序,这对于计算所有基于时长的 KPI 以及理解流程流向和瓶颈至关重要。
获取方式
这是与工作项历史中每次更新关联的“变更日期”。对于构建或部署等外部事件,它是该事件的完成时间戳。
示例
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:00Z
|
|||
|
开发项
DevelopmentItem
|
单个工作单元(如功能、Bug 或用户故事)的唯一标识符,作为流程分析中的案例 (case) 标识符。 | ||
|
描述
开发项代表在 Azure DevOps 中追踪的独立工作单元。每个项目由唯一 ID 标识,是所有流程活动(从创建规划到开发、测试和部署)的核心围绕对象。 在流程挖掘分析中,该属性是将所有关联事件串联成单一“案例轨迹”的基础。它支持重建每个工作项的端到端生命周期,从而可以针对单个项目分析其交付周期、流程偏差和返工循环。
为何重要
这是将所有流程步骤连接成连贯案例的核心标识符,使得对软件开发生命周期的端到端分析成为可能。
获取方式
对应 Azure DevOps Boards 工作项的 ID 字段。可通过用于工作项追踪的 Azure DevOps REST API 访问。
示例
10234102351023610237
|
|||
|
活动名称
ActivityName
|
在工作项开发生命周期的某一时间点发生的特定事件或任务的名称。 | ||
|
描述
活动名称描述了流程中的具体步骤或里程碑,例如“开发已启动”、“Pull Request 已创建”或“已部署到生产环境”。这些活动源于工作项状态的变更、关联事件(如构建或 PR)或自定义事件。 该属性对于构建流程图(可视化呈现工作流)至关重要。它能让分析人员理解事件顺序,识别常规路径,发现特定活动间的瓶颈,并分析每一步骤的发生频率。
为何重要
定义流程中的各个步骤,构成流程图的核心骨架,支持对工作流、瓶颈和偏差的深入分析。
获取方式
通常源自工作项“状态”字段的变更,或者源自构建、提交和 PR 等关联事件。工作项历史记录为这些事件提供了原始数据。
示例
开发开始Pull Request 已完成QA 测试失败已部署到生产环境工作项已关闭
|
|||
|
最后数据更新
LastDataUpdate
|
指示此流程的数据最后一次从源系统刷新的时间戳。 | ||
|
描述
该属性记录了从 Azure DevOps 提取和更新数据集的时间。它清晰地显示了数据的新鲜度以及分析所涵盖的时间范围。 在任何流程分析中,了解数据的实时性对于做出明智决策都至关重要。此时间戳帮助用户判断他们看到的是实时信息还是历史快照,这直接影响到分析结论的时效性。
为何重要
向用户说明数据的更新时间,确保所有的分析和决策都基于明确的时间范围。
获取方式
这是在数据提取、转换和加载 (ETL) 过程中生成并存储的元数据时间戳。
示例
2024-05-20T08:00:00Z
|
|||
|
源系统
SourceSystem
|
提取流程数据的源系统,在本案例中为 Azure DevOps。 | ||
|
描述
该属性标识了数据的原始系统。在需要合并多个系统的数据以获得更广阔流程视角的场景中尤其有用。在本模型中,该值统一为 Azure DevOps。 虽然在单系统分析中它看起来是静态的,但它提供了关于数据来源的核心上下文,这对于数据治理、故障排查以及未来与其他系统(如 ServiceNow 或 SAP)的集成都至关重要。
为何重要
提供有关数据来源的关键上下文,这对于数据治理、验证以及跨系统流程分析非常重要。
获取方式
这是一个静态值,应在数据提取和转换过程中添加,用于标记数据集。
示例
Azure DevOps
|
|||
|
优先级
Priority
|
开发项相对于其他项重要性的数字或描述性排名。 | ||
|
描述
优先级表示工作项的调度重要程度。高优先级意味着该项目应比低优先级项目更快得到处理。通常使用数字表示(如 1、2、3、4),其中 1 为最高优先级。 该属性对于“基于优先级的吞吐量与周期时间”仪表板至关重要。通过此维度分析数据,有助于判断优先级体系是否有效,即高优先级项目是否确实比低优先级项目流转得更快。
为何重要
通过分析流程是否有效地为高优先级项目开辟了“快车道”,这是评估优先级策略成效的关键。
获取方式
对应 Azure DevOps 工作项中的“优先级”字段。
示例
1234
|
|||
|
分配给
AssignedTo
|
当前负责该开发项的用户或团队成员。 | ||
|
描述
该属性标识了在流程特定阶段负责该工作项的个人。在项目的整个生命周期中,负责人可能会多次变更(例如从开发人员到测试人员,再到发布经理)。 按“负责人”分析对于“开发与测试人员工作负载概览”仪表板至关重要。它有助于了解资源分配、识别超负荷的团队成员,并分析个人或团队之间的绩效差异。
为何重要
支持基于资源的分析,有助于了解工作负载分布、识别特定资源的瓶颈,并有效管理团队效能。
获取方式
对应 Azure DevOps 工作项中的“负责人”字段。该值从每个事件的工作项历史记录中捕获。
示例
jane.doe@example.comjohn.smith@example.com未分配
|
|||
|
团队名称
TeamName
|
负责该工作项的开发团队名称。 | ||
|
描述
团队名称标识了工作项分配到的具体团队。在 Azure DevOps 中,工作通常按团队组织,团队可以是大型项目下的子集。 该属性支持按团队细分流程分析。这对于比较不同团队间的流程和绩效、识别高绩效团队的最佳实践以及发现特定团队可能需要的支持或流程改进非常有价值。
为何重要
支持跨团队的对比分析,帮助识别绩效差异并在全公司范围内推广最佳实践。
获取方式
通常源于工作项的“区域路径”,因为在 Azure DevOps 中,团队通常映射到特定的区域路径。
示例
凤凰团队Omega 小组平台核心前端小组
|
|||
|
工作项类型
WorkItemType
|
开发项的分类,例如 Bug、功能、用户故事或任务。 | ||
|
描述
工作项类型用于对正在进行的工作性质进行分类。不同类型的工作项往往遵循不同的流程路径,并有不同的绩效预期或 SLA。例如,“Bug”可能比“功能”走更快的响应路径。 该属性对于对比分析必不可少。它允许您按工作类型过滤流程图或 KPI,以了解特定流程在处理 Bug 与功能时的效率差异,或追踪不同类别工作的历史周期时间趋势。
为何重要
支持对流程分析进行细分,以便对比不同工作类型(如 Bug 和新功能)的工作流及绩效。
获取方式
对应 Azure DevOps 工作项中的“工作项类型”字段。
示例
Bug功能用户故事任务
|
|||
|
开发周期时间
DevelopmentCycleTime
|
从开发项创建到其部署到生产环境的总耗时。 | ||
|
描述
开发周期时间是一个关键绩效指标,用于衡量单个工作项开发流程的端到端持续时间。它的计算方法是“已部署到生产环境”活动与“工作项已创建”活动之间的 timestamp 差值。 这一计算得出的指标是“端到端开发周期时间”dashboard 和“历史周期时间趋势”的核心 KPI。它提供了流程速度和效率的整体衡量标准,随着时间的推移进行跟踪,可以展示流程改进计划的效果。
为何重要
这是一个核心 KPI,用于衡量开发流程从开始到结束的整体速度和效率。
获取方式
通过计算每个案例的最终部署事件时间戳与创建事件时间戳之差得出。
示例
10 天 4 小时 30 分钟25 天 8 小时 0 分钟5 天 2 小时 15 分钟
|
|||
|
是否返工
IsRework
|
一个布尔标记,指示开发项是否在其生命周期中重新进入了之前的阶段。 | ||
|
描述
如果工作项表现出返工循环(例如从“QA 测试完成”返回到“开发已启动”),该标记将设为 true。它是通过分析案例的活动序列并检测非线性进展计算得出的。 该属性对于“返工与重新测试频率”仪表板及“返工循环频率”KPI 必不可少。它支持对返工进行轻松过滤和量化,帮助查明导致低效的质量问题、沟通断层或测试不足。
为何重要
直接识别并量化返工情况,帮助发现质量问题和导致交付周期延长的低效环节。
获取方式
这是一个计算属性,通过分析每个案例事件日志中的活动序列得出。
示例
truefalse
|
|||
|
状态
State
|
开发项在工作流中的当前状态,例如“新建”、“活动”、“已解决”或“已关闭”。 | ||
|
描述
状态 (State) 属性代表项目流程模板所定义的工作项在任何时间点的正式状态。状态之间的切换是生成事件日志中各活动的主要来源。 虽然“活动”属性通常是状态变更的更详细描述,但原始的“状态”属性在过滤和分析时非常有用。它有助于了解工作项在特定状态下的停留时间,是构建“阶段耗时”仪表板和分析交接环节的基础。
为何重要
显示工作项在生命周期中的状态,这对于理解流程流向及计算各阶段耗时至关重要。
获取方式
对应 Azure DevOps 工作项中的“状态”字段。
示例
新建在职QA 中已解决已结案
|
|||
|
结束时间
EndTime
|
表示活动完成的时间戳,用于计算该活动的处理时间。 | ||
|
描述
结束时间标志着一项活动的完结。在许多事件日志中,下一项活动的开始时间即为前一项的结束时间。然而,拥有独立的结束时间可以更准确地计算活动的“处理时间”以及活动间的“闲置时间”。 该属性对于计算处理时间 KPI 和进行详细瓶颈分析至关重要。它有助于区分真正投入工作的时间与等待下一步开始的时间,这对于“阶段交接分析”仪表板非常关键。
为何重要
支持精准计算活动的处理时间和闲置时间,这是进行瓶颈分析和提升效率的基础。
获取方式
通常为衍生值。它可以是同一案例后续事件的开始时间,或者如果源系统能捕获任务的开始和结束时间,则可以直接记录。
示例
2023-10-26T18:00:00Z2023-10-27T15:00:00Z2023-10-28T11:00:00Z
|
|||
|
Pull Request ID
PullRequestId
|
关联到该开发项的 Pull Request 标识符。 | ||
|
描述
该属性将工作项关联到具体的 Pull Request(提交和评审代码变更的机制)。单个工作项可能关联多个 PR。 通过 PR ID,可以对生命周期中的代码评审和集成部分进行更细致的分析。它可以用来衡量从 PR 创建到完成的时间,并分析 PR 被驳回或需要重大修改的频率,这通常是代码质量或需求不明的信号。
为何重要
将开发工作与具体的代码评审活动关联,从而能够对代码集成和质量保证流程进行深度分析。
获取方式
此信息可在 Azure DevOps 工作项的“链接”或“开发”部分找到。
示例
452145334589
|
|||
|
严重性
Severity
|
表示 Bug 或问题对系统或最终用户的影响。 | ||
|
描述
严重程度用于对 Bug 的影响进行分类,从关键系统故障到轻微的界面问题。这与决定工作顺序的“优先级”不同。如果一个高严重程度的 Bug 有现成的替代方案,其优先级可能会被设得很低。 该属性提供了另一个分析维度,尤其适用于“基于优先级的吞吐量与周期时间”仪表板。它有助于探究诸如“我们是否优先修复了最关键的 Bug?”之类的问题,并帮助理解正在处理的工作的风险概况。
为何重要
根据业务影响对工作项进行分类,从而分析团队处理高影响问题的效率。
获取方式
对应 Azure DevOps 中工作项(通常是 Bug)的“严重程度”字段。
示例
1 - 紧急2 - 高3 - 中4 - 低
|
|||
|
审批等待时间
ApprovalWaitingTime
|
开发项在提出申请后等待审批所花费的时间。 | ||
|
描述
该指标测量工作项等待审批的特定时长。一个典型的例子是“UAT 已启动”与“UAT 已获批”之间的时间。它是通过测量特定案例中这两个活动之间的时间差得出的。 这一计算属性直接支持“审批等待时间分析”仪表板及相应 KPI。通过隔离这些特定延迟,团队可以针对性地优化沟通和决策流程,减少闲置时间并加速整个生命周期。
为何重要
专门测量因等待决策或审批而导致的延迟,找出改进沟通和决策流程的机会。
获取方式
通过在事件日志中找到特定的审批开始和结束活动(例如“UAT 已启动”和“UAT 已获批”)并计算其时间差得出。
示例
3天2小时1 天 8 小时 30 分钟4 小时
|
|||
|
迭代路径
IterationPath
|
工作项所属的开发 Sprint 或时间盒。 | ||
|
描述
迭代路径(或 Sprint)代表一个特定的、有时限的开发周期。工作项被分配到迭代中,并在该时间段内完成。 按迭代路径分析有助于了解各个 Sprint 的流程绩效。它可以用来追踪交付周期是否在连续的 Sprint 中得到改善,分析未完成的遗留工作,并评估 Sprint 计划的可预测性。
为何重要
支持基于 Sprint 的分析,帮助团队评估不同阶段的绩效表现并持续优化敏捷实践。
获取方式
对应 Azure DevOps 工作项中的“迭代路径”字段。
示例
电商平台\Sprint 12电商平台\Sprint 13移动端 App 重启\第二阶段\Sprint 4
|
|||
|
阶段交接时间
StageHandoffTime
|
一个主要阶段完成到下一个阶段开始之间的闲置时长。 | ||
|
描述
阶段交接时间用于衡量连续流程阶段之间的等待期,例如“开发完成”到“QA 测试启动”之间的时间。通过识别这些关键流转点并测量前一活动结束到后一活动开始之间的时间差来计算。 该指标是“阶段耗时与交接分析”仪表板的核心。隔离并测量交接时间对于识别隐藏瓶颈至关重要,这些瓶颈通常是由于资源空缺、沟通延迟或流程低效导致的工作闲置。
为何重要
量化各流程阶段之间的等待时间,直接揭示那些隐藏的、非活跃工作状态下的瓶颈和延迟。
获取方式
这是一个计算属性。它需要识别代表交接的成对连续活动,然后计算它们之间的时间差。
示例
2小时15分钟1天4小时0 小时 30 分钟
|
|||
|
项目名称
ProjectName
|
该开发项所属的 Azure DevOps 项目名称。 | ||
|
描述
该属性标识了工作项所属的 Azure DevOps 组织内的具体项目。它提供了宏观背景信息,尤其是在拥有众多项目的组织中。 项目名称是过滤和对比的关键维度。它通过支持按项目细分分析,为“历史周期时间趋势”仪表板提供数据支持,从而揭示某些项目的效率差异,或验证某个项目的流程改进是否产生了积极影响。
为何重要
提供高层级的分析分组,支持跨项目的绩效对比和趋势分析。
获取方式
对应 Azure DevOps 工作项中的“团队项目”字段。
示例
电商平台移动端 App 重启数仓现代化
|
|||
软件开发生命周期活动
| 活动 | 描述 | ||
|---|---|---|---|
|
Pull Request 已创建
|
表示开发人员已完成初始编码,并已通过拉取请求提交更改以供评审。此 event 将工作项链接到 Azure Repos 中的特定代码更改。 | ||
|
为何重要
这是从开发到代码评审的关键交接点。追踪此项有助于测量编码时长,并确定代码何时可以进行同行评审。
获取方式
通过将拉取请求创建 event 链接到其关联的工作项,从 Azure Repos 数据中捕获。这通常由开发人员显式链接。
捕获
捕获自链接到工作项的 Azure Repos 拉取请求创建 event。
事件类型
explicit
|
|||
|
Pull Request 已完成
|
代表代码评审成功完成,即 Pull Request 已获批且代码已合并到目标分支。此事件会在 Azure Repos 中明确记录。 | ||
|
为何重要
标志着代码评审阶段的结束(这是一个常见的瓶颈)。分析从 PR 创建到完成的时间可以揭示评审周期的效率。
获取方式
捕获自 Azure Repos 中链接到工作项的拉取请求完成或合并 event。
捕获
捕获自链接到工作项的拉取请求合并 event。
事件类型
explicit
|
|||
|
QA 测试已启动
|
代表正式质量保证测试阶段的开始。当工作项状态变更为“QA 中”、“测试中”或类似值时,系统会判定此活动。 | ||
|
为何重要
标志着 QA 循环的开始。分析此阶段的持续时间对于理解测试瓶颈和效率至关重要。
获取方式
通过跟踪工作项历史记录中 System.State 字段更改为“QA 中”或其他指定测试状态而推断得出。
捕获
推断自状态字段变为“QA 中”或“测试中”。
事件类型
inferred
|
|||
|
UAT 已通过
|
此活动表示业务相关方在用户验收测试后已批准变更。通常根据状态从“UAT 中”变更为“UAT 已通过”或“发布就绪”来判定。 | ||
|
为何重要
这是一个关键的审批里程碑,确认工作项符合业务需求并已就绪,可进行生产部署。
获取方式
通过检测工作项历史记录中 System.State 字段从 UAT 状态到已批准或准备发布状态的变化而推断得出。
捕获
推断自状态字段从“UAT 中”变为“准备发布”。
事件类型
inferred
|
|||
|
工作项已创建
|
此活动标志着开发生命周期的开始,代表创建了一个新的工作项(如用户故事、Bug 或任务)。当在 Azure DevOps Boards 中保存新记录时,系统会明确捕获此活动。 | ||
|
为何重要
这是流程的主要启动事件。对于测量端到端开发周期时间以及理解工作的最初来源至关重要。
获取方式
此事件从工作项本身的“创建日期”中捕获。工作项历史记录表也会记录这一初始状态变更。
捕获
捕获自工作项的“创建日期”字段。
事件类型
explicit
|
|||
|
已部署到生产环境
|
标志着工作项关联的代码已成功部署到生产环境。这是从 Azure Pipelines 发布日志中获取的明确事件。 | ||
|
为何重要
这是代表价值交付的关键里程碑,作为计算前置时间和交付周期的终点。
获取方式
捕获自 Azure Pipelines 发布流水线数据,特别是链接到该工作项且部署到“生产”阶段的完成 event。
捕获
捕获自发布流水线部署完成 event。
事件类型
explicit
|
|||
|
开发开始
|
此活动表示开发人员已开始投入该项目。通过判定工作项状态变更为“活动”、“进行中”或“已承诺”来捕获。 | ||
|
为何重要
标志着进入活跃开发阶段。通过分析从“已创建”到“开发已启动”的时间,可以揭示待办事项的排队等待时间。
获取方式
推断自工作项历史记录,当 System.State 字段从“新建”或“已批准”状态更改为“进行中”状态时。
捕获
推断自状态字段变为“活动”或“进行中”。
事件类型
inferred
|
|||
|
Build 成功
|
此活动确认源代码(包括新变更)已通过构建流水线成功编译并打包。这是由 Azure Pipelines 记录的明确事件。 | ||
|
为何重要
作为关键的质量门禁,确保新代码在不破坏构建的情况下正确集成。此阶段的失败通常意味着存在集成问题。
获取方式
捕获自 Azure Pipelines build 完成 event。Build 需要直接或通过关联的拉取请求链接到工作项。
捕获
捕获自 Azure Pipelines build 完成 event。
事件类型
explicit
|
|||
|
QA 测试失败
|
表示工作项未通过质量保证测试,正被发回开发阶段。这通过状态从测试状态变回“进行中”或“活动”状态来捕获。 | ||
|
为何重要
该活动对于识别返工循环至关重要。此事件发生频率过高通常意味着代码质量、需求定义或测试流程存在问题。
获取方式
通过检测工作项历史记录中从“QA 中”等状态回到“活动”或“进行中”等状态的迁移而推断得出。
捕获
推断自状态字段从“QA 中”变回“活动”。
事件类型
inferred
|
|||
|
QA 测试已完成
|
标志着质量保证阶段圆满结束。当工作项状态从测试状态变更为“UAT 就绪”或“QA 已审批”时,即可判定此状态。 | ||
|
为何重要
这是一个关键的质量门禁,表示项目已就绪,可以进行用户验收测试或发布。此后的延迟可能意味着 UAT 或发布计划存在瓶颈。
获取方式
推断自工作项历史记录,当 System.State 字段从“QA 中”更改为随后的“准备 UAT”或“完成”等状态时。
捕获
推断自状态字段从“QA 中”变为“准备 UAT”。
事件类型
inferred
|
|||
|
UAT 已开始
|
代表用户验收测试的开始,由业务相关方验证功能。通常根据状态变更为“UAT 中”或类似状态来判定。 | ||
|
为何重要
测量发布前最终验证的开始时间。UAT 的持续时间和审批等待时间是流程优化分析中的关键指标。
获取方式
推断自工作项历史记录,当 System.State 字段更新为代表 UAT 的自定义状态(如“UAT 中”)时。
捕获
推断自状态字段变为“UAT 中”。
事件类型
inferred
|
|||
|
工作项已关闭
|
代表部署及部署后验证完成后的工作项最终关闭。通过状态变更为“已关闭”或“已完成”来获取。 | ||
|
为何重要
此活动标志着一个工作项整个流程的最终成功完成。它是生命周期的明确终点。
获取方式
推断自工作项历史记录,当 System.State 字段更改为“已关闭”或“已完成”类别中的类似终态时。
捕获
推断自状态字段变为“已关闭”。
事件类型
inferred
|
|||
|
工作项已取消
|
表示工作项已取消,将不再完成或部署。这通过状态更改为“已移除”、“已取消”或类似状态来捕获。 | ||
|
为何重要
这代表了一种非成功的流程终点。分析已取消的项目可以揭示在计划、优先级排序或需求定义方面存在的问题。
获取方式
推断自工作项历史记录,当 System.State 字段更改为“已移除”类别中的终态时。
捕获
推断自状态字段变为“已移除”或“已取消”。
事件类型
inferred
|
|||
|
工作项已批准
|
代表工作项的正式审批,确认其定义清晰并可进入开发。通常根据“状态”字段变更为“已审批”或“开发就绪”等值来判定。 | ||
|
为何重要
追踪审批环节有助于分析从提交创意到承诺开发之间的时间。它能突出呈现计划和待办事项整理阶段可能存在的延迟。
获取方式
通过检测工作项历史记录中 System.State 字段更改为“已批准”或类似的自定义状态而推断得出。
捕获
推断自状态字段变为“已批准”。
事件类型
inferred
|
|||
|
开发完成
|
表示所有开发和单元测试活动已完成,项目已准备好进行正式测试。通常根据工作项状态变更为“已解决”或“测试就绪”来判定。 | ||
|
为何重要
这标志着从开发团队到 QA 团队的重要交接。测量直到“QA 测试已启动”的时间有助于识别交接延迟。
获取方式
推断自工作项历史记录,当 System.State 字段更改为“已解决”或指示准备好进行 QA 的自定义状态时。
捕获
推断自状态字段变为“已解决”。
事件类型
inferred
|
|||