SCRUM变化与每日目标？

Question

在工作中，我们有点跟随SCRUM，但在每周开始时，我们计划每天进行一次冲刺。

例如，常规周会像这样计划：

第1天

• 故事1
• 故事2

第2天

• 故事3

第3天

• 故事4
• 故事5
• 故事6

......等等。

我们使用Pivotal跟踪器，并使用发布标记每个每日冲刺，然后继续定期循环开始 - 交付 - 接受或拒绝。

正如预期的那样，大多数时间故事花费的时间比预期的要长，或者在完成之前被拒绝几次，然后释放所有故事都会下地狱。

我知道也许敏捷的理念不是试图让每个故事达到这样的准确度，但我们正努力将我们的承诺保持在最大限度，以便尽可能快地完成。

是否有人使用SCRUM的变体或任何其他针对日常冲刺优化的方法？

Answer 1

2~4周是冲刺的正常长度，并在许多公司中广泛使用。在你的情况下，这似乎是一周的冲刺，在一周的每一天都有额外的计划，这有点密集，因为团队可能会感受到每日发布的不必要的压力。

根据您的冲刺设置，如果“大部分时间故事花费的时间比预期的要长”，我会说，最有可能在估算中发生了错误。因此，您可能需要考虑几个问题：

1. 谁制定了每日计划？
2. 谁给出了每个故事的估计？
3. 谁识别故事之间的依赖关系？

根据我的经验，一周的冲刺是可以的，但不需要每日计划。每日站立会议已经是Scrum团队的“日常计划会议”。在这次会议上，团队成员拉出任务并制定自己的计划，这是合理的。您可能希望在一天内完成每个任务（或“故事”），但实际上这很难实现。即使对于简单的“代码更改”任务，也可能会导致一些评论评论，这些评论意味着比任务本身更大的变化。因此，每日目标可能比每​​周目标或冲刺目标更难实现。

然而，即使你无法达到每日目标，你还要检查你的冲刺目标是否在最后实现？我认为这更为重要，因为从理论上讲，在冲刺结束时，应该演示一些可交付的和客户价值的东西。这是利益相关者真正关心的目标。

所以我的建议是：在每日目标上轻松一点，更多地关注冲刺目标。

Answer 2

我想说你需要停止将你的任务/故事视为连续的，而是将它们视为并行运行的多日项目。

同行评审和客户反馈循环使得在一天内编写，审查和关闭任务非常困难，因此像您一样编程，团队成员每天开始和完成多项任务可能总是注定要失败。

在我们（​​即我的公司）的经历中，最好在两周内选择一个真实数量的故事（比您对团队的速度有信心的情况要少）然后每两周正式检查一次您的进度每隔几天一次非正式的基础（只是为了确保没有人真正陷入困境，或者在某项特定任务中过于严重。）每日站立对于快速的健全检查都很好。

有一点需要注意，你说：

  

但是我们正努力将我们的承诺保持在最高水平以便继续下去   尽可能快

您无需将任务编程为连续项目即可实现;每个工作日完成的1个任务每周产生相同数量的任务，因为5个任务全部在周五完成。

希望有所帮助。

Answer 3

我建议你看看Kanban，因为从你的描述来看，这可能更适合你的环境。