> 持续流程改进 > 软件开发生命周期 (SDLC) > Jira Software > 数据模板

您的软件开发生命周期数据模板

Jira Software

← 返回改进指南

软件开发生命周期属性 (22) 软件开发生命周期活动 (14) 提取指南 (4)

您的软件开发生命周期数据模板

此模板为您收集 SDLC 分析所需的核心数据提供了清晰路线图。它概述了需要收集的字段、关键流程步骤，以及从 Jira Software 提取信息的实践指导。请参考此指南准备您的事件日志，以开展高效的流程挖掘。

建议收集的属性
需要追踪的关键活动
Jira Software 数据提取指南

不熟悉事件日志？了解如何创建流程挖掘事件日志.

下载模板

软件开发生命周期属性

为了进行全面的 SDLC 分析，建议在事件日志中包含这些数据字段。

5 必填 6 推荐 11 可选

	名称	描述
	Event 时间 EventTime	特定开发活动或事件发生的具体日期和时间。
描述事件时间 (Event Time) 是记录活动发生的时间戳。这是所有流程挖掘分析的时间基础，为每个案例提供了事件的时间顺序。此属性对于计算所有基于时间的指标（包括周期时间、处理时间以及活动间的等待时间）至关重要。它能够分析流程随时间变化的绩效，帮助识别在开发生命周期的何时何地发生了延迟。为何重要该时间戳是正确排列事件顺序以及计算所有耗时指标的基础，对于理解流程效率和识别延迟至关重要。获取方式这对应于 Issue 变更日志或历史记录中每个条目的“created”时间戳。示例 2023-10-26T10:00:00Z2023-11-15T14:35:10Z2024-01-05T09:00:00Z
	开发项 DevelopmentItem	Jira Software 中单个工作单元（如 Story、Bug 或任务）的唯一标识符。
描述 “开发事项”作为主要案例标识符 (Case ID)，代表一个独立的工作单元，如功能、Bug 修复或任务。它关联了该事项从最初构思、规划到开发、测试及部署的所有活动。在 Jira 中，这通常对应于 Issue Key，例如“PROJ-123”。分析此属性可以追踪每个工作项的完整端到端生命周期，它是构建流程图、计算周期时间以及识别不同事项在开发流程中流动差异的基础。为何重要这是将所有相关开发活动关联在一起的核心密钥，通过它可全程追踪单个工作项从开始到结束的完整旅程。获取方式这是 Jira Software Issue API 对象中 Issue 的标准“key”字段。示例 PROJ-101CORE-5432API-789
	活动 Activity	事项开发生命周期中发生的特定事件或状态变更的名称。
描述此属性代表软件开发过程中的一个独立步骤或里程碑。这些活动源于 Jira Issue 状态字段的变更或其他重要事件（如代码提交或评审）。在流程挖掘中，这些活动的顺序构成了流程图。通过分析活动，您可以识别流程走向、衡量各阶段耗时，并检测与标准流转不符的情况，如返工循环或跳过质量门禁。为何重要活动定义了流程的步骤，它们的顺序对于可视化流程流、识别瓶颈以及分析流程变体至关重要。获取方式通常源自 Jira Issue 历史记录或变更日志中的“status”字段变更。还可以通过连接的开发工具数据进行补充。示例开发已开始已执行代码审查QA 测试完成已部署到生产环境
	最后数据更新 LastDataUpdate	指示该流程数据上次从源系统刷新的时间戳。
描述该属性记录了最近一次从 Jira Software 提取数据的日期和时间，反映了分析数据的时效性。了解上次更新时间对于评估流程洞察的时效性非常重要。它能帮助分析师和业务人员确认所见即所得，并明确分析中所包含事件的时间截止点。为何重要指示数据的实时性，这对于确保分析和仪表板能够反映流程的最新状态至关重要。获取方式该时间戳在数据提取、转换和加载 (ETL) 流程结束时生成并记录。示例 2024-03-15T02:00:00Z2024-03-16T02:00:00Z
	源系统 SourceSystem	提取开发生命周期数据的源系统。
描述该属性标识数据的来源。在此流程中，它始终为“Jira Software”。如果在大型分析中组合了多个源系统，该字段对于区分数据非常有用。在更广泛的 IT 架构中，指定源系统可确保数据血缘清晰，并有助于跨不同平台管理数据质量和集成工作。为何重要提供清晰的数据来源记录。在集成多个系统的数据，或进行数据治理和审计时，这一点至关重要。获取方式这是一个静态值，应在数据提取和转换过程中添加。示例 Jira Software
	受理人 Assignee	当前被分配处理该开发事项的用户。
描述 “负责人 (Assignee)”是当前阶段负责该事项的个人。在 Jira 中，这是一个标准字段，随着事项在人员和团队间流转而更新。分析负责人是了解资源分配、负载分布和交接点的关键。它有助于解答：各阶段涉及哪些开发人员或团队？谁是效率瓶颈？工作在组织中是如何分配的？为何重要识别活动对应的负责用户或资源，从而实现工作量分析、资源管理并了解个人之间的交接情况。获取方式这是 Jira Issue API 响应中“fields”对象下的“assignee”字段。示例 Alice SmithBob Johnson未分配
	团队名称 TeamName	负责该事项的开发团队。
描述代表分配给开发事项的特定敏捷团队或功能团队。在 Jira 中，这通常作为一个自定义字段实现，或者通过项目、组件等信息推断得出。该属性对于团队维度的绩效分析至关重要。通过它，您可以筛选仪表板以查看各团队的周期时间、返工率和吞吐量等指标，这对于“跨阶段协作效率”和“开发负载与进度”分析非常有价值。为何重要允许对不同开发团队进行绩效衡量和比较，有助于识别高绩效团队并分享最佳实践。获取方式这通常是 Jira 中的自定义字段。请咨询您的 Jira 管理员以确认具体的字段名称，可能是“Team”、“Squad”或类似名称。示例凤凰团队核心服务UI/UX 复仇者联盟
	项优先级 ItemPriority	分配给开发事项的优先级，指示其紧急程度。
描述项优先级 (Item Priority) 定义了工作项的相对重要性或紧急程度。Jira 提供了一个标准的“优先级”字段，具有可配置的级别，如最高、高、中和低。分析优先级对于检查合规性和识别关键项的瓶颈至关重要。例如，“高优先级项合规性检查”仪表板依靠此属性来验证高优先级项是否按预期得到了加速处理，还是与低优先级项一样被卡在了同一个队列中。为何重要有助于分析高优先级项是否比低优先级项处理得更快，以及它们是否遵循了更精简的路径，从而确保达成 SLA。获取方式这是 Jira Issue API 响应中“fields”对象下的“priority”字段。示例最高高中低
	项目名称 ProjectName	开发事项所属的 Jira 项目名称。
