飞飞

Epic看板上有 18 个“进行中”项目，并不代表团队交付了 18 项业务价值；更可能意味着其中一部分需求没有明确边界、依赖没有人负责，或者已经超过可控周期却仍留在看板上。实施团队…

在实施团队里，Epic常常不是因为拆得太大而失效，而是因为它被当成一张“更大的需求卡”：没有清晰的业务结果，没有可验证的边界，也没有跨团队依赖的处理机制。结果是看板上的Epic持续…

敏捷项目里，Feature（特性）拆得越细，团队不一定越快：我见过最典型的反效果，是一项业务能力被拆成十几个“特性”，每个都要单独评审、排期、跨团队确认，结果需求看起来更清楚了，交…

Scrum 团队最危险的时刻，往往不是冲刺目标没完成，而是团队连续几个迭代都按时交付，直到上线前才发现关键验收条件没人确认、外部接口没人负责、测试环境也没有准备好。Scrum 不会…

不少实施团队的 Sprint 看板看起来很忙：任务不断进入进行中，站会每天开，迭代结束时却仍有关键配置、数据迁移或验收事项没有完成。问题往往不是团队“不够敏捷”，而是把风险控制误解…

敏捷项目最常见的失控，不是团队没有按时开站会，而是风险在每个迭代里都被“看见”，却没有人负责把它变成决策：依赖团队迟迟不确认、关键验收口径反复变化、测试时间被压缩，最后所有人仍然盯…

敏捷项目从0到1，最容易失控的时刻通常不是团队不会开站会，而是第一轮迭代结束后，需求、缺陷和临时任务同时涌进来，却没人能说清楚哪一项必须先做、谁有权改变计划、什么情况需要暂停发布。…

实施团队采用 Story 后，最先暴露出来的往往不是开发速度，而是“需求已经做完，客户却说不是他要的”。在一个用于说明方法的模拟项目中，团队把 12 周内的需求拆成 Story、补…

不少敏捷项目看起来已经有了 Story、迭代和每日站会，交付却仍然靠项目经理逐项催办：需求进了迭代，中途不断插单；开发说“完成”了，测试才发现验收口径没有谈清；迭代结束，团队忙着补…

不少敏捷团队的 Backlog 看起来很满：需求一条接一条，迭代计划会开得很久，开发开始后却仍然频繁追问“这条到底要解决什么”。问题通常不是团队缺少任务，而是待办项没有形成可执行的…