InfoQ

新闻

“完成”意味着“可交付”吗?

作者 Vikas Hazrati译者 张海龙 发布于 2008年2月18日 下午7时39分

社区
Agile
主题
质量交付,
配置管理
标签
测试,
持续改进,
持续集成
在很多敏捷论坛和博客上都有大量关于“完成”和“可交付”不同之处的讨论。尽管它们听上去含义相同,但在一些讨论列表和博客上认为,二者都是被人广泛误解和错误使用的词汇。下面我们集中看看别人是怎么理解“完成”的。

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

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

  1. 大多数公司从来没有注意到“完成任务清单”与“可交付”之间的差别,所以他们从来不讨论这个话题;
     
  2. 大多数程序员对从“完成任务清单”到“可交付”有多少工作要做没有概念,所以他们和他们的管理者都不会做相应的计划;
     
  3. 因为第二点的存在,导致对于怎样计划和评估可“所谓的可交付”版本,在各个部分间缺乏相应的协调性对话。

最近,在Jeff Patton outlined的文章(请见Info的摘要)中,他对“可交付”的特性进行了概述:

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

“可交付”就意味着“完成”,而且是彻底完结,尘埃落定。没有必要再通过迭代去处理已经完成的东西,应该就是可交付的完成状态。

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之内增量式扩展“完成”的软件直到“可交付”。团队成员还需要与产品所有者以及客户一起,定义出“可交付”在当前项目上下文中的具体含义。

查看英文原文Does "Done" Mean "Shippable"?

没有回复

回复

独家内容

剖析短迭代

敏捷教练Dave Nicolette提出:我们应该如何设定迭代长度?是要根据发布周期的时间么?使用短迭代又有哪些好处?

应用JSF、Ajax和Seam开发Portlets(1/3)

本文主要讲述了如何用JBoss Portlet Container 和JBoss Portlet Bridge创建新项目,怎样配置一个JSF应用去使用JBoss Portlet Bridge,以及JBoss Portlet Bridge所具备的功能。

AtomServer:数据分发的发布动力(第二部分)

在这篇文章里,Bryon Jacob和Chris Berry将和我们继续探讨AtomServer,它是基于Apache Abdera的完整Atom存储实现。作者还创建了几个Atompub规范扩展,其中包括自动标记、批处理和Feeds聚合。

架构师(试刊第二期)

InfoQ中文站的电子杂志《架构师》试刊第二期出版了!相比于上期,我们在内容的选择安排和版式上都根据读者的意见重新做了修正。“细节决定成败”,我们希望基于InfoQ中文站的专业内容,《架构师》能逐渐成为大家喜欢的电子刊物!

一种正规的性能调优方法:基于等待的调优

在本文中,Steven Haines探讨了Web应用性能调优问题。该领域过去更像是一门艺术而不是一门科学。他提出了一种称为基于等待调优的方法,使整个调优过程更加可度量,也因此更具科学性。

Java程序员ActionScript 3入门

通常来说,改变技术路线时最艰难的部分是辨别语言语法之间的不同。这篇文章就为Java开发者提供了一份如何转向Flex基础语言ActionScript的指南。

浅谈如何创建Rails应用

本视频主要以财帮子为例,介绍了如何创建一个PV为百万级的Rails应用。其中包括:Rails应用的服务器架构、Rails Cache的优化、负载均衡的处理、Web服务器的调试、分布式解决方案、Open API的设计等等。

Alexandru Popescu谈InfoQ.com网站架构

InfoQ首席架构师Alexandru Popescu在采访中谈论了InfoQ架构、Webwork与DWR、Hibernate与JCR、Hibernate可扩展性、最新的InfoQ视频流系统和InfoQ的未来规划。