【敏捷FAQ 第4回】如何在未确定所有功能的情况下进行更改项目估算？

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

 这是将更改项目中的“现有功能保证”分成三个子主题探讨的第二篇。上一次（第3回）中，我们看到所谓“现有”实际上有三种内涵，并在最后质疑了“确定”这一前提。本文将思考如何构建一个能够与发包方达成一致的“整体概貌”。

 在对现有系统进行更改项目时，我提出了使用敏捷方式推进的方案，却被发包方要求“请提供作为估算依据的功能列表”。当我解释“敏捷方法一开始不会确定所有项”时，他们反问“那我们要为哪些功能支付多少钱呢？”，结果话题就此中断。
 在不确定所有功能的情况下，如何才能制定既能通过审批流程、又能在合同中达成约定的估算方案呢？

 如果被要求作为估算依据提供整体概貌……是可以做到的。关键在于以何种粒度来呈现。选择合适的粒度，就能给出发包方习惯的列表形式以及由此得出的规模感。但这并不意味着开发的内容必须在一开始就全部固定下来。
 在第3回的最后，我们将问题从“能否确定”转换为“将哪些内容纳入繁琐手续，哪些内容保留在无需手续即可变更的范围”。提交的功能列表很可能会被当作确定范围——归入了繁琐手续的范畴。那么，就应选择一个即使放在那一侧也能遵守的粒度，并将灵活性保留在其内部。
 提供整体概貌与保留灵活性，二者通过选择适当的粒度即可共存。

 在现场支援中经常感受到的一点是，发包方和承包方虽然都使用“功能”这个词，但心中想象的粒度可能并不相同。承包方的敏捷团队所想到的是“用户故事”（Story）——也就是在培训中学到的要在一次冲刺（1～2周）内完成到测试阶段的那种单位。而发包方脑海中浮现的，则是作为预算获取依据而列出的功能列表——以页面或报表为单位书写，远比用户故事更大的粒度。这样的粒度差异几乎不会被提上讨论桌。因此，当由于预算或进度的原因决定“取消某项功能的开发”时，发包方与承包方对于将失去的内容规模的感受也常会出现不一致。
 除了对粒度的认知存在差异之外，在培训中几乎没有机会学习“更改类项目的上下文”也让问题更加棘手。
 敏捷的教科书和案例大多以新开发场景为舞台——尤其是像网络服务那样，究竟什么会被用户接受只有上线后才知道的世界。在那个场景下，“不确定所有功能”是合理的判断。
 那么，更改类项目呢？业务已经在运行，新系统的价值首先在于覆盖性——只要有遗漏就会中断业务——而目标也从一开始就已确定。若要分阶段构建，就需要先俯瞰全局，选择“这次要做哪些部分”。发包方之所以要求“请展示整体概貌”，正是因为他们想确认“这样能否保证业务正常运行”，这是理所当然的要求。如果将网络服务场景下的逻辑——“不确定所有功能”——原封不动地搬过来，双方对话自然会出现偏差。

 虽然“谈到敏捷就想到用户故事”的印象已经深入人心，但在敏捷领域中其实也存在用于整理粒度的机制。通过加入史诗（Epic）和特性（Feature）等类型，从大到小逐级改变粒度，并在每一级粒度上明确要关注的内容——是关注业务目标，还是关注用户使用方式——形成一整套整理方法。不过，不同方法论对这些类型的定义各有差异，且团队需要自行决定粒度设计的部分很多，所以对于经验不足的团队来说负担颇重。
 因此，本文将介绍一种粒度结构已事先定义好的用例（Use Case）方法（本系列刊物旨在“提供可选方案”，此处仅作为一种选择）。参考的是 Ivar Jacobson 等人的“Use-Case 3.0”（Jacobson, Spence, de Mendonca, 2024）——这是一部将用例重新整理为驱动敏捷开发的简易实践指南，前提是假设与用户故事并用。
 具体用法稍后将在示例中展示。在此之前，我们先确认一下基础。
 用例可定义为“为达成某一特定用户的目标而使用系统的所有方式”。其构成要素有三个。

