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

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

Jira Software

← 返回改进指南

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

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

该模板为收集软件开发生命周期分析所需的关键数据提供清晰路线图，列出需要收集的核心数据字段、需要跟踪的关键流程步骤，以及从Jira Software提取这些信息的实用指导。使用本指南准备事件日志，以便开展有效的流程挖掘。

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

刚接触事件日志？了解如何创建流程挖掘事件日志.

下载模板

软件开发生命周期属性

以下是建议纳入事件日志的数据字段，用于全面分析软件开发生命周期。

5 必需 6 建议 10 可选

	名称	说明
	事件时间 EventTime	特定开发活动或事件发生的准确日期和时间。
说明事件时间是记录活动发生时刻的时间戳，是所有流程挖掘分析的时间基础，为每个案例提供事件的时间顺序。该属性对于计算所有基于时间的指标至关重要，包括周期时间、处理时间以及活动之间的等待时间。它支持按时间分析流程绩效，帮助识别开发生命周期中延迟发生的时间和位置。为什么重要该时间戳是正确排列事件顺序并计算所有基于持续时间的指标的基础，对于理解流程效率和识别延迟至关重要。获取位置这对应于问题变更日志或历史记录中每条记录的“created”时间戳。示例 2023-10-26T10:00:00Z2023-11-15T14:35:10Z2024-01-05T09:00:00Z
	开发项目 DevelopmentItem	Jira Software中单个工作单元（如用户故事、缺陷或任务）的唯一标识符。
说明开发项目是主要案例标识符，代表一个独立的工作单元，如功能、缺陷修复或任务。它关联该项目从构思和规划，到开发、测试及部署的全部活动。在Jira中，这通常对应问题键，例如“PROJ-123”。分析该属性可以追踪每个工作项目完整的端到端生命周期，是构建流程图、计算周期时间以及识别不同项目在开发流程中流转差异的基础。为什么重要这是关联所有相关开发活动的关键字段，使您能够追踪单个工作项目从开始到结束的完整历程。获取位置这是Jira Software Issue API对象中问题的标准“key”字段。示例 PROJ-101CORE-5432API-789
	活动 Activity	开发项目生命周期中发生的特定事件或状态变更的名称。
说明此属性表示软件开发流程中的一个独立步骤或里程碑。这些活动来自Jira问题状态字段的变化，或代码提交、代码评审等其他重要事件。在流程挖掘中，这些活动的顺序构成流程图。分析活动有助于识别流程、衡量具体阶段的持续时间，并发现偏离标准工作流的情况，例如返工循环或跳过质量关卡。为什么重要活动定义流程步骤，其顺序对于可视化流程、识别瓶颈和分析流程差异至关重要。获取位置通常源自Jira问题历史记录或变更日志中的“status”字段变更，也可以结合已连接开发工具中的数据进行丰富。示例开发已开始已完成代码评审QA测试已完成已部署到生产环境
	最后更新时间 LastDataUpdate	表示该流程数据最近一次从源系统刷新时间的时间戳。
说明该属性记录最近一次从Jira Software提取数据的日期和时间，帮助您了解当前分析数据的新鲜度。了解最后更新时间对于判断流程洞察的时效性非常重要。它有助于分析人员和业务用户确认所查看的是当前数据，并明确分析所包含事件的截止时间。为什么重要表示数据的新鲜度，对于确保分析结果和仪表板反映流程最新状态至关重要。获取位置该时间戳在数据提取、转换和加载（ETL）流程结束时生成并记录。示例 2024-03-15T02:00:00Z2024-03-16T02:00:00Z
	源系统 SourceSystem	提取开发生命周期数据的系统。
说明该属性标识数据来源。对于此流程，其值始终为“Jira Software”；如果在更大范围的分析中合并多个源系统，则该属性有助于区分不同来源的数据。在更广泛的IT环境中，明确源系统可以确保数据血缘清晰，并帮助管理不同平台之间的数据质量和集成工作。为什么重要提供清晰的数据来源信息，在整合多个系统的数据，或开展数据治理和审计时至关重要。获取位置这是一个静态值，应在数据提取和转换过程中添加。示例 Jira Software
	受派人 Assignee	当前负责处理开发项目的用户。
说明受派人是当前阶段负责该工作项目的人员。在Jira中，这是一个标准字段，项目在不同人员和团队之间流转时，该字段也会随之变化。分析受派人对于了解资源分配、工作负载分布和交接节点至关重要。它可以帮助回答以下问题：哪些开发人员或团队参与了特定阶段，谁构成了瓶颈，以及工作如何在组织内分配。为什么重要标识活动的负责用户或资源，支持工作负载分析、资源管理以及人员之间交接情况的了解。获取位置这是Jira Issue API响应中“fields”对象内的“assignee”字段。示例 Alice SmithBob Johnson未分配
	团队名称 TeamName	负责工作项的开发团队。
