敏捷圈子里有个很讽刺的现象越是强调拥抱变化的团队越容易把建模当成一件只能在项目启动时做的事越是把迭代跑得飞快的团队越容易在需求澄清时靠嘴硬撑。我这些年服务过好几个采用Scrum的团队见过 Sprint 计划会上大家拿着一堆口头需求就开始排期也见过另一拨人花了两周画出一套完整用例图、类图、时序图结果开发的同事根本不看。问题不在于“要不要建模”而在于我们把建模放错了位置、用错了方式。“在Scrum中实施敏捷建模”这件事本质上不是让你在跑得很快的迭代里再插入一道沉重的文档工序而是要把建模变成一种轻量、持续、协作式的思考工具让它和已有的 Sprint 节奏自然咬合。这篇文章我会用实际带团队的经验讲清楚为什么Scrum团队需要建模、怎样把建模嵌进待办梳理和冲刺计划的时间窗口、选哪些建模手法不会拖慢交付以及我踩过的一些坑和修复方法。想找一套“画图仪式”的人可以不用往下看了这里不提供那种东西如果你的团队正处于“看不见产品全貌每次迭代都在补昨天的窟窿”的状态这篇应该对你有用。1. 为什么Scrum团队总在“不做建模”和“过度建模”之间反复横跳1.1 当年我们在Sprint里画了一堆没人看的图我第一次在Scrum团队里尝试正儿八经建模是在给某个后台管理系统做重构的时候。产品经理刚梳理完三个史诗故事技术负责人就觉得信息不够拉着架构师闭关三天画了完整的模块依赖图、数据库关系图、接口时序图。里面确实有很多真知灼见但问题是这些图是在一个和业务隔离的会议室里画出来的。等 Sprint 计划会开始开发同事们看着那套图眼神是茫然的。图上的“订单域”“支付域”和真实代码库里的包结构对不上时序图画到了第三层可我们第一个Sprint只打算做用户登录改造。结果就是建模产物成了“墙纸”。没人删除它也没人更新它它挂在Wiki里唯一的读者是下个季度来审计的架构组。那一次给我的教训非常直接建模若不能跟开发者的日常动作产生连接它就是纯成本而不是资产。Scrum的迭代节奏天然排斥重型前置设计这没有错。但很多团队走过头了直接退回到“零设计”状态。另一种常见景象是Daily Standup上大家用嘴巴画图“A服务调B服务的接口然后C来做补偿”所有人点头但每个人脑中的“B服务”长得都不一样。这种口头建模的信息衰减比画错一张图严重得多。1.2 不建模的真正代价口头同步的信息黑洞不画图不代表没有模型。每个开发脑子里其实都有一份关于系统的理解模型关键区别在于这份模型是私有的还是共享的。当模型只存在于个人脑子里它就无法被检验、无法被挑战、无法被演进。举个例子。某个团队要做一个多方审批流业务方说“某些条件下审批人可以跳过”。产品经理在待办项里写了一句话“如果当前节点没有审批人则自动通过”。开发A的理解是“只能跳过不生成待办”开发B的理解是“系统自动找上级领导代为审批”。两人各自开发联调时才暴露出理解分歧一个迭代直接报废。如果待办梳理阶段用一张简单的流程图或者状态表把条件分支画出来这个坑90%能避免。所以我后来在团队里一直强调一件事Scrum里的模型不是设计文档而是共享认知的容器。它的作用是让参与各方把脑中默认的、没说出来的假设放到桌面上来。围绕这一点你再去看敏捷建模的各种原则才说得通。1.3 不是没有模型而是模型活在角落里还有一种情况让团队觉得自己“不需要建模”后端接口写得很规范数据库表结构也清晰API文档生成得漂漂亮亮。于是大家觉得这些就是模型了。但只要你问三个问题——“整个业务链路里哪个环节最容易丢数据”“这个模块将来的两个可能扩展方向是什么”“如果并发翻五倍哪里会先崩”——大多数团队回答不上来。接口文档解决的是契约问题解决不了结构问题。这些系统不是没有模型而是模型藏在代码堆叠的“角落里”某位资深开发的笔记里、某个旧项目的架构图里、某次技术分享的PPT里。它们存在但是零散、过期、没有人拥有。Scrum要求团队自组织试想一个连结构认知都无法共享的团队拿什么自组织这也是为什么我会主张敏捷建模的核心目标是把模型从角落请回团队协作的中心但用完全不同于传统文档的方式去维护它。2. 敏捷建模的底层逻辑从“完整草图”转向“可演化的地图”2.1 增量建模模型是“活”的不是交付物传统建模被诟病的最大原因是它试图在代码存在之前就把系统画完。但软件开发的历史已经反复证明人类没法对一个复杂系统做一次性完整的精确预测。敏捷建模换了个思路——不追求“完整”追求“当前够用且方向正确”。英国有一句航海谚语“计划赶不上变化但计划让你在变化时知道自己在哪里。”模型的作用也是一样。它不承担“一步到位”的责任而是承担“我们当前对系统的理解是什么”的责任。这个理解每过一个Sprint都应该被修正。增量建模在操作上有个具体做法只对当前正在做和下一个迭代马上要做的东西建立精细模型离得远的功能只保留抽象层面的草图。比如我们在规划一个交易系统时第一个Sprint只需要把“下单”这条链路的对象关系图细化到类级别至于“对账”“报表”只画一个边界框写上“未来接入”就够了。等迭代真的推进到那里再深入画细。这套做法最大的好处是模型永远在需求的射程内不会出现画了一堆图最后没人用的尴尬。但要注意增量建模不等于不建模对系统级的关键约束比如技术选型、安全边界、数据一致性策略还是要在早期达成一致框架。框架图可以粗但约束不能含糊。2.2 简单建模原则够用就好怎么判断“够用”敏捷建模里有条核心价值叫“简单建模”翻译成大白话就是用最小成本画出刚好能推动团队前进的图。问题是很多人都困惑什么算“刚好”我给自己定了一个判断标准叫“问题触发原则”如果团队能用文字白板在三分钟内把需求对齐就不画正式图如果讨论中发现某个概念反复解释不清或者不同人对同一概念给出不同解释就在白板上画一个图把讨论靶子立起来。等图完成了它的使命——推进了理解、消除了分歧、指导了编码——它就算完成了任务。剩下的事不是“维护这幅图”而是决定它要不要成为长期资产。这个“够用就好”的原则对应到Scrum里意味着模型图和用户故事的关系应当是故事是承诺模型是背景。Sprint Backlog里的每个故事都应该能找到对应的模型片段没有模型片段支撑的故事说明我们对它的理解还停留在表面进入Sprint有风险。我会在下一节讲怎么把这个判断嵌入流程。2.3 团队所有权让写代码的人拥有模型敏捷建模能落地的另一个关键是模型的所有权属于整个团队而不是属于某个“架构师”或“设计组”。我在一些公司看到过很别扭的流程设计团队画一套目标架构图交付代码的团队按自己对架构的理解实现。结果两个团队各说各话互相觉得对方不行。正确姿势应该是谁写代码谁就必须参与建模谁参与建模谁就必须写代码。哪怕你是这个系统的技术负责人也不应该一个人在工具里画完图丢给团队而是要组织大家一起在白板上拼图。这样做不仅是为了“认知对齐”这个虚词更是因为只有动手实现的人才分得清哪些抽象是合理的、哪些会变成代码里的补丁。在实际操作上我推行过“模型守护者”的做法每个业务模块由一位开发同事兼任模型守护者负责在代码重构或需求变更时同步更新对应的模型。这个人不一定是架构师但一定是最熟悉该模块的人。模型守护者让“模型要被更新”这件反人性的事有了责任人。3. 把建模动作无缝嵌入Scrum节奏四个时间窗口3.1 Backlog Refinement把产品待办项“翻译”成可讨论的模型很多团队的Backlog Refinement就是产品经理念需求、开发举手提问口头确认之后就散会。等到Sprint Planning时才发现故事拆分不下去——不知道接口边界在哪里。我的建议是在Refinement环节引入“一图一故事”的惯例。具体操作是当团队要从史诗故事中拆出故事时先在白板上画一张当前业务的轻量上下文图。这张图不需要规范可以就是几个方块和连线重点是标出这样几个元素涉及的参与角色、核心业务对象、它和现有模块的依赖关系。画完这张图再去看手册里列出的故事列表哪些能拆、哪些拆不动一目了然。我这里有一个实际经验Refinement画模型的时间最好控制在二十分钟左右超过这个时间说明故事太大了。有一次某团队为一个“客户积分兑换”的史诗整整画了四十分钟画到后来已经开始设计数据库索引所有人都很激动。但我当场叫停因为这说明这个史诗的复杂度远超一个Refinement节点能处理的量需要把它拆成多次细化而不是一口气把所有细节都敲定。模型细化程度必须和故事进入Sprint的时间窗口匹配。3.2 Sprint Planning给模型腾出“黄金一小时”Sprint Planning是Scrum的四个正式事件中最容易失控的一个期。团队要在几分钟内做出对接下来一到两周交付的承诺压力和焦虑是必然的。在承诺之前我们应该确保每个人对要做的东西有共同理解这时候建模就是最好的“定心丸”。我习惯在Sprint Planning的“做什么”阶段结束后专门留出最多一小时的时间做“模型走查”。做法很简单把产品和开发最关心的三四个场景用我们已有的模型图走一遍。从一个用户动作开始顺着系统边界、核心对象、依赖服务一路走到底。走查中发现的偏差要么是模型该更新的信号要么是故事描述该补充的信号。这个走查不是走形式。我们曾经在一次规划中走查一个“退款”场景发现现有的订单模型里退款单和原订单是多对一关系但实际业务中同一笔订单可以发起多次部分退款模型设计根本考虑不到。如果不做走查这一轮计划里的故事就得全部推翻重新拆分那浪费的就是整个开发组两周的时间。走查还能顺便校准验收标准验收条件不是产品经理拍脑袋写的而是和模型行为一致的。3.3 Daily与实施过程中的“模型小修”模型不是只在计划阶段出现它应该在开发进行中持续被小修。我强调“小修”而不是“大改”。当开发过程中发现模型假设和现实不符正确的做法不是马上停下来改模型也不是无视它而是先在模型上做一个轻量标记比如画一个红圈、写一条备注然后继续按事实推进。等到当天或者次日的Daily Standup用两分钟同步一下“我发现模型这里写的是‘支付成功后回调通知’但实际支付网关可能要我们主动轮询我们是不是要调整这个故事范围”这种“小修文化”特别依赖心理安全感。如果团队成员觉得“发现模型错了”是自己的错他们就会偷偷绕过模型去写代码很快模型重新沦为僵尸文档。所以团队负责人要做的不是惩罚修正而是表扬修正。我在例会上经常说的一句话是“模型错了是正常的模型没被发现错才是危险的。”当每个人把模型当作活地图而不是圣旨它才能真正参与到日常开发决策中。3.4 Review与Retrospective让模型接受实战检验Sprint Review通常只演示功能很少专门讨论结构演进。但如果一个Sprint开发中出现了好几次“模型修正”这些修正信号不能白白流失。我会建议团队在Review的最后十分钟由一个模块负责人快速展示这个Sprint产出的模型变更。这个做法有几个好处第一让业务方看到系统结构正在为业务能力服务而不只是看到几个界面第二让跨团队成员看到接口和依赖的变化很多“为什么你的特性依赖我的模块”这类跨团队问题会在这个环节提前暴露第三给Retrospective积累素材。到了Retrospective关于建模有一个非常有价值的回顾题“这个Sprint里哪张图或者哪个模型帮我们减少了返工哪个模型的缺失让我们多走了弯路”让团队成员用投票选出最值得保留的模型实践和最该废除的模型负担。我在一个团队连续三个Sprint用这个问题结果他们自发砍掉了一张从来没更新过的系统全景图——因为每次都是手动改太痛苦他们决定用代码库目录结构来解决同样的问题。这种由团队自主驱动的调整远比我从外部强推有效得多。4. 从哪里开始画轻量建模手法的选择4.1 用户故事地图一张纸看清产品全貌在Scrum里最该被经常拿出来画的不是类图而是用户故事地图。它把用户旅程横着铺开把每个节点上的用户故事竖着排成优先级。这不只是产品规划工具它本身就是一种敏捷建模——它建模的是“用户在这个产品中的完整体验流”。我为什么偏爱故事地图因为Scrum的Sprint节奏容易让团队掉进“一棵棵树的细节”忘了“森林长什么样”。每个Sprint都很忙忙着拆故事、估点、开发、交付但很少有人会在冲刺过程中停下来问一句“我们做的这一堆功能是不是真的把用户的核心路径走通了”故事地图天然回答这个问题。在实操层面我建议每个季度至少做一次故事地图工作坊时长控制在三小时左右。把核心角色列出来然后把他们的主要活动从左到右展开再在每个活动下面贴上当前Backlog中的故事代表。当故事太多地图上放不下时这就是Ruthless Prioritization无情排序的上手时机哪些故事可以被剪掉哪些活动其实可以走手工流程。注意故事地图的价值在于“全体参与”和“便利贴运动”别把它变成产品经理一个人在工具里画的线上图。4.2 事件风暴对齐业务流程的高效工具如果一个业务领域的规则复杂、涉及多个部门协作我第一推荐的手法不是画类图或者流程图而是办一场Event Storming事件风暴。这是一种极限的协作建模方式业务人员和开发人员围在一面长墙前用橙色便利贴写“已经发生的事件”用蓝色便利贴写“触发命令”用黄色便利贴写“参与角色”通过这些便利贴拼出整个业务的时间线。事件风暴惊人的地方在于信息密度。曾经有一个金融领域的项目业务方一开始说“我们的流程很简答就是录入然后审核”。结果呢用事件风暴跑了一个下午墙上出现了七十多张橙色便利贴业务人员看到后自己都懵了“我们居然有这么多分支和边界情况平时根本没人统计过。”那一次我们不仅画清了流程还发现了两个已经线上运行了几年的隐藏风险。这种高信息量的产出是任何口头会议都给不了的。事件风暴不算轻量级建模——前期准备和组织成本不小——但它收益巨大尤其适合拿来启动一个全新的复杂领域模块。有人可能会觉得Scrum说“拥抱变化”花一个下午画这么多细节值得吗我的回答是恰恰因为Scrum迭代快才更需要用事件风暴这样的方式把领域知识快速榨干。一次爆发的付出可以避免之后五六个Sprint里反复被领域规则打脸。4.3 CRC卡片和上下文草图对付复杂领域对于中低复杂度的模块大动干戈做事件风暴有点“杀鸡用牛刀”但又不能用一句话带过。这种情况下我很喜欢用CRC卡片Class-Responsibility-Collaborator类-职责-协作卡。每张卡片就是一个主要领域对象上面写它的名字、核心职责、需要协作的对象。三五个开发围在桌边把系统对象像扑克牌一样摆开用口头模拟一遍业务流程很快就能发现职责分配不合理的地方。CRC卡片的好处是足够轻没有任何学习成本白纸裁几张小卡片就能开始。我在一个物联网项目里就用它做过一次“设备上线与OTA升级”的建模原本要设计四个类才能解决的问题五张卡片一摆发现其中两个类其实是同一个东西在不同阶段的表现直接合并简化了整个模块的结构。当CRC卡片发现对象之间的协作关系复杂到难以理清时就该画上下文草图Context Sketch了。这种图不需要严格的建模语法就用几个大方块表示模块或子域箭头表示依赖。重点是标出关键依赖的方向——谁依赖谁、谁不该依赖谁。很多系统腐化的前兆都是从“不该依赖的箭头跨过去了”开始的。5. 工具选型与模型归档白板、Wiki还是PlantUML5.1 白板依然是最敏捷的“工具”我见过团队花很多功夫选建模工具从高端架构设计软件到在线协同白板每个工具都有自己的生态位。但我想先给一个反直觉的结论在Scrum的日常活动中实体白板或者办公室的一面玻璃墙依然是最敏捷的建模工具。原因很简单敏捷建模的首要目标是建立共享认知而非沉淀精美文档。白板允许所有人同时动手修改零学习成本即时反馈。建模过程中那些涂涂改改、随手画的箭头、画到一半又擦掉重来的痕迹都是思考过程的外化这是事后重画的美观图完全无法替代的。所以我通常建议每个Sprint室至少保留一整面可书写的墙面作为“模型墙”。墙上放四样东西当前迭代的故事地图骨架、关键约束清单、正在争议的“问题图”比如箭头画不清楚的依赖关系、以及下一个迭代要讨论的“预览草图”。这面墙不需要保持整洁它需要的是时刻“活着”。如果团队是分布式的退而求其次用在线白板替代但要把“多人同时编辑”和“过程可见”这两个特性留住别只是把一个人画好的图贴上去给大家看。5.2 模型存档的黄金标准源代码附近白板上的模型存在一个致命问题Sprint结束后它会被擦掉。所以在SCRUM里模型的归档问题不能靠“拍照上传Wiki”应付了事。拍照上传可以但需要在当天就完成而且要指定一个人干这个活儿。更重要的不是存在哪而是“怎么防腐化”模型一旦离开团队讨论现场就会迅速过期。我的经验是把需要长期存在的模型尽量以文本形式放到代码仓库里和源代码放在一起。可以用Mermaid、PlantUML或者简单的ASCII图来画只要能通过代码提交记录追踪变更它就有机会和这些模块同步更新。这也解决了上一节“模型守护者”的执行问题那个人只需要在合并代码时顺手更新模型文件。关于用哪种语法我推荐遵循一个原则团队成员能直接编辑的优先。如果你选了一个只能在专业IDE里打开的格式那维护门槛就把大多数开发挡在门外了。反之一个能直接在代码审查Diff里看到文本变化的PlantUML文件虽然画得丑但会被开发者当作代码的一部分来对待。丑一点没关系活着就比漂亮但冷冰冰的照片有价值。5.3 工具的统一与克制别让建模变成第二套工作流建模工具最大的坑是它会成长为一套独立的工作流——有自己的生命周期、组织结构和考核指标。一旦建模工具变得比代码仓库还复杂团队就会在代码之外维护一个“影子系统”。这跟Scrum强调的“Working Software over Comprehensive Documentation”价值是直接冲突的。我见过一个团队建模工具用得很热闹里面存了两百多张图但开发时完全不管。原因很简单没有人把工具图和代码关系对应起来更新哪张图、什么时候更新、谁负责全是模糊的。这样的建模资产不仅无用还会制造误导。所以我的建议是整个团队只保留一到两个建模工具能力。白板用于日常协作代码仓库的文本图用于存档。如果你们觉得专业建模工具好看又好用前提是工具里的模型能通过代码生成或导入导出和代码建立绑定关系否则别碰。克制是对敏捷建模最好的保护。有时候我们混淆了问题以为缺的是工具其实是缺一个能让模型和代码同步演进的机制。6. 我踩过的坑模型回退、僵尸文档与“建模天团”6.1 坑一Sprint Planning变成画图大赛一开始推行建模时我犯过一个影响很大的错误在Sprint Planning里给建模留了太多时间而且没有任何边界。结果团队兴致勃勃地讨论技术方案画了一张又一张类图把本来计划两个Sprint做完的模块在计划会上就把未来四个Sprint的细节全部设计了一遍。计划会开了八个小时人仰马翻。事后反思问题不是“建模过度”而是我对建模的触发时机没有把关。正确的方式应该在Sprint计划会上先确定故事范围再针对这些故事的实现细节建模。未来Sprint的事情用一句话带过就好——如果真的要现在讨论说明这个故事该拆分了。现在我会在计划会前先在团队约法三章建模只服务于当前Sprint目标的明确化不进细节迷宫如果两个人在一张图上花超过二十分钟就把争议记到“问题图”上带出计划会。6.2 坑二模型与代码分叉谁都不信谁还有一个更隐蔽的坑模型在一定时间段内没有及时更新逐渐和代码脱节比没有模型更糟糕。当模型和代码不一致时团队内部会出现严重的信任崩坏——新伙伴认真看模型结果代码逻辑跟模型对不上浪费半天时间资深同事从此断言“模型就是纸老虎”再也不看模型。这个坑一旦踩上就会进入负循环模型被忽略没人更新模型更新越来越少更加被忽略。要打破这个循环靠的不是下命令喊口号而是要有个“让模型重新有用”的引入点。我的修复方法是提交一个为了“让模型对齐代码”的技术债故事把它放回Sprint Backlog。在这个故事里团队不用做全新设计只需要把代码的真实结构抽出来反哺更新已有模型图。同时在前面说的模型守护者机制落地前先别指望这种事能持续发生。6.3 坑三建模小组隔离在交付链之外再讲一个组织层面的坑。某次我在另一个团队做敏捷教练时发现他们有个“架构建模小组”专门负责画目标架构图然后交给各开发小组落地。这个小组工作努力图表精美但开发团队的Sprint冲刺几乎不受这些图影响大家只按照Backlog条目埋头干活。这就是典型的“建模天团”问题模型虽然很完美但因为不参与交付、不对模型的实际可行性负责模型和交付之间必然会出现鸿沟。我推动做了一件事取消“架构建模小组”这个独立角色把建模任务分散到各个特性团队里让开发人员自己画自己模块的模型技术负责人变成“建模协调者”而非“建模独裁者”。第一个月很痛苦很多人不习惯在椅子前站起来画图但三个月后模型更新频率显著提升因为每个开发都会为了自己的便利去修改自己拥有的模型。组织方式的调整往往比流程微调有效得多。6.4 排查与修复的思路链如果你们的Scrum团队也已经出现了“建模无效”的现象我建议不要急着上方法论先按这条思路排查一遍第一步检查模型的所有权。模型有没有明确的负责人如果每张图都没有责任人那它必然走向消亡。第二步检查模型更新的触发点。当代码改变、需求改变时有没有任何机制让模型被同步修改如果没有就在Definition of Done里加一条“涉及结构变化的故事完成后必须同步修改对应的模型片段。”第三步检查模型的消费场景。团队在哪些环节会真正阅读模型如果只在审查时看这个模型基本就是摆设。要把模型嵌入到Refinement、Planning和Review这些日常事件中创造真实的使用场景。第四步检查模型的语言和形式。模型是不是复杂到没人愿意碰如果是换成更简单的表达方式——一句话也行一个白板照片也行关键是团队愿意去维护。这四步走完几乎能覆盖90%的建模失效场景。剩下那10%的问题通常出在业务和开发的组织隔离上那已经不是流程能解决的问题要回到自组织和跨职能团队建设上慢慢磨。最后再分享一条我个人的体会敏捷建模的成败不在建模的那一两个瞬间而在模型被使用和被更新的日常。只要你发现一个Sprint里没有任何模型产物被改动过这个团队基本可以判定为“假敏捷建模”——画图只是为了仪式感不是为了决策。反过来如果每个Sprint都有那么两三处模型因为真实需求的变化而被修正说明你的团队已经把建模融进了Scrum的脉搏里。做到这一点Scrum和敏捷建模就不再是两个需要“结合”的事物而是同一件事——用结构性的思考让交付更轻盈。