描述在 Jira 中，所有工作项都按项目组织。项目名称 (Project Name) 提供了高层级的背景信息，通常对应于特定的产品、团队或倡议。此属性是一个强大的过滤和对比维度。它允许分析并基准化不同项目或产品间的 SDLC 流程。这可以揭示哪些项目效率更高、哪些返工更多，以及不同团队是否遵循了不同的流程变体。为何重要允许按项目、产品或团队对流程分析进行细分，从而进行绩效对比并识别最佳实践。获取方式这是 Jira Issue API 响应中“fields”对象下的“project”字段。示例移动应用开发核心平台数据科学
	项目状态 ItemStatus	开发事项在工作流中的当前状态。
描述该属性反映了开发事项在特定时间点所处的具体阶段，如“进行中”、“评审中”或“完成”。随时间变化的状态变更序列构成了流程挖掘的活动基础。 “活动”属性代表变更事件，而“事项状态”则提供事项的即时状态。它可以作为筛选和分析的维度，帮助您查看当前各状态的事项分布，或分析长期停留在某一状态下的事项特征。为何重要提供事项在生命周期中所处位置的快照，这对于基于状态的分析以及掌握当前在制品 (WIP) 的状态至关重要。获取方式这是 Jira Issue API 响应中“fields”对象下的“status”字段。示例待办进行中审核中已完成
	项目类型 ItemType	开发事项的类型，例如 Bug、Story、Task 或 Epic。
描述项类型 (Item Type) 对正在执行的工作性质进行分类。Jira 使用标准的 `issuetype` 字段来区分不同种类的工作项，这些项通常具有独特的工作流。此属性对于对比分析至关重要。它允许您针对特定类型的工作过滤流程，例如对比“Bug”与“Story”的生命周期。这有助于识别某些类型的工作是否更容易出现延迟、返工或偏离标准流程的情况。为何重要允许对流程分析进行切片，以比较不同类型的工作（如 Bug 与新功能）是如何处理的，以及它们的流程在何处存在差异。获取方式这是 Jira Issue API 响应中“fields”对象下的“issuetype”字段。示例 StoryBug任务Epic
	Sprint 名称 SprintName	开发事项所属的敏捷 Sprint 名称。
描述对于使用 Scrum 的团队，Sprint（迭代）是完成一组工作的时间盒。此属性记录了某个项所属的 Sprint 名称或标识符。按 Sprint 分析是专注于敏捷的流程挖掘的基础。它有助于评估单个 Sprint 的表现，了解遗留工作，并根据 Sprint 目标跟踪进度。它提供了一个比通用日期范围更具体的时间背景。为何重要为敏捷团队提供关键背景信息，支持按 Sprint 维度分析流程效率和吞吐量。获取方式此信息通常存储在由 Jira Software (Agile) 管理的“Sprint”自定义字段中，可通过 Issue API 访问。示例 PROJ Sprint 12023年第四季度 Sprint 311月 PI Sprint 2
	事件结束时间 EventEndTime	活动或状态完成的时间戳。
描述该属性标记活动的完成时间。它是一个特定案例中后续活动开始的时间戳。当“事件时间 (EventTime)”标记活动开始时，“结束时间 (EventEndTime)”标记其结束。两者之差即为该活动的处理时间。这对于计算“平均阶段处理时间”KPI 以及构建分析活动持续时间的仪表板至关重要。为何重要定义活动的结束点，从而可以计算流程中每个步骤的持续时间，这对于瓶颈分析至关重要。获取方式这是一个派生属性。对于给定事件，其结束时间即为同一案例中后续活动的开始时间。示例 2023-10-26T12:30:00Z2023-11-15T18:00:15Z2024-01-05T11:45:00Z
	交接等待时间 HandoffWaitTime	两个连续活动之间的空闲时间。
描述该指标计算从一个活动结束到下一个活动开始之间的等待时间或排队时间，代表了工作闲置等待处理的耗时。它是“平均交接等待时间”KPI 和“跨阶段协作效率”仪表板的关键指标。较长的交接时间通常意味着协调不当、资源受限或团队间（如开发与测试）沟通低效。缩短这种闲置时间是优化整体周期时间的有力杠杆。为何重要突出显示流程中的闲置或排队时间，暴露团队或个人之间交接的低效，并揭示协作问题。获取方式这是一个计算指标。计算方法为：同一案例中当前活动的开始时间减去前一活动的结束时间。示例 017280043200
	修复版本 FixVersion	该开发事项实际解决并发布的软件版本。
描述 Jira 中的“修复版本 (Fix Version)”指包含该已完成事项的发布版本，标志着开发工作的具体成果。该属性提供了实际的发布背景。通过将其与“计划发布版本”对比，可以分析交付绩效。它还可用于将特定版本中的所有交付项分组，以便统一查看发布成果。为何重要确认某项工作包含在哪个版本中，为发布分析和跟踪已交付功能提供真实依据。获取方式这对应于 Jira Issue API 响应中的“fixVersions”字段。示例 v2.1.1 热修复v3.0.0 重大版本发布v2.2.0
	处理时间 ProcessingTime	在特定活动上花费的总活跃时间。
描述 “处理时间”是事项处于特定状态或活动中的持续时间。它的计算方式是日志中单个事件的“结束时间”与“开始时间”之差。该指标是瓶颈分析的核心组成部分，直接用于“平均阶段处理时间”这一 KPI。通过汇总每个活动的处理时间，您可以清晰地看到开发生命周期中哪些阶段最耗时，从而集中精力进行改进。为何重要直接衡量每个活动的持续时间，使其成为识别哪些流程步骤是耗时最长瓶颈的首要指标。获取方式这是一个计算指标，通过事件日志中每一行的“结束时间”减去“开始时间”得出。示例 86400360000604800
	总周期时间 CycleTime	开发事项的完整端到端持续时间。
描述周期时间 (Cycle Time) 衡量从开发项创建到最终解决（如部署到生产环境）所经历的总时长。它在案例级别计算，即第一个事件的时间戳与最后一个事件的时间戳之差。这是衡量整体流程速度和效率的首要 KPI。“平均端到端周期时间”KPI 和“整体 SDLC 周期时间分析”仪表板直接基于此计算。缩短周期时间通常是流程改进计划的核心目标。为何重要衡量开发流程的端到端速度，为整体效率和交付速率提供关键绩效指标 (KPI)。获取方式这是案例层级的计算属性。计算方法为：特定“开发事项”的最后一个事件时间戳减去第一个事件时间戳。示例 12096002592000604800
	报告人 Reporter	最初创建或报告该开发事项的用户。
