如果我不喜欢敏捷方法论，这会让我成为一个糟糕的程序员吗？[关闭]

我喜欢小迭代。我喜欢单元测试。我喜欢代码审查。我不喜欢的是很少或根本没有文档的开始。我一个人吗？我是否只是对该过程有误解？

任何想法将不胜感激。

请记住，敏捷并不意味着没有文档，敏捷意味着您了解“客户”并不了解他们想要的一切，因此他们不能给您提供概述所有内容的庞大需求文档。敏捷倡导者，您经常与客户交谈并说：“这是您想要的吗？” 或“发生Y时X将如何工作？” 所以一起创建需求。

就是说，如果您不喜欢特定的方法论，那没有错。无论如何，大多数人似乎都会选择不同方法的各个方面。

敏捷方法论指出，您当时仅做您需要做的事情。如果您想要/需要的文档多于给定的文档，那么这就是过程中的问题，不是您自己。有时，需要大量文档才能使项目继续进行。需要这一点与敏捷并不矛盾。您不能以敏捷为幌子放松需求。这实际上是我所看到的一个大问题。很多人会先懒起来，然后将其归纳到整个过程中。真正的问题需要问：“开发人员有他们需要的吗？” 如果答案是否定的，则需要做更多的工作。

现在可以将其推到极致，有人可以说：“除非记录了整个程序，否则我将无法进行工作。” 有时候这是真的，但是团队需要看一下，看看是否真的必要。

我不明白为什么会因为您不喜欢特定的方法而使您成为一名糟糕的程序员。这可能会使您难以与实施此功能的商店集成；话虽这么说，我对它在任何地方的实施效率都有些怀疑。

使您成为不良程序员的原因是糟糕的代码-我知道这很容易-但是您可以喜欢/擅长使用所有喜欢的方法，并且仍然会成为不良程序员，因为您的代码不足。

敏捷的基本思想是，除非您有预见能力，否则您将无法预见未来。因此，您无法记录，无法预见。

这并不意味着您根本没有任何文档。您可以记录当前需求的技术设计（当然也可以记录需求本身），并记录当前的实现。您无需记录系统将如何处理10个以上的冲刺，因为您生活在动态的世界中，需求可能会发生变化。

我认为您误会了这个过程。您想要什么文件？开始之前，您需要某种目标。我从与客户交谈中收集到的用例开始。我不会花几天时间制作精美的图表。我们进行交谈，然后编写一个Wiki页面，然后进行介绍。然后我写一些测试。然后我写一些代码。

团队规模，领域，语言，个性，预算和要求是无限的组合。没有一种方法适合每种情况。同样，很多人都有个人喜好和风格。

即使您不喜欢它，也值得尝试新的想法来严格分析结果。有很多我不喜欢的东西，但是尝试了一段时间后才学会了爱。像橄榄。

另一件事是时尚定期变化。我与Waterfall一起成长，当时我在一个团队中工作，试图在Rational Unified Process中做所有事情，这在当时是“最好的”。很快，敏捷将被更新和更好的东西取代，没有人会再提到敏捷一词。

因此，不要觉得您需要像敏捷这样的一种方法。（我个人不喜欢）它不会使您成为一个糟糕的程序员。