【敏捷FAQ 第1回】在AI时代重新审视！真的有必要吗？Scrum基础的「意义」与「价值」

 感谢您阅读本文。我是隶属于敏捷组的藤井智弘。

 在以「is的最后一名兼职者」这一神秘头衔让客户摸不着头脑的同时，我日复一日地投身于培训和支持工作，并在多年里不断收到类似的提问。敏捷开发问世近30年，实践者也在不断更替，因此曾经似乎已被充分讨论过的问题，如同打者轮换，反复成为话题也不足为奇。

 正是基于这些常见问题，我将以FAQ形式，把其背后的结构性问题以及在现场可用的应对方法加以明文化，这就是本连载的宗旨。

 本连载的目标读者群设定如下。

• 通过培训或专业书籍的学习，已了解「冲刺是什么？」这一基本术语概念
• 在进入新年度后开始运行冲刺几个月，「这样做对吗？」的疑惑开始累积

学习了基础的人更进一步……「明明知道，却在现场无法顺利执行，这是为什么？」……本连载旨在创造一个深入思考的机会。

 由于出发点是实际收到的问题，乍看标题可能会认为是「开发者视角」，但我们始终着眼于「与敏捷相关的人都应该了解的内容」。因此，无论是带领团队的负责人，还是作为发包方或管理层与Scrum团队打交道的立场者，也请一同阅读。

 在进入正题之前，请允许我说明三点事宜。

• 不是「标准答案」，而是「可选方案」。
  …针对问题的应对方法，常常会根据项目所处的背景（Context）采取不同的方式。本篇也会提出一些应对思路，但请理解这些更像是「各位可以采用的可选方案」，而非「标准答案」。这或许与其他书籍或博客中建议的做法有所不同，但希望您能将其视为「选项增多了」的机会，并结合您自己团队的背景思考该做何种选择。
• 并非「AI工具具体使用方法」的解说。
  …近年来，开发现场对AI的使用兴趣日益高涨，但本连载并不会解说AI工具的具体使用方法。相信会有其他人以其他文章来专题介绍。
• 术业有专攻，法律问题请交给专家。
  …诸如承包合同等法律及契约实务方面的问题也不在本连载讨论范围之内。

 前言略长，本期FAQ选择了在培训和导入支援现场日益增多、体现时代特征的问题。

 如今已是AI能编写代码、生成测试和设计方案的时代，开发速度飞跃式提升。老实说，现在再去学习Scrum的基础还有意义吗？将开发划分为冲刺周期，由人来估算和回顾，在AI的速度面前，似乎只是一种“仪式”。

 学习仍然有意义，其重要性甚至在提升。因为Scrum所关注并管理的，不是“制造速度”，而是“前进的方向”。
 AI戏剧性地加快的是“如何去制作”，而“制作什么”和“从结果中学习什么”是需要人主动进行的活动。AI虽能辅助，但无法完全交由其处理。制造速度越快，错误的产出也会越快出现——这一简单事实，使得检验与适应（即频繁检查产出及方式，并不断调整下一步）的平凡基础活动，其价值前所未有地提升。

 首先，让我们冷静区分。生成型AI确实改变的是实现、测试代码编写、模板化设计、调研等“如何制作”的领域。关于这部分提升了数倍（甚至更多）的说法，毫无异议，我自己也深有体会。

 那么，以下这些问题又如何呢？

• 该功能解决的是谁的什么业务痛点？
• 发布后是否达成了预期效果？
• 如果未达成，下一步要改变什么？
• 团队当前的工作方式是否在正常运作……

 这些都是需要人主动决策的议题，AI并没有现成答案。它能生成看似合理的答复，但验证责任始终落在人的身上。如您所察，“制作什么”“从结果中学习什么”“团队如何进行检验与适应循环”正是敏捷在过去30年里始终在问的核心问题。AI并未承担任何这些问题，反而只是提高了在不面对这些问题的情况下快速产出的速度（至少目前是如此）。

 其结果是在现场出现了这样的场景：对AI生成的产物毫无验证，也不理解其意图，只是直接照搬、层层堆积式地进行开发……让人不禁想大声喊道“这不就是‘AI唯命是从式开发（AI-Dictated-Development）’吗！”？而这与真正的“AI驱动式开发（AI-Driven-Development）”大相径庭。

