【虽是敏捷 FAQ 却大大偏离正道篇】我为何担任“私设·消灭日式敏捷协会”会长

 感谢您阅读本文。我是隶属于敏捷小组的藤井智弘。
 首先，请允许我重新做一下自我介绍。我长期担任“私设·消灭日式敏捷协会”的会长。会员人数不公开（不如说，从来没有数过）。不收会费，协会章程和成立经过会刊载在本文最后。
 表面上是在开玩笑。但内容非常认真。而且实际上我经常被问到这件事。
 这次，我不以 is 的兼职员工身份，而是以这个可疑协会会长的身份，写下我为什么想要消灭它。

 合作方提议采用一种名为“日式敏捷（混合敏捷）”的推进方式。据说会在需求定义阶段之前充分确定需求并敲定预算，开发则以每两周一次的迭代方式推进，最后集中进行综合测试。由于预算能够确定，内部审批也更容易通过，我觉得这很适合我们公司。请问会有什么问题吗？

 这种推进方式本身，作为过渡期的形态是可以存在的。问题在于名称。如果先确定需求和预算，之后能够变更的量就与瀑布式开发的变更管理几乎没有区别。若将其称为“敏捷”，委托方就会期待自己实际上得不到的灵活性。如果无法获得敏捷的自由度，那么称之为“混合瀑布”会更诚实。
 而且，想要先知道总预算这一诉求，其实并不与敏捷矛盾。应当确定的不是需求清单，而是预算和目标。

 首先，我想明确一下究竟要消灭什么。
 在需求定义之前采用瀑布式推进，只在构建阶段进行迭代，最后集中进行测试。这种形态有一个名字，叫作“Water-Scrum-Fall”。据说这是调研公司 Forrester 的 Dave West 为许多组织中的敏捷现实形态所取的名称。前面的流程（需求与预算的批准）和后面的流程（测试与发布）依旧保留传统做法，只有中间变成了迭代。这是许多组织在转向敏捷的过程中，至少都会经历一次的形态。
 因此，我并不打算责备正处于这个阶段本身。如番外篇《正论行不通时》所写，在组织的前提条件无法改变的情况下，从能够做的地方开始，是正确的战斗方式。
 本协会想消灭的，是将这种过渡期的形态称作“适合日本组织的敏捷”，并作为最终形态出售的说辞。若作为最终形态来售卖，转型（换言之就是进化）就会止步于此。

 我很理解这种卖法为何具备一定的吸引力。
 委托方想尽早知道总预算。要通过内部审批，就需要金额。承接方如果给不出金额，就无法接单。但也不能凭不可靠的数字签订合同。因此，便试图认真完成需求定义，确定预算。到这里为止，无论从哪一方的立场看都是合理的。没有人在做错事。
 问题在于接下来。

 确定需求并确定预算，意味着此后的变更会成为“预算框架内的变更”。超出框架的变更，需要提出变更请求、评估影响并获得批准。这正是瀑布式开发的变更管理流程本身。即使迭代单位变成两周，从总量来看，能够变更的量也几乎没有变化。
 然而，“敏捷”一词带有“可以灵活变更”的印象。委托方基于这种印象签订合同，之后却会疑惑：“明明是敏捷，为什么每次变更都要给出估算？”
 本协会亲切地将此称为，招牌诈骗。
 ……这样说会显得尖锐，所以在正文中我会写得更准确一些。销售方未必有意欺骗。更常见的情况是，销售方自己也相信他们正在做敏捷。但结果是，委托方被引导去期待自己无法获得的灵活性。
 也就是说，招牌与内容不一致。

 如果只是名称问题，也许不至于如此斤斤计较。然而，这种错位会造成实际损害。因为连载中讨论过的许多问题，都会以结构性的方式被嵌入这种形态中。

