对于多数国内企业和团队来说，以 Scrum+XP 为代表的轰轰烈烈的“敏捷运动 1.0”确实是一个坑(还不止一个坑)，一不小心就容易掉坑里。

　　中美的软件工程处于不同的发展阶段与水平，论平均水平至少还差 8-10 年吧，尤其是人们的科学、工程意识与水平。Scrum+XP 并不是普适的，从一开始就不是针对中国软件工程的现状和特点提出来的，所以许多做法基本上不适合国内，适用面非常窄。

　　Scrum+XP 主推的那些实践有点用，但缺陷也很明显，比如理想化、片面、偏激、失衡，极端主义倾向，忽视需求分析、系统建模、架构设计，因此不能很好、有针对性地，或从根本上解决国内团队面临的一些现实主要问题，而 Scrum+XP 实践所要解决的那些问题也并不是国内多数团队所面临的真正的短板。

　　显然，两者(卖方与买方)的不匹配，水土不服，加上长期的商务洗头和运动洗头式传播，结果导致国内的伪敏捷、伪 Scrum 比比皆是。

　　感觉需求都没有搞清楚，就开始弄的所谓敏捷开发 其实浪费了更多的时间和制造了大量无用的消耗

　　感觉需求都没有搞清楚，就开始弄的所谓敏捷开发 其实浪费了更多的时间 和制造了大量无用的消耗，这正是 Scrum+XP 最薄弱的环节之一。

　　XP 中的需求分析实践其实是很弱的，Kent Beck 发明了用户故事(User Story)，想要取代用例故事(Use Case)。

　　然而，有多少人相信，在实际的工程项目实践中，仅靠一堆文字量非常有限的故事卡片(用完之后还要优雅地撕掉)，加上口头沟通，而不需要做大量科学、系统、细致的需求分析，建立起高质量、书面的需求文档和需求模型，就能把复杂软件的需求真正搞清楚?

　　连最上游的软件需求都没搞清楚，自然会导致开发中的许多返工和浪费，更谈不上敏捷了。