敏捷的神话和误解[关闭

Question

与敏捷有关的神话或误解是什么？

与敏捷有关的误解是普通的新来者可能会陷入的。敏捷世界中有什么误解，您如何证明这确实是一种误解？

---

更新：敏捷神话摘要

• 敏捷不允许文档
• 敏捷方法不扩展
• 敏捷意味着没有计划
• TDD涵盖了所有单元测试需求
• 配对编程总是会产生更好的代码
• 敏捷是用于软件工程问题的银色子弹解决方案（有一个银色子弹解决方案）
• 敏捷不需要前面设计
• 我们正在做Scrum，因此我们不需要进行TDD，重构对编程等。
• 一个人可以从书中学习敏捷
• 敏捷仅适用于微不足道的项目
• 敏捷总是使用“用户故事”

阅读以下答案，以获取有关上述神话和更多神话的更多信息。

Answer 1

1. “我们正在做Scrum-所以我们不需要（配对| Rebactor | do tdd | ...）” 实际上，Scrum创始人-Ken和Jeff一直在说所有高生产力的Scrum团队都实施了一系列极端编程实践。

2. 测试驱动的开发不会发现所有错误 /不容易应用于所有内容 - 因此我们不会尝试！ - 学习TDD并不是“全部或全无的交易”，您会更好地判断测试的方法以及如何有效地做到这一点。我已经做了十年了，但我仍在寻找更好的方法以及要考虑的新事物。

3. 我可以学习从书中应用敏捷方法所需的一切。 - 您需要通过做学习，这通常意味着指导和与其他可以提供帮助的人。当人们只是尝试从书中学习时，很多事情都会出错。

4. 歇斯底里（非常真实） “候选人必须从上周发送的工作规格，并支持Scrum Master。 - Scrum主人 不应该告诉别人该怎么办. 。他/她在那里促进 - 即帮助团队学习解决问题。这是一个巨大的失败模式 - 拥有“指挥”人的Scrum主人！

5. 谈论“敏捷方法” - 大的无知指标。首先，谈论“敏捷”，就像是一件特定的事情，而对于许多不同的事情来说，这是一个非常模糊的伞。其次，使用“ The”敏捷方法 - 其中有很多负载，以及许多做许多方法的方法！第三，敏捷社区中的许多人在这里反对90年代的大型，重型UML的方法。这些人不倾向于使用“方法论”一词...

6. 您需要特别有才华的人以敏捷的方式开发软件。 杰夫·萨瑟兰（Jeff Sutherland）说，他们考虑使用“首席程序员团队”模型来管理银行中的团队 - 但发现他们没有足够的“酋长”。 Scrum旨在从许多适度的程序员中获得最佳生产力。实际上，不想帮助其他人可以“取消阻止”平庸的团队成员，并使他们的合并生产力提高到超出了超级生产的前团队成员，这就是杰夫（Jeff），这就是杰夫（Jeff），这就是杰夫（Jeff），这就是杰夫（Jeff），这就是杰夫（Jeff），这就是杰夫（Jeff），这就是杰夫（Jeff），这就是杰夫（Jeff），这就是杰夫（Jeff），这就是杰夫（Jeff），这就是杰夫（Jeff），这就是杰夫（Jeff），这就是杰夫（Jeff），这就是杰夫（Jeff），这就是杰夫（Jeff），这就是杰夫（Jeff），这就是杰夫（Jeff），这就是杰夫（Jeff），这就是杰夫（Jeff），这就是杰夫（Jeff）无论如何...

有 其他许多与XP相关的 我们最近在我领导的开放空间研讨会上想到了： http://xpday-london.editme.com/wherehasxpgone

Answer 2

“超越全面文档的工作软件”意味着您不需要功能性规范...

错误的！！！这只是意味着您可以与用户一起迭代皱纹 - 作为供应商，您仍然需要良好的文档来协助质量检查和签名阶段...

Answer 3

误解：使用敏捷开发实践是用于软件工程问题的银弹解决方案。

Answer 4

误解：测试优先开发迫使您的项目进行足够的单位测试。

事实：许多开发人员会变得懒惰，并且在代码往往很虚弱和不足之前，他们编写的单元测试。

误解：配对编程总是会产生更好的代码。

事实：程序员倾向于有点反社会，并且彼此之间的思维过程有显着不同。当您的代码时，有人呼吸您的脖子非常不愉快，结果通常是紧张的工作氛围，代码质量和数量都会降低。

Answer 5

神话：敏捷意味着没有文件

事实：敏捷的价值工作软件不仅仅是全面的文档，但这并不意味着根本没有文档。文档应及时编写，就足够了。不，敏捷不说应该 总是 使用用户故事。在合适的情况下，只有在它们合适的情况下使用它们！

神话：敏捷意味着没有计划

事实：如果没有计划，敏捷就不支持开发。敏捷使用持续的计划和估算来最大程度地提高ROI。实际上，敏捷是关于范围管理的。

神话：敏捷意味着没有纪律

事实：敏捷开发人员必须更加纪律。

神话：敏捷仅适用于琐碎的项目

事实：敏捷（在这里实际上是Scrum）已用于

• FDA批准的，X射线和MRIS的生命关键软件，
• 财务付款申请，
• 24x7具有99.99999％的正常运行时间要求，
• 多稳定数据库应用程序，
• ETC

神话：敏捷不会扩展

事实：萨瑟兰（Sutherland

Answer 6

神话：“没有大型设计”意味着没有设计。

Answer 7

神话：瀑布总是失败。

现实：您在敏捷项目中使用的大多数软件都是通过瀑布开发的。在许多情况下，即使是BDUF瀑布。

Answer 8

没有真正的神话 - 但是任何事情都极端的事情都是错误的。一个进行零设计的敏捷项目，希望“随着它进行设计”可能会失败。将所有内容设计到最后一个半隆的瀑布项目可能会因预算，时间或更改用户要求而失败。

Answer 9

反复说，“敏捷设计方法不会扩展”，而如果实施并考虑到正确的考虑，敏捷开发将有效地扩展到任何规模。

Answer 10

神话：您需要仔细计划并安排每个冲刺。

这会导致您进行很多前期计划，以便您可以完全计划每个冲刺。

这使您击败敏捷性，并创建一个称为“敏捷”的瀑布。

Answer 11

我看到的最大的神话是，人们认为它比其他开发过程更好。

这是我们多年来在这个行业中一直看到的通常的银蛇油。

https://stackoverflow.com/questions/301993/is-agile-development-dead/302060#302060

Answer 12

神话：与其他替代方案相比，敏捷始终是一个更好的选择。

事实：根据项目规模，要求（尤其是此类灵活性），外部时间表和客户态度，与东正教方法相比，它可能并不总是更有生产力。

Answer 13

神话: ：敏捷表示XP和Scrum

事实: ：还有其他做法，例如OpenUP，AMDD，等。

Answer 14

很容易知道如何向客户收费。 这对我们来说是最大的问题，因为我们不知道该项目的范围我们不能给客户以固定价格给客户，而且大多数客户都需要固定价格。

Answer 15

很棒的线程。虽然我在相关的博客文章中没有提供任何新内容，但我确实说明了敏捷失败时失败的两个原因。 1）缺乏前期要求（将“开始编码不完整的要求”到极端）和2）缺乏适当的单位测试（因为会发生变化 - 单位测试是捕获所有因素的最快方法改变）。

http://www.anujvarma.com/blogengine.net/post/2010/11/11/03/agile-versus-flat-fook-development.aspx

Answer 16

您完全正确的是，敏捷周围有很多神话，有些来自外面，有些来自内部。我想到的还有一些要添加到列表中：

“您不再需要项目经理或业务分析师”

尽管我们没有做BDUF，而团队则是自我指导的，但随着事情的规模扩大，他们的工作正在协调正在发生的事情。而且，如果您的业务场景非常复杂，那么您很可能需要有人来帮助您理解它。 IME，许多真正需要PMS和BAS的项目仍然需要它们（以及现在不需要的项目，可能永远不需要它们！）。但是，当然，PMS和BAS的角色在敏捷世界中往往会有所不同，这可能会使人们感到不安。

“敏捷不能用于固定价格项目”

它可以，但是要困难得多。特别是因为我们都知道“固定价格”确实意味着“固定价格，范围和时间” ...

“我们不做bduf，我们会在我们前进时做所有事情”

唯一的工作方法是Jeduf（前面是足够的设计）。有时您需要更多，有时您可以用更少的钱获得，但是当时您的所作所为并不多。

Answer 17

神话： 敏捷是对安全性的反感。

事实： 只有在您试图将成熟的瀑布风格的SDL（安全开发生命周期）迫使敏捷团队迫使，这是事实。实际上，我已经在众多组织中设计和实施了敏捷SDL变体，我可以说将敏捷的变体放置 进入 安全实际上可以负担得起更高，更强大的安全性。它只需要改变安全性思维方式 - 从 控制 至 能见度 和 指导.

Answer 18

如果您没有用敏捷表现出真正的价值，它将失败。就像破产的公司惨败一样，失败了。敏捷只是因为它是“敏捷”的，这会让您看起来像本视频中的CIO一样愚蠢：

http://www.youtube.com/watch?v=nvks70pd0rs

约翰