问敏捷神话与误解

EN

1. "We're做scrum -所以我们不需要(结对、重构、做TDD .)“实际上是Scrum的创始人-- Ken和Jeff一直在说，所有高效的Scrum团队都实现了全部的极限编程practices.
2. Test-driven开发不会发现所有的bug/不容易应用于所有的东西--所以我们不会尝试！--学习TDD并不是”全部或没有交易“，您可以得到更好地判断该测试什么以及如何有效地进行测试。我已经做了十年了，我仍然在寻找更好的方法来做这件事，consider.
3. I的新东西可以从一本书中学到我所需要的所有应用敏捷方法。--你需要通过做来学习，这通常意味着指导和会见其他可以帮助你的人。当人们试图从book.
4. Hysterical (也是相当真实的)那里学到它时，很多事情都出了问题--“应聘者必须听从并支持scrum主人”(我上周收到的一份职务说明)-- scrum的主人不应该告诉人们做什么。他/她在那里是为了方便--即帮助团队学会自己解决问题。这是一种大规模的失败模式--拥有一个“命令”people!
5. Talking关于“敏捷方法”的scrum大师--一个巨大的无意义指示器。首先，把“敏捷”说成是一个特定的东西，而对于许多不同的事情，它却是一个非常模糊的总括术语。其次，使用“敏捷”方法--有大量的敏捷方法，以及许多不同的方法！第三，敏捷社区中的许多人对90年代大量使用UML的方法产生了强烈的反感。这些人不喜欢用“方法论”这个词.
6. You需要特别有才华的人来以敏捷的方式开发软件。杰夫·萨瑟兰( Jeff )表示，他们考虑过使用“首席程序员团队”模型来管理银行的团队，但发现他们没有足够的“首席执行官”。Scrum的设计是为了从许多中等能力的程序员那里获得最佳的生产力。事实上，除去一名不愿帮助其他团队成员的工作效率过高的团队成员，可以“解除”平庸的团队成员的障碍，并将他们的综合生产力提高到足以补偿超级高效的前团队成员……杰夫是这么说的.

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

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

错了！这只是意味着你可以反复解决与用户的皱纹-作为一个供应商，你仍然需要良好的文件，以协助QA和签署阶段.

神话:使用敏捷开发实践是解决软件工程问题的灵丹妙药。