《Smart Agricultural Technology》：Process Mining for Agile Development of Farm Management Information Systems
编辑推荐：
研究人员应用过程挖掘（Process Mining, PM）改进园艺农场管理信息系统（Farm Management Information System, FMIS）软件的敏捷开发（Agile Software Development, ASD）。研究识别出
研究人员应用过程挖掘（Process Mining, PM）改进园艺农场管理信息系统（Farm Management Information System, FMIS）软件的敏捷开发（Agile Software Development, ASD）。研究识别出等待时间（Waiting Time, WT）是开发周期时间（Cycle Time, CT）的主要贡献因素。较小的项目规模将整体周期时间缩短了约30天。协作开发（Collaborative Development, CD）项目比内部项目实现了显著更短的周期时间。将过程挖掘与访谈相结合，使研究人员能够识别流程低效的潜在原因以及流程改进的途径。
农场管理信息系统（Farm Management Information System, FMIS）是现代设施农业和园艺生产中支撑运营管理、质量追溯及合规要求的核心工具。随着农业数字化进程加速，FMIS的功能复杂度持续上升，其开发方式需要不断适应农业场景的动态需求。敏捷软件开发（Agile Software Development, ASD）通过短周期迭代与持续客户反馈，成为FMIS定制化功能开发的主流方法。然而，ASD过程常因需求变更频繁、任务协调复杂、资源分配不均等问题，导致开发周期长、等待时间（Waiting Time, WT）占比高、返工频发等瓶颈。过程挖掘（Process Mining, PM）作为一种基于事件日志发现、监控和改进业务流程的技术，已在多个行业取得成效，但在农业领域及FMIS软件开发中的应用研究仍属空白。为此，研究人员以一家为园艺行业开发FMIS的中型企业（Case Company Under Study, CUS）为研究对象，开展了一项深入的案例研究，旨在探究PM对提升FMIS开发过程敏捷性的价值，并回答三个研究问题：ASD过程实际是如何执行的？过程中存在哪些瓶颈？这些瓶颈的潜在原因是什么？
研究采用混合方法案例设计，结合定量PM与定性访谈，首次将PM应用于FMIS软件开发的ASD过程分析。核心发现包括：等待时间占整体周期时间（Cycle Time, CT）的72%，是最大的流程延迟来源；代码审查（Code Review）是首要瓶颈，并且随着时间推移其耗时持续增加；公司实施的缩小项目规模策略使整体CT缩短约30天，其中约80%的改善来自WT的降低；协作开发（Collaborative Development, CD）项目的CT（中位数48天）显著短于内部项目（85天）；将PM与定性访谈相结合，有效识别了批处理、优先级排序和资源不可用等潜在瓶颈原因。该研究填补了PM在FMIS软件开发领域应用的空白，也为农业软件组织改善交付效率提供了数据驱动的路径参考。
在技术方法上，研究依据Runeson和H?st的软件工程案例研究框架，分两阶段实施。第一阶段采用收敛并行设计，在开展探索性半结构化访谈的同时对过程数据进行PM，构建期望过程模型；第二阶段采用解释性顺序设计，通过绩效分析识别瓶颈，再以开放式访谈验证和深化定量结果。过程数据来源于CUS的DevOps系统，事件日志在清洗、缺失值中位数填补、异常值删除、多表合并及过滤后，最终包含376个产品待办项（Product Backlog Item, PBI）和2110个任务，时间覆盖2020年3月至2025年1月，仅纳入2023年后的PBI以对应组织变革。定量分析采用过程诊断方法（Process Diagnostics Method, PDM），包括控制流分析和绩效分析；控制流分析使用归纳挖掘器（Inductive Miner）生成Petri网，绩效分析计算中位数处理时间（Processing Time, PT）、WT、CT及流程效率（Flow Efficiency, FE）。定性数据采用开放编码方法，借助MAXQDA软件进行主题归纳。
4.1 期望流程
基于访谈，CUS的ASD期望流程从功能设计开始，依次经过技术设计、估算、开发、代码审查、测试和返工等阶段，直至功能满足质量要求后发布。项目分为内部项目和客户驱动的协作开发（CD）项目。
4.2 挖掘流程
实际事件日志包含270种过程变体，高度异质。控制流分析显示，仅49%的PBI以“功能设计”作为正确起点，22%的PBI以“测试返工”正确结束；最常被跳过的步骤包括代码审查、开发返工和技术设计；测试与开发返工等步骤存在频繁的直接循环。
4.3 过程模型发现
使用归纳挖掘器从校正后的事件日志中生成Petri网，模型拟合度为74.9%，精度为81.1%。模型显示功能设计与估算、开发与代码审查存在并行执行关系，这与期望流程不符；并行和循环模式反映了真实开发过程中的偏差。
5.1 处理时间分析
开发与测试阶段贡献了总处理时间的70%，其中开发活动耗时约为测试的三倍。代码审查虽预期耗时较小，却表现出比开发任务更长的处理时间，成为处理时间层面的首要瓶颈。缩小项目规模后，多数步骤的处理时间下降，但代码审查的处理时间反而上升。
5.1.1 按项目类型比较处理时间
CD项目的处理时间普遍低于内部项目，其中设计和代码审查完成更快，但技术设计耗时更长，反映出将客户特定需求整合进标准软件产品的复杂性。开发仍是CD项目中最耗时的步骤。
5.2 等待时间分析
等待时间是周期时间的主导因素。整体上，估算和技术设计步骤的等待时间最长。填补缺失时间戳会降低等待时间的估计值，但保留了有限数据集中的有效观测。CD项目的等待时间整体低于内部项目，但技术设计等待时间最长，且随着项目数量增加而有上升趋势。
5.2.1 整体等待时间及变化
通过中位数等待时间比较，较大比例的项目期间处于非活跃状态。等待时间在组织变革后总体下降，但技术设计和开发等关键步骤在某些时期再次出现等待时间上升。
5.2.2 按项目类型比较等待时间
CD项目由于其客户导向和优先级较高，流程流动性更好，等待时间较短；内部项目则更多经历因资源分配和批次处理导致的延迟。
5.3 周期时间分析
整体中位周期时间为79天，其中约57天（72%）为等待时间，流程效率较低。代码审查是周期时间层面的最大瓶颈，其次为开发活动。组织变革使周期时间从109天降至79天，其中80%的缩短来自等待时间的减少。
5.3.1 整体周期时间现状
代码审查的中位过程步骤时长最高，且随时间推移而增长；估算步骤的周期时间主要由等待时间而非实际执行造成；功能设计、开发和返工步骤因等待时间下降而变得更为高效。
5.3.2 按项目类型比较周期时间
CD项目的中位周期时间为48天，内部项目为85天。内部项目的改善主要由等待时间驱动，而CD项目的改善主要由处理时间驱动；但后期技术设计和开发的等待时间上升表明，项目量增长带来了新的协调挑战。
5.4 研究问题2的答案——瓶颈
等待时间占周期时间的72%，是最主要的瓶颈来源。代码审查是首要过程级瓶颈，其次为估算（低流程效率）和开发（高处理时间且频繁执行）。内部项目主导了整体瓶颈，CD项目则呈现在技术设计和开发方面，反映客户需求整合的复杂性。
6.1 努力与处理时间的相关性
处理时间与估算努力比率（Processing Time Effort Ratio, PTER）在代码审查和开发步骤中最高，表明这些任务按估算努力来看异常耗时；努力与处理时间之间仅存在弱正相关，说明延迟不能完全由工作量解释。
6.2 短周期与长周期项目对比
对比短周期（<90天）和长周期（≥90天）的PBI，功能设计返工和等待时间差异显著。长周期项目中，测试返工、功能设计和测试步骤的等待时间大幅增加（分别增加82%、80%和71%）。主要潜在原因包括批处理、CD项目优先于内部项目，以及测试人员同时担任Scrum Master导致的资源不可用。
6.3 对CUS开发过程的定性洞察
访谈揭示了日志中不可见的驱动因素：设计文档以文本为主，歧义导致开发延迟；代码审查中自动生成的DevOps任务缺少及时跟进和关闭，行政纪律不足影响进度可见性；测试高度手动且工作量大，测试用例常被推迟；全球分布式团队的时间差异和远程沟通工具降低协作效率。
6.4 研究问题3的答案——瓶颈的原因
综合定量与定性证据，代码审查是首要瓶颈（中位过程步骤时长16.9天），其部分原因在于任务未及时关闭的管理问题；等待时间的主要来源为设计和返工活动中的批处理、CD项目优先排序对内部项目的挤占，以及高度手动流程导致的测试能力不足。
讨论部分指出，PM与定性方法结合能够超越单纯的速度改进，帮助理解瓶颈的因果机制。缩短项目交付时间虽然提高了响应性，但同时也观察到更多过程循环和返工，这可能反映了对质量和准确性更严格的追求，而非单纯的效率损失。不同项目类型和团队存在执行策略上的差异，部分团队更重视速度，另一些则更关注减少返工。改善任务管理、过程纪律和跨团队协调有助于在速度、效率和质量之间取得平衡。研究还存在数据缺失、单一案例和难以做出因果推断等局限性，但通过数据清洗、利益相关者验证和非参数统计方法得到了部分缓解。
研究结论可翻译为：本研究调查了过程挖掘在一家为园艺行业开发FMIS软件的中小型企业中敏捷软件开发中的应用。研究将定量PM技术与定性访谈相结合，分析了性能瓶颈并评估了缩小项目规模这一业务战略的影响。分析显示，等待时间占整体周期时间的72%，批处理、任务优先级和资源不可用是主要原因。代码审查成为首要瓶颈，很大程度上归因于任务未关闭等管理问题。缩小项目规模的策略使周期时间减少了约30天，主要由等待时间下降驱动。基于情境的绩效分析显示，协作开发项目比内部项目具有更短的周期时间，但速度提升伴随更多过程循环，表明时间和质量之间需要权衡。研究得出结论：PM与定性洞察相结合，是诊断和改进FMIS开发中ASD过程的强大工具，数据质量、利益相关者参与和情境分析在PM研究中至关重要。未来研究应在更大数据集和其他FMIS公司中验证发现，并可将PM视为业务流程管理循环中的关键组成部分，持续推动FMIS开发过程的优化。