说明表示负责开发项的具体敏捷团队或功能团队。在Jira中，这通常通过自定义字段实现，也可以根据项目或特定组件等其他信息推导得出。该属性对于团队级绩效分析至关重要。您可以按团队筛选仪表板，查看各团队的周期时间、返工率和吞吐量等指标。这对于“阶段间交接效率”和“开发人员工作负载与工作项进度”仪表板尤为重要。为什么重要支持对不同开发团队进行绩效衡量和比较，帮助识别高绩效团队并推广最佳实践。获取位置这通常是Jira中的自定义字段。请咨询Jira管理员，确认具体字段名称，可能是“Team”“Squad”或类似名称。示例 Phoenix团队核心服务UI/UX复仇者联盟
	项目优先级 ItemPriority	分配给开发项目的优先级，用于表示其紧急程度。
说明项目优先级定义工作项目的相对重要性或紧急程度。Jira提供标准“priority”字段，并支持配置Highest、High、Medium和Low等级别。分析优先级对于检查流程遵循度和识别关键项目的瓶颈至关重要。例如，“Priority Item Conformance Check”仪表板依赖该属性，验证高优先级项目是否按预期加速处理，还是与低优先级项目一样滞留在队列中。为什么重要有助于分析高优先级项目是否比低优先级项目处理得更快，是否遵循更顺畅的路径，从而确保满足SLA。获取位置这是Jira Issue API响应中“fields”对象内的“priority”字段。示例最高高中低
	项目名称 ProjectName	开发项目所属的Jira项目名称。
说明在Jira中，所有工作项目都按项目组织。项目名称提供高层背景，通常对应特定产品、团队或计划。该属性是用于筛选和比较的重要维度。它支持跨不同项目或产品分析和对标软件开发生命周期流程，从而发现哪些项目效率更高、哪些项目返工更多，以及不同团队是否遵循不同的流程变体。为什么重要支持按项目、产品或团队细分流程分析，以比较绩效并识别最佳实践。获取位置这是Jira Issue API响应中“fields”对象内的“project”字段。示例移动应用开发核心平台数据科学
	项目状态 ItemStatus	开发项目在工作流中的当前状态。
说明该属性反映开发项目在特定时间点所处的阶段，例如“In Progress”、“In Review”或“Done”。状态随时间发生的变化会生成流程挖掘所需的活动。 “Activity”属性表示状态变更事件，而“ItemStatus”表示项目状态。它可作为筛选和分析维度，帮助您查看当前处于特定状态的项目数量，或分析长期停留在某一状态的项目特征。为什么重要提供项目在生命周期中所处位置的快照，对于基于状态的分析和了解当前进行中工作的状态至关重要。获取位置这是Jira Issue API响应中“fields”对象内的“status”字段。示例 To DoIn ProgressIn ReviewDone
	项目类型 ItemType	开发项目的分类，例如Bug、Story、Task或Epic。
说明项目类型用于对所执行工作的性质进行分类。Jira使用标准“issuetype”字段区分不同类型的工作项目，而不同类型通常对应不同的工作流。该属性对于比较分析至关重要。您可以按特定工作类型筛选流程，例如比较“Bug”和“Story”的生命周期，从而发现某些工作类型是否更容易出现延迟、返工或偏离标准流程的情况。为什么重要支持按工作类型细分流程分析，比较缺陷与新功能等不同工作的处理方式及其流程差异。获取位置这是Jira Issue API响应中“fields”对象内的“issuetype”字段。示例用户故事缺陷任务史诗
	事件结束时间 EventEndTime	活动或状态完成时的时间戳。
说明该属性记录活动的完成时间，即某个案例中下一项活动的时间戳。 “EventTime”（StartTime）记录活动开始时间，EventEndTime记录活动结束时间。两者之差就是该活动的处理时间。这对于计算“平均阶段处理时间”KPI，以及构建分析活动持续时间的仪表板至关重要。为什么重要定义活动的结束点，使您能够计算流程各步骤的持续时间，这对瓶颈分析至关重要。获取位置这是一个派生属性。对于给定事件，其结束时间是同一案例中后续事件的开始时间。示例 2023-10-26T12:30:00Z2023-11-15T18:00:15Z2024-01-05T11:45:00Z
	交接等待时间 HandoffWaitTime	两个连续活动之间的空闲时间。
说明该指标计算一项活动完成到下一项活动开始之间的等待时间或排队时间，表示工作等待人员接手期间处于空闲状态的时长。这是“平均交接等待时间”KPI和“阶段间交接效率”仪表板的关键指标。较长的交接时间通常意味着团队之间存在协调问题、资源受限或沟通低效，例如开发团队与QA团队之间。减少这段空闲时间，是缩短整体周期时间的重要手段。为什么重要突出流程中的空闲时间或排队时间，揭示团队或个人之间交接的低效环节和协调问题。获取位置这是一个计算指标。对于同一案例，它等于某项活动的开始时间减去前一项活动的结束时间。示例 017280043200
	修复版本 FixVersion	开发项实际完成并发布所在的软件版本。
说明 Jira中的“Fix Version”表示包含该工作项已完成工作的发布版本，标志着开发工作的实际结果。该属性提供实际发布背景，可与“PlannedReleaseVersion”进行比较，以分析交付绩效。它还可用于汇总特定版本交付的所有工作项，集中查看已完成的内容。为什么重要确认某项工作包含在哪个发布版本中，为发布分析和已交付功能跟踪提供事实依据。获取位置对应Jira Issue API响应中的“fixVersions”字段。示例 v2.1.1热修复v3.0.0重大版本发布v2.2.0
	冲刺名称 SprintName	开发项所属敏捷冲刺的名称。
