变更成本
-
最反预期的瀑布开发教训：文档越详细越难改
你有没有见过一份“要命的”详细设计文档？我见过。三年前我接手过一个项目交接，对方团队交过来一个压缩包，里面有一份187页的详细设计说明书，目录就有6页。光“用户登录模块”就写了14页，包含了20多种异常分支的处理方案、8张时序图、还有一份数据库字段设计，精确到了每个字段的NOT NULL约束都标得清…
-
需求变更毁掉瀑布项目，我们用版本锁解决
一、我的核心结论：版本锁不是冻结需求，而是把变更成本可视化 做了十五年项目，我见过最贵的失败不是因为技术不行，而是需求变更的成本从来没人算过账。开发团队觉得“改一下嘛”，业务方觉得“我需求合理”，两边都觉得对方矫情。直到项目延期扣款、用户验收失败、团队核心成员离职，这些成本发生的时候，已经没人愿意回…
-
三个真实场景证明瀑布开发依然能打
不是敏捷不行,是你把场景搞错了 去年冬天,我接手了一个医疗器械软件项目的咨询诊断。技术团队用Scrum跑了三个迭代,每次Sprint Review都被产品负责人叫停，不是因为代码质量差,而是因为每个迭代产出的功能增量,放到医疗器械注册的框架里,都不构成一个“可提交审评的交付物”。当开发团队开始第八次…
-
瀑布开发适合哪些行业，别盲从
一、先给结论：瀑布开发不是“有没有用”，而是“你敢不敢用错” 如果你正在纠结团队到底该用瀑布还是敏捷，我的第一个建议是：先别翻那本 Scrum Guide，也别急着听敏捷教练画饼，先把你的项目性质看清楚。 我在过去十年里，见过不止一个团队在“敏捷转型”的口号下，把需求极度稳定、变更代价巨大的项目硬塞…