描述 “报告人 (Reporter)”是在 Jira 中创建 Issue 的个人，可能是开发人员、QA 测试人员、产品经理，甚至是外部客户。分析报告人可以揭示工作的来源。例如，您可以对比 QA 提交的 Bug 与客户反馈的 Bug 在生命周期上有何差异。这也有助于理解流程起步阶段的沟通模式和信息流转。为何重要识别工作项的来源，可用于分析基于任务创建者或 Bug 报告者的模式。获取方式这是 Jira Issue API 响应中“fields”对象下的“reporter”字段。示例查尔斯·达尔文玛丽·居里艾萨克·牛顿
	是否返工 IsRework	指示活动是否属于返工循环一部分的标记。
描述该布尔属性用于标记活动是否代表流程的回退，例如在 QA 测试失败后返回“开始开发”阶段。这通过分析案例的活动序列来判定。识别返工是提升流程效率和质量的基础。该属性直接支持“返工活动率”KPI 和“返工循环频率与路径”仪表板，帮助量化无效工作的比例并找出导致返工的质量瓶颈。为何重要明确标记属于低效返工循环的活动，从而对流程浪费和质量问题进行精确衡量和分析。获取方式这是一个计算属性。它需要预先定义预期的流程走向，然后标记任何回退到前序阶段的异常活动。示例 truefalse
	组件 Component	该项所属项目的子部分或功能区域。
描述在 Jira 中，组件 (Components) 用于将项目中的问题分组成更小、更易于管理的部分。这可以代表一个功能区域（如“用户身份验证”）、一个技术层（如“后端 API”）或一个模块（如“报表”）。按组件分析可以提供更细粒度的开发流程视图。它可以帮助识别应用程序的某些部分是否产生了更多 Bug、拥有更长的开发周期或经历了更多返工，从而指向技术债或复杂性较高的领域。为何重要允许按产品的核心功能或技术领域对流程进行切片，有助于精确定位哪些组件是导致延迟或质量问题的根源。获取方式这是 Jira Issue API 响应中“fields”对象下的标准“components”字段。示例用户界面数据库API Gateway身份验证
	计划发布 PlannedReleaseVersion	该事项计划部署的目标软件版本或发布计划。
描述该属性（通常对应 Jira 中的“影响版本”）指示了功能或修复程序预定的发布版本，作为工作完成的期限或目标。它是衡量“发布及时率”KPI 的核心属性。通过对比实际部署日期与该版本关联的计划发布日期，您可以评估进度的执行力度和发布流程的可预测性。为何重要定义目标交付日期或发布版本，从而计算准时交付率并分析进度计划的遵守情况。获取方式这对应于 Jira Issue API 中的“versions”或“fixVersions”字段。具体使用的规划字段可能因配置而异。示例版本 2.12024年第一季度发布凤凰项目启动
	项解决结果 ItemResolution	关闭开发事项的最终结果或原因。
描述 “解决结果”解释了事项被关闭的具体原因。例如，状态虽然是“已关闭”，但解决结果可能是“已完成”、“不做了”、“重复事项”或“无法重现”。这为工作成果提供了关键背景。分析解决结果有助于区分真正完成的工作与被取消或拒绝的事项。这对于质量分析以及了解高价值工作的实际吞吐量（而非浪费在弃用事项上的精力）至关重要。为何重要区分成功完成的项和因其他原因关闭的项，这对于准确的生产力和质量分析至关重要。获取方式这是 Jira Issue API 响应中“fields”对象下的“resolution”字段，通常仅在 Issue 关闭时填充。示例已完成暂不处理重复无法复现

必填推荐可选

软件开发生命周期活动

这些是事件日志中需要捕获的关键步骤和里程碑，对于准确挖掘 SDLC 流程至关重要。

6 推荐 8 可选

	活动	描述
	QA 测试完成	表示开发事项已通过所有质量保证 (QA) 检查，准备进入下一阶段（如 UAT 或发布）。这通过状态移出核心测试状态来识别。
为何重要这标志着重要质量门禁的完成。分析 QA 阶段的耗时有助于优化测试流程和资源分配。获取方式从 Jira 问题变更日志中推断。它是“状态”字段从“QA 测试中”流转到后续状态（如“准备 UAT”或“准备发布”）时的时间戳。捕获状态从“QA 中”变更为“UAT 就绪”的时间戳。事件类型 inferred
	QA 测试开始	此事件标志着开发事项正式进入 QA 测试阶段。它通常通过 Jira 状态变更为“QA 中”、“测试中”或“待测试”来识别。
为何重要这是开启质量验证循环的关键里程碑。通过衡量从“开发完成”到此时点的耗时，可以直观展示开发与测试团队间的交接延迟。获取方式从 Jira 问题变更日志中推断。它是“状态”字段更改为指定的 QA 测试状态（如“QA 测试中”）时的时间戳。捕获状态变更为“QA 中”或“测试中”的时间戳。事件类型 inferred
	UAT 已批准	代表 UAT 顺利完成，意味着干系人已批准发布。这通常通过状态从“UAT 中”变更为“发布就绪”或“完成”来识别。
为何重要此里程碑确认了业务部门的接受，并为生产环境部署开了绿灯。它是确保交付成果符合用户预期的关键关口。获取方式从 Jira 问题变更日志中推断。它是状态从“UAT 测试中”更改为工作流中下一个状态的时间戳，代表已通过批准。捕获状态从“UAT 中”变更为“发布就绪”的时间戳。事件类型 inferred
	已部署到生产环境	此事件标志着与开发事项相关的代码更改已在生产环境上线。这可以通过状态变更为“完成”或“已发布”来识别，也可以通过集成的 CI/CD 工具捕获。
为何重要这是流程的主要成功终点。对于计算端到端周期时间以及衡量部署频率和吞吐量至关重要。获取方式当状态更改为“已发布”或“已完成”时，可以从 Jira 问题变更日志中推断出来。为了提高准确性，也可以从 Jenkins、Bamboo 等 CI/CD 工具推送的部署事件中捕获，或通过 Jira 中的部署 (Deployments) 功能获取。捕获状态变更为“完成”或“已发布”的时间戳。事件类型 inferred
	开发已开始	代表开发人员开始处理事项的时刻。这通常通过 Jira 工作流中的状态变更来识别，例如 Issue 状态变更为“进行中”。
