开发流程与小步迭代：为什么不要憋到最后一天

接到“做一个知识库”的任务，你可能计划先把全部页面画完，再写全部接口，最后统一测试。三周后页面很完整，却发现用户最需要的搜索一直没接上。问题不一定是写得慢，而是太晚才得到有用的反馈。这一章学习怎样把大任务变成几次看得见的交付。

从一个小功能开始 2026/10/54 分钟阅读

开发流程与小步迭代：为什么不要憋到最后一天

1. 先认识软件的生命周期

一个功能通常会经历需求、设计、实现、验证、发布和维护，最终也可能下线。这些活动合起来描述了软件从产生到退出使用的过程。它们不是每个团队都必须设置的六个部门，也不表示测试只能等实现全部结束才开始。

收藏功能的需求讨论可以同时产出测试例子；设计时可以先验证数据库是否支持需要的约束；发布前就该准备失败后的恢复办法。早点考虑后面的活动，往往能减少返工。

如果需求稳定、外部验收节点明确，团队可以按阶段建立计划和交付检查点。常说的瀑布式流程强调阶段推进，但现实项目仍可能反馈和返工，不能把它简化成“绝对不能修改”。

如果用户还说不清想要什么，可以先做原型。原型可能只是能点击的页面，用来验证交互，不一定具备生产所需的权限和可靠性。要标清哪些是假的，否则大家会误以为离上线只差改颜色。

还有一种办法：先交付一个小但完整的能力，再逐步扩展。这叫增量开发。围绕已有结果反复改进，叫迭代。两者常一起发生，但不是同一个意思：新增收藏列表是增量；根据反馈调整列表顺序是迭代。

不要只安排“周一做数据库、周二做后端、周三做前端”，因为任何一天结束都可能没人能实际使用。试着这样划分：

每轮都可能涉及界面、规则、数据和测试。我们称这种做法为纵向切片：沿着用户操作切出一条窄而完整的路。它不意味着第一轮就可以忽略基本权限，必要的安全要求要贯穿每一轮。

敏捷强调通过合作和反馈调整工作，并不等于不要计划、不要文档或想改就改。计划仍然存在，只是新证据出现时可以更新。把每次插单都叫“敏捷”，反而会让团队无法完成任何一件事。

Scrum 是一种具体框架。按照 2020 版 Scrum Guide，Sprint 是一个月或更短的固定长度事件；团队围绕 Sprint Goal 工作，用 Product Backlog 管理待办，并通过评审和回顾获得反馈。它不是敏捷的唯一做法，也不是开了每日站会就自动具备全部要素。

初学者先抓住区别：评审关注做出来的东西和接下来的方向；回顾关注团队如何改进工作方式。发现按钮难用应进入产品讨论；发现测试总要等某个人，应改进协作流程。

“做收藏两天”可能漏掉登录和数据库迁移。先列出假设：已有登录、可复用文章查询、无需历史数据迁移。在这些假设下估一个范围，再把最不确定的部分安排为短时间的探索。

估算是帮助安排工作的信息，不是保证永远不会变化的承诺。故事点是一些团队用于相对估算的尺度，不能直接拿来比较不同团队的效率。今天完成了几张卡，也不能说明这些卡给用户带来了多少价值。

把“实现搜索、收藏、评论、推荐”缩成第一周目标。一个合理答案是先让用户找到并保存文章，暂缓评论和推荐。保留验收、权限与失败提示，把可选功能后移，而不是把全部验证工作后移。每轮结束请真实用户完成一个任务，记录卡在哪里，再决定下一步。