• 参与者（Actor）（谁）
• 用例（Use Case）（为了什么目的，需要做什么）
• 流程（Flow）（如何进行）——包括基本流程（Basic Flow）（达到目标的最简单路径）和派生出的替代流程（Alternative Flow）（其他路径、异常、失败时的处理）集合

          图1：用例图

 图1是表示参与者与用例关系的用例图。能够从整体上俯瞰谁为了何种目的使用系统。
 在每个用例中，用户会实际操作系统，其大致步骤即为流程。
 基本流程与替代流程的关系将在随后示例（图2）中具体展示。
 如此一来，用例工具中既包含了俯瞰整体的阶段（参与者与用例），也包含了查看各个用例内部细节的阶段（流程）。这便是“结构已事先定义好”的含义。
 以上作为基础，让我们通过实际示例加深理解。

 以下以账单业务为例，将用例方法应用于更改项目的四个步骤进行演示，并在每个步骤中即时定义所使用的概念。示例仅供参考，步骤和概念适用于任何业务。如果您希望用 Epic/Feature/Story 的方式构建，只需将用例映射到您所用方法中最接近的层级（Epic 或 Feature），并将切片（Slice）映射为一组用户故事即可。

（1）制作一览表——不是按页面，而是按目的统计
 所需材料为从现有规格文档或现行系统中取得的页面一览、报表一览以及接口一览。请从“为谁、出于何种目的而设”这一视角对它们进行整理。
 以账单业务为例，可得出如下表格。

 从表格可以注意到两点。首先，发票取消页面并无独立目的，它只是“发行发票”这一大目的下的一个处理环节，在用例中应作为替代流程（取消已发行）纳入。其次，发票一览页面由会计担当和销售担当出于不同目的使用，因此会跨越两个用例。对于手动启动的批处理等从界面上难以看出的内容，则需要通过访谈补充。
 之所以不是按页面而是按目的进行统计，是因为业务能否正常运行取决于这些目的集合是否覆盖了业务需求。信息虽可按现行页面来收集，但真正要实现的并非仅仅是重现那些页面。在新系统中，从零重新设计页面并不罕见，页面数量和排布都可能变化。而不变的，是谁为了什么目的使用它——即这些目的本身。
 将上述获得的5项用例按与参与者的关系绘制到一张图上便是用例图（如前文图1所示）。这样可以从高抽象层次俯瞰谁在为何目的使用系统。若对每一业务领域都执行相同操作，即可得到整个项目的用例一览表。该一览即为整体概貌的骨架。为了作为估算依据，需要对所有移行目标的用例完成接下来的步骤（2）和（3）。

（2）为每个用例绘制一张大纲——明确当前已掌握的范围
 接下来，为每个移行目标用例分别绘制一张大纲。将基本流程以条目形式列出，并将主要的替代流程按照当前所了解的情况一并列出。只需列出条目，无需深入到界面元素或处理逻辑的细节。以“发行发票”为例，大纲如下。

用例：发行发票
参与者：会计担当　目的：对已结算交易发行发票并发送
基本流程：1. 列出已结算交易 → 2. 选择收款方 → 3. 确认账单内容 → 4. 发行发票 → 5. 发送
替代流程：A1 将多笔交易合并为一张／A2 在月初批量发行／A3 取消已发行的发票／A4 收款方的信用被暂停／A5 发送对象未注册

    图2：用例大纲——基本流程与替代流程

 这张大纲图就是系统为达成该目的而如何使用的整体。A1～A5是目前已知的替代流程。这张图的价值在于，其不仅展示了可能存在尚未发现的流程，还能指出它们的位置，即在“A5之后”。通过用例，可以在同一张图上同时标注已知范围与未知范围。整体感并非来源于对所有内容的完全掌握，而是要知道未知部分的位置。《Use-Case 3.0》也指出，要把握用例的规模与复杂度，就需要这种程度的大纲。对于判断为范围外的用例，只需在一览表中保留其名称即可。