为何重要这是衡量活跃开发时间的衡量里程碑，有助于区分等待时间与增值工作，是识别瓶颈的核心指标。获取方式从 Jira 问题变更日志中推断。它是“状态”字段首次更改为“进行中”、“开发中”或类似的活跃状态时的时间戳。捕获状态变更为“进行中”的时间戳。事件类型 inferred
	开发项已创建	这标志着生命周期的开始。当一个新的开发事项（如 Story、Bug 或任务）在 Jira 中正式记录时，系统会自动捕获该 Issue 的创建时间戳。
为何重要此活动标志着流程的正式开始，对于计算端到端周期时间和跟踪待办工作总量至关重要。获取方式这是每个 Jira Issue 的基础事件。创建时间戳存储在 Issue 记录的“created”字段中，可通过 Jira API 访问。捕获 Jira Issue 对象上的“created”时间戳字段。事件类型 explicit
	QA 测试失败	表示 QA 团队发现了缺陷，导致开发项发回给开发人员进行返工。这是从向后的状态流转中推断出来的，例如从“QA 测试中”回退到“进行中”或“待办”。
为何重要此活动对于识别返工循环至关重要。跟踪其频率有助于量化低质量带来的成本，并突出开发或需求阶段需要改进的领域。获取方式从 Jira 问题变更日志中推断。在“状态”字段从测试状态（例如“QA 测试中”）流转回先前的开发状态（例如“进行中”）时捕获。捕获状态从测试状态回退到开发状态的时间戳。事件类型 inferred
	UAT 已开始	标记用户验收测试 (UAT) 的开始。在此阶段，业务干系人或最终用户将验证新功能。该活动通常通过 Jira 状态变更为“UAT 中”或“用户验收测试”来识别。
为何重要此活动跟踪发布前最后验证阶段的开始。分析其耗时是了解并减少因干系人响应延迟或反馈周期过长而导致瓶颈的关键。获取方式从 Jira 问题变更日志中推断。它是“状态”字段更新为“UAT 测试中”或类似的指定状态时的时间戳。捕获状态变更为“UAT 中”的时间戳。事件类型 inferred
	发布就绪	表示开发项已通过所有检查，并已打包进特定的软件发布版本中，等待部署。这通常在问题的状态更改为“准备发布”或填充了“修复版本 (Fix Version)”字段时推断出来。
为何重要此活动有助于跟踪发布就绪情况，以及事项在完成所有开发和测试后等待部署窗口的耗时。获取方式通常通过 Jira Issue 变更日志中的状态变更为“发布就绪”来推断，也可以通过设置“修复版本”字段的时间戳来推断。捕获状态变更为“发布就绪”或填充“修复版本”时的时间戳。事件类型 inferred
	已执行代码审查	表示同行或负责人已针对质量、标准和功能对代码进行了审查。这可以从状态更改中推断，例如从“审核中”移至“准备 QA”，或直接从集成的开发工具中获取。
为何重要此活动是关键的质量门禁。分析其持续时间和结果（如返工）有助于提升代码质量并减少后续流程中发现的 Bug。获取方式通常在状态移出“代码审查”状态时从 Jira 问题变更日志中推断出来。如果集成了 Bitbucket 或 GitHub 等代码仓库工具，它也可以是一个明确的事件。捕获状态从“评审中”变更为下一状态的时间戳。事件类型 inferred
	开发已完成	此活动表示开发人员已完成编码，事项准备进入下一阶段（如代码评审或测试）。它通过 Jira 状态变更（如从“进行中”变更为“评审中”或“QA 就绪”）来识别。
为何重要这标志着核心开发阶段的结束，支持对编码时长以及向 QA 团队交接效率的深度分析。获取方式通过捕获“状态”字段从活跃开发状态更改为后续状态（如“审核中”或“准备 QA”）的时间戳，从 Jira 问题变更日志中推断出来。捕获状态从“进行中”变更为“评审中”或“QA 就绪”的时间戳。事件类型 inferred
	开发项已关闭	这是流程的最后一步，确认该事项不再需要进一步处理。通常通过状态变更为“已关闭”并设置“解决结果”字段来识别。
为何重要代表事项旅程的绝对终点。将其与“部署到生产环境”对比，可以揭示管理层面的延迟或部署后的监控期耗时。获取方式从 Jira 问题变更日志中推断。它是“状态”字段更改为“已关闭”并设置了解决结果时的时间戳。捕获状态变更为“已关闭”的时间戳。事件类型 inferred
	开发项已取消	代表开发事项在完成前被终止。这通过状态变更为终态（如“已取消”、“已拒绝”或“不做了”）来识别，通常伴随有特定的解决结果。
为何重要此活动跟踪非成功的流程结果。分析事项取消的原因可以揭示规划、优先级排序或需求定义方面的问题。获取方式从 Jira 问题变更日志中推断。这是问题“状态”更改为“已取消”或“不予解决”并设置了相应解决结果时的时间戳。捕获状态变更为“已取消”、“已拒绝”或“不做了”的时间戳。事件类型 inferred
	项准备开发	表示开发项已完全明确规格、经过评审并排定优先级，开发人员可以随时开始工作。这通常从工作流中的状态更改推断出来，例如从“积压工作 (Backlog)”移至“待办 (To Do)”或“准备开发 (Ready for Dev)”。
为何重要跟踪此项有助于衡量待办事项的准备情况以及开发开始前的等待时间，从而将规划和完善时间与实际开发时间区分开来。获取方式从 Jira 问题变更日志中推断。寻找“状态”字段更改为“准备开发”、“待办”或“选定进行开发”等值的时间戳。捕获状态变更为开发就绪前置状态的时间戳。事件类型 inferred

推荐可选

提取指南

如何从 Jira Software 获取您的数据

步骤

登录您的 Jira Software 实例。
在主导航栏中，选择 问题 (Issues)，然后点击 搜索问题 (Search for issues)。这将打开问题导航器。
在搜索页面上，将默认的 基本 (Basic) 搜索切换为 高级 (Advanced) 搜索，以启用 Jira 查询语言 (JQL)。
在 JQL 查询栏中输入提供的 JQL 查询。根据您的具体要求替换项目键和日期范围的占位符值。
点击搜索图标或按 Enter 键执行查询。这将显示符合您条件的所有开发项列表。
在搜索结果页面的右上角，点击 导出 (Export) 图标（可能看起来像分享图标或有明确标签），然后选择 XML 选项。请勿使用 CSV，因为 XML 格式包含创建事件日志所需的完整且结构化的变更日志历史记录。
将下载的 XML 文件保存到本地。该文件为每个 Jira 问题包含一条记录，但在其中嵌套了所有的历史变更。
重要转换步骤：导出的 XML 文件不是扁平的事件日志。您必须使用外部脚本或 ETL 工具来解析此文件。脚本需要遍历 XML 中的每个 <item> 标签（代表一个 Jira 问题）。
对于每个问题，脚本必须首先使用 created 字段的时间戳为 Development Item Created（开发项已创建）活动生成一行数据。
接下来，脚本必须解析每个问题中的 <changelog> 数据。对于每个代表状态流转的 <changeitem>，在输出文件中生成一个新行。将 Jira 状态流转（例如从“进行中”到“审核中”）映射到相应的业务活动（例如“开发已完成”），并使用流转的时间戳作为 EventTime。
脚本应为每行填充所有必需和推荐的属性，从 XML 结构中提取诸如问题键、问题类型、经办人和项目等数据。
处理完所有问题及其历史记录后，将转换后的数据保存为 CSV 文件，且表头需与指定的属性匹配，以便上传到流程挖掘工具中。

