敏捷文档如何影响合同和最初的工作说明？

Question

敏捷需要正确的文档级别，而不是太多或很少，没有“好运”声明(我不记得用过这个问题的原因)。

所以，如果你在写用户故事之类的东西，你是如何在最初的谈判中开始的？你不只是写一份合同，或声明或工作，说，“建立一个购物车网站”(我的想法是不)。

看起来敏捷并不真正喜欢软件设计文档，至少不是马上就开始的，但是从契约的角度来看，这不正是您所需要的吗？在软件的实际构建中，我意识到需求的变化(人们忘记了东西，我们需要这个等等)，但是我关心的是最初的签约。

编辑：https://www.joelonsoftware.com/2000/10/03/painless-functional-specifications-part-2-whats-a-spec/很老了，但我觉得还是不错的。这如何与敏捷相适应？

Answer 1

敏捷坚持严格的反馈循环。没有任何规范是敏捷的，如果它要求一年前制定的实现细节在今天得到忠实的遵循，不管世界和我们对它的理解如何改变。反馈是你从中学到的东西。

Joel在您链接到的使它变得灵活的规范文档中的第一件事是免责声明：

“这个规范不完整”

即使你认为它已经完成了，他仍然坚持让你去对冲：

“据我所知，这个规格是完整的，但如果我忘了什么东西，请告诉我。”

这意味着当你学习的时候你可以随时更新它。

你可以尝试预测他们会说些什么--他们期望他们没有得到“非目标”。但是，尽管列出非目标是一种很好的做法，但它并不是一个很好的防御措施，不管他们怎么想你都没有。

什么是一个好的辩护是一个支付结构，将这类索赔解释为对新工作的要求，也将需要支付。只要您从不表示您的第一个版本很可能是您的最后一个版本，这就很好了。预先告诉客户，这是一个迭代过程。只要他们不断找到更多需要做的事情，你就会继续发布。当发布间隔为几周，而不是几个月或几年时，这种情况通常是客户非常可以接受的。

Answer 2

以下链接提供了关于如何为敏捷项目准备合同的必要知识：

1. http://www.agilecontracts.org/agile_合同_primer.pdf。
2. http://alistair.cockburn.us/Agile+contracts。

虽然这个问题没有简短的答案，但我建议阅读这些参考资料。第一个是一位IT律师和两位创业书籍作者的合作。第二个例子包含了著名的Alistair (方法论家和敏捷运动的关键发起者之一)的一些实践。

Answer 3

但从契约的角度来看，这不正是你所需要的吗？

不，它不是。合同可以是任何东西，合同必须包括全部规格的想法是极其短视的。

例如，您可以创建一个合同，“每隔几周创建一份合同，对我们的利益相关者商定的应用程序进行增量改进，并获得报酬Z"，而不是写着”在Y之前创建做X的软件并获得支付金额Z“的合同。

我认为创建允许完全敏捷的契约是非常重要的，也是非常困难的。而且它还远远没有得到足够的讨论和研究。