说明对于采用Scrum的团队，Sprint是一个有明确时间边界的周期，团队在此期间完成一组工作。该属性记录工作项所属冲刺的名称或标识符。按冲刺分析是敏捷流程挖掘的基础。它有助于评估各个冲刺的绩效、了解延期到下一冲刺的工作，并跟踪冲刺目标的完成进度。相比通用日期范围，它提供了更具体的时间背景。为什么重要为敏捷团队提供关键背景信息，使您能够按冲刺分析流程效率和吞吐量。获取位置此信息通常存储在由Jira Software（Agile）管理的“Sprint”自定义字段中，可通过Issue API访问。示例 PROJ Sprint 1Q4-2023 Sprint 311月PI Sprint 2
	总周期时间 CycleTime	开发项端到端的总持续时间。
说明周期时间衡量开发项从创建到最终解决的总耗时，例如部署到生产环境。它以案例为单位计算，即第一个事件与最后一个事件时间戳之差。这是衡量整体流程速度和效率的核心KPI。“平均端到端周期时间”KPI和“整体SDLC周期时间分析”仪表板都直接基于该计算结果。缩短周期时间通常是流程改进计划的重点目标。为什么重要衡量开发流程的端到端速度，为整体效率和交付速度提供关键绩效指标。获取位置这是案例级计算属性。对于给定的“DevelopmentItem”，它等于最后一个事件的时间戳减去第一个事件的时间戳。示例 12096002592000604800
	报告人 Reporter	最初创建或报告开发项目的用户。
说明报告人是在Jira中创建问题的人员，可能是开发人员、QA测试人员、产品经理，也可能是通过服务台集成提交问题的客户。分析报告人可以洞察工作来源。例如，您可以比较QA团队报告的缺陷与客户报告的缺陷是否具有不同的生命周期，也可以了解流程起点的沟通模式和信息流转。为什么重要标识工作项目的来源，可用于根据任务创建者或缺陷报告者分析相关模式。获取位置这是Jira Issue API响应中“fields”对象内的“reporter”字段。示例 Charles DarwinMarie CurieIsaac Newton
	是否返工 IsRework	用于标识活动是否属于返工循环的标志。
说明如果活动表示流程中的回退步骤，该布尔属性则为true，例如QA测试失败后返回“开发已开始”。该属性通过分析案例中的活动序列确定。识别返工是提升流程效率和质量的基础。该属性直接支持“返工活动率”KPI和“返工循环频率与路径”仪表板，可量化无效工作量，并定位导致返工的质量问题根因。为什么重要明确标记属于低效返工循环的活动，从而精确衡量和分析流程浪费及质量问题。获取位置这是一个计算属性。您需要先定义预期流程，然后标记所有偏离流程、回退到较早阶段的活动。示例 truefalse
	组件 Component	项目中的子部分或功能区域，工作项归属于其中。
说明 Jira使用组件将项目中的问题划分为更小、更易管理的部分。组件可以代表“用户身份验证”等功能区域、“后端API”等技术层，或“报表”等模块。按组件分析可以更细致地了解开发流程，帮助识别应用程序的哪些部分更容易产生缺陷、开发周期更长或返工更多，从而定位技术债务或复杂性较高的区域。为什么重要支持按产品的功能区域或技术区域细分流程，帮助定位导致延迟或质量问题的组件。获取位置这是Jira Issue API响应中“fields”对象内的标准“components”字段。示例用户界面数据库API网关身份验证
	计划发布版本 PlannedReleaseVersion	计划部署该工作项的目标软件版本或发布版本。
说明该属性通常对应Jira中的“Affects Version/s”字段，用于表示功能或修复计划发布的版本。它可作为工作完成的截止时间或目标。这是“按时发布交付率”KPI的关键属性。通过比较实际部署日期与该版本关联的计划发布日期，您可以衡量计划执行情况和发布流程的可预测性。为什么重要定义目标交付日期或发布版本，用于计算按时交付率并分析计划执行情况。获取位置对应Jira Issue API中的“versions”或“fixVersions”字段。用于规划的具体字段可能有所不同。示例版本2.12024年第一季度发布Phoenix项目上线
	项目解决结果 ItemResolution	开发项目关闭时的最终结果或原因。
说明 Resolution解释项目为何进入关闭状态。状态可能是“Closed”，而解决结果可能是“Done”、“Won't Do”、“Duplicate”或“Cannot Reproduce”，为工作结果提供重要背景。分析解决结果有助于区分成功完成的工作与被取消或拒绝的项目。这对于质量分析，以及了解有价值工作的真实吞吐量与最终被弃置项目所消耗的投入非常重要。为什么重要区分成功完成的项目与因其他原因关闭的项目，对于准确开展生产力和质量分析至关重要。获取位置这是Jira Issue API响应中“fields”对象内的“resolution”字段，通常仅在问题关闭时填充。示例 DoneWon't Do重复无法复现

