障碍条件和敏捷开发

我们在实践中发现，我们的许多客户都误以为在敏捷开发过程中添加或定义标准，约束或流程是一个敏捷的概念。过程违反敏捷开发方法的概念的问题在于任何敏捷方法本身都是一个过程。我们经常发现客户经常引用上下文敏捷声明来逃避流程或标准。

我们在实践中发现，我们的许多客户都误以为在敏捷开发过程中添加或定义标准，约束或流程是一个敏捷的概念。过程违反敏捷开发方法的概念的问题在于任何敏捷方法本身都是一个过程。我们经常发现客户经常引用上下文敏捷声明来逃避流程或标准。让我们回顾一下敏捷宣言中的敏捷方法的价值:●个人和互动比流程和工具更重要●可用软件比完整文档更重要●客户协作比合同谈判更重要●响应变化更重要比以下计划有些组织经常忽略“个人和互动比过程和工具更重要”的背景，在此之后没有阅读句子，即“简而言之，尽管这些比较的右侧也很有价值，左边的物品更有价值。“ 。有了这句话，很明显这个过程很有价值，但是当我们需要做出选择时，人和互动的价值就更大了。我们完全同意这种方法，并倾向于将人工流程作为快速开发测试的障碍，以实现合理的质量，可扩展性和可用性水平，或帮助确保工程师得到适当的评估和培训。现在让我们分析一些关键的屏障条件如何有助于增强敏捷方法。我们将软件的可用值与人力资源的完整文档进行比较。从ARB到代码审查，到性能测试和生产环境评估，我们的每个建议都与此原则不冲突。在敏捷方法中，可以使用诸如ARB和联合架构设计（JAD）之类的屏障条件来确保正在开发的产品得到适当扩展。可以由一组人执行ARB和JAD，然后执行少量文档，这与敏捷方法一致。引入屏障条件和标准，以帮助确保系统和产品在生产环境中启动和运行，实际上支持可用的软件的开发。 对于我们提出的所有活动，虽然它们的结果记录在某处，但我们没有完整的文档作为它们的重要部分。请记住，我们希望不断改进流程，因此我们只记录绩效结果。例如，记录性能结果可以帮助我们确定在开发过程中出错的频率，从而导致QA性能测试失败或生产环境扩展。问题。我们建议的流程不会妨碍客户协作，也不支持合同谈判比客户协作更重要。事实上，由于增加了扩展的屏障条件，您会关注客户的需求，并创建一个更好地与最终客户协作的工作环境。您的客户可能无法执行设计评估，评估，测试或测量，以确定产品是否可以扩展以满足需求，但他们确实希望您提供的产品或服务不仅能满足其业务目标，还能满足他们的需求。扩大需求。因此，与客户协作进行测试和测量有助于确保您的产品满足客户需求，并将这些测试和测量添加到开发过程中是满足客户需求和创造股东价值的好方法。最后，添加我们建议的障碍条件有助于我们识别有助于我们响应变化的变化。如果应用程序或服务未通过障碍条件，则这是对问题的早期警告，我们需要立即解决。如果在ARB会议上发现某个组件无法水平扩展（根据我们提出的架构设计原则，横向扩展而不是垂直扩展），这表明存在潜在问题。虽然我们可能仍然决定发布此功能，产品或服务，但我们最好确保未来的敏捷开发周期能够解决我们发现的问题。 但是，如果扩展要求非常强，我们无法扩展，我们将失败。我们不应该立即回应这个问题并修复它吗？如果没有这样的流程和一系列检查，我们怎样才能确保我们能够做到？满足客户需求？我希望我们已经说服您在敏捷开发生命周期中添加判断标准，并使用它们来评估您是否已实现扩展目标。这是一个好方法。如果我们还没有说服您，您是否敢于宣称在开发生命周期中，绝对没有确保您的产品或服务可以扩展的流程？那么你认为你的工作能持续多久？想象你他们说:“我们不会实施任何形式或形式的障碍或标准，以确保我们不会发布延长问题的产品！”牛仔布编码没有任何流程，计划或措施来确保结果满足业务需求。开发方法，我们称之为牛仔布编码。牛仔布编码等环境在流程中完全缺乏，这就是扩展经常发现某些团队声称牛仔布编码“敏捷”的地方。坦率地说，事实并非如此。敏捷解决方案成功的主要障碍。法律是根据您的需求调整开发生命周期，而其他模型往往更具预测性。牛仔布编码等模型缺乏过程，既不适应也不具有预测性。敏捷方法不反对测量和管理。它们是一种快速发布较小的组件和功能子集的方法，通过管理更小，更易于管理的组件来帮助控制混乱，而不是反复尝试预测和控制非常大的复杂项目。不要让你和你的微信网站做成沈阳微信小程序

团队陷入了误解，即不应该测量或管理敏捷方法。敏捷方法的基本原则之一是使用速度等指标来提高工程师的评估能力，而不是过度打击。如果你缺乏一项措施，你必然会永远不会改善，如果你缺乏管理，你注定要在通往目标和任务的道路上迷失方向。在设计高度可扩展的解决方案时，如果您是牛仔，您一定能够将野马扩展到马匹。