配置

JQL 查询过滤器：JQL 查询是筛选数据的主要工具。关键过滤器包括用于定位特定开发项目的 project、用于仅包含相关项（如 Story、Bug 或 Task）的 issuetype，以及用于定义分析时间窗口的 created。
日期范围：对于初步分析，建议提取 3 到 6 个月的数据。这既能提供足够的数据来发现有意义的模式，又能保持导出文件的大小在可控范围内。在 JQL 中使用 created >= 'YYYY-MM-DD' 和 created <= 'YYYY-MM-DD' 来指定范围。
问题类型：明确 issuetype 的值。通常，您需要包含 Story、Bug、Task 和 Spike，但如果要分析主流程，则应排除像 Epic 这样的容器类问题或 Sub-task 等细碎问题。
导出格式：您必须选择 XML 作为导出格式。标准的 CSV 导出无法可靠地包含重建活动序列所需的结构化变更日志（changelog）数据。
用户权限：执行导出的用户必须对 JQL 查询中指定的 Jira 项目拥有“浏览项目”权限。

a 查询示例 config

project = "[Your Project Key]" AND issuetype in (Story, Bug, Task) AND created >= "[Start Date in YYYY-MM-DD format]" AND created <= "[End Date in YYYY-MM-DD format]" ORDER BY created DESC

步骤

建立数据库连接：确保您拥有 Jira 后端 SQL 数据库的只读访问凭据以及网络连接。此方法仅适用于自托管 (Self-hosted) 的 Jira 安装。
使用 SQL 客户端连接：使用 DBeaver、SQL Server Management Studio 或 pgAdmin 等数据库客户端工具，使用提供的凭据连接到 Jira 数据库。
确认工作流状态：在运行查询之前，进入您的 Jira 项目工作流设置（项目设置 > 工作流）。仔细记录与您需要跟踪的每个活动相对应的确切状态名称，例如“待办 (Backlog)”、“进行中 (In Progress)”、“审核中 (In Review)”、“已完成 (Done)”。
自定义 SQL 查询：将提供的 SQL 查询复制到您的客户端。您必须自定义占位符值。请密切关注每个 UNION ALL 块中 WHERE 子句里的状态名称，因为这些必须与您的项目工作流完全匹配。
设置查询参数：修改日期范围过滤器 (WHERE ji.created >= '2023-01-01') 以定义您要分析的时段。强烈建议通过取消注释并设置项目键过滤器 (--AND p.pkey IN ('PROJ1', 'PROJ2')) 来过滤一个或多个特定项目。
配置自定义字段：在您的 Jira 实例中确定“团队名称”的自定义字段 ID。您可以通过导航到 Jira 的“自定义字段”管理页面找到此 ID。将查询中的占位符 'customfield_10100' 替换为您实际的 ID。
执行查询：针对 Jira 数据库运行修改后的 SQL 查询。
检查输出结果：简要检查返回的数据，确保其包含各种活动的行，且各列已按预期填充。
导出事件日志：将 SQL 客户端的完整结果集导出为 CSV 文件。确保文件编码为 UTF-8。
准备上传：验证导出的 CSV 文件中的列标题是否与要求的属性名称匹配：DevelopmentItem、Activity、EventTime、SourceSystem、LastDataUpdate、Assignee、ItemType、ItemPriority、ItemStatus、ProjectName 和 TeamName。

配置

数据库凭据：需要一个 Jira 数据库的只读用户账号，以防止意外的数据修改。
工作流状态名称：查询的核心依赖于对状态名称的过滤（例如“进行中”、“已完成”）。这些名称根据每个 Jira 工作流和项目的不同而有所区别。您必须将查询中的占位符替换为您配置中的确切名称。
日期范围：查询包含一个 WHERE ji.created >= '[YYYY-MM-DD]' 子句，以限制处理的数据量。对于初步分析，建议选择 3 到 6 个月的时间范围，以确保数据量适中并提高查询速度。
项目过滤：为了让分析更具针对性，强烈建议使用 p.pkey IN ('[YourProjectKey]') 条件来过滤特定的项目键。在大型 Jira 实例中查询所有项目可能会非常缓慢。
团队自定义字段：“团队名称”通常被视为自定义字段。提供的查询使用了一个占位符 ID (customfield_10100)，您必须根据 Jira 实例的实际配置将其更新为正确的 ID。
性能：直接进行数据库查询可能会消耗大量资源。请在非高峰时段执行此提取操作，或者最好针对生产数据库的只读副本运行，以避免影响 Jira 用户的正常使用。

a 查询示例 sql

WITH EventLogBase AS (
    SELECT
        p.pkey || '-' || ji.issuenum AS DevelopmentItem,
        au.display_name AS Assignee,
        it.pname AS ItemType,
        pr.pname AS ItemPriority,
        p.pname AS ProjectName,
        (SELECT cfv.stringvalue FROM customfieldvalue cfv JOIN customfield cf ON cfv.customfield = cf.id WHERE cf.cfname = 'Team' AND cfv.issue = ji.id LIMIT 1) AS TeamName,
        ji.created AS created_timestamp,
        cg.created AS change_timestamp,
        ci.fieldtype,
        ci.field,
        ci.oldstring,
        ci.newstring,
        s.pname as CurrentItemStatus
    FROM jiraissue ji
    LEFT JOIN project p ON ji.project = p.id
    LEFT JOIN issuetype it ON ji.issuetype = it.id
    LEFT JOIN priority pr ON ji.priority = pr.id
    LEFT JOIN issuestatus s ON ji.issuestatus = s.id
    LEFT JOIN app_user au ON ji.assignee = au.user_key
    LEFT JOIN changegroup cg ON cg.issueid = ji.id
    LEFT JOIN changeitem ci ON ci.groupid = cg.id
    WHERE ji.created >= '2023-01-01' --<<< Set your desired start date here
    --AND p.pkey IN ('PROJ1', 'PROJ2') --<<< Uncomment and set your project keys here
)
-- 1. Development Item Created
SELECT
    b.DevelopmentItem,
    'Development Item Created' AS Activity,
    b.created_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.CurrentItemStatus AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM (
    SELECT DISTINCT DevelopmentItem, created_timestamp, Assignee, ItemType, ItemPriority, CurrentItemStatus, ProjectName, TeamName
    FROM EventLogBase
) b