必需建议可选

软件开发生命周期活动

以下是建议在事件日志中记录的关键流程步骤和里程碑，用于准确发现软件开发生命周期流程。

6 建议 8 可选

	活动	说明
	QA测试已完成	表示开发项目已通过全部质量保证检查，可以进入用户验收测试或发布等下一阶段。通常根据状态离开主要测试状态来推断。
为什么重要这标志着重要质量门禁完成。分析QA阶段的持续时间，有助于优化测试流程和资源分配。获取位置根据Jira问题变更日志推断，即“status”字段从“In QA”变更为“Ready for UAT”或“Ready for Release”等后续状态时的时间戳。采集状态从“In QA”变更为“Ready for UAT”的时间戳。事件类型 inferred
	QA测试已开始	该事件标志着开发项目正式进入质量保证测试阶段。通常根据Jira状态变更推断，例如问题转为“In QA”、“In Testing”或“Ready for Testing”。
为什么重要这是质量验证周期的关键起点。衡量从“Development Completed”到该节点的时间，可以发现开发团队与QA团队之间的交接延迟。获取位置根据Jira问题变更日志推断，即“status”字段变更为“In QA”等指定QA测试状态时的时间戳。采集状态变更为“In QA”或“In Testing”的时间戳。事件类型 inferred
	UAT已批准	表示用户验收测试顺利完成，相关方已批准发布。通常根据状态从“In UAT”变更为“Ready for Release”或“Done”等状态推断。
为什么重要该里程碑确认业务验收完成，并批准项目部署到生产环境，是确保交付成果符合用户预期的关键门禁。获取位置根据Jira问题变更日志推断，即“status”字段从“In UAT”变更为工作流中的下一状态，表示已获批准时的时间戳。采集状态从“In UAT”变更为“Ready for Release”的时间戳。事件类型 inferred
	已部署到生产环境	该事件标志着与开发项目相关的代码变更已在生产环境中上线。通常根据最终状态变更为“Done”或“Released”推断，也可以由集成的CI/CD工具明确记录。
为什么重要这是流程的主要成功终点，对于计算端到端总周期时间、衡量部署频率和吞吐量至关重要。获取位置可以根据Jira问题变更日志中状态变更为“Released”或“Done”来推断。为提高准确性，也可以记录Jenkins、Bamboo等CI/CD工具推送的部署事件，或使用Jira中的Deployments功能。采集状态变更为“Done”或“Released”的时间戳。事件类型 inferred
	开发已开始	表示开发人员开始积极处理开发项目的时刻。通常通过Jira工作流中的状态变更推断，例如问题状态变为“In Progress”。
为什么重要这是衡量实际开发时间的关键里程碑，有助于区分等待时间和增值工作，是识别瓶颈的重要指标。获取位置根据Jira问题变更日志推断，即“status”字段首次变更为“In Progress”、“In Development”或类似进行中状态时的时间戳。采集状态变更为“In Progress”的时间戳。事件类型 inferred
	开发项目已创建	这标志着生命周期的开始：新的开发项目，如用户故事、缺陷或任务，已正式记录到Jira中。系统会为每个问题明确记录创建时间戳。
为什么重要该活动是流程的明确起点，对于计算端到端周期时间和跟踪新增工作总量至关重要。获取位置这是每个Jira问题的基础事件。创建时间戳存储在问题记录的“created”字段中，可通过Jira API访问。采集 Jira Issue对象中的“created”时间戳字段。事件类型 explicit
	QA测试未通过	表示QA团队发现缺陷，开发项目被退回开发人员处返工。通常根据状态反向变更推断，例如从“In QA”退回“In Progress”或“To Do”。
为什么重要该活动对于识别返工循环至关重要。跟踪其发生频率有助于量化低质量带来的成本，并发现开发或需求方面的改进空间。获取位置根据Jira问题变更日志推断，即“status”字段从测试状态（如“In QA”）变更为较早的开发状态（如“In Progress”）时记录。采集状态从测试状态变更为开发状态的时间戳。事件类型 inferred
	UAT已开始	标志着用户验收测试开始，由业务相关方或最终用户验证新功能。通常根据Jira状态变更推断，例如转为“In UAT”或“User Acceptance Testing”。
为什么重要该活动跟踪发布前最终验证阶段的开始。分析其持续时间，有助于了解并减少因相关方可用性或反馈循环造成的延迟。获取位置根据Jira问题变更日志推断，即“status”字段更新为“In UAT”或类似指定状态时的时间戳。采集状态变更为“In UAT”的时间戳。事件类型 inferred
	已准备发布	表示开发项目已通过全部检查，并已纳入特定软件发布版本，等待部署。通常根据问题状态变更为“Ready for Release”，或“Fix Version”字段已填充来推断。
为什么重要该活动有助于跟踪发布准备情况，以及开发和测试全部完成后项目等待部署窗口的时间。获取位置通常根据Jira问题变更日志中状态变更为“Ready for Release”来推断。也可以根据“Fix Version/s”字段设置时的时间戳推断。采集状态变更为“Ready for Release”或“Fix Version”字段填充时的时间戳。事件类型 inferred
	已完成代码评审	表示同级评审人员或负责人已从质量、规范和功能等方面完成代码评审。该事件可根据状态变更推断，例如从“In Review”转为“Ready for QA”，也可以由集成的开发工具明确记录。
