在很多敏捷论坛和博客上都有大量关于“完成”和“可交付”不同之处的讨论。尽管它们听上去含义相同,但在一些讨论列表和博客上认为,二者都是被人广泛误解和错误使用的词汇。下面我们集中看看别人是怎么理解“完成”的。
团队怎样才能知道他们做完的故事是“完成”状态,还是“可交付”状态呢?
Alistair Cockburm这样评论最近的一个讨论:
- 大多数公司从来没有注意到“完成任务清单”与“可交付”之间的差别,所以他们从来不讨论这个话题;
- 大多数程序员对从“完成任务清单”到“可交付”有多少工作要做没有概念,所以他们和他们的管理者都不会做相应的计划;
- 因为第二点的存在,导致对于怎样计划和评估可“所谓的可交付”版本,在各个部分间缺乏相应的协调性对话。
最近,在 Jeff Patton outlined 的文章(请见 Info 的摘要)中,他对“可交付”的特性进行了概述:
对于客户——想要销售或使用该软件的人——来说,“可交付”就意味着可以开始对该软件的实际销售和使用了,也就是说其所需具备的特性数量必须达到一个最低 限度,软件必需要按照预期意图工作——至少要具备旧有软件的功能或者它所替代的旧有纸质流程;软件的外观和行为必须是正确的——拥有足够高的质量并且是完 善的——这一点对于商业软件尤为重要,因为竞争对手就在你的背后紧紧跟随。“可交付”就意味着“完成”,而且是彻底完结,尘埃落定。没有必要再通过迭代去处理已经完成的东西,应该就是可交付的完成状态。
Alistair Cockburn 似乎同意“可交付”是充分的“彻底完结”,他认为从“完成”到“可交付”之间的转变是一个迭代过程,对此,他在“写三个故事卡片而不是一个”的策略上对此进行了详述:第一个故事卡片上描述实际的故事;第二个是占位符,为我们看到第一个故事后必然要做的改变保留位置;第三个故事卡片就完成那些改变后所需要做的优化。这三个故事都应该记录到backlog 并被列入到迭代计划之中。
目前,社区在谈论关于“可交付”和“潜在可交付”时也有着不同的理解,一些敏捷的实践者们都认同“潜在”就意味着“离可交付只差一步”, Matt Wynne 对此的建议是:
对于将“潜在可交付”转变到“实际交付”需要花多少时间这一点,大家可能有误解。编译代码再将其布署到系统测试或用户测试环境 中,可以让用户感受到你所做的改变,这让大家觉得软件目前在潜在可交付状态。但当你必须在凄清冰冷的夜里修改代码时,你就会知道它离真正的可交付差得还远呢。
……“潜在可交付”与“可交付”的含义不同。一些大型或者复杂的项目会要求在一个发布周期循环的最后阶段(一般是 6 个二周的开发 sprint 再加一个两周的发布 sprint)进入“发布 sprint”和“加固 sprint”。发布 sprint 可不是松懈懒散的工作周期,相反,它是 对系统中某些部分进行整固的时期。
在我们的公司里有三个得到正式认可的阶段(取决于你使用哪些敏捷技术):“代码开发”、“加固“和“最终验收”。“可交付”是在完成第三个阶段之后才有的。
实践者们似乎也同意“潜在可交付”和“可交付”之间的这种差别,弥合这种差距的办法可能就是在一个发布周期的最后加入一个加固 sprint。
那么团队在弥补“完成”和“可交付”之间的差距时,还要注意些什么呢? Chris Spagnuolo 的意见是:
团队可以确切地认为:“完成”就是指所有的功能特性都经历了从“分析”到“实现”的阶段。任何团队都应该将“完成”的定义扩展得尽量宽泛。我们的团队现在就将“完成”定义为:已完成分析的、已完成设计的、已完成编码的、已完成测试的和已完成文档的。
一旦你对“完成”有了明确的定义,就可以与主要干系人一起讨论什么时候才算是“可交付”的。
Alistair Cockburn 对于“加固 sprint”加上了他的意见:
要让 sprint 的长度可以满足:(a) 在这个迭代周期中,用户可以看到并修正特性,
(b) 在这个迭代周期内,所有参与者都能让自己负责的特性达到可交付的状态,而且是在消费者级别上(或者任何你认为需要的级别)。这一标准让确定这个迭代周期长度的讨论和计划变得简单了很多。
看来,现在大家对于“完成”和“可交付”二者还是有不少误解。且不论现在的状况,我们可以发现很多人还是认为交付的软件只要达到“完成”状态就足够了,而且其中涵盖了“可交付”的范畴。
敏捷团队需要将“完成”定义得与“可交付”越接近越好。可能仅靠一次熬夜加班,没有办法让软件从“完成”过渡到“可交付”状态;团队也许要在一个 sprint 之内增量式扩展“完成”的软件直到“可交付”。团队成员还需要与产品所有者以及客户一起,定义出“可交付”在当前项目上下文中的具体含义。
查看英文原文: Does “Done” Mean “Shippable”?
评论