BT

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

始终在Sprint结束时没有完成?

| 作者 Mark Levison 关注 0 他的粉丝 ,译者 石永超 关注 0 他的粉丝 发布于 2010年6月11日. 估计阅读时间: 2 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

如果你的团队始终有一些故事或所有故事没有达到“完成标准(DoD)”。他们应该延长sprint时间吗?产品负责人应该如何处理这种情况?在这个特别的案例中,询问这个问题的人提到他们的团队以4周为一个sprint。

Victor Hugo de Oliveira指出,不应该延长sprint。他解释道,sprint是Scrum基本的时间箱,其目的是帮助团队集中精力:“时间结束时Sprint就结束”。 同时,他认为即便团队只能完成90%原先承诺在sprint中完成的故事,他们也应该集中精力去完成故事(比如,完成,完成)。

Jussi Mononen说,一个sprint里没有完成的故事,由产品负责人自行决定是否移到下一个sprint。Angel Lopez讲述了一个案例:

一个案例:在一个固定时间的项目中,我们“错误评估”了实现一个功能的成本。而且在下一个sprint开始的时候,产品负责人决定遗弃那个功能,对他而言,继续下一个故事更为重要。 对于当前这个故事,没有那个功能他也可以接受。

Adam Sroka,教授团队在sprint中不要开始实现他们无法完成的故事,并且不要马上开始所有的故事,这样产品负责人可以有更大的灵活性在sprint里更改故事的优先级。

Jussi也认为,这说明团队承诺过度了,一旦他们觉得无法在预期的sprint和发布中交付所有功能,他们就应该马上进行沟通。

Roy Morien提出了两个观点:

  • 2周长的sprint:“这是一个较短的时间范围,因此更加容易把计划的确定性做得更大些。尽管我没有统计数据来支持这这种观点,我认为这种更短的时间段让sprint更加可控,带来更少未完成的工作、更为准确的sprint估算、更强的紧迫感和承诺意识,总的来说,可以在团队环境中营造更好的心理和专注性。”
  • 几乎完成、未经测试的故事代表了可能让项目受挫的组件,因为无法确定它们是否合适,也不知道它们隐藏了什么问题。

也有人问到,为什么团队不使用像FitNess、RobotFramework以及Cucumber之类的免费工具来编写他们的验收测试。

查看英文原文:Consistently Not Done, Done, Done at the End of Sprints?

 

评价本文

专业度
风格

您好,朋友!

您需要 注册一个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