我们使用 Scrum 已经大约 9 个月了，并且基本上取得了成功。然而，我们的燃尽图很少看起来像“模型”图，而是更像是可怕的过山车，其中有一些导致呕吐的爬升和下降。
为了尝试解决这个问题，我们在冲刺原型设计和设计之前花费了更多的时间，但我们似乎仍然在冲刺期间发现了比最初想象的更多的工作。注意：我的意思是，满足积压工作所需的工作比最初想象的要复杂得多，而不是我们已经为积压工作确定了新项目。
这是 Scrum 的常见问题吗？有人有任何技巧可以帮助顺利进行吗？
我应该指出，我们的大部分开发工作都不是全新的，因此我们正在维护现有大型复杂应用程序中的功能。 Scrum 不太适合这种类型的开发是否只是因为您不知道现有代码会出现什么问题？
在冲刺开始制定开发细节之前，我们应该花费多少时间？
更新：我们现在取得了更多的成功，旅程也更加顺利。这主要是因为我们在估计时采取了更为悲观的观点，这给了我们更多的喘息空间来处理那些不按计划进行的事情。你可以说它让我们变得更加“敏捷”。我们还试图改变人们的看法，即燃尽图是某种时间表，而不是范围与资源的指示。
一些让事情变得顺利的技巧。
1）正如其他人所说 - 尝试将任务分解为更小的块。更明显的方法是尝试更详细地分解技术任务。如果可能的话，我鼓励您与产品负责人交谈，看看是否可以缩小范围或“精简”故事。我发现后者更有效。如果团队和产品负责人都了解正在讨论的内容，那么处理优先级和估计就会更容易。
我的一般经验法则是任何大于理想一天一半的估计都可能是错误的:-)
2）尝试进行较短的冲刺。如果您正在进行一个月的冲刺 - 尝试两周。如果你准备两周——尝试一周。
- 它限制了故事的大小——鼓励产品所有者和团队处理更容易准确估计的更小的故事
- 您会更频繁地获得有关您的估计的反馈 - 并且更容易看到您在冲刺开始时做出的决策与实际发生的情况之间的联系
- 通过练习一切都会变得更好:-)
3）利用站会和回顾来更多地了解起伏的原因。是当您花时间研究代码库的特定区域时吗？是因为人们对产品负责人的误解造成的吗？随机的紧急情况会占用团队的开发时间吗？一旦您对起起落落有更多的了解，您通常可以专门解决这些问题。再次强调——较短的冲刺可以让这一点变得更加明显。
4）相信你的历史。你可能知道这个......但无论如何我都会说:-)如果摆弄那个可怕的遗留 Foo 包花费的时间比你想象的持续冲刺时间长 3 倍 - 那么它也将花费你想象的 3 倍的时间下一个冲刺。无论您认为这次的效率有多高；-) 相信历史并使用“昨天的天气”等信息来指导您对明年春天的估计。
希望这可以帮助！
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
