什么是与敏捷开发相关的误解或谬论？
在敏捷开发领域中，存在许多误解，新手可能会陷入其中。什么是敏捷开发中的误解，以及如何证明这确实是一个误解？
更新：敏捷开发误解总结
阅读下面的答案，了解关于以上误解的更多信息以及更多的误解。
"我们正在实行Scrum - 所以我们不需要（配对|重构|进行TDD|...）" 实际上，Scrum的创始人Ken和Jeff一直在说所有高生产力的Scrum团队都会实施完整范围的Extreme Programming实践。
测试驱动开发无法找到所有bug/难以应用于所有情况 - 所以我们不打算尝试！ - 学习TDD并不是一个“全有或全无的交易”，您会更好地判断要测试什么以及如何高效地测试它。我已经这样做了十年，仍然在寻找更好的方法以及需要考虑的新事物。
我可以从书中学到应用敏捷方法所需的全部知识。 - 您需要通过实践来学习，这通常意味着得到辅导并与其他可以提供帮助的人见面。很多事情在人们仅仅试图通过书本自学时会出现问题。
可怕（而且非常真实）的“候选人必须听从并支持Scrum Master的指示”（我上周收到的职位说明书…） - Scrum Master 不应该告诉人们该做什么。他/她的作用是促进 - 即帮助团队学会自己解决问题。拥有一个“命令”人的Scrum Master是一种巨大的失败模式！
谈论“敏捷方法” - 是无知的体现。首先，像它是一个具体的东西一样谈论“敏捷”，而它实际上是一个非常模糊的涵盖许多不同内容的抽象术语。其次，使用“the”敏捷方法 - 有很多种，并且许多种都有不同的方式进行！第三，敏捷社区的许多人在反对90年代的大型、过度使用UML的方法时加入了这里。这些人不倾向于使用“方法论”这个词...
要采用敏捷开发的方式开发软件，需要特别有才能的人。 Jeff Sutherland表示，他们曾考虑在银行管理团队时使用“首席程序员团队”模型，但发现他们没有足够多的“首席程序员”。Scrum旨在从许多能力适中的程序员中获得最佳生产力。事实上，移除一个不愿意帮助其他人，产出异常高的团队成员可以“解锁”平庸的团队成员，并将他们的联合生产力提高到超过超级高产前团队成员的水平......这是Jeff的说法。
我们最近在一个开放空间工作坊中提出了相当多与XP相关的问题：http://xpday-london.editme.com/WhereHasXpGone
迷思：使用敏捷开发方法是解决软件工程问题的灵丹妙药。
迷思：测试驱动开发会迫使项目拥有充分的单元测试。
事实：许多开发人员会变得懒惰，他们在编写代码之前撰写的单元测试往往是薄弱和不充分的。
迷思：结对编程总是能够产生更好的代码。
事实：程序员往往稍微有些反社交，并且彼此的思维过程有明显的差异。在编写代码时被人紧盯着非常不愉快，结果常常会导致紧张的工作氛围，以及代码质量和数量的减少。
神话：敏捷开发意味着没有文档
事实：敏捷开发更加重视工作软件而不是全面的文档，但这并不意味着完全没有文档。文档应该及时书写，并适量书写。而且，敏捷开发并不会说一个人必须总是使用用户故事。只有在适当的情况下才使用。
神话：敏捷开发意味着没有计划
事实：敏捷开发不支持没有计划的开发。敏捷采用持续的规划和估计来最大化投资回报率。实际上，敏捷开发关注范围管理。
神话：敏捷开发意味着没有纪律性
事实：为了成功，敏捷开发人员必须更具有纪律性。
神话：敏捷开发仅适用于琐碎的项目
事实：敏捷（实际上是Scrum）已经被用于：
神话：敏捷开发不能扩展
事实：Sutherland将Scrum用于超过500人的团队，Cohn将Scrum用于100人以上的团队。
错误观点：瀑布模型总是失败的。
事实情况：你在敏捷项目中使用的大多数软件都是采用瀑布模型开发的，甚至在许多情况下采用了BDUF瀑布模型。
没有真正的神话——但任何事情如果过分就会出错。一个敏捷项目如果希望“边开发边设计”而不做任何设计，很可能会失败。瀑布项目如果把每一个分号都设计好，很可能因为预算、时间或者用户需求的变更而失败。
有人反复说过“敏捷设计方法不可扩展”，但是如果正确实施和考虑，敏捷开发将有效地适用于任何规模。
迷思：你需要仔细计划和安排每个迭代。
这会导致你需要进行大量的前期规划，以便能够完全规划每个迭代。
这会破坏敏捷性并创建一个名为“敏捷”的瀑布流。
