生成式 AI 的潜在应用场景似乎无穷无尽。虽然这令人兴奋,但也可能让人不知所措。因此,团队在使用这项技术时需要有明确的目标:关键是要明确生成式 AI 在团队工作中能产生哪些实质性影响。
在软件工程中,一个引人注目的应用场景是需求分析。这是一个常常被忽视但充满挑战的环节,如果处理不当,可能会带来许多负面的后续影响。
本文描述了我们与一位客户进行的试点项目,我们的团队验证了一个假设,即利用生成式 AI 创建高质量的用户故事可以缩短交付周期并提高需求分析的质量。在这个案例研究中,我们验证了这一假设,并解释了我们做了什么以及得出了哪些结论。
方法
确定范围和目标
在选定该团队作为试点后,我们与他们举办了一次研讨会,确定哪些任务可以通过 AI 支持。我们还与他们合作,定义了使用 AI 可能带来的影响。研讨会达成了两个主要目标:
1. 找出适合 AI 支持的任务
团队讨论了他们经常进行且伴随一定难度的任务。随后,他们选择了部分高价值且 AI 可行性较高的任务。其中一个被选中的任务是需求分析,因为团队的工作领域相对复杂,开发过程中常常因需求被误解或遗漏边缘情况而返工。
2. 定义假设和预期结果
在研讨会的第二步,团队定义了使用 AI 期望实现的目标。以下是需求分析的假设:
我们相信,使用生成式 AI 来辅助... | ...将导致... | 我们知道它有价值的标志是... | 需要监控的风险 |
---|---|---|---|
撰写史诗和用户故事 | — 减少后续流程中的返工— 更好地满足“完成定义”中的标准— 缩短交付时间 | — 缩短交付时间(从“分析开始”到“完成”)— 开发人员对故事的反馈更好— 开发人员的问题和澄清减少— 被阻塞的故事减少— 待办事项列表始终保持充足— 测试中发现的遗漏需求减少 | — 范围蔓延(AI 提供过多的想法)— 故事冗长,团队迷失在细节中 |
实施
我们利用服务工具包中的加速器帮助实施 AI 支持。HaivenTM 团队助理 是我们与客户合作时使用的一个加速器,它为软件交付团队提供了一个试点生成式 AI 支持的精简方式。在该项目中,它为用户提供了集成上下文信息和可重用提示词的 AI 功能。
团队的业务分析师(BA)和质量分析师(QA)是主要的工具使用者。他们在各自领域都有丰富经验,并在该团队工作了很长时间。在这次试点中,他们使用该工具将三个新的史诗需求分解为用户故事。每个史诗都是关于为现有功能增加额外能力的。
收获
上下文是关键!
其中一个关键收获是团队需要为 AI 提供多少上下文信息才能让其发挥作用。Haiven 在这方面非常有帮助,因为它允许用户定义可重用的上下文描述,每次与 AI 交互时都可以调用。这意味着他们不必每次都重复相同的上下文信息。
正如我们之前提到的,团队的工作领域相对复杂,史诗的目标是扩展现有功能。因此,他们最初花了一些时间向 AI 描述领域和架构,以便每次与 AI 交互时能够重复利用。这些上下文描述既提供了逻辑和领域语言的总体描述,也明确了当前功能的工作原理,帮助 AI 进行功能扩展的支持。
这种方法显著提高了结果质量,但也表明,在他们的情况下,前期投入是必要的。类似编程助手,使用 AI 修改现有需求比从头设计新功能要困难得多。
用户需要时间适应 AI 支持
最初,用户在如何有效地与 AI 互动方面遇到了困难。了解大语言模型(LLM)响应的非确定性并理解其影响需要一个学习过程。随着时间推移,用户调整了对 AI 的期望,逐渐适应了将 AI 作为助手,而不是一个能够提供完美结果的软件。他们还学会了如何在聊天对话中让 AI 纠正方向,当初始输出不准确时进行调整。
开发人员经常报告在使用编程助手时会出现“审查疲劳”,因此我们也询问了 BA 和 QA 对审查 AI 输出的感受。他们表示审查这些场景并不太繁琐,至少在他们的经验水平下是如此。
很难定量衡量影响
我们发现,衡量 AI 在需求分析中的影响比在编程中的影响更难。
- 这些任务不像编程那样频繁,因此对它们的改进难以单独量化。
- 史诗比用户故事或技术任务更难比较,因此难以与历史数据直接对比。
- 需求分析质量的一个指标是故事在流程中被阻塞或反复返回的次数,因为不完整或不清晰。这类数据通常不会非常细致地跟踪,因为那样会让流程和任务看板过于复杂。
尽管如此,无法定量衡量并不意味着它没有价值!以下关于质量和速度的观察基于 AI 用户在该案例中的估计。
对质量和团队流程的影响
重申一下,假设的一部分是使用 AI 进行需求分析会缩短交付周期,减少返工,并减少因进一步澄清而被阻塞的故事。
业务分析师报告说,由于他们的准备更加高效和全面,AI 助手使他们在与开发人员讨论时更加自信。他们能够回答开发人员在估算会议中提出的问题,不必再进行需求填补。
质量分析师发现,一旦上下文明确,AI 生成的验收标准和测试场景比他们自己生成的要好。当他们开始测试开发人员的工作时,发现的 bug 和返工原因减少了大约 10%,因为用户故事定义更好地涵盖了边缘场景。
对分析速度的影响
虽然三个史诗的样本量不足以得出明确结论,但团队估计分析时间减少了约 20%,尽管创建上下文花费了一定时间。随着上下文创建的优化和上下文的重复
使用,未来的时间节省预计会更为显著。
结论与展望
总之,这项案例研究表明,AI 能够在质量、速度和整体团队流程上带来好处。在该组织中,下一步是将这种方法应用于其他团队,这些团队的经验水平和流程有所不同,以验证是否能重复这些收获,并进一步提高效率。
这项经验以及其他 AI 在软件团队中的使用经验再次证实了上下文编排的重要性。
- 上述团队工作在相对复杂的领域,他们发现,只有在为 AI 提供了详细的领域上下文描述后,AI 才真正有用。对于那些在电子商务或客户数据管理等常见领域工作的团队,这一障碍要低得多,因为这些领域的模型训练数据通常能广泛适用于相关用例,而无需额外的引导。
- Haiven 支持半手动的上下文编排,并允许重复使用上下文描述:团队将领域描述作为提示词的一部分,并为助理应用程序编制了相关维基文档的索引。虽然这需要一些设置工作,但它仍然是探索 AI 潜力的精简方式。然而,我们密切关注软件工具市场的创新,以实现更加自动化和智能化的上下文编排,从而为客户提供最佳建议,帮助他们充分利用 AI。
- 代码库是应用程序工作原理的最终真实信息。它始终比可能过时或不准确的文档或描述更可靠。在本案例研究之外,我们已经与客户一起探索了为 AI 提供代码库上下文的有趣而强大的方式,这使得用户能够在不需要理解或浏览代码的情况下提出问题。尽管该团队在此次试点中未使用此类工具,但其潜力显而易见,尤其是在指定现有功能的更改时。