• 学习无法抵达成果物：由于需求已被确定，即使在 Sprint Review 中发现“原来不该是这样”，要做的东西也无法改变。第 8 回中看到的、不会影响任何人决策的评审，不再是例外，而会成为标准。
• 直到最后才发现错误：由于测试集中放在最后，Sprint 中“完成”的东西实际上未经验证。第 11 回的测试延期模式会成为正式流程。敏捷最大的功效——尽早发现错误——便在这里消失了。
• 工作量会变成两者之和：瀑布式的文档和审批原封不动地保留下来，同时又加入 Scrum 的各种事件。现场只会留下“改成敏捷后会议变多了”的记忆。
• 失去锻炼基本功的理由：如果最后靠人力集中测试，那么就不需要测试自动化和 CI。业务系统现场多年未能推进的这项投资，在这种形态下将永远无法被正当化。
• PO 又回到了验收人员的角色：由于需求预先确定，PO 不再是决定方向的人，而是确认是否符合规格的人。第 8 回中看到的“内部外包”格局会被原样保留。

 而最大的危害，是这些结果最终留给组织的结论。成本增加，质量和交期却没有改变，也没有产生学习。由于这些都是以“敏捷”的名义进行，组织中便会留下“试过敏捷，但不适合我们”的经验法则。下一次有人尝试真正的敏捷时，挡在其面前的，是在重视先例的环境中对这次失败的记忆。番外篇《正论》中写过，过去曾因片假名流行词而吃过苦头的组织，只要看到招牌就会严阵以待。而播下这种种子的，正是这种卖法。

 那么，应该如何回应委托方“希望尽早知道总预算”的需求？事实上，敏捷并不与这一诉求矛盾。
 只要确定周期和团队规模，总额就可以预先确定。相应地，不固定内容。先制作优先级高的内容，交付，观察结果，再调整剩余事项的顺序。固定预算与目标，让范围可变。第 4 回讨论的、在不确定全部功能的情况下给出估算，也是建立在这种思路之上的。
 换言之，委托方真正想知道的是总额，而不是确认全部需求。日式敏捷以给出总额为名，连需求也一并确定，然后又说“因为是敏捷，所以很灵活”。错位就在这里。
 要辨别自己的项目属于哪一种，只需问一个问题。

合同中确定的是需求清单，还是预算与目标？

 如果确定的是需求清单，那么即使在进行迭代，内容依然是瀑布式。如果确定的是预算和目标，而内容作为带有优先级的候选清单来处理，那么敏捷的自由度就真正到手了。不提交变更申请文件，是否就能够替换项目内容？以此进行实际判断已经足够。
 当然，改变合同的形态并不容易。总包合同、公司内部的开发标准、审计要求——无法改变的前提条件多得很。正因如此，在无法改变时，请用诚实的名称来称呼它：混合瀑布。有了这个名称，委托方就能拥有正确的预期，承接方也不必因自己没有承诺过的灵活性而被责难。
 番外篇《正论》的第三原则是“如果内容扎实，就不要执着于招牌”。这次则是其反面：如果没有内容，就不要挂招牌。

 顺带一提，作为会长，我也要对今后可能出现的新招牌发出预警。
 以生成式 AI 为开发核心的“AI 驱动开发”，以及先编写规格、再让 AI 生成代码的“规格驱动开发（SDD：Spec-Driven Development）”，正受到关注。仅从表面来看，两者都是“先认真写好规格，再用 AI 快速迭代构建”的形态。这与日式敏捷“充分确定需求定义，只对构建进行迭代”的做法，惊人地相似。“AI 时代上游环节更重要。果然，先确定需求定义再构建的方法才是正确的”——我想，这类营销话术出现只是时间问题（不，或许已经出现了……）。

 但是，逻辑的方向恰恰相反。SDD 的关键不在于规格先存在。关键在于，修改规格并重新构建的成本几乎变为零。规格应以功能或增量为单位小范围编写；看到可运行的成果并获得学习后，就修改规格并重新构建。规格不再是合同附件，而是作为仓库中的文件持续存在。
 过去，在前期进行大规模设计的依据是：“之后再改会付出高昂代价”。XP 曾试图以测试和重构打破这一前提，AI 则进一步瓦解了它。如果之后修改的成本很低，那么在前期确定一切的理由反而会变弱。

 危险的是，只借用 SDD 的形式，在前期确定整个系统的规格，并在合同中将其冻结的组合。那是“用 AI 快速敲键盘的瀑布式开发”，是一种能够从错误的规格出发，比以往更快速、大量地制造错误成果的机制（而且人们恐怕根本无法将其全部评审完）。
 称其为第 1 回所写的AI 唯命是从开发的组织化完整版也不为过。

 为公平起见，我要补充的是：AI 确实提高了“先将意图清晰地表达成文字”的价值。预先编写本身并不与敏捷矛盾。敏捷宣言所说的是“更重视”，而不是“不要写”。违背敏捷的并非预先编写，而是以大单位编写并冻结。
 因此，刚才的问题在 AI 时代可以换成这样。