为什么重要这是关键质量门禁。分析其持续时间和返工等结果，有助于提升代码质量，减少流程后期发现的缺陷。获取位置通常根据Jira问题变更日志推断，即状态离开“Code Review”状态时记录。若集成Bitbucket或GitHub等代码仓库工具，也可以作为明确事件记录。采集状态从“In Review”变更为下一状态的时间戳。事件类型 inferred
	开发已完成	表示开发人员已完成编码，项目可以进入代码评审或测试等下一阶段。通常根据Jira状态变更推断，例如从“In Progress”转为“In Review”或“Ready for QA”。
为什么重要这标志着核心开发阶段结束，可用于分析编码时长，以及交接给质量保证团队的效率。获取位置根据Jira问题变更日志推断，记录“status”字段从开发进行中状态变更为“In Review”或“Ready for QA”等后续状态时的时间戳。采集状态从“In Progress”变更为“In Review”或“Ready for QA”的时间戳。事件类型 inferred
	开发项目已关闭	这是最终管理操作，确认该项目不再需要后续工作。通常根据状态变更为“Closed”以及“Resolution”字段已设置来推断。
为什么重要表示项目生命周期的绝对终点。将其与“Deployed to Production”进行比较，可以发现管理滞后或部署后的监控周期。获取位置根据Jira问题变更日志推断，即“status”字段变更为“Closed”且已设置解决结果时的时间戳。采集状态变更为“Closed”的时间戳。事件类型 inferred
	开发项目已取消	表示开发项目在完成前终止。通常根据状态变更为“Canceled”、“Rejected”或“Won't Do”等终止状态推断，并且通常会设置相应的解决结果。
为什么重要该活动跟踪未成功的流程结果。分析项目被取消的原因，可以发现规划、优先级排序或需求定义方面的问题。获取位置根据Jira问题变更日志推断，即问题“status”变更为“Canceled”或“Won't Do”且设置相应解决结果时的时间戳。采集状态变更为“Canceled”、“Rejected”或“Won't Do”的时间戳。事件类型 inferred
	项目已准备开发	表示开发项目已完成定义、评审和优先级排序，可以交由开发人员开始处理。通常可根据工作流中的状态变更推断，例如从“Backlog”转为“To Do”或“Ready for Dev”。
为什么重要跟踪该节点有助于衡量待办列表的准备程度，以及项目在开发开始前的等待时间，还能将规划和细化时间与实际开发时间区分开来。获取位置根据Jira问题变更日志推断。查找“status”字段变更为“Ready for Dev”、“To Do”或“Selected for Development”等值时的时间戳。采集状态变更为开发前准备状态的时间戳。事件类型 inferred

建议可选

提取指南

如何从Jira Software获取数据

步骤

登录您的Jira Software实例。
在主导航栏中选择Issues，然后点击Search for issues。这将打开Issue Navigator。
在搜索页面中，将默认的Basic搜索切换为高级搜索，以启用Jira Query Language（JQL）。
在JQL查询栏中输入提供的JQL查询。将项目键和日期范围的占位值替换为符合您具体要求的值。
点击搜索图标或按Enter执行查询。系统将显示符合条件的所有开发项。
在搜索结果页面右上角，点击Export图标（可能显示为共享图标或明确标注为该名称），然后选择XML选项。不要使用CSV，因为XML格式包含创建事件日志所需的完整结构化变更历史。
将下载的XML文件保存到本地计算机。该文件每个Jira问题包含一条记录，其中嵌套了所有历史变更。
重要转换步骤：导出的XML文件不是扁平事件日志。您必须使用外部脚本或ETL工具解析该文件。脚本需要遍历XML中的每个<item>标签（代表一个Jira问题）。
对于每个问题，脚本首先使用created字段的时间戳，为Development Item Created活动生成一行记录。
接下来，脚本必须解析每个问题中的<changelog>数据。对于代表状态转换的每个<changeitem>，在输出文件中生成一行新记录。将Jira状态转换（例如从'In Progress'到'In Review'）映射到相应业务活动（例如'Development Completed'），并将转换时间戳用作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导出不一定包含重建活动序列所需的结构化变更日志数据。
用户权限：执行导出的用户必须拥有JQL查询中指定Jira项目的“Browse Projects”权限。

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数据库的网络条件。此方法仅适用于自托管Jira安装。
**使用SQL客户端连接：**使用DBeaver、SQL Server Management Studio或pgAdmin等数据库客户端工具，凭提供的凭据连接Jira数据库。
**识别工作流状态：**运行查询前，进入Jira项目的工作流设置（Project settings > Workflows）。仔细记录与待跟踪活动对应的状态准确名称，例如“Backlog”“In Progress”“In Review”和“Done”。
**自定义SQL查询：**将提供的SQL查询复制到客户端中。必须自定义占位值。特别注意每个UNION ALL代码块中WHERE子句的状态名称，这些名称必须与项目工作流完全一致。
**设置查询参数：**修改日期范围筛选条件（WHERE ji.created >= '2023-01-01'），定义要分析的周期。强烈建议按一个或多个具体项目进行筛选，取消注释并设置项目键筛选条件（--AND p.pkey IN ('PROJ1', 'PROJ2')）。
**配置自定义字段：**确定Jira实例中“Team Name”对应的自定义字段ID。您可以进入Jira的Custom Fields管理页面查找。将查询中的占位值'customfield_10100'替换为实际ID。
**执行查询：**在Jira数据库上运行修改后的SQL查询。
**检查输出：**简要检查返回的数据，确认其中包含各类活动的记录，并且各列已按预期填充。
**导出事件日志：**从SQL客户端将完整结果集导出为CSV文件，并确保文件编码为UTF-8。
**准备上传：**确认导出CSV文件的列头与必需属性名称一致：DevelopmentItem、Activity、EventTime、SourceSystem、LastDataUpdate、Assignee、ItemType、ItemPriority、ItemStatus、ProjectName和TeamName。

