发布评论
评论(6)
您通常会执行选项 1 - 完成冲刺。使用已完成的工作,让未完成的工作反映在项目速度中 - 这样未来的规划就会考虑到您所经历的困难。
是的,选项 1 意味着我们没有完成我们承诺的事情 - 但如果这就是发生的事情,那么最好承认它并学会下次更好地应对,而不是隐藏它。每个人都会遇到不好的事情- 关键是我们如何在现有基础上进行改进。
您可以执行选项 2 - 通过延长冲刺来继续完成未完成的工作。只有当工作对客户来说具有超高优先级并且他们明确选择这样做时才这样做。延长冲刺的长度会使它们更难以相互比较 - 因为它们的长度不同。
绝对永远不要让一个冲刺合并到下一个冲刺中 - 要么延长旧的冲刺,要么开始一个全新的冲刺。如果你让两个冲刺相互合并,那么你就不再真正进行冲刺,并且计划就会崩溃......
我可以回答“视情况而定”吗?另外,我想添加一个“定义完成”。
这种情况我们已经遇到过好几次了,根据具体情况采取了不同的处理方式。
据我记得,有两个案例让冲刺失败了。这实际上更像是一次演示被拒绝的失败。团队认为这些功能本身是完整的,但在演示过程中出现了太多悬而未决的问题、未解决的问题和一些小细节。完成所有事情可能需要几天的时间,因此我们让冲刺失败,并将所有未完成的项目带入下一个冲刺。我们仍然对新的用户故事进行回顾和冲刺计划,但没有集成代码行,并且冲刺被正式标记为失败。
在另一种情况下,我们只在最后一刻出现了一些错误,再加上用户故事中的一些内容。我们估计总工作量最多为三天,只是延长了冲刺时间。这足以让我们修复错误、进行一些更改并在大约三天后进行第二次冲刺演示。
因此,当需要时,我们要么选择选项 4,要么选择选项 2。
这里有一些事情需要考虑。首先,(我在这里谈论的是 Scrum 术语,因为我已经习惯了,所以可以随意用最合适的术语来代替它)让 ScrumMaster、产品负责人和团队聚集在一起,公开讨论这些选项。我不认为只有一种方法可以走。您可以坚持纯粹的方法论,但在现实生活中,这并不总是最好的方法。有时稍微改变一下规则会有很大帮助,让每个人的生活变得更轻松。
如果你们合作得很好,你应该找到一个适合所有参与者的选择。 (如果你做不到,那么你可能会遇到潜在的问题。)不要在没有讨论或至少解释原因的情况下就将某些东西扔给团队。
选项 3 对我来说听起来是最混乱的,所以我会排除它。
这里很多人认为选项 2 违反了基本的敏捷(或 Scrum)规则,但我不同意。 Scrum 明确表示,如果需要,您可以延长冲刺,就像减少故事或添加资源一样。除非绝对必要,否则你不应该这样做,但据我所知,这并不严格违反这本书。当我们在基地做的时候,这对每个人来说都是最好的解决方案,因为我们仍然完成了冲刺,仅仅三天后,每个人都对结果非常满意。如果我们谈论一周或更长时间,选项 2 就不合适。
我不太喜欢选项 1。将半成品从工作实现中取出可能会非常混乱。您与已完成的代码失去了联系,坦率地说,集成可能会很痛苦。根据您的工作方式,这可能会有所不同,但根据我的经验,从代码行中取出代码并不是您想要做的事情。
至于选项 4,它相当苛刻,但话又说回来,如果沟通正确,应该没问题。团队通常知道什么时候会出现问题并且无法交付,所以你不会向他们透露任何消息。
因此,有一些事情需要考虑。
- 需要多少时间才能完成?如果只有一两天,延长冲刺可能是最好的选择。
- 删除已经存在的代码需要付出多少努力?如果它很混乱并且占用时间,请选择选项 2 或 4。如果很简单,也许选项 1 是最好的选择。
- 团队怎么想?产品负责人怎么想?其他人怎么看?春季失败可能会影响团队士气,但也可能不会。
对于敏捷项目来说,“完成的定义”非常重要。这是一个小的检查清单,列出了需要完成的事项,以便将某些内容归类为完整。完成不同级别的工作并不罕见:
用户故事 - 这可能包括诸如必须完成与美国相关的所有任务、所有代码均已签入并通过单元测试成功构建、验收测试已完成等事项。已完成。
冲刺 - 这可能包括诸如冲刺的所有故事都已“完成”之类的事情(参见上文,已举行回顾,产品负责人已经看到了功能演示等。
发布冲刺 - 上一个冲刺的开发系列冲刺已成功集成和回归测试,功能已发布到实际环境中。
就这 4 个选项而言,关于冲刺失败、延长冲刺以及排除某些功能等问题,人们已经说了很多,也写了很多 敏捷项目需要大量的实用主义,特别是在最初的几个冲刺中。
重要的是不要挂断它。只需从中学习、适应并继续前进。
我会对选项 1 采取变体。如果功能 B 可以分解为已完成的内容和未完成的内容,那么这应该会导致修改一组任务以在下一个冲刺中完成它。完成的事情就交付了,虽然交付并不完美,但我们的想法应该是尽力而为,然后根据优先级处理下一步的工作。
在我看来,延长冲刺时间会带来灾难。完成该功能是否也意味着解决其中的所有错误?你见过零错误的软件吗?
冲刺失败会给事情带来太多的完美主义。 99%完成的事情就毫无价值了吗?我不这么认为,但有些人的标准非常高,要求也很高。
编辑:有时,某个功能最初会给出模糊的要求,但在冲刺过程中会得到澄清。例如,“作为用户,我想下订单”的功能请求可以作为冲刺计划的一部分或冲刺期间进一步细分。在任何一种情况下,如果涉及某个功能的一些故事已经完成,那么这些故事可以而且应该在演示中呈现(如果完成了)。关键是要能够说:“这就是我们现在的处境。完成这件事有多少优先级?”因为之前可能紧急的事情在冲刺结束时可能并不那么紧急。
首先,规则:迭代是固定长度的时间盒,并且它们在时间盒结束时完成。因此,这消除了选项 2 和选项 3。对于选项 4,迭代异常终止可能在非常特殊的情况下发生(确定目标无法实现、外部事件使目标无效……),但这必须仍然是异常事件。在中止之前,通常还有其他选择: 1. 做其他事情/创新 2. 获得帮助/外包 3. 缩小范围。这给你留下了选项 1,这是显而易见的选择。
我认为选项 1 的问题是团队没有兑现其承诺。在某些情况下,您可能无法排除功能 B,而不会使整个版本变得无用(或至少大大降低价值)。如果没有特征B,可能很难指导下一个冲刺的方向。
如果这是真的,那么 B 比 A、D 和 F 更重要,并且您没有首先处理最重要的项目,这是错误的,它不应该发生或者... A、D 和 F 实际上非常有价值,在这种情况下你的假设实际上不正确,因此推迟 B 并不是一个大问题。所以,一旦你意识到它无法完成,就立即去做,看看是否可以用较小的物品替换它。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
当然是选项1。您下一次迭代的速度将会降低,因为它基于昨天的天气,因此您完成下一次迭代的机会更大。
在 Scrum 中,你要进行时间限制。而且您只提供有效的功能。
在冲刺计划中,您已经对可以交付的内容进行了估计。客户必须接受估计中一定程度的不确定性,或者准备好在团队中拥有太多资源。
如果再次错过下一次迭代,请切换到较短的迭代长度,并确保单个特征的大小更小。
Option 1 of course. Your velocity for the next iteration is going to be less, as it is based on yesterdays weather, so the next iteration you have a better chance of being complete.
In scrum you are time-boxing. And you only deliver features that work.
In the sprint planning you have made an estimate of what you could deliver. The customer has to accept a certain level of uncertainty in the estimate, or be prepared to have too many resources on the team.
If you miss the next iteration again, switch to a shorter iteration length, and make sure the size of individual features is smaller.