范围、优先级与需求变更：新想法来了怎么办
收藏按钮快做好时，朋友又说想给收藏分组，还想多人共享、自动推荐。每个想法听起来都有用，可时间没有跟着增加。软件工程不要求拒绝所有变化，而是让每一次变化的收益和代价都能被看见。
1. 写出第一版的边界
先把第一版想验证的事情写成一句话：“读者能在不同设备找回自己保存的文章。”收藏、取消和列表直接支持这个目的；自定义封面、社交分享和推荐算法暂时不支持这个目的，可以后移。
范围不是一句“做个基础版”。它应同时说明包含和不包含什么。例如保留用户隔离、保存失败提示和刷新后数据保留，但不做公开收藏夹。安全和核心正确性不能因为看起来不像新功能就全部放到下一版。
2. 从价值、风险和依赖排列顺序
如果收藏要依赖登录，而登录还没做，先画漂亮列表不能消除关键不确定性。可以先完成一次最小的登录后保存，再逐步完善界面。优先级不是只看“用户最喜欢哪个按钮”，还要考虑哪些工作会挡住后续任务。
拿三张卡试一遍：A 是防止重复收藏，B 是收藏动画，C 是失败后提示。A 保护数据规则，C 避免用户误以为成功，B 改善感受。通常先完成 A、C 再考虑 B，但如果你正在验证动画交互原型，排序也可能不同。结论要跟当前目标一起看。
3. 怎样处理临时插入的需求
接到“这周必须加共享”时，不要直接把卡塞进最上面。先确认谁能共享、共享后谁能编辑、撤销后旧链接怎样处理。一个按钮背后可能牵涉权限模型和数据迁移。
随后给出选择：保持日期，缩小共享范围；保持完整范围，延后日期；或者先做可点击原型验证是否值得投入。增加人手也可能有帮助，但新人需要熟悉上下文，工作若难以并行，交付时间不会按人数简单减半。
一个轻量变更记录就够用：
变更：增加只读分享链接
原因：读者希望把一组学习资料发给同学
影响：新增访问规则、撤销行为、隐私提示与测试
决定：本轮先完成私人收藏，下轮验证分享原型
复查时间：本轮用户试用之后
保留记录不是为了追责，而是避免两周后没人记得为什么某项工作被延后。
4. 用风险清单安排短实验
风险是尚未发生、但可能影响目标的事情。可以写“外部登录服务在目标网络下可能不稳定”，然后安排一次真实网络环境下的试用。实验应有时间上限和要回答的问题，例如一天内确认登录成功率及失败提示是否可接受。
不要把风险清单写成泛泛的“技术风险、人员风险”。写明发生条件、影响、应对办法和负责人。已经发生的登录故障则是当前问题，需要处理，不能继续藏在风险清单里等以后研究。
5. 任务做完的含义要统一
“我写完了”可能只表示本机按钮可点。团队可以约定共同完成标准：实现通过评审，关键测试通过，文档同步，能够在目标环境验收。它描述所有相关任务都要达到的质量底线。
它与单个故事的验收条件不同。FAV-02 规定重复收藏只能有一条，是这一功能的规则；“关键测试通过”是团队共同标准。一个任务可以满足其中之一却还没有真正完成，因此需要同时检查。
练习与参考答案
本周只剩一天，新增“导出全部收藏”估计需要两天。合理回应不是悄悄删掉测试，而是说明估算假设与影响，询问导出的实际用途，并提出调整范围或时间。如果只是试用讨论，可以先用样例文件确认格式；样例不能被当作已交付的导出功能。