跨团队依赖管理

不少团队把 Feature 当成“比需求大、比项目小”的任务卡，结果计划会上看起来层次分明，到了交付时却发现：一个 Feature 横跨多个团队、验收口径各说各话，迭代结束了，业务…

不少 PMO 推行敏捷时，第一轮迭代看起来很顺：团队开了站会、建了看板、排了 Story；到第三轮，管理层却发现需求仍在插队、跨团队依赖没人负责，项目状态也无法回答“什么时候能交付…

Feature 看起来只是需求拆分中的一个层级，真正让它失控的，往往不是团队不会写需求，而是 PMO、产品、研发、测试和业务部门各自使用不同的“完成”定义：PMO 看里程碑，产品看…

Task 管理真正失效，往往不是因为团队没有任务清单，而是因为清单里看不出风险何时会变成延期、谁有权处理、以及处理后是否真的降低了影响。PMO 推行敏捷项目风险控制时，我更关注一条…

敏捷项目Scrum全流程：PMO风险控制与一文讲清 Scrum项目延期，往往不是团队“执行力不够”，而是风险在需求入口、跨团队依赖和验收环节被延迟暴露：计划会上看起来一切正常，到了…

不少组织把敏捷迭代制度设计成“每两周开一次计划会、评审会和复盘会”，结果会议更多了，交付却没有更可预测：需求持续插入，团队同时做五六件事，月底再靠 PMO 汇总一张看起来很完整、却…

Epic流程与规范：PMO敏捷项目制度设计关键指标 不少组织的 Epic 看板看起来很完整：主题、负责人、计划版本、状态、进度一应俱全；但到了季度复盘，管理层仍说不清哪些战略目标真…

开发周期落地方案真正难的，不是把需求排进迭代，而是回答三个更具体的问题：哪些需求已经具备排期条件，团队在扣除支持和风险后还能承诺多少，以及需求变化时谁有权调整承诺。我在复盘中发现，…

迭代计划会准时开完，需求也都排进了版本，为什么到了迭代中段，研发仍在等澄清、测试集中补测、产品不断插单？我判断，问题通常不在团队“不会排期”，而在规划把需求数量当成了交付承诺，却没…

开发周期管理真正失控，往往不是因为团队不会估工时，而是因为需求进入之后，没有人持续回答三个问题：这件事为什么现在做、它依赖什么、什么条件下才算完成。排期表看起来精确到小时，实际却可…