（3）确定最小集合——划定业务不中断的界限
 只要基本流程可用，业务就不会中断。但在替代流程中也有一些若被剔除就会导致业务中断的流程。以“发行发票”为例，A2（在月初批量发行）若在月初的开票业务无法通过手工完成的情况下，就是必需的。A4（信用停止）同样如果信用管理由法规或内部规章规定，则无法剔除。与财务部门讨论后，例如可决定“基本流程+A2+A4”。
 这个“基本流程+必需的替代流程”即构成每个用例的最小集合，也是其验收条件。剩余的 A1、A3、A5 则通过后续所述的“深度”进行调整。如果不与业务部门共同定义最小集合，就会出现“明明说业务能运行却无法运行”的问题。最小集合也需在估算之前，为每个移行目标用例予以确定。

（4）划分切片——以冲刺为单位交付
 从这一步起，仅对将在某次冲刺开始开发的用例进行操作。开发单元为从大纲中划分出的切片——即沿着用例的起点至终点路径，按测试用例切分的一个或多个单元——其规模应能在一个冲刺内完成验证。以“发行发票”为例，首个切片为“对一笔正常交易按基本流程发行发票”——测试用例从已结算交易到生成发票PDF。接着是“A2 在月初批量发行”，然后是“A4和A5 无法发行时的处理”作为一个切片，依次从最小集合开始进行划分。A1和A3可继续留在大纲图上，当需要提高深度时再行划分。
 如果团队使用用户故事，则可将切片拆分为若干故事并纳入冲刺（例如首个切片可拆分为“显示列表”“选择收款方”等）。切片即作为该冲刺的目标。

            图3：

三层粒度——如何定义“一个单元”
 通过上述四个步骤，粒度可分为三层：

• 业务领域：如“账单业务”“库存管理”等大分类
• 用例（相当于发包方的“功能”）：参与者与目的的组合。列入一览表，作为整体概貌达成共识的估算单位
• 切片（相当于冲刺目标）：列入待办列表的单位。若团队使用用户故事，则可将切片拆分为数个故事来实施

             图4：

 以上就是第3回中搁置的“如何定义一个单元”问题的答案。无法掌握“全部”仅指的是切片这一粒度；而在用例（含流程）这一粒度上，可从现物中获取全部信息。此外，这也意味着，可以页面为起点展开讨论，使发包方能够以其熟悉的粒度来探讨整体概貌。至于“那些当时无法掌握的部分”，则留待切片以下去处理。换言之，“敏捷方法不事先确定所有功能”，在更改类项目中，到底只是“不在切片粒度上事先确定”。在一览表和最小集合层面，由于现物有限，即使将其视为确定范围并纳入繁重手续，也能遵守。而深度与切片，则留在该层之内，无需手续即可调整，也不必将其明文写入约定条款中（这也是第3回划定的分界线）。
 用例一览就如同一张地图。可从对业务影响最大的部分开始对现物进行验证，并将发现的新流程路径作为替代流程添加进去，这样地图就不断完善。

承诺什么、调整什么
 区分粒度后，可将承诺和调整分别分配到不同层级。在合同中对“全部”的承诺以用例粒度来达成——将所有用例列入一览表，对于被判断为需要移行的用例，须至少完成到最小集合。调整的“阀门”则不是用例数量，而是各用例的验证深度——是仅到最小集合（L1），还是到主要替代流程（L2），或到已识别的全部流程（L3）。切片的更换和优先级调整由产品负责人（PO）与开发团队在日常中进行，无需纳入审批流程（但需保留记录）。至于以用例为单位的取舍（如对无使用记录的用例判断为“不移行”并剔除等），则作为已确定范围的修改，由发包方显式决策。若事先明确谁在何种粒度上做决策，就能减少“擅自变更”和“明明说要做完所有却没做完”等问题。将验证完成的清单以“用例×深度”的表格形式呈现，发包方也能直观了解进度和剩余风险。

             图5：

 当降低验证深度，也就是剔除最小集合之外的替代流程时，变化的是业务能以“多轻松、在多广泛的场景下”继续运行。被剔除的部分则需通过业务流程（手工）来承担，相应的负担转移到业务部门，因此在决定剔除时，需要与业务部门一起对替代流程的执行方式达成一致。回到第3回提出的“规范有三种”话题，剔除替代流程意味着有意识地将“由人工执行的部分”显性化。目前大多数由人工执行的业务流程，往往是上次更改时被某人默默剔除的替代流程的痕迹，而本次的不同之处在于，我们将留下决策记录后进行剔除。

