您的团队在不遵循工作方法（例如Scrum）的情况下运作良好吗？

在过去的9年中，我曾在许多小型团队中工作。每个人都有明显的良好做法，例如短期会议，版本控制，持续集成软件，问题跟踪等。

在这9年中，我从未听说过很多开发方法。例如，从来没有过“我们在做Scrum”，“让我们敏捷”，或者是传递引用。所有团队的运作似乎都很好，没有经过很多程序，我们只是自由流动，自然就很好。

有没有其他人长时间进步而没有遇到混乱/敏捷/等问题？

我唯一接触过这些内容的地方就是通过此类网站。我读过诸如Sprint Meetings之类的问题-谈论什么 ...，所有的讨论似乎都描述了几乎机器人，就像遵循方法论有限状态机的人一样。真的（尽管有些夸张）吗？我想知道在互联网上发布的人们是否只是“最佳实践”的拥护者，具有类似的教科书观点，没有真正反映人们的工作方式吗？或者我遇到过一些团队自然地制定自己的流程。

此外（我在英国，这可能是相关的）...我认为，如果将一种方法论引入我要研究的任何团队中，他们只会拒绝它是愚蠢且不必要的...然后上。我倾向于同意，遵循流程似乎有些不自然。这是典型的还是常见的？

这里有20多年的开发经验，而且我从未使用过正式的方法。从来不需要它们，而且我不打算在将来使用它。方法对于某些人来说可能不错，但是它们不能替代编写优秀的，经过测试的代码的熟练程序员。

就个人而言，我认为很多人应该减少对当天最热门新方法的关注，而将更多的精力放在代码质量上。

老实说，如果您的小型团队多年来一直在没有重大事件的情况下进行良好的工作，而不考虑流程，那么您可能正在进行某种形式的敏捷。敏捷过程的全部意思是，它遵循“敏捷宣言” http://agilemanifesto.org/，其中很少涉及迭代，故事板等内容。敏捷的第一个租户是您喜欢“个人和通过流程和工具进行交互”。任何团队合作得很好，实际上并不需要认真考虑流程。

如果您拥有一个不习惯彼此合作的全新团队，则不同品牌的敏捷（例如Scrum等）非常有用。他们为建立一支具有凝聚力的团队建立了框架，这反过来又将建立一个具有凝聚力的产品。

如果您正在做什么，请继续做。如果您在交付方面经常迟到，或者必须定期加班，或者在部署某些东西之后必须修复主要的错误，那么那是错误的。到那时，您需要进行一系列小的更改来解决问题。

如果一切都很好，并且总会很好，那么就没有问题-因此，引入一种新的方法（您的团队将遵循某种方法论–正式的或其他方法）确实会浪费时间。

方法论真正有用的地方是团队遇到问题或从外部来源遇到问题时-方法论不仅会引入良好实践，还可以帮助您保护它们。当您有意识地进行良好实践时，在压力下保持良好作法要容易得多，否则会很快被淘汰。

我认为您不一定需要一种正式的方法，但是每个团队都需要某种形式的模式（不一定是重复的，它可能是事件驱动的）才能有效实现恕我直言。

如果您没有问题要解决，那就很幸运。

我已经看到许多团队（尤其是在非常小的公司中）在没有任何确定的方法的情况下工作良好。

因为有趣或因为您在互联网上阅读了博客文章而实施一种方法（或技术）非常危险。

如果您还好，请不要进行任何更改。只要可以就尝试一些优化。

他们有很多方法学，其中有些很明智，有些则疯狂。他们似乎都编纂了常识，给他们起了一个有趣的名字，然后卖了很多书/研讨会/等。

现在，如果您的管理层或您的团队缺乏常识，并且没有有机地建立自己的明智方法（无论是有意还是无言），那么可能值得研究，然后再考虑方法论的各个部分与该团队的经验有关。

一劳永逸地采用最新的<insert-buzzword-here>工作实践可能会引起比其目标要解决的混乱。但是通常可以提供许多复选框指标，非代码部门经理可以热情地打勾。

也许您没有称其为敏捷或混乱，但这并不意味着您没有任何流程并且没有使用它。

就像软件开发本身一样。即使您没有明确考虑它们的名称，您也可能会使用几种设计模式。