配置

数据库凭据：需要使用Jira数据库的只读用户账户，以防止意外修改数据。
工作流状态名称：查询的核心依赖状态名称筛选（例如“In Progress”“Done”）。这些名称因Jira工作流和项目而异。您必须将查询中的占位值替换为配置中的准确名称。
日期范围：查询包含WHERE ji.created >= '[YYYY-MM-DD]'子句，用于限制处理的数据量。首次分析建议使用3至6个月的范围，以确保数据量可控并加快查询执行。
项目筛选：为聚焦分析，强烈建议使用p.pkey IN ('[YourProjectKey]')条件筛选具体项目键。在大型Jira实例中查询所有项目可能非常缓慢。
团队自定义字段：“Team Name”被视为自定义字段。提供的查询使用占位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。运行命令pip install requests pandas，安装用于API调用的requests和用于数据处理的pandas库。
**生成Jira API令牌：**登录Jira实例。进入用户个人资料设置，然后打开Security并选择“Create and manage API tokens”。创建新令牌并妥善复制保存。脚本身份验证将使用此令牌代替密码。
**配置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查询匹配的全部问题。
**处理问题changelog：**对于每个问题，脚本会提取其完整历史，识别创建事件，然后遍历所有状态变更，根据STATUS_MAPPING为每个相关转换在事件日志中创建新行。
**生成事件日志文件：**处理完所有问题后，脚本会将事件汇总到pandas DataFrame中，添加SourceSystem和LastDataUpdate等必需元数据列，并将最终事件日志保存为同一目录下名为jira_event_log.csv的CSV文件。

配置

JIRA_URL：Jira实例的基础URL，例如https://your-company.atlassian.net。
JIRA_EMAIL：用于身份验证的用户账户电子邮件地址。
JIRA_API_TOKEN：从Jira用户安全设置中生成、用于脚本身份验证的API令牌。
JQL_QUERY：用于筛选要提取的问题的Jira Query Language字符串。强烈建议按日期范围筛选，例如最近6至12个月，以控制数据量。同时应按项目和相关问题类型（例如Story、Bug、Task）筛选，确保分析正确的流程。
STATUS_MAPPING：将具体Jira工作流状态名称映射到所需通用活动名称的Python字典。这是确保流程模型准确性的最重要配置，您必须根据项目工作流进行自定义。
前置条件：脚本要求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 Automation、出站webhook和HTTPS接收端可用于Jira项目。接收端必须接受POST请求，并保留完整JSON载荷，包括事件元数据和问题字段。
创建规则前定义事件契约。使用Development Item作为案例标识符，Activity作为活动名称，EventTime作为事件时间戳，SourceSystem作为Jira Software，LastDataUpdate作为摄取或刷新时间戳。配置接收端，保留Jira问题键作为DevelopmentItem。
创建带有问题事件触发器的Jira Automation规则。为问题创建、工作流状态转换、解决方案变更、Fix Version变更（如适用），以及Jira配置中可用的集成部署或审核事件配置规则。Jira没有统一适用的工作流，因此请将本地状态名称和转换条件映射到所需活动。
配置每条规则，向[Your webhook endpoint]发送webhook。使用POST和JSON格式。包含问题键、问题类型、经办人、优先级、状态、项目、团队字段（如可用）、事件时间戳、转换信息、解决方案、Fix Version值和Jira事件标识符。不要依赖ProcessMind根据状态历史推断活动。
在webhook接收端或数据摄取层创建明确的活动映射。每个符合条件的webhook都必须转换为一行事件日志。将问题创建映射为Development Item Created，将就绪转换映射为Item Ready for Development，将In Progress转换映射为Development Started，将审核或开发完成转换映射为Development Completed，将审核转换或集成审核事件映射为Code Review Performed，将测试转换映射为QA Testing Started，将回退的QA转换映射为QA Testing Failed，将成功测试转换映射为QA Testing Completed，将UAT转换映射为UAT Started和UAT Approved，将发布准备映射为Prepared For Release，将生产部署或已配置的发布完成映射为Deployed To Production，将关闭映射为Development Item Closed，将取消或拒绝映射为Development Item Canceled。
根据流程负责人批准的Jira工作流和事件配置应用映射。例如，仅当Backlog、To Do、Ready for Dev、In Progress、In Review、Ready for QA、In QA、In Testing、In UAT、Ready for Release、Done、Released、Closed、Canceled、Rejected或Won't Do等本地状态具有预期业务含义时，才进行相应映射。除非载荷明确代表多个符合条件的事件，否则不要为一个webhook创建多行。
将每个事件标准化为必需架构。DevelopmentItem必须包含Jira问题键，Activity必须准确包含14个必需活动名称之一，EventTime必须包含事件发生时间戳，SourceSystem必须为Jira Software，LastDataUpdate必须为数据摄取刷新时间戳。在存在时填充建议属性，包括Assignee、ItemType、ItemPriority、ItemStatus、ProjectName和TeamName。
使用Jira事件标识符、问题键、事件时间戳、转换标识符和活动映射对webhook交付去重。webhook交付可能会重试，因此接收端必须具备幂等性。保留原始事件时间戳，不要将其替换为数据摄取时间戳。
通过检查架构、时间戳、案例标识符、活动名称、重复处理和配置日期范围内的覆盖情况，验证生成的事件日志。确认14个活动值都可以作为记录出现，并且无需由ProcessMind在后续推断任何活动。
将标准化事件日志导出为CSV或其他ProcessMind支持的事件日志格式。每个明确事件占一行，并包含DevelopmentItem、Activity、EventTime、SourceSystem、LastDataUpdate、Assignee、ItemType、ItemPriority、ItemStatus、ProjectName和TeamName列。根据ProcessMind摄取配置上传文件，或连接接收端输出。