插图左：AI驱动　　插图右：AI唯命是从

 AI唯命是从式开发的特点在于，每一个成果物都看似合乎情理。代码可以运行，测试可以通过，文档也整理齐全。问题在于，没有人能令人满意地解释：这些全部是为谁、为了解决什么而制作的。在未经验证的假设之上，未经验证的产物就以高速堆积起来。过去可能需要数月的“朝错误方向行军”，现在几周即可重演。

 然而，这并非新病。早就存在“不问意图，只问要求”的开发模式：“因为需求定义书上写了就做”“照着说的做完”——AI只是将其加速，并更善于用“已完成”的假象来掩盖。
 如果诊断相同，处方也属于同一范畴。

 让我们将本连载所讨论的基础重新放到AI的语境中来审视。

• 质问受众和目的的习惯：要对AI的输出也提出“这段代码是为谁、为了解决什么？”（图2）。生成物越是看似合理，这个问题就越成为人的工作。
  
• 小规模完成并检验的节奏：不盲目接受生成结果，而要强制安排运行、使用并学习的机会。冲刺的目的不是“因为人太慢才分段”，而是为了“建立学习的节奏”，因此即使生成速度提高，也不会变得多余。反而因为需要检验的生成物更多，检验节奏的价值更高。
• 度量与记录的纪律：将“感觉用AI做得更快了”转换为可验证的事实。要考察实际的交付周期（从开始到交付的时间）是否真的缩短，返工是否增加。工具的评估也同样是检验与适应的对象。

 反过来，也有可以改变的内容。冲刺的长度、估算方式、文档的编写方法……这些是Scrum推进的“运行参数”，AI可能会改变其最优值（本连载后续各论中会反复提到“基础”和“运行参数”的区别）。如果生成速度更快，冲刺时间可以更短。与其在估算上争论，不如先生成后验证更快。请大胆地重新审视这些参数。在这个技术大变革的时代，“无批判精神的因循守旧，就是‘罪’”。

 这些参数的更改也要在团队内讨论并达成一致，并将其效果纳入检验范围。无视周围在现场随意为之，可不是件好事。

 而一旦去掉了上述检验与适应的循环，剩下的就只是“高速唯命是从”而已。

 “既然有了新工具，流程基础是不是就可以省略了？”这一质问，事实上AI并非首例。从CASE工具（20世纪80~90年代从设计图自动生成代码的工具群）、RAD（20世纪90年代通过反复试作在短时间内开发的手法）、到低代码让程序员变得可有可无……每当新工具出现，同样的质问就会上演。打者不止轮了一次，这已是多轮打击了。

 而每次的结论也都相同：工具改变了“如何制作”，有时带来戏剧性改进，但“应制作什么”“从结果中学到什么”始终留在工具之外；忽视这些的项目，往往会在更快的工具上更快地失败……

 我承认，AI与过去的工具相比，在规模上确实带来了不同层面的变革。正因为如此，更应该这样说：工具越强大，握住方向盘一方的基础就越受检验。本连载接下来要探讨的，正是如何稳握这个方向盘。

 下面是后续各期的计划，按顺序列出标题。请注意，这些仅为暂定，可能会在未通知的情况下发生变更，敬请知悉。

• 第2回: 运维团队不适合Scrum吗？
• 第3回: 如何面对升级项目中的“现有功能保障”？
• 第4回: 针对变更项目，如何在未确定所有功能的情况下给出估算？
• 第5回: 文档不可信赖的现有系统，要以什么作为“规范”来验证？
• 第6回: 每日Scrum变成了进度报告会
• 第7回: 回顾会议不起作用……重复相同的改进方案和仅列举ToDo项
• 第8回: 冲刺评审会上利益相关者不再参加
• 第9回: 上司要求将故事点换算为人日
• 第10回: Velocity不稳定，可以用来做计划吗？
• 第11回: 每次冲刺都会出现未完成的任务
• 第12回: 如何将插入性工作纳入计划？
• 第13回: PO过于忙碌，无法来到团队
• 第14回: Scrum Master是做什么的？看起来很闲
• 第15回: 即使说要自组织化，最终还是由领导一手决策
• 第16回: PO不优先偿还技术债务
• 第17回: 文档到底要写到什么程度？
• 第18回: 一开始改善顺利，但最近感觉团队陷入停滞
• 第19回（最终回）: 连载总结

 感谢您耐心阅读这篇较长的文章。

下次: 「运维团队不适合Scrum吗？」