以生产为导向的开发（又称交付为驱动的开发）是取得优异成绩的必经之路

在我看来，定义生产/交付驱动的开发的动机是缺乏对所有其他DD中软件开发的最重要部分的关注。 最重要的是为最终客户提供价值，这是通过使用我们的软件达到量产而实现的。 大多数DD将此作为附带目标，而它始终必须是任何软件开发的主要目标。

生产/交付驱动开发中有4条规则

• 规则0 –尽快交付生产
• 规则1 –从用户角度看质量至关重要
• 规则2 –尽可能重复
• 规则3 –量身定制的方法

现在让我们更详细地看一下此规则。

规则0 –我们必须尽快达到生产，尽快交付价值

不幸的是，一遍又一遍被忽视的一件事是，最重要的事情是通过生产达到最终用户的价值。

没有人会在乎我们使用哪种编程语言，框架或库。 没有人会在乎我们编写的算法有多酷，或者是否有单元测试，或者是否使用TDD或BDD，或者都不使用它们，或者如果我们不使用Scrum或Waterfall，或者不使用它们，或者没有提供，价值或达到生产无所谓。

达到生产就是一切，应该尽快达到。 生产一直是我们始终关注的重点。

尽可能快的方式，因情况而异。 从性能，安全性和其他角度来看，创建银行或聊天程序对可以容忍的内容有不同的理解。 在确定当前速度时，我们需要考虑环境。

您可能会问自己，为什么达到生产如此重要。 只有进入生产阶段，我们才能验证所构建的产品是否良好，用户是否喜欢它以及用户与之交互时的行为。 只有在生产中，我们才能验证在构建软件时遵循的所有假设。 没有其他任何事情可以为我们提供100％保证的答案。

快速到达生产很重要，因为如果我们迟到，我们会发现有人已经击败了我们，并占领了整个市场。 我们还可以发现，当我们进入生产阶段时，我们需要做出很多改变。 如果我们花了很长时间到达那里，我们可能没有时间和预算进行必要的更改。

有时人们认为，如果他们“做Scrum”或“敏捷”，那就足够好了，并且可以解决。 不，不是，如果我们不将代码快速推向生产环境，那么其他任何事情都没有。 这与方法论无关，与思维定势以及我们关注的重点有关。

我们必须尽快达到生产要求，或者为失败做好准备。

规则1 –质量很重要，从用户的角度出发，我们必须始终在生产中拥有

如果我们设法非常快地达到生产，但是所有时间都在崩溃，那我们就杀死了我们的产品。

达到生产水平很重要，但是从用户的角度来看，生产质量也必须很高。 如果一切都在我们的系统中爆炸，但用户不知道它，那么一切仍然很好。 从上下文的角度来看，质量意味着不同的事物。 如果用户对温度或湿度感兴趣，则他们的期望将与通过在线服务转帐时的情况有所不同。

我们需要知道我们的产品在实际用户中的表现方式，以及这是否足够好。 请记住，足够好的是游戏的名称，我们应该力求比同一个领域的其他人更好，而不是完美。 这是微妙的差异，但很重要。 我们不应牺牲交货速度和其他所有条件，只是为了确保所有时间都完美无缺。 在大多数情况下，完美不是必需的，因此如果将其放在桌子上，挑战它，以及在这种情况下和上下文中完美意味着什么。

在大多数情况下，如果用户不时看到一些错误，他们会接受的，他们会刷新页面或在移动应用程序中查看，甚至可能不会注意到它。

当然，上下文在这里确实很重要，所以不要以这是一般规则，而是根据当前情况来适应质量的含义。

规则2 –我们必须尽可能经常地迭代我们的产品，不断发展并改进它

一旦投入生产，游戏还没有结束，它才刚刚开始。 请记住这一点。

我们必须继续迭代和发展我们的产品，使其变得更好，吸引更多客户，增加新功能。 我们需要尽可能频繁地并尽可能快地执行此操作。 一旦投入生产，我们将开始从用户及其行为中获得真正的反馈，我们将看到哪些部分是好的，哪些部分需要一起进行优化，修改或删除，以及哪些部分需要添加以满足用户的需求。

当然，根据当前的情况，我们可能面临的问题或局限性，尽可能快意味着不同。 例如，如果我们遇到很多问题，我们应该首先处理它们，然后集中精力发展我们的平台，否则我们可能会陷入更加糟糕的境地。

要记住的一件事是，即使我们今天排名第一，世界仍在不断发展，这并不意味着我们明天就会成为第一，甚至是至关重要的。 我们需要确保考虑用户反馈并尽快迭代解决方案，并确保我们始终处于最佳状态，否则我们可能很快陷入困境。

我们不仅需要达到生产水平，而且还需要确保呆在那里，并专注于我们所做的事情，当前状态和未来。

规则3 –根据当前问题，将交付的团队和所涉及的情况而量身定制的方法

人们常常希望拥有适合所有用例的最终解决方案。 老实说，产品不同，用例不同，团队不同，环境不同，技术不同。 在决定采取行动时，我们应该考虑到这一点。 我个人认为，对每个问题使用相同的方法，或者试图找到一种适合所有问题的解决方案，是一个错误的想法，注定会失败。 在一种情况下，某些东西可能会完美地工作，但在另一种情况下，这会很糟糕。 我们应该意识到这一点，知道什么时候有效，什么时候不起作用，一切都有局限性。

考虑到所有这些因素，令人惊讶的是，在生产/交付驱动型开发的情况下，没有一种适合所有用例的解决方案。 根据团队，正在构建的产品以及其他情况，我们将使用或组合不同的事物和方法来在目标时间范围内实现目标目标。 我们可能使用TDD或BDD或其他方法，或者在某个时间点只能使用其中的一部分，而在其他时间忽略它们。 我们可能会使用Scrum或看板，或者不使用上述任何一种。 有很多选择，我们应该在决定并投资之前了解它们如何适应更大的前景。 同样，重要的是不要把事情固定在一块，如果我们尝试某些操作而又行不通的话，请对其进行修改和验证。

我们应该考虑到自己的长处并在这些长处上建立基础，同时要意识到我们的短处，并选择可以帮助我们克服或控制它们的事物。 我们还需要时刻注意任何限制，例如在应该考虑的法规中可以使用或不能使用的红外线等。

真正重要的是构建什么，由谁构建以及在什么情况下构建。 可以遵循一些一般准则，但是多少实际上取决于很多变量，在大多数情况下，这些变量因情况而异。 我们应该查看所有最佳实践，看看哪些适合我们的用例，哪些不适合，我们已经处于良好的状态

例如，如果我们正在构建社交应用程序或类似的应用程序，我们可能需要非常敏捷和快速地执行，而稳定性只要不算太差 ，就不应成为我们的首要任务。 如果我们有100万用户，而其中0.1％的用户可能会不时出错，请说每天一次。 在大多数情况下，它们只会刷新一下，一切都会很好。 如果他们经常出错，那我们就应该纠正它，但是在这种情况下，不需要100％时间的0错误。

另一方面，如果我们正在为银行或核电厂开发软件，那么在这种情况下，错误的代价可能会更高，因此，我们应尽最大努力不要安装它们。

摘要和下一步去

如果您想更多地了解所有这些以及如何实现这一目标，请随时与我联系或关注我将来在此主题上的发帖以及一些最佳实践

翻译自: https://www.javacodegeeks.com/2019/02/development-driven-development-achive-results.html