敏捷开发不是开站会就完事：一个定制项目的真实复盘

说句得罪人的话：很多公司声称在用敏捷开发，实际上就是把瀑布模型改名叫"迭代"。每周开个站会，完了还是按老套路干活。这不叫敏捷，这叫装敏捷。

我之前带过一个定制项目，客户是一家连锁健身品牌，要做会员管理系统。项目周期4个月，预算25万。最后用敏捷的方式跑下来，3个月就交付了，客户满意度还特别高。今天复盘一下这个项目，聊聊敏捷开发在定制项目中到底怎么用。

先搞清楚：敏捷不等于没有计划

很多人对敏捷开发有个误解，觉得敏捷就是"不写文档、不做计划、先干再说"。大错特错。

敏捷的核心是"把大计划拆成小计划，把大风险拆成小风险"。我们那个健身项目，整体计划是4个月、分6个迭代（每迭代2周），每个迭代结束都有可演示的成果。第一个迭代做的是会员注册和基础信息管理，第二个迭代做的是会员卡和课程预约，以此类推。

跟瀑布模型最大的区别是：瀑布要等4个月才能看到东西，敏捷2周就能看到。客户能看到进度，心里就踏实。开发团队也能早点发现问题，不用等到最后才知道方向跑偏了。

一个迭代到底怎么跑

我们团队的一个标准迭代（2周）是这样运作的：

迭代规划会（第1天上午，2小时）

把产品Backlog里的需求拉出来，评估工作量和优先级，确定这个迭代要做哪些。关键原则：不要排满。留20%的buffer给突发问题和bug修复。

之前有个迭代我们排了100%的容量，结果第三天客户提了个紧急需求，整个迭代计划全乱套了。从那以后我养成了习惯：迭代规划最多排80%的容量。

每日站会（每天早上，15分钟）

三个人回答三个问题：昨天做了什么、今天要做什么、有没有卡住的。站会不是汇报会，是同步会。超过15分钟就跑偏了。

有个小技巧：站会站着开。物理上的站姿会让人说话更简洁。坐下来就容易扯远了。

迭代评审会（第10天下午，1小时）

向客户演示这个迭代完成的成果。注意，演示的必须是可运行的功能，不是PPT。客户看到真东西，给的反馈才有价值。

我们在这个项目里有个做法我觉得特别好：每次评审会准备一个"体验清单"，让客户自己操作几个核心流程。客户自己点出来的问题，比你主动演示发现的问题更真实。

迭代回顾会（第10天下午，30分钟）

团队内部复盘：这个迭代哪些做得好、哪些要改进。不追责，只改进。

第三个迭代结束后我们回顾发现，前后端联调花了太多时间。原因是没有提前约定接口格式。从第四个迭代开始，我们先出接口文档再开发，联调时间从2天缩短到半天。

敏捷在定制项目中的3个真实挑战

什么时候别用敏捷

敏捷不是银弹。以下场景我建议老老实实用瀑布：

• 需求极其明确且不会变：比如政府项目的固定功能模块，需求三年前就定好了。
• 涉及安全关键系统：比如医疗设备控制软件、航空系统。这类系统需要完整的设计文档和严格的评审流程，敏捷的"快速迭代"可能带来风险。
• 客户没有时间参与：敏捷需要客户频繁反馈，客户配合不了就白搭。

一点个人感受

敏捷开发用好了确实能提高效率，但它对团队的要求其实比瀑布更高——需要每个人都能自我管理、主动沟通。如果团队习惯等指令再干活，敏捷反而会更乱。

华慕科技在敏捷开发实践上积累了大量经验。如果你的团队正在转型敏捷，或者想了解敏捷适不适合你的项目，欢迎联系我们交流。