我见过不少团队提“开发模型”四个字人人能说出瀑布、敏捷、Scrum、看板但真到项目启动会上面对“这次我们怎么组织开发”这个问题往往答不上来。最后多半是一句“我们一直走敏捷”可实际连Sprint backlog都没建过需求还是产品经理口头传。这不是态度问题是大家把开发模型当成了考试术语没当成“控制风险的组织方式”。开发模型不是一张纸上的流程图它决定了需求怎么拆、质量怎么保、交付怎么排是整个工程活动的骨架。这篇总结想把这堆模型重新梳理一遍不背定义就看每个模型在什么场景下真能站住脚同时会延伸到当下比较热门的“结合自建业务模型的智能体简易开发”看看智能体应用兴起之后传统开发模型又发生了哪些变形。1. 先搞清楚开发模型到底在解决什么问题1.1 模型不是流程是风险应对策略很多人把开发模型理解为“工作步骤”比如瀑布是先写需求、再设计、再编码、再测试。这个理解不算错但太浅了。真正的问题是一个软件项目的风险来自哪里不同模型为什么会选择不同的步骤顺序任何软件项目都面对三重不确定性需求不确定性用户说不太清楚自己到底要什么技术不确定性方案能不能落地、性能能不能达标开工前往往只是估计交付不确定性整个项目到底多久能做完、资源够不够用。不同开发模型的本质就是对这三重不确定性采取不同比例的应对策略。瀑布模型的隐含假设是需求和技术在开工前都能确定所以线性推进步骤之间是严格的上下游关系。迭代和螺旋模型承认不确定性存在所以每一轮都做风险分析先攻核心风险再逐步展开。敏捷则干脆把不确定性当成默认状态用短周期反馈让方向偏差尽早暴露。你可以把开发模型理解成一个团队“赌”的方式赌需求不会变还是赌自己有能力快速纠偏。装修房子是个很适合类比开发模型的事。全包模式像瀑布总价、工期、效果图都提前定死中间想改要办各种变更手续半包模式像V模型关键节点验收水电、防水这些隐蔽工程必须阶段检查清包模式像敏捷只定目标和预算上限过程中自己参与决策材料买错了随时换。没有哪种绝对好只看你的需求明不明确、你对施工方的信任度有多高。1.2 任何模型都要回答三个基本变量选模型之前先回答三个问题范围是固定的还是流动的质量靠什么机制保证速度的优先级如何设定。范围固定意味着需求被冻结后续变更必须走正式变更流程瀑布、V模型就是这么运作的。范围流动意味着需求永远在调整敏捷和看板都接受这一点只是调整频率和机制不同。质量机制上瀑布让测试集中在开发完成后V模型让测试活动从需求和设计阶段就开始定义敏捷把测试嵌入到每个迭代内部。速度优先级上有的项目想“早日拿到一个可用最小集”有的项目明确“宁可晚交付必须一次到位”。这三组选择组合起来基本就勾勒出一个项目适合什么模型。比如一个监管报送类项目范围由国家文件定义质量要求有明确测试标准那用瀑布或V模型完全合理。一个面向内部员工的效率工具需求每天都在变团队希望月底就能看到效果那再不敏捷就是跟自己过不去。开发模型是围绕这些约束做的组织设计不是拍脑袋选个名字。1.3 真实项目里模型往往是混用的我强调一点实际项目中几乎没有哪个团队是100%纯瀑布或100%纯Scrum。一个企业级系统核心业务链路可能走敏捷迭代数据迁移和报表模块可能是典型的瀑布交付涉及安全合规的部分要按V模型做阶段验收。这不是不专业而是对“风险分布不同”的正确映射。打个比方一个电商平台商品浏览页面的需求变化极快适合小步快跑但支付清算模块哪怕只修一个字段映射错误都可能引发资损必须有严格的评审和验证流程。同一个系统、同一个团队面对不同风险等级的子模块采用不同的组织方式这才是做工程该有的态度。后面的章节会按这个思路逐个拆解帮你建立“按风险选模型”的判断框架。2. 经典模型不是过时是边界清晰2.1 瀑布模型需求冻结不是缺点是前提瀑布模型被吐槽了几十年似乎已经成了“落后”的代名词。但真做过传统企业项目的人心里都清楚很多场合你根本绕不开瀑布。它的核心逻辑是一句话需求、设计、开发、测试按阶段推进每个阶段有明确交付物和评审门槛通过之后才进入下一阶段。这种模型最大的优势是可控性和确定性。范围、成本、工期的估算相对容易合同中可以写明交付物和验收标准。对甲方来说瀑布有安全感对乙方来说瀑布能减少无限修改。现实中适合瀑布的项目有一个共同特征需求方权威且需求源稳定。政府项目、军工项目、硬件嵌入式项目、有严格合同约束的外包项目几乎都天然走瀑布。批评瀑布的声音集中在“需求测不准”上。但问题是如果项目一开始就明确“需求就是测不准”那本来就不该选瀑布这是选型错误不是模型本身有罪。用瀑布的前提是需求冻结需求冻结本身不是缺点而是对“需求已充分收敛”这一事实的承认。我见过不少失败案例本质上是“用瀑布的流程配需求随时变更的现实”最后流程被架空质量也失控。2.2 V模型测试左移的思想源头V模型比瀑布多了个关键动作左侧每个开发阶段都对应右侧一个测试层级。需求分析对应验收测试概要设计对应系统测试详细设计对应集成测试编码对应单元测试。这样一来测试不是开发完成后的“尾部动作”而是从项目启动就同步定义的验证活动。这样设计的价值在安全攸关系统里体现得最充分。医疗器械、银行核心账务、汽车电子控制系统这些领域一旦出问题代价不是用户多等几天而是安全事故和资损事故。V模型强制你在写需求文档时就明确“怎么证明我们做对了”在设计评审时就想清楚“集成点上的风险是什么”质量是设计出来的不是测出来的。用V模型最大的经验是右侧的测试设计必须和左侧的开发文档一起评审。很多团队画了一个V字但右侧的测试用例是等到编码完成之后才补这等于把V模型硬生生掰回了瀑布测试左移变成了“测试后补”。真正的V模型需求评审会上就要有测试负责人参与用例设计得比编码早评审比编码早这样研发人员写代码时心里才有一把尺子。2.3 螺旋模型与RUP风险驱动的前辈螺旋模型是很多人容易忽略的一个但它对现代迭代开发的影响非常大。它的基本流程是四步循环确定目标、识别风险、开发验证、规划下一步。每一轮循环都先做风险分析再决定这一轮要投入多少精力、交付什么内容。这种“风险驱动”的思路比单纯的时间驱动要高级。RUP把螺旋模型的思想产品化定义了初始、细化、构建、移交四个阶段每个阶段内部又可以有多次迭代。你可能觉得RUP太重但它其实为后来的敏捷提供了很多养分迭代开发、以架构为核心、用例驱动这些概念在RUP里都已经成型了。我个人的看法是如果项目体量大、复杂度高、牵涉多个团队直接上纯Scrum往往太理想化反而RUP这种“阶段迭代”的混合体更好用。比如一个数字化转型项目先做初始和细化阶段搞清楚业务全景和关键架构约束再进入构建阶段按迭代交付。现在很多团队嘴上说敏捷实际干的还是RUP的活只不过没意识到而已。2.4 经典模型横向对比模型核心控制点典型适用场景主要风险瀑布模型阶段评审与文档交付合同项目、硬件固件、需求稳定需求变化时调整成本极高V模型测试与开发的阶段对应医疗、银行、车控等高合规领域流程繁琐交付周期长螺旋模型每轮风险分析与迭代规划高风险创新项目、大型系统对PM的风险分析能力要求高RUP四阶段迭代架构演进复杂企业级项目、多团队协作过程裁剪不当会变重这几种经典模型到今天都没有消失只是因为它们大多诞生于“需求确定、交付周期长”的年代今天的互联网和AI应用场景让它们看起来有些笨重。但如果你做的是To B、To G、嵌入式或者合规敏感的项目这些模型依旧是正确选择。3. 敏捷和看板把不确定性当成默认状态3.1 敏捷的核心是反馈闭环不是短周期很多人以为敏捷就是“两周一个版本”这是最常见也最危险的误解。敏捷的真正内核是反馈闭环每个迭代都包含完整的需求、设计、开发、测试、评审、复盘然后带着上一轮的认知进入下一轮。短周期不是目的短周期提供的高频反馈才是目的。为什么敏捷对不确定性的耐受度更高因为瀑布在需求确定后才进入设计遇到需求变化会被流程惯性推着走敏捷是在每个迭代里重新确认优先级需求变化不仅不被排斥还会被当成信息来源。产品经理和真实用户的每一次试用、每一个反馈都会进入下一个迭代的Backlog实现“方向纠偏”和“价值验证”。敏捷落地有一个关键前提必须能形成“可交付的增量”。如果团队做的东西在两周内无法形成一个可运行、可体验的版本那敏捷就跑不起来。我见过一个做嵌入式底层的团队强行切Scrum两周过去了增量连编译环境都还没稳定Sprint评审会拿什么给用户看所以敏捷之前先问自己这个项目能不能被切成小步能不能每步都产出可感知的价值。3.2 Scrum落地最容易翻车的三件事Scrum是敏捷最主流的实施框架但真正严格执行到位的团队很少。结合我带团队的经验最常见的翻车点有三个。第一用户故事没有拆细。一个Story动辄要开发两周以上进了Sprint根本没法完成最后要么延期要么删功能时间盒形同虚设。好的用户故事应该满足INVEST原则尤其是“小”一个Story最好不要超过两三天工作量完不成就要继续拆。第二评审会变成了“演示会汇报会”。评审的本质是让干系人真实试用并给出反馈不是研发团队对着PPT演示功能。如果产品经理包揽所有试用动作开发人员对真实用户反应一无所知那敏捷的反馈闭环就被切断了。第三复盘会没有输出改进项。很多团队的Retrospective开成吐槽大会大家把问题说了一遍会散了问题还在。正确的做法是每次只挑一到两个最痛的改进点落到下个Sprint的待办里并指定负责人跟踪闭环。一次改一点持续稳定改进比一次改革十项最后全落空强得多。3.3 看板约束在制品而不是约束时间看板不像Scrum那样用固定Sprint约束时间它约束的是在制品数量WIP。团队把任务列在业务流上每个环节待办、开发中、测试中、已发布设置同时处理任务的上限超过上限就先堵住源头。这个机制对两类场景特别适用一类是需求到达时间不确定的运营型团队比如技术支持、运维响应、质量改进另一类是开发中插入太多紧急事项、团队已经不堪重负的情况。看板让问题“可视化暴露”如果测试环节积压了十张卡说明瓶颈在测试不是开发不够快。大家每天站会站在看板前面讨论的是怎么让卡流动起来而不是谁的任务更多。Scrum和看板不是互斥的很多团队把两者结合用Scrum规划迭代用看板管理迭代内的流动。只要团队保持对WIP的纪律这套组合拳在研发场景里效果很好。核心原则就一条别同时开太多战线把事情一件一件做利落整体交付速度反而更快。维度Scrum看板节奏固定时间盒一般为1-4周迭代连续流动无固定周期核心约束迭代目标与故事范围在制品数量WIP变更策略迭代内尽量不引入新需求随时可拉新的任务但需有容量最佳场景新功能研发、版本交付运维、技术支持、需求持续输入4. DevOps把开发模型从“研发内部”推向“交付全链路”4.1 传统模型的盲区上线之后怎么办瀑布、敏捷、看板本质都聚焦在“开发”这个环节上线通常是终点。但云原生和微服务时代真正的风险往往出现在上线之后配置漂移导致环境不一致、灰度流量切错比例、数据库变更引发线上故障、回滚时发现版本不兼容。DevOps的出现把开发模型的边界从“开发管理”扩展为“交付全链路”代码提交、自动化测试、构建镜像、部署、配置变更、监控告警、日志分析全部串成一条流水线。传统模型讨论的是“怎么把功能做出来”DevOps讨论的是“怎么稳定快速地让功能生效并持续演进”。这一步扩展不是因为技术炫酷而是软件交付风险的重心转移了。单体应用一年发布两次人工运维完全能搞定微服务一天发布几十次每次都要手工操作必然出错。开发模型的粒度要变细前提是部署和发布动作必须自动化、可信赖否则小步快跑只会加速崩溃。4.2 CI/CD如何反过来影响研发节奏持续集成的意义不只是“跑自动化测试”它让每个提交都能被验证让“主干随时可发布”成为可能。这也倒逼团队简化分支策略GitFlow这类重分支模型适合低频发布时代主干开发TrunkBased短命特性分支更适合持续集成否则每次合并都在解决冲突CI再快也没意义。持续交付还改变了“完成”的定义。以前“功能完成”是代码写完了现在是“代码合入主干且通过自动化流水线随时可以部署”。只有这样的标准敏捷迭代的每轮增量才真正具备交付价值。否则就是每个Sprint都在Demo但真实环境永远跑着三个月前的版本。Feature Toggle功能开关在这里扮演了关键角色。它把“代码合入”和“功能上线”解耦功能代码可以随时合入主干但通过开关控制对用户可见性。这样团队可以频繁合代码、频繁部署避免大合并地狱同时让产品和运维决定什么时候真正“开闸放水”。这等于在开发模型里加了一层“发布与开发的解耦阀”。4.3 发布策略反过来影响迭代粒度DevOps不是只谈自动化流水线发布策略同样是模型的一部分。蓝绿发布准备两套完全一致的环境切换时流量整体切换风险集中在“切换的一瞬间”金丝雀发布则先把新版本给小比例用户使用监控指标稳定后逐步放大流量。这些发布策略直接决定了迭代能有多小。如果项目没有灰度能力每次上线都只能停服更新那功能再小发布成本也降不下来开发模型自然偏向“攒一批再发”的大版本模式。反过来如果发布了自动化灰度能力团队才能放心地做小步迭代、每天多次发布。我有一个判断团队DevOps是否到位的土办法问他们“上周上线了几次、回滚了几次、平均耗时多少”。如果回答都是个位数甚至零那说明所谓DevOps基本停留在口号和流水线玩具阶段。真正的DevOps文化是让发布变成低风险的例行事件让回滚变成快速完成的操作而不是一次充满仪式感的夜间大作战。5. 结合自建业务模型的智能体简易开发开发模型的新变种5.1 从交付功能到交付“可编排的智能业务”过去我们开发软件交付的是“功能”用户点一个按钮系统执行一段逻辑返回一个结果。到了AI智能体应用阶段交付物的形态变了交付的是“业务模型工具模型决策链路”的组合体用户用自然语言发起请求智能体判断意图、查阅规则、调用工具、组织答案完成一个完整的业务闭环。“自建业务模型”这个词值得展开说。它指的是企业自己的高价值流程逻辑客服分诊规则、合同审批流、风控策略、订单履约异常处理路径。这些规则和路径通常不在公开知识里而是散落在制度文档、老员工经验和系统代码中。传统开发把这些规则写成if-else和流程编排智能体开发则把这些规则结构化成可供大模型调用的决策单元。为什么强调“自建”因为大模型只懂通用知识不懂你公司的红线、你业务的上下文、你历史的坑。要让智能体真正可用核心工作就是把这些业务规则显式建模、沉淀成可编排、可测试、可版本管理的资产。这正是开发模型从“写代码”转向“织模型”的关键一步。5.2 为什么不能“直接问大模型”而要自建模型举一个真实场景合同审批智能体。如果让一个通用大模型直接回答“这个合同能不能通过”它只会告诉你合同法的一般原则比如内容合法、权责明确。但你们公司的实际红线可能是金额超过50万必须法务介入、付款条件里不允许出现全额预付、客户所在行业属于敏感类需要额外尽调、历史合作评分低于60分自动拒绝。这些业务Constraint根本不是公开知识也没法靠大模型的通用能力补全必须用业务模型显式表达。把它们写进规则引擎、状态机或者知识库切片让智能体在处理流程里先匹配业务模型再结合大模型的自然语言理解能力才能产出真正可用的审批结论。这就是“结合自建业务模型的智能体”和“裸用大模型”的分水岭。前者对企业有价值后者只是玩具。很多企业做智能体失败不是因为大模型不够聪明而是压根没把自己的业务模型梳理出来直接把ChatGPT套到业务流程里得到的回答自然泛泛而谈没法落地。5.3 智能体简易开发的五步法智能体应用继承了敏捷的基因但也有自己的开发特征。我把一套适合中小团队的简易流程总结为五步。第一步业务场景拆解。不要一上来就搞“企业级智能体”先把高频、规则密集、重复性强的环节挑出来例如售后咨询、订单查询、合同初审、工单分类。一个场景跑通远比十个场景画饼有价值。第二步业务模型显式化。把该场景涉及的规则、阈值、流程节点结构化定义成规则引擎可以执行的条件和动作同时梳理所需的知识文档。这一步是整个智能体开发里最需要业务方深度参与的部分。第三步工具与数据接入。识别智能体需要调用哪些接口订单API、退换货API、客户管理系统、知识库文档通过标准API或连接器接进来。第四步智能体编排。用编排平台或代码把链路串起来意图识别 → 业务模型匹配 → 工具调用 → 结果生成。这里可以先用低代码平台快速搭建验证链路再谈优化。第五步反馈闭环。每次交互记录日志标注错误答案定期把高频错例转化为新的业务规则或知识条目形成持续改进的数据飞轮。这个流程和传统开发模型的映射很有意思场景拆解对应需求分析业务模型显式化对应概要设计和领域建模编排对应编码反馈闭环对应测试和运维。但整个循环的节奏比传统软件快了不只一个量级因为每个场景的边界小、改动聚焦在模型而非代码架构。5.4 编排层、规则引擎与知识库的协同一套简单的智能体业务模型定义长这样business_model: refund_rule version: 2.3 rules: - id: R-001 condition: 订单金额 5000 AND 签收时间 7天 action: 自动退款 - id: R-002 condition: 订单金额 5000 OR 签收时间 7天 action: 转入人工审批 tools: - query_order_api - refund_api - approval_workflow_api knowledge: - 售后政策_v3 - 特殊类目售后须知你可以看到业务模型并不是一个黑盒“AI大脑”它由规则引擎处理硬性条件、知识库给大模型提供非结构化参考、工具层执行真实业务动作三部分组成。智能体的编排层先识别用户意图然后按业务模型路由到对应分支命中规则直接执行未命中规则则交给大模型结合知识库生成答案必要的时候启动工具调用。这套架构的优点是把“确定性”和“创造性”分开管理。凡是能写死为规则的事情就用规则引擎确保准确凡是需要理解和表达的才交给大模型。很多团队一上来就让大模型做全部分析结果准确性一塌糊涂。正确的姿势反而是“尽量用规则少用模型模型只负责理解、生成、总结”。5.5 一个完整的简易案例售后客服智能体把五步法和架构落到具体案例里。假设我们要做一个售后客服智能体处理“退货退款”这类高频场景。需求进来后先拆场景锁定退款条件查询、退货进度跟踪、异常投诉升级这三个子场景。业务模型里写入订单金额区间、签收时长、是否在保、特殊类目限制这些来自企业的售后政策同时接上订单查询API、售后单创建API和人工客服工作台API。用户发来一句“我上周买的东西想退能退吗”智能体的流程是先通过意图识别判断为“退款咨询”再调用order_query把订单拉出来将订单数据代入退款规则引擎计算是否符合自动退款条件如果符合直接引导用户提交退货运单并安排退款如果不符合说明原因并把链路切换至人工客服。整个过程中大模型负责两件事理解用户的自然语言生成易懂的解释话术规则和动作都落在自建业务模型里。这样一来准确率可测、动作可审计、异常可升级企业才敢把它放到生产环境。这个例子也说明智能体开发不是“替代传统开发模型”而是传统模型在新领域的延伸和重构。6. 现实选择给团队的模型选择建议6.1 六维判断模型替代一刀切面对一个新项目别急着喊“我们用敏捷”也别直接照抄上一家公司的流程。我建议从六个维度做判断。需求确定性需求有没有权威来源是否会频繁变化确定性高优先瀑布或V模型确定性低优先敏捷或迭代。交付频率业务方希望多久看到一次可用版本交付频率低可以接受较长周期交付频率高必须配套CI/CD和发布能力。失败成本出错一次的代价有多大失败成本极高账务、安全、医疗要强调测试门禁和评审中等成本可以靠灰度发布控制低成本可以大胆试错。团队规模与分布团队是否跨时区、跨公司分布式异步协作更适合文档化的Scrum和阶段里程碑小而紧密的团队可以更轻量。监管与审计要求是否需要完整留痕需要审计链路的项目无论内部多敏捷里程碑评审、阶段交付物一个都不能少。模型可演进性你的业务模型是稳定还是快速变化的AI智能体项目尤其要看规则和知识的迭代节奏变化越快模型越要轻、反馈闭环越要短。把这六个维度评估完模型选择基本不是拍脑袋而是推导出来的结论。6.2 常见组合推荐项目类型推荐组合不建议合规要求高的核心系统V模型阶段评审敏捷微调纯Scrum互联网产品研发ScrumCI/CDFeature Toggle纯瀑布运维/技术支持团队看板自动化发布强行Sprint企业级复杂系统RUP式四阶段内部迭代无阶段控制的全敏捷智能体应用开发场景化五步法反馈闭环先写三个月PRD再动手这张表是我在实际项目中验证过的组合不是理论推导。关键在于团队要敢于裁剪任何一个模型都是参考框架最终要适配自己的组织特点和项目约束。6.3 我踩过的坑希望你避开最后分享几个真实的教训。第一个坑我给一个做嵌入式固件的团队强行导入Scrum因为管理层觉得“敏捷是先进方向”。结果每个Sprint都没法形成可交付增量评审会开着开着变成了进度汇报会。后来退回V模型加阶段迭代才让团队恢复信心。敏捷不是万能药它只适合能形成增量反馈的场景。第二个坑一个运营支持团队按照我的建议从Scrum切到看板但WIP上限没严格执行大家习惯性一个人同时开三四件事看板变成了“任务列表”。花了两周重新训练团队强制每人同时最多两卡流动效率才真正上来。看板的有效性全靠纪律支撑没有纪律任何工具都是白搭。第三个坑跟智能体相关。我接手过一个智能体项目需求方坚持先用瀑布方式写三个月PRD把所有场景、规则、话术全部敲定再开发。结果PRD写到一半业务政策已经改了两轮大模型能力也升级了。后来我们调整为“先挑一个高频场景两周内做出原型业务方真实试用后再扩场景”才把项目盘活。智能体项目的业务模型变化很快反馈闭环必须前置这是和传统软件最大的差异。写在最后的实操心法开发模型这个东西真正工作了十几年之后回头看会发现它并不是用来“遵守”的而是用来“权衡”的。瀑布让你看清足够确定时怎么稳妥推进敏捷让你学会不确定时怎么快速纠偏DevOps告诉你交付才是价值落地的起点智能体的五步法则提醒我们无论模型怎么演进核心永远是让反馈回到流程里让质量在早期被发现让风险在可控范围内试错。我个人现在每接一个项目第一件事不是选模型而是把上面那六个维度画出来和团队一起打分。分数出来模型自然就浮出水面了。这些年踩过的坑和总结的经验说到底就一句话选对模型不是选一个漂亮的口号而是选一种与项目真实风险结构匹配的协作方式。
开发模型怎么选？从瀑布敏捷到智能体自建业务模型
我见过不少团队提“开发模型”四个字人人能说出瀑布、敏捷、Scrum、看板但真到项目启动会上面对“这次我们怎么组织开发”这个问题往往答不上来。最后多半是一句“我们一直走敏捷”可实际连Sprint backlog都没建过需求还是产品经理口头传。这不是态度问题是大家把开发模型当成了考试术语没当成“控制风险的组织方式”。开发模型不是一张纸上的流程图它决定了需求怎么拆、质量怎么保、交付怎么排是整个工程活动的骨架。这篇总结想把这堆模型重新梳理一遍不背定义就看每个模型在什么场景下真能站住脚同时会延伸到当下比较热门的“结合自建业务模型的智能体简易开发”看看智能体应用兴起之后传统开发模型又发生了哪些变形。1. 先搞清楚开发模型到底在解决什么问题1.1 模型不是流程是风险应对策略很多人把开发模型理解为“工作步骤”比如瀑布是先写需求、再设计、再编码、再测试。这个理解不算错但太浅了。真正的问题是一个软件项目的风险来自哪里不同模型为什么会选择不同的步骤顺序任何软件项目都面对三重不确定性需求不确定性用户说不太清楚自己到底要什么技术不确定性方案能不能落地、性能能不能达标开工前往往只是估计交付不确定性整个项目到底多久能做完、资源够不够用。不同开发模型的本质就是对这三重不确定性采取不同比例的应对策略。瀑布模型的隐含假设是需求和技术在开工前都能确定所以线性推进步骤之间是严格的上下游关系。迭代和螺旋模型承认不确定性存在所以每一轮都做风险分析先攻核心风险再逐步展开。敏捷则干脆把不确定性当成默认状态用短周期反馈让方向偏差尽早暴露。你可以把开发模型理解成一个团队“赌”的方式赌需求不会变还是赌自己有能力快速纠偏。装修房子是个很适合类比开发模型的事。全包模式像瀑布总价、工期、效果图都提前定死中间想改要办各种变更手续半包模式像V模型关键节点验收水电、防水这些隐蔽工程必须阶段检查清包模式像敏捷只定目标和预算上限过程中自己参与决策材料买错了随时换。没有哪种绝对好只看你的需求明不明确、你对施工方的信任度有多高。1.2 任何模型都要回答三个基本变量选模型之前先回答三个问题范围是固定的还是流动的质量靠什么机制保证速度的优先级如何设定。范围固定意味着需求被冻结后续变更必须走正式变更流程瀑布、V模型就是这么运作的。范围流动意味着需求永远在调整敏捷和看板都接受这一点只是调整频率和机制不同。质量机制上瀑布让测试集中在开发完成后V模型让测试活动从需求和设计阶段就开始定义敏捷把测试嵌入到每个迭代内部。速度优先级上有的项目想“早日拿到一个可用最小集”有的项目明确“宁可晚交付必须一次到位”。这三组选择组合起来基本就勾勒出一个项目适合什么模型。比如一个监管报送类项目范围由国家文件定义质量要求有明确测试标准那用瀑布或V模型完全合理。一个面向内部员工的效率工具需求每天都在变团队希望月底就能看到效果那再不敏捷就是跟自己过不去。开发模型是围绕这些约束做的组织设计不是拍脑袋选个名字。1.3 真实项目里模型往往是混用的我强调一点实际项目中几乎没有哪个团队是100%纯瀑布或100%纯Scrum。一个企业级系统核心业务链路可能走敏捷迭代数据迁移和报表模块可能是典型的瀑布交付涉及安全合规的部分要按V模型做阶段验收。这不是不专业而是对“风险分布不同”的正确映射。打个比方一个电商平台商品浏览页面的需求变化极快适合小步快跑但支付清算模块哪怕只修一个字段映射错误都可能引发资损必须有严格的评审和验证流程。同一个系统、同一个团队面对不同风险等级的子模块采用不同的组织方式这才是做工程该有的态度。后面的章节会按这个思路逐个拆解帮你建立“按风险选模型”的判断框架。2. 经典模型不是过时是边界清晰2.1 瀑布模型需求冻结不是缺点是前提瀑布模型被吐槽了几十年似乎已经成了“落后”的代名词。但真做过传统企业项目的人心里都清楚很多场合你根本绕不开瀑布。它的核心逻辑是一句话需求、设计、开发、测试按阶段推进每个阶段有明确交付物和评审门槛通过之后才进入下一阶段。这种模型最大的优势是可控性和确定性。范围、成本、工期的估算相对容易合同中可以写明交付物和验收标准。对甲方来说瀑布有安全感对乙方来说瀑布能减少无限修改。现实中适合瀑布的项目有一个共同特征需求方权威且需求源稳定。政府项目、军工项目、硬件嵌入式项目、有严格合同约束的外包项目几乎都天然走瀑布。批评瀑布的声音集中在“需求测不准”上。但问题是如果项目一开始就明确“需求就是测不准”那本来就不该选瀑布这是选型错误不是模型本身有罪。用瀑布的前提是需求冻结需求冻结本身不是缺点而是对“需求已充分收敛”这一事实的承认。我见过不少失败案例本质上是“用瀑布的流程配需求随时变更的现实”最后流程被架空质量也失控。2.2 V模型测试左移的思想源头V模型比瀑布多了个关键动作左侧每个开发阶段都对应右侧一个测试层级。需求分析对应验收测试概要设计对应系统测试详细设计对应集成测试编码对应单元测试。这样一来测试不是开发完成后的“尾部动作”而是从项目启动就同步定义的验证活动。这样设计的价值在安全攸关系统里体现得最充分。医疗器械、银行核心账务、汽车电子控制系统这些领域一旦出问题代价不是用户多等几天而是安全事故和资损事故。V模型强制你在写需求文档时就明确“怎么证明我们做对了”在设计评审时就想清楚“集成点上的风险是什么”质量是设计出来的不是测出来的。用V模型最大的经验是右侧的测试设计必须和左侧的开发文档一起评审。很多团队画了一个V字但右侧的测试用例是等到编码完成之后才补这等于把V模型硬生生掰回了瀑布测试左移变成了“测试后补”。真正的V模型需求评审会上就要有测试负责人参与用例设计得比编码早评审比编码早这样研发人员写代码时心里才有一把尺子。2.3 螺旋模型与RUP风险驱动的前辈螺旋模型是很多人容易忽略的一个但它对现代迭代开发的影响非常大。它的基本流程是四步循环确定目标、识别风险、开发验证、规划下一步。每一轮循环都先做风险分析再决定这一轮要投入多少精力、交付什么内容。这种“风险驱动”的思路比单纯的时间驱动要高级。RUP把螺旋模型的思想产品化定义了初始、细化、构建、移交四个阶段每个阶段内部又可以有多次迭代。你可能觉得RUP太重但它其实为后来的敏捷提供了很多养分迭代开发、以架构为核心、用例驱动这些概念在RUP里都已经成型了。我个人的看法是如果项目体量大、复杂度高、牵涉多个团队直接上纯Scrum往往太理想化反而RUP这种“阶段迭代”的混合体更好用。比如一个数字化转型项目先做初始和细化阶段搞清楚业务全景和关键架构约束再进入构建阶段按迭代交付。现在很多团队嘴上说敏捷实际干的还是RUP的活只不过没意识到而已。2.4 经典模型横向对比模型核心控制点典型适用场景主要风险瀑布模型阶段评审与文档交付合同项目、硬件固件、需求稳定需求变化时调整成本极高V模型测试与开发的阶段对应医疗、银行、车控等高合规领域流程繁琐交付周期长螺旋模型每轮风险分析与迭代规划高风险创新项目、大型系统对PM的风险分析能力要求高RUP四阶段迭代架构演进复杂企业级项目、多团队协作过程裁剪不当会变重这几种经典模型到今天都没有消失只是因为它们大多诞生于“需求确定、交付周期长”的年代今天的互联网和AI应用场景让它们看起来有些笨重。但如果你做的是To B、To G、嵌入式或者合规敏感的项目这些模型依旧是正确选择。3. 敏捷和看板把不确定性当成默认状态3.1 敏捷的核心是反馈闭环不是短周期很多人以为敏捷就是“两周一个版本”这是最常见也最危险的误解。敏捷的真正内核是反馈闭环每个迭代都包含完整的需求、设计、开发、测试、评审、复盘然后带着上一轮的认知进入下一轮。短周期不是目的短周期提供的高频反馈才是目的。为什么敏捷对不确定性的耐受度更高因为瀑布在需求确定后才进入设计遇到需求变化会被流程惯性推着走敏捷是在每个迭代里重新确认优先级需求变化不仅不被排斥还会被当成信息来源。产品经理和真实用户的每一次试用、每一个反馈都会进入下一个迭代的Backlog实现“方向纠偏”和“价值验证”。敏捷落地有一个关键前提必须能形成“可交付的增量”。如果团队做的东西在两周内无法形成一个可运行、可体验的版本那敏捷就跑不起来。我见过一个做嵌入式底层的团队强行切Scrum两周过去了增量连编译环境都还没稳定Sprint评审会拿什么给用户看所以敏捷之前先问自己这个项目能不能被切成小步能不能每步都产出可感知的价值。3.2 Scrum落地最容易翻车的三件事Scrum是敏捷最主流的实施框架但真正严格执行到位的团队很少。结合我带团队的经验最常见的翻车点有三个。第一用户故事没有拆细。一个Story动辄要开发两周以上进了Sprint根本没法完成最后要么延期要么删功能时间盒形同虚设。好的用户故事应该满足INVEST原则尤其是“小”一个Story最好不要超过两三天工作量完不成就要继续拆。第二评审会变成了“演示会汇报会”。评审的本质是让干系人真实试用并给出反馈不是研发团队对着PPT演示功能。如果产品经理包揽所有试用动作开发人员对真实用户反应一无所知那敏捷的反馈闭环就被切断了。第三复盘会没有输出改进项。很多团队的Retrospective开成吐槽大会大家把问题说了一遍会散了问题还在。正确的做法是每次只挑一到两个最痛的改进点落到下个Sprint的待办里并指定负责人跟踪闭环。一次改一点持续稳定改进比一次改革十项最后全落空强得多。3.3 看板约束在制品而不是约束时间看板不像Scrum那样用固定Sprint约束时间它约束的是在制品数量WIP。团队把任务列在业务流上每个环节待办、开发中、测试中、已发布设置同时处理任务的上限超过上限就先堵住源头。这个机制对两类场景特别适用一类是需求到达时间不确定的运营型团队比如技术支持、运维响应、质量改进另一类是开发中插入太多紧急事项、团队已经不堪重负的情况。看板让问题“可视化暴露”如果测试环节积压了十张卡说明瓶颈在测试不是开发不够快。大家每天站会站在看板前面讨论的是怎么让卡流动起来而不是谁的任务更多。Scrum和看板不是互斥的很多团队把两者结合用Scrum规划迭代用看板管理迭代内的流动。只要团队保持对WIP的纪律这套组合拳在研发场景里效果很好。核心原则就一条别同时开太多战线把事情一件一件做利落整体交付速度反而更快。维度Scrum看板节奏固定时间盒一般为1-4周迭代连续流动无固定周期核心约束迭代目标与故事范围在制品数量WIP变更策略迭代内尽量不引入新需求随时可拉新的任务但需有容量最佳场景新功能研发、版本交付运维、技术支持、需求持续输入4. DevOps把开发模型从“研发内部”推向“交付全链路”4.1 传统模型的盲区上线之后怎么办瀑布、敏捷、看板本质都聚焦在“开发”这个环节上线通常是终点。但云原生和微服务时代真正的风险往往出现在上线之后配置漂移导致环境不一致、灰度流量切错比例、数据库变更引发线上故障、回滚时发现版本不兼容。DevOps的出现把开发模型的边界从“开发管理”扩展为“交付全链路”代码提交、自动化测试、构建镜像、部署、配置变更、监控告警、日志分析全部串成一条流水线。传统模型讨论的是“怎么把功能做出来”DevOps讨论的是“怎么稳定快速地让功能生效并持续演进”。这一步扩展不是因为技术炫酷而是软件交付风险的重心转移了。单体应用一年发布两次人工运维完全能搞定微服务一天发布几十次每次都要手工操作必然出错。开发模型的粒度要变细前提是部署和发布动作必须自动化、可信赖否则小步快跑只会加速崩溃。4.2 CI/CD如何反过来影响研发节奏持续集成的意义不只是“跑自动化测试”它让每个提交都能被验证让“主干随时可发布”成为可能。这也倒逼团队简化分支策略GitFlow这类重分支模型适合低频发布时代主干开发TrunkBased短命特性分支更适合持续集成否则每次合并都在解决冲突CI再快也没意义。持续交付还改变了“完成”的定义。以前“功能完成”是代码写完了现在是“代码合入主干且通过自动化流水线随时可以部署”。只有这样的标准敏捷迭代的每轮增量才真正具备交付价值。否则就是每个Sprint都在Demo但真实环境永远跑着三个月前的版本。Feature Toggle功能开关在这里扮演了关键角色。它把“代码合入”和“功能上线”解耦功能代码可以随时合入主干但通过开关控制对用户可见性。这样团队可以频繁合代码、频繁部署避免大合并地狱同时让产品和运维决定什么时候真正“开闸放水”。这等于在开发模型里加了一层“发布与开发的解耦阀”。4.3 发布策略反过来影响迭代粒度DevOps不是只谈自动化流水线发布策略同样是模型的一部分。蓝绿发布准备两套完全一致的环境切换时流量整体切换风险集中在“切换的一瞬间”金丝雀发布则先把新版本给小比例用户使用监控指标稳定后逐步放大流量。这些发布策略直接决定了迭代能有多小。如果项目没有灰度能力每次上线都只能停服更新那功能再小发布成本也降不下来开发模型自然偏向“攒一批再发”的大版本模式。反过来如果发布了自动化灰度能力团队才能放心地做小步迭代、每天多次发布。我有一个判断团队DevOps是否到位的土办法问他们“上周上线了几次、回滚了几次、平均耗时多少”。如果回答都是个位数甚至零那说明所谓DevOps基本停留在口号和流水线玩具阶段。真正的DevOps文化是让发布变成低风险的例行事件让回滚变成快速完成的操作而不是一次充满仪式感的夜间大作战。5. 结合自建业务模型的智能体简易开发开发模型的新变种5.1 从交付功能到交付“可编排的智能业务”过去我们开发软件交付的是“功能”用户点一个按钮系统执行一段逻辑返回一个结果。到了AI智能体应用阶段交付物的形态变了交付的是“业务模型工具模型决策链路”的组合体用户用自然语言发起请求智能体判断意图、查阅规则、调用工具、组织答案完成一个完整的业务闭环。“自建业务模型”这个词值得展开说。它指的是企业自己的高价值流程逻辑客服分诊规则、合同审批流、风控策略、订单履约异常处理路径。这些规则和路径通常不在公开知识里而是散落在制度文档、老员工经验和系统代码中。传统开发把这些规则写成if-else和流程编排智能体开发则把这些规则结构化成可供大模型调用的决策单元。为什么强调“自建”因为大模型只懂通用知识不懂你公司的红线、你业务的上下文、你历史的坑。要让智能体真正可用核心工作就是把这些业务规则显式建模、沉淀成可编排、可测试、可版本管理的资产。这正是开发模型从“写代码”转向“织模型”的关键一步。5.2 为什么不能“直接问大模型”而要自建模型举一个真实场景合同审批智能体。如果让一个通用大模型直接回答“这个合同能不能通过”它只会告诉你合同法的一般原则比如内容合法、权责明确。但你们公司的实际红线可能是金额超过50万必须法务介入、付款条件里不允许出现全额预付、客户所在行业属于敏感类需要额外尽调、历史合作评分低于60分自动拒绝。这些业务Constraint根本不是公开知识也没法靠大模型的通用能力补全必须用业务模型显式表达。把它们写进规则引擎、状态机或者知识库切片让智能体在处理流程里先匹配业务模型再结合大模型的自然语言理解能力才能产出真正可用的审批结论。这就是“结合自建业务模型的智能体”和“裸用大模型”的分水岭。前者对企业有价值后者只是玩具。很多企业做智能体失败不是因为大模型不够聪明而是压根没把自己的业务模型梳理出来直接把ChatGPT套到业务流程里得到的回答自然泛泛而谈没法落地。5.3 智能体简易开发的五步法智能体应用继承了敏捷的基因但也有自己的开发特征。我把一套适合中小团队的简易流程总结为五步。第一步业务场景拆解。不要一上来就搞“企业级智能体”先把高频、规则密集、重复性强的环节挑出来例如售后咨询、订单查询、合同初审、工单分类。一个场景跑通远比十个场景画饼有价值。第二步业务模型显式化。把该场景涉及的规则、阈值、流程节点结构化定义成规则引擎可以执行的条件和动作同时梳理所需的知识文档。这一步是整个智能体开发里最需要业务方深度参与的部分。第三步工具与数据接入。识别智能体需要调用哪些接口订单API、退换货API、客户管理系统、知识库文档通过标准API或连接器接进来。第四步智能体编排。用编排平台或代码把链路串起来意图识别 → 业务模型匹配 → 工具调用 → 结果生成。这里可以先用低代码平台快速搭建验证链路再谈优化。第五步反馈闭环。每次交互记录日志标注错误答案定期把高频错例转化为新的业务规则或知识条目形成持续改进的数据飞轮。这个流程和传统开发模型的映射很有意思场景拆解对应需求分析业务模型显式化对应概要设计和领域建模编排对应编码反馈闭环对应测试和运维。但整个循环的节奏比传统软件快了不只一个量级因为每个场景的边界小、改动聚焦在模型而非代码架构。5.4 编排层、规则引擎与知识库的协同一套简单的智能体业务模型定义长这样business_model: refund_rule version: 2.3 rules: - id: R-001 condition: 订单金额 5000 AND 签收时间 7天 action: 自动退款 - id: R-002 condition: 订单金额 5000 OR 签收时间 7天 action: 转入人工审批 tools: - query_order_api - refund_api - approval_workflow_api knowledge: - 售后政策_v3 - 特殊类目售后须知你可以看到业务模型并不是一个黑盒“AI大脑”它由规则引擎处理硬性条件、知识库给大模型提供非结构化参考、工具层执行真实业务动作三部分组成。智能体的编排层先识别用户意图然后按业务模型路由到对应分支命中规则直接执行未命中规则则交给大模型结合知识库生成答案必要的时候启动工具调用。这套架构的优点是把“确定性”和“创造性”分开管理。凡是能写死为规则的事情就用规则引擎确保准确凡是需要理解和表达的才交给大模型。很多团队一上来就让大模型做全部分析结果准确性一塌糊涂。正确的姿势反而是“尽量用规则少用模型模型只负责理解、生成、总结”。5.5 一个完整的简易案例售后客服智能体把五步法和架构落到具体案例里。假设我们要做一个售后客服智能体处理“退货退款”这类高频场景。需求进来后先拆场景锁定退款条件查询、退货进度跟踪、异常投诉升级这三个子场景。业务模型里写入订单金额区间、签收时长、是否在保、特殊类目限制这些来自企业的售后政策同时接上订单查询API、售后单创建API和人工客服工作台API。用户发来一句“我上周买的东西想退能退吗”智能体的流程是先通过意图识别判断为“退款咨询”再调用order_query把订单拉出来将订单数据代入退款规则引擎计算是否符合自动退款条件如果符合直接引导用户提交退货运单并安排退款如果不符合说明原因并把链路切换至人工客服。整个过程中大模型负责两件事理解用户的自然语言生成易懂的解释话术规则和动作都落在自建业务模型里。这样一来准确率可测、动作可审计、异常可升级企业才敢把它放到生产环境。这个例子也说明智能体开发不是“替代传统开发模型”而是传统模型在新领域的延伸和重构。6. 现实选择给团队的模型选择建议6.1 六维判断模型替代一刀切面对一个新项目别急着喊“我们用敏捷”也别直接照抄上一家公司的流程。我建议从六个维度做判断。需求确定性需求有没有权威来源是否会频繁变化确定性高优先瀑布或V模型确定性低优先敏捷或迭代。交付频率业务方希望多久看到一次可用版本交付频率低可以接受较长周期交付频率高必须配套CI/CD和发布能力。失败成本出错一次的代价有多大失败成本极高账务、安全、医疗要强调测试门禁和评审中等成本可以靠灰度发布控制低成本可以大胆试错。团队规模与分布团队是否跨时区、跨公司分布式异步协作更适合文档化的Scrum和阶段里程碑小而紧密的团队可以更轻量。监管与审计要求是否需要完整留痕需要审计链路的项目无论内部多敏捷里程碑评审、阶段交付物一个都不能少。模型可演进性你的业务模型是稳定还是快速变化的AI智能体项目尤其要看规则和知识的迭代节奏变化越快模型越要轻、反馈闭环越要短。把这六个维度评估完模型选择基本不是拍脑袋而是推导出来的结论。6.2 常见组合推荐项目类型推荐组合不建议合规要求高的核心系统V模型阶段评审敏捷微调纯Scrum互联网产品研发ScrumCI/CDFeature Toggle纯瀑布运维/技术支持团队看板自动化发布强行Sprint企业级复杂系统RUP式四阶段内部迭代无阶段控制的全敏捷智能体应用开发场景化五步法反馈闭环先写三个月PRD再动手这张表是我在实际项目中验证过的组合不是理论推导。关键在于团队要敢于裁剪任何一个模型都是参考框架最终要适配自己的组织特点和项目约束。6.3 我踩过的坑希望你避开最后分享几个真实的教训。第一个坑我给一个做嵌入式固件的团队强行导入Scrum因为管理层觉得“敏捷是先进方向”。结果每个Sprint都没法形成可交付增量评审会开着开着变成了进度汇报会。后来退回V模型加阶段迭代才让团队恢复信心。敏捷不是万能药它只适合能形成增量反馈的场景。第二个坑一个运营支持团队按照我的建议从Scrum切到看板但WIP上限没严格执行大家习惯性一个人同时开三四件事看板变成了“任务列表”。花了两周重新训练团队强制每人同时最多两卡流动效率才真正上来。看板的有效性全靠纪律支撑没有纪律任何工具都是白搭。第三个坑跟智能体相关。我接手过一个智能体项目需求方坚持先用瀑布方式写三个月PRD把所有场景、规则、话术全部敲定再开发。结果PRD写到一半业务政策已经改了两轮大模型能力也升级了。后来我们调整为“先挑一个高频场景两周内做出原型业务方真实试用后再扩场景”才把项目盘活。智能体项目的业务模型变化很快反馈闭环必须前置这是和传统软件最大的差异。写在最后的实操心法开发模型这个东西真正工作了十几年之后回头看会发现它并不是用来“遵守”的而是用来“权衡”的。瀑布让你看清足够确定时怎么稳妥推进敏捷让你学会不确定时怎么快速纠偏DevOps告诉你交付才是价值落地的起点智能体的五步法则提醒我们无论模型怎么演进核心永远是让反馈回到流程里让质量在早期被发现让风险在可控范围内试错。我个人现在每接一个项目第一件事不是选模型而是把上面那六个维度画出来和团队一起打分。分数出来模型自然就浮出水面了。这些年踩过的坑和总结的经验说到底就一句话选对模型不是选一个漂亮的口号而是选一种与项目真实风险结构匹配的协作方式。