提交审批的估算——数量×规模
 在提交审批时，在用例中所需记录的内容是步骤（1）〜（3）所产出的要素——参与者与目的的一句话描述、基本流程和主要替代流程的条目列表，以及最小集合——并可附上主要输入输出和联动方，已足够。那些在瀑布模型下通常于基本设计阶段确定的细节，如页面字段定义、处理逻辑、例外情况的全列表等，则留待替代流程的发现与验证过程中补全。
 估算的数量模型为数量×规模。数量即一览表中的条目数，若附上“用例×页面”对应表，还可替换为页面一览。规模指各用例的相对大小，不以页面字段数度量，而以挂载在其下的替代流程条数即“块”的厚度为基准——例如“发行发票”很厚，“维护负责人主数据”则较薄——可用点数表示（S＝1、M＝3、L＝8等）。再结合深度的初始设定（L1〜L3），若大多数保持在L1，总量会较小；若多数升至L3，总量则较大。优先度和深度的初始值可以依据现行系统的使用实绩（使用次数和使用部门数）来确定。
 在外观上，此方式与瀑布模型的“功能一览×规模”估算类似，因此可直接纳入审批表格。然而，到此为止的仍是量度，而非工时或金额。将量度换算为时间和金额，则需依赖团队的实际测量，相关程序将在下次讨论。

需要事先确定的问题
 最小集合要书写到何种细节程度？深度的变更流程如何处理？那些即便经过验证仍残留的风险由谁来承担？以何种方式替代纸质文档作为验收依据？此后各组织和项目会给出不同的答案，本文不做统一规定。关键在于，大家能在同一张桌子上开始讨论这些问题。无论是准备提交审批的估算，还是事先确定无需审批即可调整的范围，都不属于教科书式的 Scrum，而是在现有公司流程基础上重新打造的一套方式。

注意——用例在何时会退化为“纸质文档”
 需要警惕的是那种“超出大纲范围，在开发前将所有用例描述全部写入”的诱惑。如果这样做，就会回到第3回提到的结构：只有纸面文档取代了对‘全部’的掌握。当用例是作为纸质文档还是作为探索工具，并不取决于其格式，而在于何时、写到什么程度这个决策本身。

 无论是开发标准、合同模板，还是敏捷教科书，都以“功能”一词来概括问题。只要粒度差异隐藏在这样的用词背后，双方就会觉得对方违背了承诺，而这种感受又会跨越世代不断传承。
 本文提出的三层粒度并非“解”，而是一种重新启动陷入僵局对话的工具。将“无法确定所有功能”这一结论，转换为“在哪个粒度上划定边界”这种具体问题。无论是“敏捷就用故事”还是“我们是功能拆分，无法做敏捷”，都是将工具与流程混淆后导致的思考停止。应当不再使用标准化的概念，而是以实际项目的粒度来交流。如此一来，停滞了30年的对话模式或许能被改变。
 剩下要解决的，是如何在切片粒度上发现未知并将其转化为已验证项，以及为此发现预留怎样的预算并进行合理分配。将于下次以另一个问题的形式予以探讨。

 笔者虽然迄今在各种媒体上撰写过文章，但从未如本系列三连作那般深刻地感受到“自己此刻双脚踩在地雷上”。下次我们将深入探讨在这颗地雷上“把什么作为规范进行验证”，并使这三项工作顺利落地。

下次：“在无法信赖文档的现行系统中，将什么作为‘规范’进行验证？”