UNION ALL

-- 2. Item Ready for Development
SELECT DISTINCT
    b.DevelopmentItem,
    'Item Ready for Development' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.oldstring = 'Backlog' AND b.newstring = 'To Do' --<<< Adjust status names

UNION ALL

-- 3. Development Started
SELECT DISTINCT
    b.DevelopmentItem,
    'Development Started' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring = 'In Progress' --<<< Adjust status names

UNION ALL

-- 4. Development Completed
SELECT DISTINCT
    b.DevelopmentItem,
    'Development Completed' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.oldstring = 'In Progress' AND b.newstring = 'In Review' --<<< Adjust status names

UNION ALL

-- 5. Code Review Performed
SELECT DISTINCT
    b.DevelopmentItem,
    'Code Review Performed' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.oldstring = 'In Review' AND b.newstring = 'Ready for QA' --<<< Adjust status names

UNION ALL

-- 6. QA Testing Started
SELECT DISTINCT
    b.DevelopmentItem,
    'QA Testing Started' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring = 'In QA' --<<< Adjust status names

UNION ALL

-- 7. QA Testing Failed
SELECT DISTINCT
    b.DevelopmentItem,
    'QA Testing Failed' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.oldstring = 'In QA' AND b.newstring = 'In Progress' --<<< Adjust status names

UNION ALL

-- 8. QA Testing Completed
SELECT DISTINCT
    b.DevelopmentItem,
    'QA Testing Completed' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.oldstring = 'In QA' AND b.newstring = 'Ready for UAT' --<<< Adjust status names

UNION ALL

-- 9. UAT Started
SELECT DISTINCT
    b.DevelopmentItem,
    'UAT Started' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring = 'In UAT' --<<< Adjust status names

UNION ALL

-- 10. UAT Approved
SELECT DISTINCT
    b.DevelopmentItem,
    'UAT Approved' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.oldstring = 'In UAT' AND b.newstring = 'Ready for Release' --<<< Adjust status names

UNION ALL

-- 11. Prepared For Release
SELECT DISTINCT
    b.DevelopmentItem,
    'Prepared For Release' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring = 'Ready for Release' --<<< Adjust status names

UNION ALL

-- 12. Deployed To Production
SELECT DISTINCT
    b.DevelopmentItem,
    'Deployed To Production' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring = 'Released' --<<< Adjust status names

UNION ALL

-- 13. Development Item Closed
SELECT DISTINCT
    b.DevelopmentItem,
    'Development Item Closed' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring = 'Closed' --<<< Adjust status names

UNION ALL

-- 14. Development Item Canceled
SELECT DISTINCT
    b.DevelopmentItem,
    'Development Item Canceled' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring IN ('Canceled', 'Won''t Do', 'Rejected'); --<<< Adjust status names

步骤

前置要求：确保您的系统中已安装 Python 3。运行以下命令安装必要的库（用于 API 调用的 requests 和用于数据处理的 pandas）：pip install requests pandas。
生成 Jira API 令牌：登录您的 Jira 实例。导航到用户个人资料设置，进入“安全”并选择“创建并管理 API 令牌”。创建一个新令牌并安全保存。此令牌将代替密码用于脚本身份验证。
配置 Python 脚本：将提供的 Python 脚本复制到一个文件中，例如 extract_jira_log.py。打开文件并更新顶部的配置部分，填入您的 Jira 站点 URL、电子邮箱以及刚生成的 API 令牌。
定义 JQL 查询：修改脚本中的 JQL_QUERY 变量。此查询定义了要提取的问题范围。一个好的起点是按项目、问题类型和特定日期范围进行过滤，例如：project = "MyProject" AND issuetype in (Story, Bug, Task) AND updated >= -180d。
自定义状态映射：检查脚本中的 STATUS_MAPPING 字典。由于该字典负责将您特定的 Jira 工作流状态转换为流程挖掘的标准活动，因此至关重要。您必须更新字典的键（即 Jira 状态名称），使其与您的工作流完全一致。
执行脚本：在终端中使用以下命令运行脚本：python extract_jira_log.py。脚本将连接到 Jira API，获取问题数据并处理变更日志 (changelog)。
处理 API 分页：脚本会自动处理分页，每批获取 50 个问题。它将持续发送请求，直到检索完符合 JQL 查询的所有问题。
处理问题变更日志：对于每个问题，脚本会检索其完整历史记录。它会识别创建事件，然后迭代所有状态更改，并根据您的 STATUS_MAPPING 为每个相关的流转在事件日志中创建新行。
生成事件日志文件：处理完所有问题后，脚本会将事件编译到 pandas DataFrame 中，添加 SourceSystem 和 LastDataUpdate 等必要的元数据列，并将最终的事件日志保存为同一目录下的 CSV 文件，命名为 jira_event_log.csv。

配置

JIRA_URL：Jira 实例的基础 URL，例如 https://your-company.atlassian.net。
JIRA_EMAIL：用于身份验证的用户账号邮箱地址。
JIRA_API_TOKEN：从 Jira 用户安全设置中生成的 API 令牌，用于脚本身份验证。
JQL_QUERY：Jira 查询语言字符串，用于过滤要提取的问题。强烈建议根据日期范围（如过去 6-12 个月）进行过滤，以控制数据量。您还应该按项目和相关的任务类型（例如 Story、Bug、Task）进行过滤，以确保分析的是正确的流程。
STATUS_MAPPING：一个 Python 字典，用于将特定的 Jira 工作流状态名称映射到所需的通用活动名称。这是确保流程模型准确性的最关键配置。您必须根据项目的实际工作流进行自定义。
前提条件：该脚本需要一个对要提取的项目和问题具有读取权限的 Jira 用户账号。该用户必须拥有使用 REST API 的权限。

a 查询示例 python

import requests
import pandas as pd
from requests.auth import HTTPBasicAuth
from datetime import datetime, timezone
import json

class=class="hl-string">"hl-comment"># --- CONFIGURATION SECTION ---
class=class="hl-string">"hl-comment"># Replace with your Jira instance details
JIRA_URL = class="hl-string">"https://[your-company].atlassian.net"
JIRA_EMAIL = class="hl-string">"[your-email@example.com]"
JIRA_API_TOKEN = class="hl-string">"[your-jira-api-token]"

