软件开发生命周期数据模板
软件开发生命周期数据模板
- 建议收集的属性
- SDLC需要跟踪的关键活动
- Azure DevOps数据提取详细指南
软件开发生命周期属性
| 名称 | 说明 | ||
|---|---|---|---|
|
事件时间
EventTime
|
指明开发项的特定活动或事件发生时间的精确时间戳。 | ||
|
说明
事件时间记录开发生命周期中每项活动的日期和时间。此时间戳是按时间顺序排列事件并计算事件间耗时的基础。 在分析中,此属性对于计算所有基于时间的指标至关重要,包括周期时间、处理时间和等待时间。它可用于生成按时间排序的事件日志,这是开展流程挖掘分析所需的输入数据。您可以据此诊断延误、衡量相对于SLA的绩效,并追踪趋势变化。
重要性
此时间戳提供事件的时间顺序,是计算所有基于时长的KPI、了解流程走向和发现瓶颈的关键。
获取途径
这是工作项历史记录中每次更新对应的“Changed Date”。对于构建或部署等外部事件,则使用该事件的完成时间戳。
示例
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:00Z
|
|||
|
开发项
DevelopmentItem
|
单个工作单元的唯一标识符,例如功能、Bug或用户故事,也是流程中的案例标识符。 | ||
|
说明
开发项是Azure DevOps中追踪的独立工作单元。每个开发项都有唯一ID,是所有流程活动围绕的核心对象,涵盖创建、规划、开发、测试和部署。 在流程挖掘分析中,此属性是将所有相关事件关联到同一案例的基础。它可以还原每个工作项的端到端生命周期,从而逐项分析周期时间、流程偏差和返工循环。
重要性
这是将所有流程步骤关联为完整案例的核心标识符,使软件开发生命周期的端到端分析成为可能。
获取途径
对应Azure DevOps Boards中工作项的“ID”字段,可通过Azure DevOps Work Item Tracking REST API获取。
示例
10234102351023610237
|
|||
|
活动名称
ActivityName
|
开发生命周期中某个时间点发生的特定事件或Task的名称。 | ||
|
说明
活动名称用于描述流程中的具体步骤或里程碑,例如“开发已开始”、“拉取请求已创建”或“已部署到生产环境”。这些活动根据工作项状态变更、关联的构建或拉取请求事件,以及自定义事件得出。 此属性对于构建流程图至关重要,流程图可以直观呈现工作流。分析人员可借此了解事件顺序、识别常见路径、发现特定活动之间的瓶颈,并分析各步骤的发生频率。
重要性
它定义了流程中的各个步骤,构成流程图的基础,并支持对工作流、瓶颈和偏差进行分析。
获取途径
通常根据工作项“State”字段的变更,或构建、提交和拉取请求等关联事件得出。工作项历史记录提供这些事件的原始数据。
示例
开发已开始拉取请求已完成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中工作项的“Priority”字段。
示例
1234
|
|||
|
团队名称
TeamName
|
负责该工作项的开发团队名称。 | ||
|
说明
团队名称用于标识负责某个工作项的具体团队。在Azure DevOps中,工作通常按团队组织,一个团队可能是较大项目中的一个子集。 此属性支持按团队细分流程分析。您可以借此比较不同团队的流程和表现,找出高绩效团队的有效做法,并发现哪些团队需要支持或改进流程。
重要性
它支持不同团队之间的对比分析,帮助发现绩效差异,并在组织内分享有效做法。
获取途径
通常根据工作项的“Area Path”推导,因为Azure DevOps中一般会将团队映射到特定区域路径。
示例
凤凰团队欧米茄小组平台核心团队前端团队
|
|||
|
工作项类型
WorkItemType
|
开发项的分类,例如Bug、功能、用户故事或Task。 | ||
|
说明
工作项类型用于对所执行的工作进行分类。不同类型的工作项通常遵循不同的流程路径,并有不同的绩效预期或SLA。例如,与功能相比,Bug可能采用更快的处理路径。 此属性对于对比分析至关重要。您可以按工作类型筛选流程图或KPI,了解Bug和功能各自的流程效率,或追踪不同工作类别的历史周期时间趋势。
重要性
它支持对流程分析进行细分,以便比较Bug、功能等不同工作类别的工作流和绩效。
获取途径
对应Azure DevOps中工作项的“Work Item Type”字段。
示例
缺陷功能用户故事Task
|
|||
|
指派对象
AssignedTo
|
当前负责该开发项的用户或团队成员。 | ||
|
说明
此属性用于标识流程某一阶段负责工作项的人员。工作项在生命周期中可能多次变更指派对象,例如从开发人员转给测试人员,再转给发布经理。 按“指派对象”分析,对于开发人员和测试人员工作量概览仪表板至关重要。它有助于了解资源分配、发现工作负荷过重的团队成员,并分析个人或团队之间的绩效差异。
重要性
它支持按资源开展分析,帮助您了解工作负荷分布、发现特定资源相关的瓶颈,并管理团队产能。
获取途径
对应Azure DevOps中工作项的“Assigned To”字段。每个事件的值取自工作项历史记录。
示例
jane.doe@example.comjohn.smith@example.com未指派
|
|||
|
是否返工
IsRework
|
用于标记开发项是否重新进入生命周期中先前阶段的布尔值。 | ||
|
说明
如果工作项出现返工循环,此标记将设为true。例如,工作项从“QA测试已完成”退回到“开发已开始”。系统通过分析案例的活动顺序并识别非线性进展来计算此属性。 此属性是“返工与重新测试频率”仪表板和返工循环频率KPI的重要依据。您可以轻松筛选并量化返工,进而定位导致效率低下的质量问题、沟通不畅或测试不足。
重要性
它能直接识别并量化返工,帮助发现延长周期时间的质量问题和流程低效之处。
获取途径
此属性根据事件日志中每个案例的活动顺序计算得出。
示例
truefalse
|
|||
|
状态
State
|
开发项在工作流中的当前状态,例如“新建”“活跃”“已解决”或“已关闭”。 | ||
|
说明
“State”属性表示工作项在任一时点的正式状态,具体状态由项目的流程模板定义。状态之间的转换是生成事件日志活动的主要依据。 “Activity”属性通常能更清楚地描述状态变化,而原始“State”属性则适用于筛选和分析。它有助于了解工作项在各状态中停留的时间,也是构建阶段耗时仪表板和分析交接情况的基础。
重要性
它表示工作项在生命周期中的状态,是了解流程顺序流和计算各阶段耗时的基础。
获取途径
对应Azure DevOps中工作项的“State”字段。
示例
新建活跃测试中已解决已关闭
|
|||
|
结束时间
EndTime
|
表示活动完成时间的时间戳,用于计算活动的处理时间。 | ||
|
说明
结束时间标记活动的结束。在许多事件日志中,下一项活动的开始时间会作为上一项活动的结束时间。不过,单独记录结束时间可以更准确地计算活动处理时间和活动间的空闲时间。 此属性对于计算ProcessingTime KPI和开展详细的瓶颈分析至关重要。它有助于区分实际处理Task的时间与等待下一步开始的时间,这也是阶段交接分析仪表板的关键数据。
重要性
它可以精确计算活动处理时间和空闲时间,是瓶颈分析和效率改进的基础。
获取途径
此值通常通过推算得出,可以使用同一案例中后续事件的开始时间;如果源系统记录了Task的开始和结束时间,也可以直接使用记录值。
示例
2023-10-26T18:00:00Z2023-10-27T15:00:00Z2023-10-28T11:00:00Z
|
|||
|
严重程度
Severity
|
表示缺陷或问题对系统或最终用户造成的影响。 | ||
|
说明
严重程度用于划分缺陷的影响范围,从严重的系统故障到轻微的界面问题。它与决定处理顺序的优先级不同。例如,严重程度较高的缺陷如果有现成的替代方案,优先级也可能较低。 此属性为分析提供了另一个维度,尤其适用于“按优先级分析吞吐量和周期时间”仪表板。借助它,您可以分析“我们是否优先修复最严重的缺陷”等问题,并了解当前处理工作的风险状况。
重要性
它有助于按业务影响对工作项分类,从而分析团队处理高影响问题的成效。
获取途径
对应Azure DevOps中工作项的“Severity”字段,通常用于缺陷。
示例
1-严重2-高3-中4-低
|
|||
|
审批等待时间
ApprovalWaitingTime
|
提出审批请求后,开发项等待审批所用的时间。 | ||
|
说明
此指标衡量工作项等待审批的特定时段,例如“UAT已开始”到“UAT已批准”之间的时间。系统会针对指定案例,计算这两个活动之间的时长。 此计算属性直接支持“审批等待时间分析”仪表板及相应KPI。单独识别这些延误后,团队便可改进沟通和决策流程,减少空等时间并加快整体生命周期。
重要性
它专门衡量等待决策或审批造成的延误,帮助发现改进沟通和决策流程的机会。
获取途径
系统会在事件日志中查找特定的审批开始和结束活动(例如“UAT已开始”和“UAT已批准”),并计算两者之间的时间差。
示例
3天2小时1天8小时30分钟4小时
|
|||
|
拉取请求ID
PullRequestId
|
与开发项关联的拉取请求标识符。 | ||
|
说明
此属性将工作项关联到特定拉取请求。拉取请求用于提交和审查代码更改,一个工作项可能关联多个拉取请求。 有了拉取请求ID,您就可以更细致地分析生命周期中的代码审查和集成环节。您可以衡量从创建拉取请求到完成所需的时间,也可以分析拉取请求被拒绝或需要大幅修改的频率,这些情况可能反映代码质量或需求清晰度。
重要性
它将开发工作与具体的代码审查活动关联起来,便于详细分析代码集成和质量保证流程。
获取途径
此信息可在Azure DevOps工作项的“Links”或“Development”部分找到。
示例
452145334589
|
|||
|
迭代路径
IterationPath
|
工作项所属的开发冲刺或固定周期。 | ||
|
说明
迭代路径(即冲刺)表示一段特定的限时开发周期。工作项会分配到某个迭代中,并计划在该周期内完成。 按迭代路径分析有助于逐个冲刺了解流程表现。您可以跟踪周期时间是否随冲刺推进而缩短,分析延期结转的工作,并评估冲刺计划的可预测性。
重要性
它支持按冲刺分析,帮助团队评估长期表现并改进敏捷实践。
获取途径
对应Azure DevOps中工作项的“Iteration Path”字段。
示例
电子商务平台\冲刺12电子商务平台\冲刺13移动应用重启项目\阶段2\冲刺4
|
|||
|
阶段交接时间
StageHandoffTime
|
一个主要阶段完成到下一阶段开始之间的空闲时长。 | ||
|
说明
阶段交接时间用于衡量流程相邻阶段之间的等待时长,例如“开发已完成”到“QA测试已开始”之间的时间。系统会识别这些关键转换,并计算前一活动结束到后一活动开始之间的间隔。 此指标是“阶段耗时与交接分析”仪表板的重点。单独识别和衡量交接时间,有助于发现工作闲置的隐性瓶颈,常见原因包括资源不可用、沟通延迟或流程低效。
重要性
它量化流程各阶段之间的等待时间,直接揭示不属于实际工作的隐性瓶颈和延误。
获取途径
此属性需要通过计算得出。首先识别代表交接的相邻活动,再计算两者之间的时间差。
示例
2小时15分钟1天4小时30分钟
|
|||
|
项目名称
ProjectName
|
开发项所属Azure DevOps项目的名称。 | ||
|
说明
此属性用于标识工作项所在的Azure DevOps组织内的具体项目,为拥有多个项目的组织提供整体背景信息。 项目名称是筛选和比较的重要维度。它支持“历史周期时间趋势”仪表板按项目细分分析,帮助您发现不同项目的效率差异,以及某个项目的流程改进是否带来了积极影响。
重要性
它为分析提供了较高层级的分组依据,便于比较不同项目的绩效并分析趋势。
获取途径
对应Azure DevOps中工作项的“Team Project”字段。
示例
电子商务平台移动应用重启项目数据仓库现代化项目
|
|||
软件开发生命周期活动
| 活动 | 说明 | ||
|---|---|---|---|
|
QA测试已开始
|
表示正式质量保证测试阶段开始。通常在工作项状态变更为“In QA”、“Testing”或类似值时推断此活动。 | ||
|
重要性
标志着QA周期的开始。分析此阶段的耗时,对于了解测试瓶颈和效率至关重要。
获取途径
通过工作项历史记录推断:追踪System.State字段是否变更为“In QA”或其他指定的测试状态。
采集
根据State字段变更为“In QA”或“Testing”推断。
事件类型
inferred
|
|||
|
UAT已批准
|
此活动表示业务相关方在用户验收测试后已批准更改。通常根据状态从“In UAT”变更为“UAT Approved”或“Ready for Release”来推断。 | ||
|
重要性
这是关键审批节点,确认工作项符合业务需求并已准备好部署到生产环境。
获取途径
通过工作项历史记录推断:检测System.State字段是否从UAT状态变更为已批准或已准备发布的状态。
采集
根据State字段从“In UAT”变更为“Ready for Release”推断。
事件类型
inferred
|
|||
|
工作项已创建
|
此活动标志着开发生命周期的开始,表示创建了新的工作项,例如用户故事、Bug或Task。在Azure DevOps Boards中保存新记录时,系统会明确记录此事件。 | ||
|
重要性
这是流程的主要开始事件,对于衡量端到端开发周期时间和了解工作的初始来源至关重要。
获取途径
此事件取自工作项本身的“Created Date”。工作项历史记录表也会记录这次初始状态转换。
采集
取自工作项的“Created Date”字段。
事件类型
explicit
|
|||
|
已部署到生产环境
|
标志着与工作项关联的代码已成功部署到生产环境。Azure Pipelines发布日志会明确记录此事件。 | ||
|
重要性
这是代表价值交付的关键节点,也是计算交付周期和周期时间的终点。
获取途径
取自Azure Pipelines发布流水线数据,具体为部署到与工作项关联的“Production”阶段时记录的完成事件。
采集
取自发布流水线的部署完成事件。
事件类型
explicit
|
|||
|
开发已开始
|
此活动表示开发人员已开始实际处理该工作项。通常根据工作项状态变更为“活跃”、“In Progress”或“Committed”来推断。 | ||
|
重要性
标志着主动开发阶段的开始。分析从“Created”到“Development Started”的时间,可以了解待办事项的排队时长。
获取途径
通过工作项历史记录推断:当System.State字段从“New”或“已批准”变更为“In Progress”时记录。
采集
根据State字段变更为“活跃”或“In Progress”推断。
事件类型
inferred
|
|||
|
拉取请求已创建
|
表示开发人员已完成初步编码,并通过拉取请求提交更改以供审查。此事件将工作项与Azure Repos中的特定代码更改关联起来。 | ||
|
重要性
这是从开发到代码审查的关键交接。追踪此事件有助于衡量编码耗时,并确定代码何时可以进入同行审查。
获取途径
从Azure Repos数据中获取,将拉取请求创建事件与关联的工作项关联起来。通常由开发人员明确建立此关联。
采集
取自Azure Repos中与工作项关联的拉取请求创建事件。
事件类型
explicit
|
|||
|
拉取请求已完成
|
表示代码审查已成功完成:拉取请求获批,代码合并到目标分支。Azure Repos会明确记录此事件。 | ||
|
重要性
标志着代码审查阶段结束,该阶段通常是瓶颈。分析从PR创建到完成的时间,有助于了解审查周期的效率。
获取途径
取自Azure Repos中与工作项关联的拉取请求完成或合并事件。
采集
取自与工作项关联的拉取请求合并事件。
事件类型
explicit
|
|||
|
QA测试已完成
|
标志着质量保证阶段已成功完成。通常在工作项状态从测试状态变更为“Ready for UAT”或“QA Approved”等状态时推断。 | ||
|
重要性
这是关键质量关卡,表示工作项已准备好进行用户验收测试或发布。此后出现延误,可能表明UAT或发布规划环节存在瓶颈。
获取途径
通过工作项历史记录推断:当System.State字段从“In QA”变更为“Ready for UAT”或“Done”等后续状态时记录。
采集
根据State字段从“In QA”变更为“Ready for UAT”推断。
事件类型
inferred
|
|||
|
QA测试未通过
|
表示工作项未通过质量保证测试,正在退回开发阶段。此事件通过状态从测试状态变更回“In Progress”或“活跃”来记录。 | ||
|
重要性
此活动对于发现返工循环至关重要。此事件频繁发生,可能表明代码质量、需求或测试流程存在问题。
获取途径
通过工作项历史记录推断:检测状态是否从“In QA”等状态变更回“活跃”或“In Progress”等状态。
采集
根据State字段从“In QA”变更回“活跃”推断。
事件类型
inferred
|
|||
|
UAT已开始
|
表示用户验收测试开始,业务相关方将在此阶段验证功能。通常根据状态变更为“In UAT”或类似状态来推断。 | ||
|
重要性
衡量发布前最终验证的开始时间。分析UAT耗时和审批等待时间,对于优化流程至关重要。
获取途径
通过工作项历史记录推断:当System.State字段更新为表示UAT的自定义状态(例如“In UAT”)时记录。
采集
根据State字段变更为“In UAT”推断。
事件类型
inferred
|
|||
|
工作项已关闭
|
表示工作项在部署及部署后验证完成后正式关闭。通常根据状态变更为“Closed”或“Done”来记录。 | ||
|
重要性
此活动标志着工作项整个流程最终成功完成,是其生命周期的明确终点。
获取途径
通过工作项历史记录推断:当System.State字段变更为“Completed”类别中的“Closed”或类似终止状态时记录。
采集
根据State字段变更为“Closed”推断。
事件类型
inferred
|
|||
|
工作项已取消
|
表示工作项已取消,不会完成或部署。通常根据状态变更为“Removed”、“Cancelled”或类似状态来记录。 | ||
|
重要性
这表示流程以另一种未成功的方式结束。分析已取消的工作项,有助于发现规划、优先级排序或需求定义方面的问题。
获取途径
通过工作项历史记录推断:当System.State字段变更为“Removed”类别中的终止状态时记录。
采集
根据State字段变更为“Removed”或“Cancelled”推断。
事件类型
inferred
|
|||
|
工作项已批准
|
表示工作项已正式获批,确认其定义清晰并已准备好进入开发阶段。通常根据“State”字段变更为“已批准”或“Ready for Dev”等值来推断此事件。 | ||
|
重要性
追踪审批情况有助于分析从提交想法到承诺开发所需的时间,并揭示规划和待办事项梳理阶段可能存在的延误。
获取途径
通过工作项历史记录推断:检测System.State字段是否变更为“已批准”或类似的自定义状态。
采集
根据State字段变更为“已批准”推断。
事件类型
inferred
|
|||
|
开发已完成
|
表示所有开发和单元测试活动均已完成,工作项已准备好进入正式测试。通常根据工作项状态变更为“Resolved”或“Ready for Test”来推断。 | ||
|
重要性
标志着工作从开发团队交接给QA团队。衡量到“QA Testing Started”所需的时间,有助于发现交接延误。
获取途径
通过工作项历史记录推断:当System.State字段变更为“Resolved”或表示已准备好进行QA的自定义状态时记录。
采集
根据State字段变更为“Resolved”推断。
事件类型
inferred
|
|||
|
构建成功
|
此活动确认源代码及新增更改已由构建流水线成功编译并打包。Azure Pipelines会明确记录此事件。 | ||
|
重要性
这是关键质量关卡,可确保新代码正确集成且不会导致构建失败。此阶段出现故障可能表明存在集成问题。
获取途径
取自Azure Pipelines的构建完成事件。构建需要直接关联工作项,或通过关联的拉取请求建立关联。
采集
取自Azure Pipelines的构建完成事件。
事件类型
explicit
|
|||
数据提取指南
立即优化Azure DevOps中的SDLC!
将周期时间缩短30%,消除SDLC工作流中的瓶颈。
无需信用卡,几分钟即可开始。