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