在很多敏捷论坛和博客上都有大量关于“完成”和“可交付”不同之处的讨论。尽管它们听上去含义相同，但在一些讨论列表和博客上认为，二者都是被人广泛误解和错误使用的词汇。下面我们集中看看别人是怎么理解“完成”的。

　　团队怎样才能知道他们做完的故事是“完成”状态，还是“可交付”状态呢？

　　Alistair Cockburm这样评论最近的一个讨论：

　　大多数公司从来没有注意到“完成任务清单”与“可交付”之间的差别，所以他们从来不讨论这个话题；
 
　　大多数程序员对从“完成任务清单”到“可交付”有多少工作要做没有概念，所以他们和他们的管理者都不会做相应的计划；
 
　　因为第二点的存在，导致对于怎样计划和评估可“所谓的可交付”版本，在各个部分间缺乏相应的协调性对话。
　　最近，在Jeff Patton outlined的文章中，他对“可交付”的特性进行了概述：

　　对于客户——想要销售或使用该软件的人——来说，“可交付”就意味着可以开始对该软件的实际销售和使用了，也就是说其所需具备的特性数量必须达到一个最低 限度，软件必需要按照预期意图工作——至少要具备旧有软件的功能或者它所替代的旧有纸质流程；软件的外观和行为必须是正确的——拥有足够高的质量并且是完 善的——这一点对于商业软件尤为重要，因为竞争对手就在你的背后紧紧跟随。

　　“可交付”就意味着“完成”，而且是彻底完结，尘埃落定。没有必要再通过迭代去处理已经完成的东西，应该就是可交付的完成状态。
　　Alistair Cockburn似乎同意“可交付”是充分的“彻底完结”，他认为从“完成”到“可交付”之间的转变是一个迭代过程，对此，他在“写三个故事卡片而不是一个”的策略上对此进行了详述：第一个故事卡片上描述实际的故事；第二个是占位符，为我们看到第一个故事后必然要做的改变保留位置；第三个故事卡片就完成那些改变后所需要做的优化。这三个故事都应该记录到backlog并被列入到迭代计划之中。

　　目前，社区在谈论关于“可交付”和“潜在可交付”时也有着不同的理解，一些敏捷的实践者们都认同“潜在”就意味着“离可交付只差一步”，Matt Wynne对此的建议是：

　　对于将“潜在可交付”转变到“实际交付”需要花多少时间这一点，大家可能有误解。编译代码再将其布署到系统测试或用户测试环境 中，可以让用户感受到你所做的改变，这让大家觉得软件目前在潜在可交付状态。但当你必须在凄清冰冷的夜里修改代码时，你就会知道它离真正的可交付差得还远呢。
　　Mike Cohn似乎认同这一点： ……“潜在可交付”与“可交付”的含义不同。一些大型或者复杂的项目会要求在一个发布周期循环的最后阶段（一般是6个二周的开发 sprint再加一个两周的发布sprint）进入“发布sprint”和“加固sprint”。发布sprint可不是松懈懒散的工作周期，相反，它是 对系统中某些部分进行整固的时期。

Mike Kirby也给出了类似的意见：

　　在我们的公司里有三个得到正式认可的阶段（取决于你使用哪些敏捷技术）：“代码开发”、“加固“和“最终验收”。“可交付”是在完成第三个阶段之后才有的。
实践者们似乎也同意“潜在可交付”和“可交付”之间的这种差别，弥合这种差距的办法可能就是在一个发布周期的最后加入一个加固sprint。

　　那么团队在弥补“完成”和“可交付”之间的差距时，还要注意些什么呢？Chris Spagnuolo的意见是：

　　团队可以确切地认为：“完成”就是指所有的功能特性都经历了从“分析”到“实现”的阶段。任何团队都应该将“完成”的定义扩展得尽量宽泛。我们的团队现在就将“完成”定义为：已完成分析的、已完成设计的、已完成编码的、已完成测试的和已完成文档的。
　　一旦你对“完成”有了明确的定义，就可以与主要干系人一起讨论什么时候才算是“可交付”的。

　　Alistair Cockburn对于“加固sprint”加上了他的意见：

　　要让sprint的长度可以满足：

　　(a)在这个迭代周期中，用户可以看到并修正特性，
　　(b)在这个迭代周期内，所有参与者都能让自己负责的特性达到可交付的状态，而且是在消费者级别上（或者任何你认为需要的级别）。

　　这一标准让确定这个迭代周期长度的讨论和计划变得简单了很多。
　　看来，现在大家对于“完成”和“可交付”二者还是有不少误解。且不论现在的状况，我们可以发现很多人还是认为交付的软件只要达到“完成”状态就足够了，而且其中涵盖了“可交付”的范畴。

　　敏捷团队需要将“完成”定义得与“可交付”越接近越好。可能仅靠一次熬夜加班，没有办法让软件从“完成”过渡到“可交付”状态；团队也许要在一个 sprint之内增量式扩展“完成”的软件直到“可交付”。团队成员还需要与产品所有者以及客户一起，定义出“可交付”在当前项目上下文中的具体含义。