> 持续流程改进 > 软件开发生命周期 > 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
	事项优先级 ItemPriority	分配给开发事项的优先级，用于表示其紧急程度。
说明事项优先级用于确定工作事项的相对重要性或紧急程度。Jira提供标准的“priority”字段，并支持配置“最高”“高”“中”和“低”等级别。分析优先级对于开展一致性检查和识别高优先级事项的瓶颈至关重要。例如，“高优先级事项一致性检查”仪表板会使用此属性，检查高优先级事项是否按预期优先处理，或是否与低优先级事项一样滞留在队列中。重要性有助于分析高优先级事项是否比低优先级事项处理得更快、路径是否更顺畅，并确认是否满足SLA。获取途径这是Jira Issue API响应中“fields”对象内的“priority”字段。示例最高高中低
	事项状态 ItemStatus	开发事项在工作流中的当前状态。
说明此属性反映开发事项在特定时间所处的阶段，例如“进行中”“评审中”或“已完成”。状态随时间发生的变化会生成流程挖掘所需的活动。 “活动”属性表示状态变更事件，“ItemStatus”则表示事项当前所处的状态。此属性可用于筛选和分析，例如查看当前处于特定状态的事项数量，或分析长期停留在某一状态的事项特征。重要性显示事项在生命周期中的当前阶段，是开展状态分析和了解在制工作的当前状态的重要依据。获取途径这是Jira Issue API响应中“fields”对象内的“status”字段。示例待办进行中评审中已完成
	事项类型 ItemType	开发事项的分类，例如缺陷、用户故事、Task或Epic。
说明事项类型用于对所执行工作的性质进行分类。Jira使用标准的“issuetype”字段区分不同类型的工作事项，这些事项通常采用不同的工作流。此属性对于对比分析至关重要。您可以筛选特定类型的工作，例如比较“Bug”和“Story”的生命周期，从而发现某些工作类型是否更容易出现延迟、返工或偏离标准流程的情况。重要性可按工作类型细分流程分析，比较缺陷与新功能等不同工作的处理方式，并找出流程差异。获取途径这是Jira Issue API响应中“fields”对象内的“issuetype”字段。示例用户故事缺陷TaskEpic
	团队名称 TeamName	负责该工作事项的开发团队。
说明表示负责开发事项的特定敏捷团队或功能团队。在Jira中，这通常通过自定义字段实现，也可以根据项目或特定组件等信息推导得出。此属性对于团队层面的绩效分析至关重要。您可以按团队筛选仪表板，查看周期时间、返工率和吞吐量等指标。这对于“阶段间交接效率”和“开发人员工作量与事项进度”仪表板尤为重要。重要性可衡量并比较不同开发团队的绩效，帮助识别表现出色的团队并分享最佳实践。获取途径这通常是Jira中的自定义字段。请咨询Jira管理员，确认具体字段名称，可能为“Team”“Squad”或类似名称。示例凤凰团队核心服务UI/UX复仇者联盟
	经办人 Assignee	当前负责处理开发事项的用户。
说明经办人是当前阶段负责处理工作事项的人员。在Jira中，这是一个标准字段，事项在不同人员和团队之间流转时，该字段也会随之变化。分析经办人有助于了解资源分配、工作量分布和交接环节。您可以据此了解哪些开发人员或团队参与了特定阶段、谁造成了瓶颈，以及工作如何在组织内分配。重要性标识活动的负责人或资源，以便分析工作量、管理资源并了解人员间的交接情况。获取途径这是Jira Issue API响应中“fields”对象内的“assignee”字段。示例 Alice SmithBob Johnson未分配
	项目名称 ProjectName	开发事项所属Jira项目的名称。
说明在Jira中，所有工作事项都按项目组织。项目名称提供较高层级的背景信息，通常对应特定产品、团队或计划。此属性是用于筛选和对比的重要维度。您可以据此分析并对标不同项目或产品的SDLC流程，了解哪些项目效率更高、返工更多，以及不同团队是否采用了不同的流程变体。重要性可按项目、产品或团队细分流程分析，以便比较绩效并发现最佳实践。获取途径这是Jira Issue API响应中“fields”对象内的“project”字段。示例移动应用开发核心平台数据科学
	事件结束时间 EventEndTime	活动或状态完成时的时间戳。
