1

我已经开发了几年,并且对我团队中的一些年长程序员如何在没有任何开发理念的情况下进行设计和实现感到沮丧,这通常会导致开发轨道进一步出现问题,通常是由于缺乏灵活性和有效性。我向我的同事提出了这个问题,他们回答说:“那么,你建议我们使用数百种开发理念中的哪一种?”

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

我的问题是

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

  • 你遇到了什么问题,你是如何克服的?

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

4

5 回答 5

2

作为承包商,您可能无法影响特定公司的发展理念变化。这是大多数公司认为临时的价格的一部分。作为一个人,有时你能做的最好的事情就是学习适应当前的企业文化,并了解在你有影响力的情况下什么是有效的,什么是无效的。

你总是可以自己做测试驱动的部分,所以至少你知道你的代码会通过测试。我也不认为这是开销,它是编写代码以测试它以确保它工作的一部分。与不编写测试相关的开销要多得多。

如果一个地方没有特定的开发方法,那么有两种方法可以得到一个。首先是如果开发人员大多同意使用什么理念,他们只是开始使用它并展示管理它的工作原理并改进产品。与许多其他专业人士相比,开发人员可以非常自由地弄清楚如何完成他们的工作。使用它对您有利。召集一小群志同道合的人,开始使用你们都同意的方法。向小组中的任何新人灌输你如何做事。表现出真正的进步,管理层会参与其中(经理喜欢任何让他们看起来不错的东西)。

改变企业文化的第二种方式是自上而下。改变一位高级经理的想法,他可以要求使用新的方法。这并不漂亮,人们会为此而抗争(这被称为抵制变革,这是一种正常情况,你需要期待处理它。)再次取得一些成功,它会变得更容易,但你的经理必须有勇气在让人们使用新方法的艰难阶段坚持政策,对于那些不遵循新方法的人必须承担后果。有时,与志愿者一起进行测试项目首先使用该方法可以向其他人证明其价值,有时,人们只是死木,无论如何都不会改变。

那些在经过一段时间和多次改变的机会后仍然拒绝接受新政策的人,无论他们作为个体开发人员有多优秀,都需要被放手。如果您不能遵守团队规则,则需要继续前进或继续前进。如果没有每个人最终都加入进来,就无法实现文化变革。

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

于 2009-09-09T17:41:24.703 回答
1

它非常主观,但是您需要阅读这些方法,看看您的工作流程是否以某种方式匹配,然后使用所有方法的想法来改进事物。所有团队都是不同的,方法论的工作方式都不同,具体取决于工作性质、启动、维护和运行项目的方式。

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

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

于 2009-09-08T08:03:52.980 回答
0

我的客户使用各种方法(敏捷/Scrum/XP 等)。从我的角度来看,我没有看到这些之间的性能差异。

但是,我确实看到使用这些方法的不同方面的团队之间存在明显的生产力差异。特别是持续集成 (CI)、TDD 以及创建/维护测试以及经常/定期发布的意愿。使用这些方法与我共事过的团队往往会成功(不管他们如何称呼他们的方法,有站立会议等),而那些不会遇到困难的团队。

我不清楚您是否使用此类方法(我认为您不会),但我建议您引入特定实践(最有可能是 CI/TDD)并从那里开始工作,而不是推动一种方法论。我认为这将是您的同事更容易吞下的药丸,并提供最大的好处。当然,你必须强制执行 TDD 方法,我会让管理层尽早接受这一点。

于 2009-09-08T08:11:41.303 回答
0

真正理解一种方法的全部潜力(和局限性)需要多年的经验,甚至需要更多的时间来理解何时使用什么。

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

培训您的同事并分享您的愿景也很重要,这样他们才能真正理解为什么每个人都必须遵循这些原则。如果您已经知道缺点是什么,也请分享它们,并确保您清楚地说明该方法的好处如何超过坏的方面。

不过,说起来容易做起来难。最重要的是有一个开放的对话,让每个人都明白你为什么和你在做什么。

于 2009-09-08T08:13:34.127 回答
0
  1. 识别威胁项目成功的风险,对它们进行优先级排序,并首先使用短迭代来攻击最严重的风险,这些迭代通过成功的测试执行客观地展示了解决方案。

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

  3. 在发现它的迭代期间纠正每个缺陷。

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

于 2009-09-08T08:57:03.710 回答