我们为什么不能完成任何事情？

我在一个中等规模的公司的一个小团队中工作，其中大多数不参与软件开发。我是最新的，经验最少的开发人员，在开始之前没有软件方面的专业或学术背景，但是我对自己的投入受到尊重感到非常满意，并感谢在职业生涯的这么早就被认真对待。

尽管如此，我觉得我应该在如此充裕的通话时间内做更多的事情。作为一个团队，我们似乎很难完成工作。我希望能够提出一些建议来改善这种情况，并且我想如果这是个好主意，我会听取的，但是我对所提建议不知所措。

我可以确定为问题的事情包括：

• 对当前任务的说明很少。部分原因是管理是瓶颈，而我们没有钱或人来承担我们想要的尽可能多的详细需求。这也部分是因为我们正在开发的软件正在调查中，确切的方法尚待证明并用于确定其有效性之前尚不清楚。
• 首席开发人员非常喜欢他所说的“原型”，以至于他最近开始坚持认为所有东西都是“原型”，对我们其他人来说，这就像在编写不良代码并将其交给建模者一起玩。在许多情况下，尚不清楚他期望从这项练习中得到什么。然后，由于他坚持认为良好实践会花太多时间来制作原型，因此“实际”实现会遭受损失。我什至没有开始能够解开这种扭曲的逻辑，而且我不确定是否要尝试。
• 建模人员应该精确地告诉我们有关所需方法的所有信息，并且绝对相信他们提出的理论上是完美的。这几乎是不可能的，但是没有采取任何纠正措施。建模方面的任何人都不会以可能采取行动的结构化方式提出任何问题，也不会寻求应用最佳实践的指导。他们的被动性也没有做。
• 我以前曾尝试将TDD推入团队，但由于它对我来说是新事物，因此发现它很困难，尽管那些对我的工作负责的人愿意容忍它，但其他任何人都没有热情。我无法证明我花了很多时间去完成功能而不花时间，所以这个想法暂时被放弃了。我担心它不会再被捡起，因为没人喜欢被告知如何做他们的工作。
• 现在，我们有一个持续集成服务器，但它主要仅用于运行多个小时的回归测试。它应该也应该运行完整覆盖的单元和集成测试，但目前还没有人编写它们。
• 每次我与首席开发人员提出质量问题时，都会得到以下答案：“测试功能A很简单，功能B对用户来说更重要，但测试却太难了，因此我们不应该测试功能一个'。我再一次没有尝试解开这种逻辑。

.... phe 当我这样说时，它看起来比我想的要糟得多。事实证明，我想这是在寻求帮助。

让我扮演恶魔的拥护者片刻：

对手头任务的说明很少...首席开发人员非常喜欢他所说的“原型设计”

首席开发人员喜欢制作原型，因为规格很少。这可能是一件好事。这就是迭代商店的工作方式。

建模人员应准确地告诉我们有关所需方法的所有信息

这在迭代商店中不起作用。迭代开发的本质是需求通常是不完整的。迭代是充实需求的基础。

我之前曾尝试在团队中推广TDD，但由于它对我来说是新事物，所以发现它很困难

这也不行；您需要先了解这项技术，然后才能进行传播。此外，在要求很少的迭代商店中，TDD可能会产生过多开销。最好鼓励足够的单元测试覆盖范围。

现在，我们有一个持续集成服务器，但它主要仅用于运行多个小时的回归测试。

在小型的迭代商店中可能是合适的。

每次我与首席开发人员提出质量问题时，都会得到以下答案：“测试功能A很简单，功能B对用户来说更重要，但测试却太难了，因此我们不应该测试功能一个'

听起来您的商店有一些相当紧张的时间限制；不管您喜欢与否，都受这些约束的约束。

听起来您也来自软件行业的一部分，他们重视“正确的方式”做事，而不是先将产品推向市场。这没什么不对（事实上，这是令人钦佩的），除了第一个使用越野车软件的人通常是赢家。这不公平，但是事实就是如此。

我将在这里重点介绍原型

原型的主要问题是它们只是作为概念证明

但是，如果您无法在原型上进一步构建，并且需要从头开始重建最终产品，那么您可能还没有构建原型，并且浪费了构建时间

我对您的团队的建议是在这些原型中获得一定的质量和灵活性。我知道不可能一开始就创建完美的东西，但要尽量保持可扩展性以适应未来的需求

这些是很好的答案。我只能补充说，“尝试交流”充其量是一个艰难的提议。组织工作方式的变化不会很快发生。当发生这种情况时，通常就像潮水一样，动量从下方和上方形成。因此，如果您对期望值保持较低的期望，或者等待机会说出事情将如何完成，或者期待与另一个组织合作，就会感到更加快乐。

您是否已找到公司中“得到”的人，请锁定此人并从他那里学到很多东西。如果没有，请花点时间，自己开始学习并成长（加入一个开源项目或开始自己的项目），然后寻找一个可以促进自己成长的地方。

可能发生的最糟糕的事情是您呆在那里，学习如何以错误的方式做事。是的，应该采取一些务实的态度，但是一支真正熟练的团队可以以正确的方式做事，并且仍能按时交付高质量的产品。听起来您当前的团队没有能力，您应该开始寻找新的团队。