与敏捷有关的神话或误解是什么？
有很多与敏捷有关的误解可能会导致普通新人陷入困境。敏捷世界有什么误解，你如何证明这是一种误解？
更新：敏捷神话摘要
阅读以下答案，了解有关上述神话和更多神话的更多信息。
答案 0 :(得分：21)
“在综合文档上运行软件”意味着您不需要功能规范...
错误！它只是意味着您可以与用户一起反复消除皱纹 - 作为供应商说话，您仍然需要良好的文档来协助QA和签核阶段......
答案 1 :(得分：20)
“我们正在做Scrum - 所以我们不需要（对|重构|做TDD | ......）”实际上Scrum的创始人--Ken和Jeff已经说所有高效率的Scrum团队都实施了全方位的极限编程实践。
测试驱动开发不会发现所有错误/不容易应用于所有内容 - 所以我们不会尝试！ - 学习TDD不是“全有或全无”，你会更好地判断测试内容以及如何有效地进行测试。我已经做了十年了，我仍然在寻找更好的方法来做这件事和新的事情。
我可以从书中学习所有我需要应用敏捷方法的东西。 - 你需要通过实践来学习，这通常意味着指导和会见其他可以提供帮助的人。当人们试图从书本中学习时，很多事情都会出错。
歇斯底里（非常真实）“候选人必须接受指导，并支持scrum大师”（根据我上周发送的工作规范......） - Scrum主人不应该告诉人们该做什么。他/她在那里提供便利 - 即帮助团队学会自己解决问题。这是一个巨大的失败模式 - 拥有一个“命令”人的Scrum大师！
谈论“敏捷方法论” - 大无能指标。首先，谈论“敏捷”就像是一个特定的事情，而对于许多不同的事情来说，这是一个非常模糊的总括性术语。其次，使用“敏捷”方法 - 有大量的方法，以及大量不同的方法来完成其中的许多方法！第三，敏捷社区中的很多人都反对九十年代大型，重型的UML方法。这些人不倾向于使用“方法论”这个词......
你需要特别有才能的人才能以灵活的方式开发软件。 Jeff Sutherland说，他们考虑使用“首席程序员团队”模式管理银行团队 - 但发现他们没有'有足够的“酋长”。 Scrum旨在从许多中等能力的程序员中获得最佳生产力。实际上，移除一个不想帮助其他人的不成比例的高效团队成员可以“解锁”平庸的团队成员，并将他们的综合生产力提高到超过补偿超级高效的前团队成员......那就是杰夫无论如何说......
我们在最近带领的开放空间研讨会中提出了其他与XP相关的其他 ：http://xpday-london.editme.com/WhereHasXpGone
答案 2 :(得分：18)
误区：使用敏捷开发实践是解决软件工程问题的灵丹妙药。
答案 3 :(得分：15)
误区：测试优先开发会迫使您的项目进行充分的单元测试。
事实：许多开发人员变得懒惰，并且在他们的代码通常很弱且不充分之前，他们会编写单元测试。
神话：结对编程总会产生更好的代码。
事实：程序员往往具有轻微的反社会性，并且彼此之间存在明显不同的思维过程。在编码时让某人呼吸到颈部非常不愉快，结果往往是工作氛围紧张，代码质量和数量都会降低。
答案 4 :(得分：10)
神话：敏捷意味着没有文档
事实：敏捷价值工作软件不仅仅是全面的文档，但这并不意味着根本没有文档。文档应该及时编写，并且足够。不，敏捷并没有说应该总是使用用户故事。如果且仅在适当时使用它们！
神话：敏捷意味着没有计划
事实：如果没有计划，敏捷不支持开发。敏捷使用持续的计划和估算来最大化ROI。实际上，敏捷是关于范围管理的。
神话：敏捷意味着没有纪律
事实：敏捷开发人员必须更加自律，才能取得成功。
神话：敏捷只适用于琐碎的项目
事实：敏捷（实际上是Scrum）用于
神话：敏捷无法扩展
事实：Sutherland在500多人的团体中使用Scrum，Cohn在100 +组中使用Scrum
答案 5 :(得分：8)
神话：“前面没有大设计”意味着没有设计。
答案 6 :(得分：6)
神话：瀑布总是失败。
现实：您在敏捷项目中使用的大多数软件都是使用瀑布式开发的。在许多情况下甚至是BDUF瀑布。
答案 7 :(得分：4)
没有真正的神话 - 但任何极端的事情都是错误的。一个敏捷项目实现零设计，希望“按原样设计”可能会失败。由于预算，时间或用户要求的变化，设计一切到最后一个分号的瀑布项目可能会失败。
答案 8 :(得分：3)
反复说“敏捷设计方法不能扩展”，而敏捷开发如果实施和正确考虑，将有效扩展到任何规模。
答案 9 :(得分：2)
误区：你需要仔细计划和安排每个冲刺。
这使您可以进行大量的前期规划，以便您可以完全规划每个冲刺。
这会让你失去灵活性并创造一个名为“敏捷”的瀑布。
答案 10 :(得分：2)
我看到的最大的神话是人们认为它比其他开发过程更好。
这是我们多年来在这个行业中常见的银弹蛇油。
https://stackoverflow.com/questions/301993/is-agile-development-dead/302060#302060
答案 11 :(得分：1)
误区：与其他替代方案相比，敏捷始终是更好的选择。
事实：根据项目规模，要求（特别是灵活性），外部时间表和客户态度，与正统方法相比，它可能并不总是更有成效。
答案 12 :(得分：1)
神话：敏捷意味着XP和Scrum
事实：还有其他一些做法，如OpenUP，AMDD等。
答案 13 :(得分：1)
很容易知道对客户收取什么费用。这对我们来说是最大的问题，因为我们不知道项目的范围我们不能给客户一个固定的价格，大多数客户要求固定价格。
答案 14 :(得分：1)
好线程。虽然我在相关的博客文章中没有提供任何新内容，但我确实说明了Agile失败时失败的两大原因。 1）缺乏前期要求（将'开头编码与不完整的要求'推向极端）和 2）缺乏足够的单元测试（因为CHANGE会发生 - 并且单元测试是捕获CHANGE产生的所有断点的最快方法）。
http://www.anujvarma.com/BlogEngine.net/post/2010/11/03/Agile-versus-Flat-Footed-development.aspx
答案 15 :(得分：0)
如果您没有使用敏捷显示真正的价值，它将失败。并且悲惨地失败，就像破产公司一样悲惨。仅仅因为它是“敏捷”而变得敏捷让你看起来像这个视频中的CIO一样愚蠢：
http://www.youtube.com/watch?v=nvks70PD0Rs
约翰
答案 16 :(得分：0)
神话：敏捷是反安全的。
事实：如果你试图将一个完整的瀑布式SDL（安全开发生命周期）强加到所谓的敏捷团队，这是唯一的。事实上，我已经在众多组织中设计并实现了Agile-SDL变体，我可以说将Agile 放入安全性，实际上可以提供更高，更强大的安全级别。它只是改变了安全心态 - 从控制到可见性和指南。
答案 17 :(得分：0)
你是完全正确的，敏捷周围有很多神话，一些来自外部，另一些来自内部。以下是我想要添加到列表中的一些内容：
“您不再需要项目经理或业务分析师”
虽然我们没有做BDUF并且团队是自我指导的，但随着事情的扩大，仍然需要那些工作正在协调正在发生的事情的人。如果您有一个非常复杂的业务场景，您可能需要有人帮助您理解它。 IME，许多真正需要PM和BA的项目仍然需要它们（那些现在不需要它们的项目，可能永远不需要它们！）。但是，当然，在敏捷世界中，PM和BA的角色往往不同，这会让人感到不安。
“敏捷不能用于固定价格项目”
可以，但这有点困难。特别是因为我们都知道“固定价格”的确意味着“固定价格，范围和时间”......
“我们不做BDUF，我们一直这样做”
唯一的工作方式是JEDUF（Just Enough Design Up Front）。有时你需要更多，有时候你可以少花钱，但是你做的不多于你需要的时间。