说明此属性标记活动的完成时间，即特定案例中顺序流上下一项活动的时间戳。 “EventTime”（StartTime）标记活动开始时间，EventEndTime则标记结束时间。两个时间戳之差即为该活动的处理时间。这对于计算“平均阶段处理时间”KPI，以及构建分析活动时长的仪表板至关重要。重要性定义活动的结束时间，以便计算流程中每个步骤的持续时间，这对于瓶颈分析至关重要。获取途径这是一个派生属性。对于给定事件，其结束时间是同一案例中后续事件的开始时间。示例 2023-10-26T12:30:00Z2023-11-15T18:00:15Z2024-01-05T11:45:00Z
	事项解决结果 ItemResolution	开发事项关闭时的最终结果或原因。
说明解决结果说明事项为何进入关闭状态。状态可能是“Closed”，而解决结果可能是“Done”“Won't Do”“Duplicate”或“Cannot Reproduce”，为工作结果提供重要背景。分析解决结果有助于区分已成功完成的工作与已取消或拒绝的事项。这对于质量分析，以及了解有价值工作的实际吞吐量与最终被放弃事项所耗费的工作量至关重要。重要性区分已成功完成的事项与因其他原因关闭的事项，是准确开展生产力和质量分析的重要依据。获取途径这是Jira Issue API响应中“fields”对象内的“resolution”字段，通常仅在问题关闭时填写。示例已完成不予处理重复无法复现
	交接等待时间 HandoffWaitTime	两个连续活动之间的空闲时间。
说明此指标计算一个活动完成到下一个活动开始之间的等待或排队时间，反映工作等待他人接手期间的闲置时长。这是“平均交接等待时间”KPI和“阶段间交接效率”仪表板的重要指标。交接耗时过长通常意味着协调不畅、资源受限，或团队间沟通效率低下，例如开发团队与QA团队之间的沟通问题。减少这段闲置时间是缩短整体周期时间的重要手段。重要性突出显示流程中的闲置或排队时间，揭示团队或个人之间交接的低效之处及协调问题。获取途径这是一个计算指标，值为同一案例中某项活动的开始时间减去前一项活动的结束时间。示例 017280043200
	修复版本 FixVersion	开发事项实际完成并发布的软件版本。
说明 Jira中的“Fix Version”表示包含某事项已完成工作的发布版本，标记了开发工作的实际交付结果。此属性提供实际发布版本信息，可与“PlannedReleaseVersion”进行比较，以分析交付绩效。它还可用于汇总特定版本交付的所有事项，集中查看已完成的工作。重要性确认某项工作纳入了哪个发布版本，为发布分析和已交付功能跟踪提供实际依据。获取途径对应Jira Issue API响应中的“fixVersions”字段。示例 v2.1.1紧急修复v3.0.0主要版本v2.2.0
	冲刺名称 SprintName	开发事项所属敏捷冲刺的名称。
说明对于采用Scrum的团队，冲刺是一个有固定时限的周期，团队会在此期间完成一组工作。此属性记录事项所属冲刺的名称或标识。按冲刺分析是面向敏捷团队开展流程挖掘的基础。它有助于评估各次冲刺的绩效、了解结转工作，并跟踪冲刺目标的完成进度。与一般日期范围相比，它提供了更具体的时间背景。重要性为敏捷团队提供重要背景信息，支持按冲刺分析流程效率和吞吐量。获取途径此信息通常存储在由Jira Software（Agile）管理的“Sprint”自定义字段中，可通过Issue API访问。示例 PROJ冲刺12023年第四季度冲刺311月PI冲刺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年第一季度发布凤凰项目上线

必填建议填写选填

软件开发生命周期活动

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

6 建议填写 8 选填

	活动	说明
	QA测试完成	表示开发事项已通过所有质量保证检查，可以进入下一阶段，例如用户验收测试或发布。可根据事项离开主要测试状态时的状态变更推断。
重要性这标志着一个重要质量关卡的完成。分析QA阶段的耗时有助于优化测试流程和资源分配。获取途径根据Jira事项变更日志推断，即“status”字段从“QA中”变为“准备UAT”或“准备发布”等后续状态时的时间戳。采集状态从“QA中”变更为“准备UAT”时的时间戳。事件类型 inferred
	QA测试开始	此事件标志着开发事项正式进入质量保证测试阶段。可根据Jira状态变更推断，例如事项状态变为“QA中”“测试中”或“准备测试”。