配置

**方法和查询语言：**配置Jira Automation规则和HTTPS webhook接收端。query值为config，因为提取过程由规则配置和事件规范化驱动，而不是由Jira数据库查询驱动。
**案例标识符：**使用Jira问题键作为DevelopmentItem。不要将多个问题合并为一个案例。
**必需活动：**为Development Item Created、Item Ready for Development、Development Started、Development Completed、Code Review Performed、QA Testing Started、QA Testing Failed、QA Testing Completed、UAT Started、UAT Approved、Prepared For Release、Deployed To Production、Development Item Closed和Development Item Canceled配置明确映射。
**事件触发器：**仅在Jira配置支持且具有实际意义时，启用问题创建、工作流转换、解决方案、Fix Version、评审集成和部署集成触发器。
**状态映射：**为本地Jira状态和转换维护项目专属映射表或配置。In Progress、In QA、Done或Closed等状态名称必须根据批准的工作流语义进行解释。
**日期范围：**初始验证时收集3至6个月的事件。对于持续流式处理，请在目标观察期开始前启动接收端，并为中断期间生成的事件保留重放或回填策略。
**筛选条件：**按目标Jira项目、问题类型、工作流范围和事件日期范围进行筛选。Company Code和Document Type不是Jira Software的标准概念，因此请改用项目、问题类型及其他已配置的Jira字段。
**负载字段：**包括问题键、问题类型、经办人、优先级、状态、项目、可用时的团队字段、事件时间戳、转换详情、解决方案、Fix Version和事件标识符。
**时间戳处理：**数据可用时，使用带时区信息的时间戳。EventTime使用源事件时间戳，LastDataUpdate使用接收端刷新时间戳。
**投递与安全：**使用HTTPS、接收端支持的身份验证、请求校验、重试处理和幂等处理。不要将凭据直接写入事件日志记录。
**性能：**使用异步摄取，在支持的情况下接收后进行批处理，使用已建立索引的去重键，并按事件日期分区处理大数据量。避免在运行接收端无限期保留webhook负载。
**前提条件：**Jira Automation权限、配置项目规则的权限、查看相关问题和字段的权限、可访问的HTTPS端点，以及出站webhook和部署事件所需的Jira套餐或集成功能。
**数据质量：**明确已删除问题、重命名状态、缺少经办人、缺少团队字段、时区转换、重复投递和乱序接收事件的处理方式。

a 示例查询 config

