有正确的答案是不够的

我经常参与探索在大型组织中建立软件的正确方法的对话。非常普遍，客户正在探索敏捷与瀑布。最近，在我们行业的重要会议上，各种人士代表不同的“最佳方式”来构建软件。不同的人举办了Scrum，XP，安全，少，和纪律敏捷交付的选项作为正确的答案。在LinkedIn组上，我遵循2个敏捷和关键链敏捷的王子和临界链敏捷。每个人都在努力推动他们的观点作为正确的答案。几乎没有失败，这些讨论落入了不可理赔的术语或者陷入了难以解决的宗教辩论。

他们的讨论是错误的。

我发现有趣的是他们都有正确的答案 - 他们都有一个解决一些条件中的一些问题的答案。所有条件都会失败 - 不同的解决方案适用于不同的情况。每个解决方案都需要不同的条件来成功。

讨论必须开始，“解决方案解决了什么问题”和“该解决方案必须存在哪些条件“。

明确你要解决的问题。

• 我们有一个非常明确的结果，客户期望在未来的某个日期，我们必须达到那个日期。
• 我们正在为产品开发新客户，几乎每周回复我们学到的内容。
• 我们正致力于一个跨多个平台的大型项目，我们面临着跨平台测试所有内容的挑战。
• 我们需要提高我们可以提供软件的速度，因为我们的客户需要更快地预期新事物。

清楚地了解必须存在于您正在实施的解决方案的条件集。

• 必须存在什么样的组织结构?
• 团队自主，可以独立推进吗？您是否需要跨多个团队的规划和协调？
• 您正在使用的体系结构耦合有多紧密?团队是否与体系结构保持一致?
• 您是否拥有支持增量开发和快速部署的现有技术实践？
• 您可以经常集成和验证产品吗？
• 您的治理模型是否与您所面临的模糊程度对齐？
• 治理模型要求您支持什么？
• 管理，人力资源和会计理解并支持需要发生什么吗？

有正确的答案是不够的。

如果不了解解决方案所解决的问题以及解决方案工作所必须存在的条件，你甚至无法开始讨论。在大多数情况下，正确的出发点是在确定所需的解决方案之前了解解决问题所需的最终状态。然后弄清楚解决方案必须存在哪些条件才能起作用。

从那里，您可以确定组织中是否存在这些条件，弄清楚妨碍了解条件的方式，并计划将条件到位所需的具体行动。