敏捷软件开发宣言的第三和第四项

Question

敏捷软件开发宣言的第三项和第四项

1. 合同谈判中的客户协作
2. 响应按计划进行的变更

这两者有什么区别？

如果第四个意思是“有某种意愿的增量交付，而不是预先的大设计”，那么第三个是什么意思呢？

第三个和第四个一样..。

• (反对的)“合同谈判”与“遵循计划”--意思是“前面的大设计”--是一样的吗？
• “协作”和“回应”--它们之间也是一回事吗？

..。还是不一样？

我欢迎你的解释，甚至提到一个原作者解释它。

Answer 1

首先，我想说宣言中的要点并不是相互排斥的(例如:工作产品在docs上也可能与协作而不是合同重叠)。

话虽如此，我认为解释第3点和第4点不重叠的最好方法是举例说明

在过度契约的环境下，每一方通常都会捍卫自己的权利，即使这是他们自己的代价，以确保对方知道他们不会容忍任何侵犯他们的权利。显然，在协作环境中，这种姿态不太可能被采用。

例如，合同规定，所有严重程度5缺陷都在不超过一个月的时间内解决，供应商遇到了一个非常棘手的问题，需要几个月的人力才能解决。然后，客户可以选择几条路径中的一条。

• 他们可以直接放弃这个条款，因为一个继续经营的供应商能够更好地支持客户，而不是停止营业的供应商:)
• 他们可以做一些其他的安排，比如交付一些为客户提供额外价值的特性增强，而不是专注于没有真正影响到他们的低严重缺陷。
• 或者，无论对双方的影响如何，他们都可以选择过于契约的方式，坚持问题得到解决。

从经验来看，最后一条路通常会伤害到每一个人，因为供应商受到挤压，他们在改善产品质量上花费更少，导致更多的不满导致更激进的客户姿态导致更大的挤压。永无止境的循环：

希望这说明了这一点

Answer 2

斯科特写了一本名为“理解敏捷价值和原则:对敏捷宣言的审查”的短篇小说，由InfoQ出版，可免费获得PDF格式，它深入研究了敏捷软件开发宣言及其价值和原则。以下是他的思想总结。

邓肯将“合同谈判中的客户协作”与“流程和工具上的个人和交互”联系起来。“个人和交互”价值是指开发组织和开发团队的内部工作，而“客户协作”价值是指开发组织或开发团队如何与外部利益相关者互动。这里的协作是指开发团队和外部涉众如何找到方法来理解需求和用户需求，验证和验证所交付的功能，以及交流关于改进交互的反馈。

“按计划应对变化”的核心是与长期规划相关的浪费。它承认软件开发是复杂和不可预测的。这种价值不是预先估计整个工作范围和交付一次，而是定期检查工作和适应部署和使用软件的不断变化的环境的迭代性质，以及理解用户需求的变化。这在某种程度上与“在全面文档之上工作的软件”有关，这两个值共同导致迭代和增量开发模型。

正如您所指出的，我确实看到了“客户协作”和“响应更改”价值观之间的关系。有时，在定义契约、计划和需求时，团队如何与涉众合作以及团队为涉众构建什么之间的界限可能变得模糊。然而，意图似乎是明确的。

我的建议是不要孤立地接受这四种价值观中的任何一种。这四个人之间肯定有相互作用和相互关系。

Answer 3

重要的是要理解敏捷宣言是对在其编写时占主导地位的工作方式的批评。当你了解软件开发是如何在那个时候完成的，事情就开始有意义了。

基于合同协商的

客户协作

在过去，客户和建设者坐下来，写下合同和详细的规范，这是(有时仍然是)完全正常的做法。该合同将详细说明该工作的内容和时间。然后，客户就会消失，当工作应该完成时，客户就会再次出现，期望得到合同中定义的软件。大多数经验告诉我们，这是行不通的。相反，宣言告诉我们，我们应该努力让客户尽可能多地参与开发。并与他在日常的基础上合作，建立软件。

响应计划更改的

(

)

在上面的合同中，往往会有关于执行进展情况的详细计划。它将确定阶段和里程碑以及这些阶段结束和开始的具体日期。这意味着，即使一个阶段的工作还没有完成，如果计划告诉你这个阶段意味着结束，它就会结束。而且，一旦您进入了一个阶段，就很难回到以前的阶段。因此，如果您正处于实现阶段，并且发现了设计缺陷，就不可能回到设计阶段来解决这个问题。有一些灵活性，但这往往是肤浅或昂贵的。当然，这被发现是行不通的。宣言告诉我们，这种方法太危险了，我们应该以一种足够灵活的方式来构建我们的发展计划，当发现问题时，可以改变计划以适应这些问题。