迭代排期

2024 年我帮一家做工业 SaaS 的团队复盘他们的季度排期，翻出来的数据很难看：Q1 承诺了 34 个需求，按期交付 19 个，延期 11 个，剩下 4 个在中途被悄悄&quo…

跨部门迭代排期最常见的失控，不是团队把开发时间估短了，而是计划里写着“已排期”的需求，仍在等待产品确认、设计交付、数据授权或其他团队接口。需求看起来进入了迭代，实际却没有进入可执行…

跨部门团队的迭代计划经常在启动会上看起来“全都排进去了”，到迭代中段却同时出现需求插队、依赖未就绪、测试拥堵和业务方追问。问题通常不在团队不会估算，而在于排期制度只规定了“怎么把需…

迭代计划排满了，交付却一再延期，问题往往不在成员“不够努力”，而在需求、容量和不确定性被放进同一张表里，却没有被正确计算。我做迭代排期复盘时，最常见的反常识是：计划项越多，不代表团…

迭代计划看起来排满了，到了迭代中段却有三分之一需求延期；成员每天都在更新进度，负责人仍说不清哪些工作会挤占关键路径。遇到这种情况，问题通常不在成员“排期不积极”，而在规划流程没有把…

不少团队的迭代计划会在会议结束时显得很完整：需求排好了，负责人也写上了，开发任务甚至精确到了小时；但迭代开始一周后，插单、依赖等待和测试积压仍然接连出现。问题往往不在“估时不准”，…

管理层提出“下个迭代必须支持大客户的权限配置”，研发负责人看了一眼当前迭代：开发容量已排满，测试还压着两个高风险缺陷，销售承诺的交付日期却已经写进客户方案。此时真正的问题不是“要不…

迭代规划最容易失败的时刻，往往不是团队做不出排期，而是管理层把“需求都排进去了”误认为“团队已经承诺交付”。我判断一次规划是否有效，不先看计划里有多少条需求，而看三件事：团队是否有…

迭代计划按时完成率达到 90%，不代表研发团队真的具备稳定交付能力：如果计划内需求不断被临时插入、测试阶段集中暴露问题，或上线后返工持续增加，这个数字可能只是把延期藏进了下一个迭代…

研发团队的任务日历最容易出现一种反常现象：排得越满，看起来越有计划，真正遇到需求变更或线上故障时，却越难判断该移动哪项工作。日历视图的价值不在于把每个人的每个小时填满，而在于让任务…