class=class="hl-string">"hl-comment"># JQL query to select the issues for extraction
class=class="hl-string">"hl-comment"># Best practice: Filter by project, issue type, and a date range
JQL_QUERY = class="hl-string">'project = "PROJ" AND issuetype in (Story, Bug, Task) AND updated >= -180d'

class=class="hl-string">"hl-comment"># --- STATUS MAPPING ---
class=class="hl-string">"hl-comment"># CRITICAL: Customize this mapping to match your Jira workflow statuses.
class=class="hl-string">"hl-comment"># The key is the Jira status name (case-sensitive) and the value is the desired Activity name.
STATUS_MAPPING = {
    class=class="hl-string">"hl-comment"># Example Mappings - Adjust to your workflow
    class="hl-string">'To Do': class="hl-string">'Item Ready for Development',
    class="hl-string">'In Progress': class="hl-string">'Development Started',
    class="hl-string">'In Review': class="hl-string">'Development Completed',
    class="hl-string">'Code Review': class="hl-string">'Code Review Performed', class=class="hl-string">"hl-comment"># Often combined with class="hl-string">'In Review' -> class="hl-string">'In QA' transition
    class="hl-string">'In QA': class="hl-string">'QA Testing Started',
    class="hl-string">'QA In Progress': class="hl-string">'QA Testing Started',
    class="hl-string">'Done from QA to In Progress': class="hl-string">'QA Testing Failed', class=class="hl-string">"hl-comment"># Special case for backward transitions
    class="hl-string">'UAT': class="hl-string">'UAT Started',
    class="hl-string">'Ready for Release': class="hl-string">'Prepared For Release',
    class="hl-string">'Done': class="hl-string">'Deployed To Production', class=class="hl-string">"hl-comment"># Often corresponds to final class="hl-string">'Done' state
    class="hl-string">'Released': class="hl-string">'Deployed To Production',
    class="hl-string">'Closed': class="hl-string">'Development Item Closed',
    class="hl-string">'Canceled': class="hl-string">'Development Item Canceled',
    class="hl-string">'Won\'t Doclass="hl-string">': 'Development Item Canceled',
    class=class="hl-string">"hl-comment"># Transitions to specific activities
    class="hl-string">'transition_In Review_to_In QA': class="hl-string">'Code Review Performed',
    class="hl-string">'transition_In QA_to_Ready for Release': class="hl-string">'QA Testing Completed',
    class="hl-string">'transition_UAT_to_Ready for Release': class="hl-string">'UAT Approved',
}

def get_team_from_issue(issue_fields):
    class=class="hl-string">"hl-comment"># Placeholder function to extract Team Name.
    class=class="hl-string">"hl-comment"># Customize this based on how team information is stored in your Jira.
    class=class="hl-string">"hl-comment"># Common sources are Components, Labels, or a custom field.
    if class="hl-string">'components' in issue_fields and issue_fields[class="hl-string">'components']:
        return issue_fields[class="hl-string">'components'][0][class="hl-string">'name']
    return None

def extract_jira_event_log():
    class="hl-string">"""Extracts an event log from Jira based on a JQL query."""
    auth = HTTPBasicAuth(JIRA_EMAIL, JIRA_API_TOKEN)
    headers = {
        class="hl-string">"Accept": class="hl-string">"application/json"
    }
    search_url = fclass="hl-string">"{JIRA_URL}/rest/api/3/search"

    event_log = []
    start_at = 0
    max_results = 50
    total_issues = 1 class=class="hl-string">"hl-comment"># Initialize to enter loop

    while start_at < total_issues:
        params = {
            class="hl-string">'jql': JQL_QUERY,
            class="hl-string">'startAt': start_at,
            class="hl-string">'maxResults': max_results,
            class="hl-string">'expand': class="hl-string">'changelog'
        }
        response = requests.get(search_url, headers=headers, params=params, auth=auth)
        response.raise_for_status() class=class="hl-string">"hl-comment"># Exit if the request fails
        data = response.json()

        total_issues = data[class="hl-string">'total']
        issues = data[class="hl-string">'issues']

        last_data_update = datetime.now(timezone.utc).isoformat()

        for issue in issues:
            issue_key = issue[class="hl-string">'key']
            fields = issue[class="hl-string">'fields']
            
            class=class="hl-string">"hl-comment"># Common attributes for all events of this issue
            common_attrs = {
                class="hl-string">'DevelopmentItem': issue_key,
                class="hl-string">'ItemType': fields.get(class="hl-string">'issuetype', {}).get(class="hl-string">'name'),
                class="hl-string">'ProjectName': fields.get(class="hl-string">'project', {}).get(class="hl-string">'name'),
                class="hl-string">'SourceSystem': class="hl-string">'Jira Software'
            }

            class=class="hl-string">"hl-comment"># 1. Development Item Created event
            created_time = pd.to_datetime(fields[class="hl-string">'created']).isoformat()
            event_log.append({
                **common_attrs,
                class="hl-string">'Activity': class="hl-string">'Development Item Created',
                class="hl-string">'EventTime': created_time,
                class="hl-string">'Assignee': fields.get(class="hl-string">'creator', {}).get(class="hl-string">'displayName'),
                class="hl-string">'ItemPriority': fields.get(class="hl-string">'priority', {}).get(class="hl-string">'name'),
                class="hl-string">'ItemStatus': class="hl-string">'Created',
                class="hl-string">'TeamName': get_team_from_issue(fields),
                class="hl-string">'LastDataUpdate': last_data_update
            })

            class=class="hl-string">"hl-comment"># Process changelog for status transitions
            if class="hl-string">'changelog' in issue and issue[class="hl-string">'changelog'][class="hl-string">'histories']:
                for history in issue[class="hl-string">'changelog'][class="hl-string">'histories']:
                    event_time = pd.to_datetime(history[class="hl-string">'created']).isoformat()
                    author = history.get(class="hl-string">'author', {}).get(class="hl-string">'displayName')

                    for item in history[class="hl-string">'items']:
                        if item[class="hl-string">'field'] == class="hl-string">'status':
                            from_status = item[class="hl-string">'fromString']
                            to_status = item[class="hl-string">'toString']
                            activity = None

                            class=class="hl-string">"hl-comment"># Handle specific transitions first
                            transition_key = fclass="hl-string">"transition_{from_status.replace(' ', '')}_to_{to_status.replace(' ', '')}"
                            if transition_key in STATUS_MAPPING:
                                activity = STATUS_MAPPING[transition_key]
                            class=class="hl-string">"hl-comment"># Handle backward transitions (rework)
                            elif to_status == class="hl-string">'In Progress' and from_status in [class="hl-string">'In QA', class="hl-string">'QA In Progress', class="hl-string">'In Review']:
                                activity = class="hl-string">'QA Testing Failed'
                            class=class="hl-string">"hl-comment"># Handle general status changes
                            elif to_status in STATUS_MAPPING:
                                activity = STATUS_MAPPING[to_status]
                            
                            if activity:
                                event_log.append({
                                    **common_attrs,
                                    class="hl-string">'Activity': activity,
                                    class="hl-string">'EventTime': event_time,
                                    class="hl-string">'Assignee': author, class=class="hl-string">"hl-comment"># Person who made the change
                                    class="hl-string">'ItemPriority': fields.get(class="hl-string">'priority', {}).get(class="hl-string">'name'),
                                    class="hl-string">'ItemStatus': to_status,
                                    class="hl-string">'TeamName': get_team_from_issue(fields),
                                    class="hl-string">'LastDataUpdate': last_data_update
                                })
        
        start_at += len(issues)
        print(fclass="hl-string">"Processed {start_at} of {total_issues} issues...")

    if not event_log:
        print(class="hl-string">"No events were generated. Check your JQL query and STATUS_MAPPING.")
        return

    class=class="hl-string">"hl-comment"># Convert to DataFrame
    df = pd.DataFrame(event_log)

    class=class="hl-string">"hl-comment"># Ensure required columns are present
    required_cols = [class="hl-string">'DevelopmentItem', class="hl-string">'Activity', class="hl-string">'EventTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate']
    recommended_cols = [class="hl-string">'Assignee', class="hl-string">'ItemType', class="hl-string">'ItemPriority', class="hl-string">'ItemStatus', class="hl-string">'ProjectName', class="hl-string">'TeamName']
    all_cols = required_cols + [col for col in recommended_cols if col in df.columns]
    df = df[all_cols]
    
    class=class="hl-string">"hl-comment"># Save to CSV
    df.to_csv(class="hl-string">'jira_event_log.csv', index=False)
    print(class="hl-string">"\nExtraction complete. Event log saved to jira_event_log.csv")

