迭代承诺管理

迭代计划里写了 120 人天，最后却只交付 70 人天的功能；团队忙了两周，复盘时才发现其中近三分之一时间被缺陷、临时需求和跨团队等待占用。迭代容量管理的难点，通常不在于算不出人天…

迭代计划看起来排得满满当当，到了结束日却总有任务延期、临时插单和成员加班，这通常不是团队“不够努力”，而是把容量管理误当成了任务分配。迭代容量管理要回答的不是“每个人还能塞多少工作…

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

迭代计划会上，团队承诺完成 42 个需求；两周后，真正上线的只有 25 个，剩余工作被解释为“临时插单太多”。但复盘工时后发现，插单只占团队投入的 9%，更大的问题是计划时把 10…

迭代承诺经常失准，不一定是团队估时不准，更常见的原因是管理者把“团队人数”误当成“可交付容量”：一个有 12 名工程师的团队，扣除休假、线上值守、评审沟通、跨团队等待和未完成工作后…

迭代计划写着“团队容量 80 人天”，结束时却有 30 人天的工作没完成，管理层通常会先追问团队为什么估算不准。我的判断往往相反：问题未必出在估算，而可能出在“容量”被误当成可承诺…

迭代容量落地方案：管理层开展迭代管理的实操方法案例解析 迭代计划排了 80 人天，团队却连续三轮只交付了约 50 人天的承诺范围，管理层往往先追问“为什么效率这么低”。但容量管理中…

迭代容量不是把团队人数乘以工作日，再把结果填进计划表。一个 12 人团队，即使理论上有 60 人日，也可能只有 38 人日适合承诺：有人要值班，有人要处理线上故障，关键任务还可能依…

迭代计划看起来排得很满，到了迭代结束却发现承诺项只完成一半，问题往往不在团队“干得不够快”，而在容量被按人头估算、被会议和支持工作侵蚀，却没有在计划阶段如实扣除。做迭代容量管理，我…

不少企业的 Sprint 不是“没有开会”，而是开了计划会、站会、评审会和复盘会，到了迭代结束仍说不清：哪些承诺没有兑现，为什么没兑现，下一个 Sprint 应该改变什么。我的判断…