迭代容量计算

迭代容量算错，通常不是团队“做得不够快”，而是负责人把可用工时、历史交付和需求点数混成了一个数字。一个常见的复盘场景是：计划会排入 42 个故事点，团队过去几轮平均完成 38 点，…

迭代计划里写了 80 个故事点，团队最后只交付 52 个；下一轮，管理者把目标改成 60 个，结果又只完成 41 个。问题往往不在团队“不够努力”，而在于把容量当成一个可以直接分配…

迭代计划里写了 80 个故事点，不代表团队真能交付 80 个故事点。容量管理最容易犯的错，是把“估算出来的工作量”当成“可以承诺的产能”；真正决定迭代能否按期完成的，往往是可用人天…

迭代计划排得满满当当，到了结束日却只交付了六成：问题往往不是团队“不够努力”，而是计划时把可用工时当成了可承诺容量。做迭代容量规划，我更看重的不是把每个人的日历塞满，而是先算清团队…

迭代容量最容易算错的地方，不是团队人数，而是把“人在岗”误当成“能交付”。一个有 10 名开发人员的团队，若有人承担值班、有人休假、有人跨项目支援，再扣除评审、沟通和返工，实际可用…