重要性这是质量验证周期的关键里程碑。衡量从“开发完成”到此时的耗时，有助于发现开发团队与QA团队之间的交接延迟。获取途径根据Jira事项变更日志推断，即“status”字段变为“QA中”等指定QA测试状态时的时间戳。采集状态变更为“QA中”或“测试中”时的时间戳。事件类型 inferred
	UAT已批准	表示用户验收测试已成功完成，相关方已批准发布。可根据状态从“UAT中”变更为“准备发布”或“已完成”等状态推断。
重要性此里程碑表示业务方已验收，并批准该事项部署到生产环境。这是确保交付成果符合用户预期的关键关卡。获取途径根据Jira问题变更日志推断。该时间戳记录状态从“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。系统会为每个事项记录创建时间戳。
重要性此活动是流程的明确起点，对于计算端到端周期时间和跟踪待处理工作总量至关重要。获取途径这是每个Jira事项的基础事件。创建时间戳存储在事项记录的“created”字段中，可通过Jira API访问。采集 Jira事项对象中的“created”时间戳字段。事件类型 explicit
	开发开始	表示开发人员开始实际处理开发事项的时刻。通常可根据Jira工作流中的状态变更推断，例如事项状态变为“进行中”。
重要性这是衡量实际开发时间的重要里程碑，有助于区分等待时间和创造价值的工作，是识别瓶颈的关键指标。获取途径根据Jira事项变更日志推断，即“status”字段首次变为“进行中”“开发中”或类似活动状态时的时间戳。采集状态变更为“进行中”时的时间戳。事件类型 inferred
	QA测试未通过	表示QA团队发现缺陷，开发事项因此退回开发人员返工。可根据状态向前序阶段回退推断，例如从“QA中”退回“进行中”或“待处理”。
重要性此活动对于识别返工循环至关重要。跟踪其发生频率有助于量化质量不佳带来的成本，并指出开发或需求方面的改进空间。获取途径根据Jira事项变更日志推断。当“status”字段从测试状态（例如“QA中”）变更为较早的开发状态（例如“进行中”）时记录。采集状态从测试状态变更为开发状态时的时间戳。事件类型 inferred
	UAT开始	标志着用户验收测试开始，由业务相关方或最终用户验证新功能。可根据Jira状态变更推断，例如状态变为“UAT中”或“用户验收测试”。
重要性此活动用于跟踪发布前最终验证阶段的开始时间。分析其耗时有助于了解并减少因相关方时间安排或反馈周期造成的延迟。获取途径根据Jira事项变更日志推断，即“status”字段更新为“UAT中”或类似指定状态时的时间戳。采集状态变更为“UAT中”时的时间戳。事件类型 inferred
	事项已准备就绪，可开始开发	表示开发事项已完成详细说明、评审和优先级排序，可以交由开发人员开始处理。通常可根据工作流中的状态变更推断，例如从“待办事项”变为“待处理”或“准备开发”。
重要性跟踪此活动有助于衡量待办事项的准备情况，以及事项在开发开始前的等待时间。这样可以将规划和细化耗时与实际开发耗时区分开来。获取途径根据Jira事项变更日志推断。查找“status”字段变更为“准备开发”“待处理”或“已选定开发”等值时的时间戳。采集状态变更为开发前准备就绪状态时的时间戳。事件类型 inferred
	代码审查已完成	表示同事或负责人已对代码质量、规范和功能进行审查。可根据状态变更推断，例如从“审查中”变为“准备QA”，也可通过集成的开发工具明确记录。
重要性此活动是关键质量关卡。分析其耗时和结果（例如是否返工），有助于提高代码质量并减少流程后期发现的缺陷。获取途径通常根据Jira事项变更日志推断，即状态离开“代码审查”状态时。若集成Bitbucket或GitHub等代码仓库工具，也可以将其作为明确事件记录。采集状态从“审查中”变更为下一状态时的时间戳。事件类型 inferred
	已准备发布	表示开发事项已通过所有检查，并已纳入特定的软件发布版本，等待部署。通常可根据问题状态变为“Ready for Release”或“Fix Version”字段已填写来推断。
重要性此活动用于跟踪发布准备情况，以及开发和测试全部完成后，事项等待部署窗口的时长。获取途径通常根据Jira问题变更日志中状态变为“Ready for Release”的记录推断。也可以根据“Fix Version/s”字段的设置时间戳推断。采集状态变为“Ready for Release”或填写“Fix Version”时的时间戳。事件类型 inferred
	开发事项已关闭	这是最后一项管理操作，确认该事项无需继续处理。通常可根据状态变为“Closed”且“Resolution”字段已设置来推断。
