BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 Vikas Hazrati 关注 0 他的粉丝 ,译者 张海龙 关注 0 他的粉丝 发布于 2008年2月19日. 估计阅读时间: 6 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。
在很多敏捷论坛和博客上都有大量关于“完成”和“可交付”不同之处的讨论。尽管它们听上去含义相同,但在一些讨论列表和博客上认为,二者都是被人广泛误解和错误使用的词汇。下面我们集中看看别人是怎么理解“完成”的。

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

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"?

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT