33

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

一个普通的新手可能会陷入与敏捷相关的许多误解。敏捷世界中存在哪些误解？您如何证明这确实是一个误解？

更新：敏捷神话总结

  • 敏捷不允许文档
  • 敏捷方法无法扩展
  • 敏捷意味着没有计划
  • TDD 涵盖了所有的单元测试需求
  • 结对编程总是会产生更好的代码
  • 敏捷是解决软件工程问题的灵丹妙药（有灵丹妙药的解决方案）
  • 敏捷不需要预先设计
  • 我们正在做 scrum，所以我们不需要做 TDD、重构对编程等。
  • 可以从一本书中学习敏捷
  • 敏捷只适用于琐碎的项目
  • 敏捷总是使用“用户故事”

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

4

18 回答 18

21

“工作软件优于综合文档”意味着您不需要功能规格......

错误的！！！这只是意味着您可以与用户反复消除皱纹 - 作为供应商，您仍然需要良好的文档来协助 QA 和签核阶段......

于 2009-12-09T01:41:39.603 回答
20

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

  2. 测试驱动的开发不会发现所有的错误/不容易应用到所有东西——所以我们不打算尝试！- 学习 TDD 不是“全有或全无”，您可以更好地判断要测试的内容以及如何有效地进行测试。我已经做了十年了，我仍在寻找更好的方法和新的考虑。

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

  4. 歇斯底里的（而且非常真实）“候选人必须接受 Scrum Master 的指导并支持他们”（来自我上周发送的一份工作规范……） ——Scrum Master不应该告诉人们该做什么。他/她是为了促进——即帮助团队学会自己解决问题。这是一个巨大的失败模式——拥有一个“指挥”人们的 scrum master！

  5. 谈论“敏捷方法论” - 大无知指标。首先，谈论“敏捷”就像它是一个特定的东西，而它是一个非常模糊的涵盖许多不同事物的总称。其次，使用“敏捷”方法——有很多方法，并且有很多不同的方法来做这些方法！第三，敏捷社区中的很多人都是在反对 90 年代庞大、繁重的 UML 方法时来到这里的。这些人不倾向于使用“方法论”这个词......

  6. 您需要特别有才华的人以敏捷的方式开发软件。Jeff Sutherland 表示，他们曾考虑使用“首席程序员团队”模式来管理银行团队——但发现他们没有足够的“首席”。Scrum 旨在让许多能力中等的程序员获得最佳生产力。事实上，移除一个不想帮助其他人的生产力不成比例的团队成员可以“解开”平庸的团队成员，并使他们的综合生产力超过对超级生产力的前团队成员的补偿......这就是杰夫反正说...

在我最近领导的一个开放空间研讨会中，我们提出了很多其他与 XP 相关的问题：http: //xpday-london.editme.com/WhereHasXpGone

于 2009-12-09T12:00:15.577 回答
18

误区：使用敏捷开发实践是解决软件工程问题的灵丹妙药。

于 2009-12-09T01:50:25.173 回答
15

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

事实：许多开发人员变得懒惰，他们在编写代码之前编写的单元测试通常很弱且不充分。

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

事实：程序员往往有点反社会，并且彼此之间有明显不同的思维过程。在你编写代码时有人在你的脖子上喘气是非常不愉快的，结果通常是紧张的工作气氛，代码质量和数量都下降了。

于 2009-12-09T01:48:03.353 回答
10

误区：敏捷意味着没有文档

事实：敏捷比综合文档更重视工作软件，但这并不意味着根本没有文档。文档应该及时编写，并且足够。不，敏捷并没有说应该总是使用用户故事。当且仅当它们合适时才使用它们！

误区：敏捷意味着没有计划

事实：敏捷不支持没有计划的开发。敏捷使用持续的计划和估计来最大化投资回报率。实际上，敏捷是关于范围管理的。

误区：敏捷意味着没有纪律

事实：敏捷开发人员必须更加自律才能成功。

误区：敏捷只适用于琐碎的项目

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

  • FDA 批准的生命关键型 X 射线和 MRI 软件，
  • 金融支付应用，
  • 24x7 具有 99.99999% 的正常运行时间要求，
  • 多 TB 的数据库应用程序，
  • ETC

误区：敏捷无法扩展

