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