agile - 敏捷神话和误解

Closed. This question is opinion-based。它当前不接受答案。












想改善这个问题吗？更新问题，以便editing this post用事实和引用来回答。

7年前关闭。



Improve this question




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

对于普通新手可能会陷入很多与敏捷相关的误解。在敏捷世界中有什么误解，您如何证明它确实是一种误解？

更新:敏捷神话摘要

Agile不允许文档

敏捷方法无法扩展

敏捷意味着没有计划

TDD涵盖了所有单元测试需求

配对编程总是可以产生更好的代码

敏捷是解决软件工程问题的灵丹妙药(有一个灵丹妙药解决方案)

敏捷不需要前端设计

我们正在做Scrum，所以我们不需要进行TDD，重构对编程等。

可以从一本书

中学习敏捷

敏捷仅适用于琐碎的项目

敏捷始终使用“用户故事”

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

最佳答案

“我们正在做Scrum-因此我们不需要(配对|重构|做TDD | ...)” 实际上，Scrum创始人-Ken和Jeff一直在说所有高生产率的Scrum团队都在实现全面的极限编程实践。

测试驱动的开发无法找到所有错误，也不容易将其应用于所有内容-因此我们将不尝试! -学习TDD并非“一事无成”，您可以更好地判断要测试的内容以及如何有效地进行测试。我已经做了10年了，但我仍在寻找更好的方法以及需要考虑的新事物。

我可以从书本中学到所有应用敏捷方法所需的知识。 -您需要边做边学，这通常意味着指导和认识可以帮助您的其他人。当人们只是尝试从书中学习时，很多事情都会出错。

歇斯底里的(而且很真实)“候选人必须从方向出发，并支持Scrum管理员”(摘自上周我发送的一份工作说明...)-Scrum管理员不应告诉人们什么做。他/她在那儿为您提供帮助-即帮助团队学习自行解决问题。这是一个巨大的失败模式-拥有一个Scrum Master来“指挥”人们!

谈论“敏捷方法论” -大的无能指标。首先，谈论“敏捷”就像是一件事，而对于许多不同的事物来说，这是一个非常模糊的保护性术语。其次，使用“敏捷”方法-有很多方法，还有很多方法可以做到很多!第三，敏捷社区中的许多人对90年代繁重而繁重的UML加载方法感到强烈反对。这些人不倾向于使用“方法论”一词...

您需要特别有才华的人员来敏捷地开发软件。 Jeff Sutherland说，他们考虑使用“首席程序员团队”模型来管理银行中的团队-但是发现他们没有足够的“首席”。 Scrum旨在从许多中等能力的程序员中获得最高的生产率。实际上，删除一位不想帮助其他人的生产力过高的团队成员可以“解除限制”那些平庸的团队成员，并使他们的综合生产力提高到足以弥补前生产力过高的团队成员的代价……这就是杰夫反正说...

在我最近主持的一个开放空间研讨会中，我们想到了和其他许多与XP相关的:http://xpday-london.editme.com/WhereHasXpGone

关于agile - 敏捷神话和误解，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/1871110/