开发团队的发展理念

Question

我已经开发了几年了，并且对我团队中的一些老程序员在没有任何开发理念的情况下进行设计和实现的方式感到沮丧，这通常导致问题进一步发展，一般是由于缺乏灵活性和验证。我和同事们提出了这个问题，他们回答说：“那么，你建议我们使用哪几百种发展理念？”

这是一个难以回答的问题，因为在自己工作时使用开发理念比在团队中工作要容易得多。我对测试驱动开发有点偏爱，因为它似乎为我提供了最好的安全感，我的代码工作正常，但TDD确实有其局限性，主要是编写所有测试所需的开销以及确保我们的测试框架没有差距（在团队中工作很难实现）。我的一位朋友在敏捷统一流程（AUP）中发誓并拒绝使用其他任何东西。

我的问题是

• 您发现哪些开发理念在团队开发中运作良好，以及它们如何帮助您按时在预算内交付产品？

• 您遇到了哪些问题以及如何克服这些问题？

• 你认为它们甚至是必需的吗？

Answer 1

作为承包商，您可能几乎没有影响特定公司的开发哲学的变化。这是大多数公司认为温度的价格的一部分。对于你这样的人来说，有时你能做的最好的事情就是学会适应当前的企业文化，并了解当你有能力影响时，什么是有效的，什么是无效的。

你总是可以自己做测试驱动的部件，所以至少你知道你的代码会通过测试。我也不会将其视为开销，它是编写代码以测试它确保其工作的一部分。没有编写测试会产生更多的开销。

如果某个地方没有特定的开发方法，那么有两种方法可以获得一种方法。首先，如果开发人员大多同意使用philosphy，他们只是开始使用它并展示管理它的工作原理并改进产品。与许多其他专业专业相比，开发人员可以非常自由地了解如何开展工作。使用它对您有利。让一小群志同道合的人聚在一起，开始使用你们都同意的方法。在你如何做事的情况下，向团队中的任何新人灌输。显示真正的进步和管理将加入其中（管理者喜欢任何使他们看起来很好的东西）。

改变企业文化的第二种方式是自上而下。改变一位高级经理的想法，他可以强制要求使用新方法。它并不漂亮，人们会为此做斗争（这被称为变革阻力，这是正常情况，你需要期望处理它。）再次建立一些成功，它变得更容易，但你的经理必须在让人们使用新方法的艰难阶段中坚持使用政策，必须对那些不遵循新方法的人产生影响。有时与志愿者一起使用该方法的测试项目可以证明其他人的价值，有时候，人们只是枯木，无论如何都不会改变。

人们经过一段时间和多次改变的机会，仍然拒绝加入新政策，无论他们作为个人开发者有多好，都需要放手。如果您无法遵守团队规则，则需要继续前进或继续前进。如果没有人最终加入，文化变革就无法实现。

有时，您可以利用外部影响力让管理者改变经营方式。我们在这里改变了整个开发过程，以获得我们最大的客户之一所需的认证。 HIPPA和Sarbanes-Oxley法律也对许多公司正式确定开发过程负责。如果你可以提出一个案例来判断正规化流程以获得某种认证或遵守法律是一种可以让他们获得更多业务的好处，那么也许他们会突然看到价值。

Answer 2

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

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

一切都与沟通有关，是的，这是必需的。

Answer 3

我的客户使用各种方法（敏捷/ Scrum / XP等）。从我的角度来看，我看不出它们之间的性能差异。

但是，我确实看到使用这些方法的不同方面的团队之间存在明显的生产力差异。特别是持续集成（CI），TDD以及创建/维护测试的意愿，以及经常/定期发布的意愿。我使用这些团队的团队倾向于成功（无论他们称之为他们的方法，有站立会议等），以及那些不倾向于挣扎的团队。

我不清楚你是否使用这些方法（我不认为你这样做），而是推动一种方法论，我建议你引入特定的实践（很可能是CI / TDD）并从那里开始工作。我认为这对你的同事来说是一个更容易吞咽的药丸，并提供最大的益处。当然，你必须执行TDD方法，我会让管理层尽早购买。

Answer 4

真正了解方法的全部潜力（和局限性）需要多年的经验，甚至更多时间了解何时使用什么。

我认为最快的方式是阅读几个哲学的粗略描述，选择一个看起来最适合这种情况的那个，并且真正去做。最重要的是保持一个轨道。不要试图混搭。坚持一种范式并一直使用它。

同样重要的是培训您的同事并分享您的愿景，以便他们真正理解为什么每个人都必须遵循这些原则。如果你已经知道了它们的缺点，那么也要分享它们，并确保你明确这种方法的好处如何超过坏的方面。

但是，说起来容易做起来容易得多。最重要的是要有一个开放的对话框，这样每个人都能理解为什么以及你在做什么。

Answer 5

1. 确定威胁项目成功的风险，确定优先级，并首先使用通过成功执行测试来客观地证明解决方案的短迭代攻击最严重的风险。

2. 明确您的项目的目标，约束和架构，并确保团队的每个成员都理解它们。

3. 在发现它的迭代过程中纠正每个缺陷。

主要障碍始终是抵制变革。以身作则。