重要性表示某事项整个处理过程的最终结束时间。将其与“已部署到生产环境”进行比较，可以发现管理流程延迟或部署后的监控时段。获取途径根据Jira问题变更日志推断。该时间戳记录“status”字段变为“Closed”且已设置解决结果的时间。采集状态变为“Closed”时的时间戳。事件类型 inferred
	开发事项已取消	表示开发事项在完成前终止。可根据状态变为“Canceled”“Rejected”或“Won't Do”等终止状态推断，通常还会设置相应的解决结果。
重要性此活动用于跟踪未成功完成的流程结果。分析事项取消的原因，有助于发现规划、优先级安排或需求定义方面的问题。获取途径根据Jira问题变更日志推断。该时间戳记录问题“status”变为“Canceled”或“Won't Do”且已设置相应解决结果的时间。采集状态变为“Canceled”“Rejected”或“Won't Do”时的时间戳。事件类型 inferred
	开发完成	表示开发人员已完成编码，事项可以进入下一阶段，例如代码审查或测试。可根据Jira状态变更推断，例如从“进行中”变为“审查中”或“准备QA”。
重要性这标志着核心开发阶段结束，可用于分析编码耗时，以及向质量保证团队交接的效率。获取途径根据Jira事项变更日志推断，记录“status”字段从开发活动状态变为“审查中”或“准备QA”等后续状态时的时间戳。采集状态从“进行中”变更为“审查中”或“准备QA”时的时间戳。事件类型 inferred

建议填写选填

数据提取指南

如何从Jira Software获取数据

步骤

登录您的Jira Software实例。
在主导航栏中选择问题，然后点击搜索问题。系统将打开问题导航器。
在搜索页面，将默认的基本搜索切换为高级搜索，以启用Jira查询语言（JQL）。
在JQL查询栏中输入提供的JQL查询，并根据您的具体需求替换项目键和日期范围的占位值。
点击搜索图标或按Enter执行查询。系统将显示所有符合条件的开发事项。
在搜索结果页面右上角，点击导出图标（可能显示为分享图标，也可能直接标注“导出”），然后选择XML。请勿使用CSV，因为只有XML格式包含创建事件日志所需的完整结构化变更历史。
将下载的XML文件保存到本地。该文件为每个Jira问题包含一条记录，并在记录中嵌套所有历史变更。
重要转换步骤：导出的XML文件不是扁平的事件日志。您必须使用外部脚本或ETL工具解析该文件。脚本需要遍历XML中的每个<item>标签（代表一个Jira问题）。
对于每个问题，脚本必须先使用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导出无法可靠地包含重建活动顺序所需的结构化变更历史数据。
用户权限：执行导出的用户必须拥有JQL查询中指定Jira项目的“浏览项目”权限。

查询示例 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项目的工作流设置（项目设置>工作流）。仔细记录与需要跟踪的各项活动对应的状态准确名称，例如“待办”、“进行中”、“审核中”和“已完成”。
自定义SQL查询：将提供的SQL查询复制到客户端，并替换占位值。特别注意每个UNION ALL区块中WHERE子句的状态名称，确保与项目工作流完全一致。
设置查询参数：修改日期范围筛选条件（WHERE ji.created >= '2023-01-01'），以指定分析时段。也强烈建议筛选一个或多个特定项目：取消项目键筛选条件（--AND p.pkey IN ('PROJ1', 'PROJ2')）的注释并设置相应值。
配置自定义字段：找到Jira实例中“团队名称”自定义字段的ID。您可以在Jira的自定义字段管理页面中查看。将查询中的占位值'customfield_10100'替换为实际ID。
执行查询：对Jira数据库运行修改后的SQL查询。
检查输出：简要检查返回的数据，确认其中包含各类活动的记录，且各列均已按预期填充。
导出事件日志：从SQL客户端将完整结果集导出为CSV文件，并确保文件编码为UTF-8。
准备上传：确认导出CSV文件的列标题与所需属性名称一致：DevelopmentItem、活动、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实例中查询所有项目可能会非常缓慢。
团队自定义字段：“团队名称”假定为自定义字段。提供的查询使用占位ID（customfield_10100），必须将其更新为Jira实例配置中的正确ID。
性能：直接查询数据库可能占用大量资源。请在业务低峰时段执行数据提取，或优先查询生产数据库的只读副本，以免影响用户使用Jira。