if __name__ == class="hl-string">"__main__":
    extract_jira_event_log()

步骤

登录您的 Jira Software 实例。
在主导航栏中，选择 问题 (Issues)，然后点击 搜索问题 (Search for issues)。这将打开问题导航器。
在搜索页面上，将默认的 基本 (Basic) 搜索切换为 高级 (Advanced) 搜索，以启用 Jira 查询语言 (JQL)。
在 JQL 查询栏中输入提供的 JQL 查询。根据您的具体要求替换项目键和日期范围的占位符值。
点击搜索图标或按 Enter 键执行查询。这将显示符合您条件的所有开发项列表。
在搜索结果页面的右上角，点击 导出 (Export) 图标（可能看起来像分享图标或有明确标签），然后选择 XML 选项。请勿使用 CSV，因为 XML 格式包含创建事件日志所需的完整且结构化的变更日志历史记录。
将下载的 XML 文件保存到本地。该文件为每个 Jira 问题包含一条记录，但在其中嵌套了所有的历史变更。
重要转换步骤：导出的 XML 文件不是扁平的事件日志。您必须使用外部脚本或 ETL 工具来解析此文件。脚本需要遍历 XML 中的每个 <item> 标签（代表一个 Jira 问题）。
对于每个问题，脚本必须首先使用 created 字段的时间戳为 Development Item Created（开发项已创建）活动生成一行数据。
接下来，脚本必须解析每个问题中的 <changelog> 数据。对于每个代表状态流转的 <changeitem>，在输出文件中生成一个新行。将 Jira 状态流转（例如从“进行中”到“审核中”）映射到相应的业务活动（例如“开发已完成”），并使用流转的时间戳作为 EventTime。
脚本应为每行填充所有必需和推荐的属性，从 XML 结构中提取诸如问题键、问题类型、经办人和项目等数据。
处理完所有问题及其历史记录后，将转换后的数据保存为 CSV 文件，且表头需与指定的属性匹配，以便上传到流程挖掘工具中。

配置

JQL 查询过滤器：JQL 查询是筛选数据的主要工具。关键过滤器包括用于定位特定开发项目的 project、用于仅包含相关项（如 Story、Bug 或 Task）的 issuetype，以及用于定义分析时间窗口的 created。
日期范围：对于初步分析，建议提取 3 到 6 个月的数据。这既能提供足够的数据来发现有意义的模式，又能保持导出文件的大小在可控范围内。在 JQL 中使用 created >= 'YYYY-MM-DD' 和 created <= 'YYYY-MM-DD' 来指定范围。
问题类型：明确 issuetype 的值。通常，您需要包含 Story、Bug、Task 和 Spike，但如果要分析主流程，则应排除像 Epic 这样的容器类问题或 Sub-task 等细碎问题。
导出格式：您必须选择 XML 作为导出格式。标准的 CSV 导出无法可靠地包含重建活动序列所需的结构化变更日志（changelog）数据。
用户权限：执行导出的用户必须对 JQL 查询中指定的 Jira 项目拥有“浏览项目”权限。

a 查询示例 config

project = "[Your Project Key]" AND issuetype in (Story, Bug, Task) AND created >= "[Start Date in YYYY-MM-DD format]" AND created <= "[End Date in YYYY-MM-DD format]" ORDER BY created DESC

您的软件开发生命周期数据模板

您的软件开发生命周期数据模板

软件开发生命周期属性

软件开发生命周期活动

提取指南

使用 Jira JQL 查询并导出 CSV 或 XML

步骤

配置

a 查询示例 config

通过 SQL 直接查询 Jira 数据库 (自托管版)

步骤

配置

a 查询示例 sql

使用官方 Jira REST API 的 Python 脚本

步骤

配置

a 查询示例 python

通过自动化 Webhook 实现实时事件流

步骤

配置

a 查询示例 config

准备好开始了吗？

立即开始优化您的 Jira 软件开发生命周期！

您的软件开发生命周期数据模板

您的软件开发生命周期数据模板

软件开发生命周期属性

软件开发生命周期活动

提取指南

使用 Jira JQL 查询并导出 CSV 或 XML

步骤

配置

a 查询示例 config

通过 SQL 直接查询 Jira 数据库 (自托管版)

步骤

配置

a 查询示例 sql

使用官方 Jira REST API 的 Python 脚本

步骤

配置

a 查询示例 python

通过自动化 Webhook 实现实时事件流

步骤

配置

a 查询示例 config

我们重视您的隐私

准备好开始了吗？

立即开始优化您的 Jira 软件开发生命周期！