迭代容量

迭代计划会上，团队把每个人的“可用工时”加起来，得出 240 小时容量；两周后，实际交付却只有 150 小时，延期原因还被归结为“估算不准”。这类偏差往往不是团队不会估算，而是把容…

迭代计划会上，团队把 42 个任务全部标成“已承诺”，两周后却只完成了 29 个；更麻烦的是，剩下的 13 个任务里，有 8 个并非开发做不完，而是测试环境、接口依赖和需求验收条件…

迭代计划看起来排得很满，到了评审会却发现一批任务没有验收、关键依赖还没完成、开发人员忙了一周但业务价值说不清，这通常不是团队“不够努力”，而是迭代管理把任务数量当成了进度。我的判断…

迭代计划最常见的失败，不是团队估错了几天，而是计划里装进了太多“看起来必须做”的工作，却没有给缺陷、依赖、验收和变更留下空间。项目经理真正要控制的，不是每个人每天完成多少任务，而是…

迭代容量不是把团队人数乘以工作日，再把所有需求塞满日历。一个团队即使有 8 名开发人员、两周迭代，如果同时承担线上故障、代码评审、跨团队联调和临时需求，纸面上的 80 人日也不等于…

迭代容量实操方法：项目经理提升迭代管理效率的实操方法方法与模板 迭代计划会开了两小时，团队把每个人排得满满当当，到了迭代结束却只交付了计划的一半，这通常不是团队“不够努力”，而是容…

迭代计划排得满满当当，到了周三却发现关键需求还没开始；开发说等接口，测试说环境没好，产品又临时插入“只改一点”的需求，这通常不是成员不努力，而是排期把“需求列表”误当成了“可交付计…

迭代计划排得满满当当，到了迭代结束却只交付了几项功能、还留下一串“等联调、等确认、等测试”的任务，这通常不是团队不够努力，而是排期时把“需求数量”误当成“交付能力”。我做迭代规划时…

去年我帮一家做企业服务的公司复盘交付延期问题，翻完 6 个迭代的排期表，发现一件反常识的事：延期最严重的 11 个需求里，有 9 个在排期时的估算偏差不到 20%。问题并不出在“估…

迭代规划流程与规范：项目负责人需求排期风险控制关键指标 一个迭代排了 18 个需求，开发估算刚好用满团队 100% 的可用工时，计划看起来很紧凑；但到迭代结束，真正按期验收的只有 …