查询示例 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实例，进入用户资料设置，然后依次选择“安全”和“创建并管理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、获取问题数据并处理变更历史。
处理API分页：脚本会自动分页，每批获取50个问题，并持续发起请求，直到检索完所有符合JQL查询的问题。
处理问题变更历史：脚本会检索每个问题的完整历史记录，识别创建事件，然后遍历所有状态变更，并根据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查询语言字符串。强烈建议按日期范围筛选，例如最近6至12个月，以控制数据量。还应按项目和相关问题类型（如Story、Bug、Task）筛选，确保分析的是正确流程。
STATUS_MAPPING：Python字典，用于将特定的Jira工作流状态名称映射到所需的通用活动名称。这是确保流程模型准确性的关键配置，必须根据项目工作流进行自定义。
准备工作：脚本需要一个拥有待提取项目和问题只读权限的Jira用户账户。该用户还必须拥有使用REST API的权限。

查询示例 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项目支持Jira Automation、出站Webhook和HTTPS接收端。接收端必须接受POST请求，并保留完整的JSON负载，包括事件元数据和问题字段。
创建规则前先定义事件契约。使用Development Item作为案例标识符，Activity作为活动名称，EventTime作为事件时间戳，SourceSystem设为Jira Software，LastDataUpdate设为数据接收或刷新时间戳。配置接收端，将Jira问题键保留为DevelopmentItem。
创建由问题事件触发的Jira Automation规则。针对问题创建、工作流状态转换、解决结果变更、适用时的Fix Version变更，以及Jira配置中可用的集成部署或审核事件设置规则。Jira没有通用的统一工作流，因此请将本地状态名称和转换条件映射到所需活动。
配置每条规则，将Webhook发送到[您的Webhook端点]。使用POST和JSON格式。包含问题键、问题类型、受分派人、优先级、状态、项目、可用时的团队字段、事件时间戳、转换信息、解决结果、Fix Version值和Jira事件标识符。不要依赖ProcessMind根据状态历史推断活动。
在Webhook接收端或数据接入层中明确设置活动映射。每个符合条件的Webhook都必须生成一行事件日志。将问题创建映射为“开发事项已创建”，准备就绪状态转换映射为“事项已准备好开发”，进入进行中状态映射为“开发已开始”，审核或开发完成状态转换映射为“开发已完成”，审核状态转换或集成审核事件映射为“已执行代码审核”，测试状态转换映射为“QA测试已开始”，QA回退状态转换映射为“QA测试未通过”，测试成功状态转换映射为“QA测试已完成”，UAT状态转换映射为“UAT已开始”和“UAT已批准”，发布准备状态映射为“已准备发布”，生产部署或已配置的发布完成状态映射为“已部署到生产环境”，关闭状态映射为“开发事项已关闭”，取消或拒绝状态映射为“开发事项已取消”。
根据流程负责人批准的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接收端。由于数据提取由规则配置和事件规范化驱动，而非Jira数据库查询，因此查询值设为config。
**案例标识符：**使用Jira问题键作为DevelopmentItem。不要将多个问题合并为一个案例。
**必需活动：**为“开发事项已创建”、“事项已准备好开发”、“开发已开始”、“开发已完成”、“已执行代码审核”、“QA测试已开始”、“QA测试未通过”、“QA测试已完成”、“UAT已开始”、“UAT已批准”、“已准备发布”、“已部署到生产环境”、“开发事项已关闭”和“开发事项已取消”明确配置映射。
**事件触发器：**仅在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套餐或集成功能。
**数据质量：**明确处理已删除问题、状态重命名、缺少受分派人、缺少团队字段、时区转换、重复投递和事件乱序的方式。

查询示例 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%。

开始免费试用

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

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

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

软件开发生命周期属性

软件开发生命周期活动

数据提取指南

使用Jira JQL查询并通过内置功能导出CSV或XML

步骤

配置

查询示例 config

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

步骤

配置

查询示例 sql

使用Jira官方REST API的Python脚本

步骤

配置

查询示例 python

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

步骤

配置

查询示例 config

准备好开始了吗？

立即优化Jira Software中的SDLC！