事实：Sutherland 以 500 多人为一组使用 Scrum，Cohn 以 100 多人为一组使用 Scrum

于 2009-12-10T15:05:07.247 回答
8

误区：“没有预先设计”意味着没有设计。

于 2009-12-09T06:08:09.093 回答
6

神话：瀑布总是失败。

现实：您在敏捷项目中使用的大多数软件都是使用瀑布式开发的。在很多情况下，甚至是 BDUF 瀑布。

于 2010-01-12T21:46:11.220 回答
4

没有真正的神话——但任何极端的事情都是错误的。一个进行零设计以期“随心所欲地设计”的敏捷项目很可能会失败。由于预算、时间或用户需求的变化，将所有内容都设计到最后一个分号的瀑布项目可能会失败。

于 2009-12-09T01:57:48.497 回答
3

人们反复说“敏捷设计方法无法扩展”，而如果实施和考虑得当，敏捷开发将有效地扩展到任何规模。

于 2009-12-09T02:02:42.877 回答
2

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

这是我们多年来在这个行业看到的常见的银弹蛇油。

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

于 2009-12-10T06:15:27.963 回答
2

误区：您需要仔细计划和安排每个 sprint。

这会导致您进行大量的前期计划，以便您可以充分计划每个 sprint。

这会导致你打败敏捷并创建一个名为“敏捷”的瀑布。

于 2009-12-09T01:53:08.103 回答
1

误区：敏捷意味着 XP 和 Scrum

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

于 2009-12-17T07:30:07.483 回答
1

误区：与其他替代方案相比，敏捷始终是更好的选择。

事实：根据项目规模、要求（尤其是此类的灵活性）、外部时间表和客户态度，与传统方法相比，它可能并不总是更有效率。

于 2009-12-10T05:56:24.483 回答
1

很容易知道向您的客户收取什么费用。这一直是我们最大的问题，因为我们不知道项目的范围我们不能给客户一个固定的价格，而且大多数客户要求一个固定的价格。

于 2010-02-02T09:17:28.763 回答
1

很棒的线程。虽然我在我的相关博客文章中没有提供任何新内容，但我确实说明了敏捷失败时失败的两大原因。1) 缺乏前期需求（将“以不完整的需求开始编码”发挥到了极致）和 2) 缺乏足够的单元测试（因为会发生变化——单元测试是捕捉由改变）。

http://www.anujvarma.com/BlogEngine.net/post/2010/11/03/Agile-versus-Flat-Footed-development.aspx

于 2010-11-16T16:46:50.147 回答
0

Myth: Agile is anti-thetical to security.

Fact: This is only true, if you try to force a full-blown waterfall-style SDL (security development lifecycle) onto supposedly Agile teams. In fact, I have designed and implemented Agile-SDL variants in numerous organizations, and I can say that putting the Agile into the Security, can actually afford a higher, more robust level of security. it just takes a change of security mindset - from control to visibility and guidance.

于 2010-06-26T22:13:42.270 回答
0

如果你没有展示敏捷的真正价值，它就会失败。并且惨败如在一家公司惨遭破产。仅仅因为它是“敏捷”而转向敏捷会让你看起来像这个视频中的 CIO 一样愚蠢：

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

约翰

于 2011-11-09T01:07:23.240 回答
0

你完全正确，关于敏捷有很多神话，有些来自外部，有些来自内部。以下是我想添加到列表中的更多内容：

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

虽然我们没有做 BDUF 并且团队是自我指导的，但随着事情的扩大，仍然需要负责协调正在发生的事情的人。如果您有一个非常复杂的业务场景，您可能需要有人帮助您理解它。IME，许多真正需要 PM 和 BA 的项目仍然需要它们（而那些现在不需要它们的项目，可能永远不需要它们！）。但是，当然，在敏捷世界中，PM 和 BA 的角色往往不同，这会让人们感到不安。

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

可以，但是难度比较大。尤其是我们都知道“固定价格”真正意味着“固定价格、范围和时间”......

“我们不做 BDUF，我们一边做一边做”

唯一的工作方式是 JEDUF（Just Enough Design Up Front）。有时你需要更多，有时你可以用更少的钱过日子，但此时你做的事情并没有超出你的需要。

于 2009-12-10T06:10:31.060 回答