那份规格书是合同的附件，还是仓库中的文件？

 如果每次修改都需要变更申请书，那么无论 AI 生成什么，它都是混合瀑布。

 最后，作为会长，有一件事我无论如何都想说：关于“日式”这个名称。
 追溯“Scrum”的起源，正如许多人所知，会发现它出自竹内弘高、野中郁次郎两位于 1986 年发表的论文“The New New Product Development Game”。这篇论文将按顺序交接流程的开发比作接力赛，将流程重叠、所有人一同前进的开发比作橄榄球，并论述了日本优秀制造商的优势在于后者。Scrum 这个名称正是由此而来。
 Water-Scrum-Fall，是在接力赛的中间夹入一个 Scrum 的形态。将曾作为日本现场优势介绍给世界的东西，恰好反着做，却自称“日式”。
 真正的日式，早已漂洋过海，并以 Scrum 之名被逆向引进了。

 那么，供参考起见，下面刊载本协会的章程。入会和退会都自由（←因为是玩笑啦，并没有在招募会员）。

第一条：招牌名副其实
 无法获得敏捷自由度的推进方式，不称为敏捷。若预先确定需求和预算，就称为混合瀑布。没有内容就不要挂招牌

第二条：欢迎过渡期，但不将其作为终点
 处于 Water-Scrum-Fall 并不可耻。不过，应当确定下一步要打破哪里。将测试前移、缩小预先确定需求的范围、在中途插入发布。做到其中任意一项即可。

第三条：确认合同
 当有人说“将以敏捷方式推进”时，要确认合同中确定的是需求清单，还是预算与目标。

第四条：变更，以替换来实现
 如果欢迎变更，就应预先就替换规则达成共识。加入某项内容时，就移除某项内容。还应确定由谁做出该判断。

 我开始自称会长，是因为我在同一块招牌之下，反复见过两种截然相反的混乱。

 第一种，是完全没有灵活性的现场。将需求定义阶段确定的功能清单，按 Sprint 的顺序逐项消化。我把这称为，分期付款。买什么、总额是多少，在签订合同时就已经确定。Sprint 只是决定将这笔款项分成几次支付而已。即使途中发现“原来这个不需要”，也只能继续偿还剩余款项。即使在 Sprint Review 中观察到用户的反应，下一个 Sprint 要做什么也早已确定。明明在迭代，却没有让学习介入的空间。

 第二种则恰恰相反。委托方将“既然是敏捷，变更就自由”这块招牌当了真，不断提出变更。然而，预算和需求已经确定，承接方没有吸收这些变更的余地。起初会勉强接受，通过加班和质量下降来吸收，到了极限后变更管理便重新复活。委托方会说：“不是说敏捷吗？”承接方会说：“不是说在预算范围内吗？”双方都没有说谎。

 这两种情况，是同一块招牌的正反两面。第一种，是承接方坚持让内容维持瀑布式的结果。第二种，是委托方相信了招牌的结果。而两个现场所缺失的东西是相同的。在真正的敏捷中，之所以欢迎变更，是因为在预算和周期的框架内，会以优先级较低的事项替换新加入的事项。变更不是追加，而是替换。没有人将这一替换规则写进合同或共识中。分期付款的现场不允许替换，而变更蜂拥而至的现场也没有要求替换。
 “日式敏捷”这块招牌，让最重要的这一句话从双方的视野中都消失了。

 虽然说要消灭它，但本协会的目标是解散协会。当“日式敏捷”这个词不再被使用，过渡期能够作为过渡期，以诚实的名称被称呼时，届时本协会便能带着无比光荣的心情解散。

本篇连载的列表请参阅第 1 回。