问开发团队的开发理念

EN

作为一个承包商，你可能没有什么影响力来影响某一特定公司的开发哲学的改变。这是大多数公司认为是临时工的代价之一。对于一个人来说，有时候你能做的最好的事情就是学会适应当前的企业文化，了解什么是有效的，什么是不可行的，当你处于影响的地位时。

您始终可以自己执行测试驱动的部分，因此至少您知道您的代码将通过测试。我也不会把它看作是开销，它是编写代码的一部分，用来测试它是否正常工作。与不编写测试相关的开销要大得多。

如果一个地方没有特定的开发方法，那么有两种方法可以得到。首先，如果开发人员大多同意使用什么，而他们只是开始使用它，并显示管理，它的工作和改进的产品。与其他专业相比，开发人员非常自由地想出了如何做他们的工作。利用这个对你有利。把一小群志同道合的人聚在一起，开始使用一种大家都同意的方法。向新来的人灌输你做事的方法。表现出真正的进步，管理层也会参与其中(经理们喜欢任何让他们看起来不错的事情)。

改变企业文化的第二个方法是自上而下。改变一位高级经理这样做的想法，他就可以强制使用新的方法。它不漂亮，人们会为此而斗争(这叫做抵抗改变，这是一种正常的状况，你需要期待它的处理)。再一次建立一些成功，它会变得容易，但你的经理必须有进取心，坚持的政策，通过艰难的阶段，让人们使用新的方法，必须有后果，谁不遵循新的方法。有时候，与志愿者一起进行测试项目，先使用该方法可以向其他人证明其价值，有时，人们只是呆板的人，无论如何也不会改变。

一些人，经过一段时间和多重机会的改变，仍然拒绝加入新的政策将需要放手，不管他们是多么好的个别开发商。如果你不能遵守团队规则，你需要继续前进或者继续前进。如果没有每个人最终都加入进来，文化变革就不可能实现。

有时，你可以利用外界的影响，让管理者改变经营方式。我们在这里改变了我们的整个开发过程，以获得我们最大的客户之一所要求的认证。HIPPA和萨班斯-奥克斯利法案也是许多公司正规化开发过程的责任。如果你能证明这一过程的正规化以获得某种认证或遵守法律是一种好处，这将给他们带来更多的生意，那么他们也许会突然意识到这一价值。

这是非常主观的，但你需要阅读这些方法，看看你的工作流程在某种程度上是否匹配，然后使用所有方法的想法来改进事物。所有的团队都是不同的，根据工作的性质、启动、维护和运行项目的方式，所有的方法都是不同的。

与团队交谈，讨论他们愿意做什么/改变什么，而不是试图强加给他们一些东西。你会遇到接受和改变的问题。

这一切都是为了沟通，是的，这是必需的。

我的客户使用各种各样的方法(敏捷/Scrum/XP等等)。从我的角度来看，我看不出它们之间在性能上有什么差异。

但是，我确实看到了使用这些方法的不同方面的团队之间的生产力差异。特别是持续集成(CI)、TDD和创建/维护测试的意愿，以及经常/定期发布。我所使用过的团队往往会成功(不管他们称其方法如何，有站立式的会议等等)，而那些并不倾向于挣扎的团队。

我不清楚你是否使用这样的方法(我不认为你会这么做)，但我建议你引入特定的实践(很可能是CI/TDD)，然后从那里开始工作，而不是推动一种方法。我认为这将是一个更容易的药丸，让你的同事吞下，并提供最大的好处。当然，您必须执行TDD方法，我会让管理层尽早投入进来。