{
  "method": "Real-time Event Streaming via Automation Webhooks",
  "approach": "Jira Automation rules send issue event JSON payloads to a configured HTTPS endpoint. The receiver normalizes each qualifying payload into one explicit event-log row.",
  "queryLanguage": "config",
  "confidence": "verified",
  "caseIdentifier": "DevelopmentItem",
  "sourceSystem": "Jira Software",
  "endpoint": "[Your webhook endpoint]",
  "dateFrom": "[Start date and time]",
  "dateTo": "[End date and time]",
  "filters": {
    "projects": "[Configure based on your Jira projects]",
    "issueTypes": "[Configure based on your Jira issue types]"
  },
  "outputColumns": [
    "DevelopmentItem",
    "Activity",
    "EventTime",
    "SourceSystem",
    "LastDataUpdate",
    "Assignee",
    "ItemType",
    "ItemPriority",
    "ItemStatus",
    "ProjectName",
    "TeamName"
  ],
  "activityMappings": [
    {
      "activity": "Development Item Created",
      "trigger": "Issue created",
      "condition": "The Jira issue creation event is received within the configured scope"
    },
    {
      "activity": "Item Ready for Development",
      "trigger": "Workflow transition",
      "condition": "The issue transitions from a configured backlog or specification status to a configured ready-for-development status"
    },
    {
      "activity": "Development Started",
      "trigger": "Workflow transition",
      "condition": "The issue transitions to the configured active development status, commonly In Progress"
    },
    {
      "activity": "Development Completed",
      "trigger": "Workflow transition",
      "condition": "The issue transitions from active development to a configured development-complete, review, or QA-ready status"
    },
    {
      "activity": "Code Review Performed",
      "trigger": "Workflow transition or configured review integration event",
      "condition": "A qualifying code review completion event is received, such as a transition from review to QA-ready"
    },
    {
      "activity": "QA Testing Started",
      "trigger": "Workflow transition",
      "condition": "The issue transitions to a configured QA or testing status"
    },
    {
      "activity": "QA Testing Failed",
      "trigger": "Workflow transition",
      "condition": "The issue transitions backward from a configured QA or testing status to a development or rework status"
    },
    {
      "activity": "QA Testing Completed",
      "trigger": "Workflow transition",
      "condition": "The issue leaves the configured primary QA or testing status through a successful testing transition"
    },
    {
      "activity": "UAT Started",
      "trigger": "Workflow transition",
      "condition": "The issue transitions to a configured UAT or user acceptance testing status"
    },
    {
      "activity": "UAT Approved",
      "trigger": "Workflow transition",
      "condition": "The issue transitions from UAT to a configured approval, release-ready, or completed status"
    },
    {
      "activity": "Prepared For Release",
      "trigger": "Workflow transition or Fix Version field change",
      "condition": "The issue reaches a configured release-ready status or receives a qualifying Fix Version value"
    },
    {
      "activity": "Deployed To Production",
      "trigger": "Configured deployment event or workflow transition",
      "condition": "A production deployment event is received, or the configured final release transition represents production deployment"
    },
    {
      "activity": "Development Item Closed",
      "trigger": "Workflow transition or resolution change",
      "condition": "The issue reaches the configured Closed status and, where required, has a qualifying Resolution value"
    },
    {
      "activity": "Development Item Canceled",
      "trigger": "Workflow transition or resolution change",
      "condition": "The issue reaches a configured canceled, rejected, or won't-do terminal state and, where required, has a qualifying Resolution value"
    }
  ],
  "normalization": {
    "oneRowPerEvent": true,
    "developmentItem": "payload.issue.key",
    "eventTime": "payload.event.timestamp or the source timestamp supplied by the Jira event",
    "sourceSystem": "Jira Software",
    "lastDataUpdate": "receiver ingestion timestamp",
    "assignee": "payload.issue.fields.assignee.displayName or account identifier when available",
    "itemType": "payload.issue.fields.issuetype.name",
    "itemPriority": "payload.issue.fields.priority.name",
    "itemStatus": "payload.issue.fields.status.name",
    "projectName": "payload.issue.fields.project.name",
    "teamName": "payload.issue.fields.team or the configured team field when available"
  },
  "deduplication": {
    "key": "payload.event.id, payload.issue.key, payload.event.timestamp, payload.transition.id, mapped activity",
    "behavior": "Ignore repeated deliveries with the same deduplication key while retaining the first valid event row"
  },
  "requiredConfiguration": [
    "Configure one or more Jira Automation rules for each qualifying event type",
    "Configure the webhook receiver at [Your webhook endpoint]",
    "Configure local Jira status and transition mappings",
    "Configure project and issue-type filters at [Configure based on your Jira projects] and [Configure based on your Jira issue types]",
    "Configure authentication and request validation according to the receiver implementation"
  ]
}

准备好开始了吗？

立即使用此模板准备数据，开始优化软件开发生命周期。获取相关洞察，加快交付并提升质量。

返回改进指南下载模板

立即在Jira Software中优化您的SDLC！

精准定位SDLC中的低效环节，将周期时间缩短30%。

开始免费试用

无需信用卡，几分钟内即可开始优化。

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

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

软件开发生命周期属性

软件开发生命周期活动

提取指南

通过内置CSV或XML导出的Jira JQL查询

步骤

配置

a 示例查询 config

通过SQL直接查询Jira数据库（自托管）

步骤

配置

a 示例查询 sql

使用官方Jira REST API的Python脚本

步骤

配置

a 示例查询 python

通过自动化Webhook实时流式传输事件

步骤

配置

a 示例查询 config

准备好开始了吗？

立即在Jira Software中优化您的SDLC！

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

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

软件开发生命周期属性

软件开发生命周期活动

提取指南

通过内置CSV或XML导出的Jira JQL查询

步骤

配置

a 示例查询 config

通过SQL直接查询Jira数据库（自托管）

步骤

配置

a 示例查询 sql

使用官方Jira REST API的Python脚本

步骤

配置

a 示例查询 python

通过自动化Webhook实时流式传输事件

步骤

配置

a 示例查询 config

准备好开始了吗？

立即在Jira Software中优化您的SDLC！

我们重视您的隐私