Scrum Burndown 问题 [已关闭]
https://stackoverflow.com/questions/91257
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian题
我们使用 Scrum 已经大约 9 个月了，基本上取得了成功。然而，我们的燃尽图很少看起来像“模型”图，而是更像是一个可怕的过山车，有一些令人呕吐的爬升和下降。
为了尝试解决这个问题，我们在冲刺原型设计和设计之前花费了更多的时间，但我们似乎仍然在冲刺期间发现了比最初想象的更多的工作。笔记：我的意思是，满足积压工作所需的工作比最初想象的要复杂得多，而不是我们为积压工作确定了新项目。
这是 Scrum 的常见问题吗？有人有任何技巧可以帮助顺利进行吗？
我应该指出，我们的大部分开发工作都不是全新的，因此我们正在维护现有大型复杂应用程序中的功能。Scrum 不太适合这种类型的开发是否只是因为您不知道现有代码会出现什么问题？
在冲刺开始制定开发细节之前，我们应该花费多少时间？
更新：现在，我们取得了更大的成功，旅程也更加顺利。这主要是因为我们在估计时采取了更为悲观的观点，这给了我们更多的喘息空间来处理那些不按计划进行的事情。你可以说它让我们变得更加“敏捷”。我们还试图改变人们的看法，即燃尽图是某种时间表，而不是范围与资源的指示。
解决方案
一些让事情变得顺利的技巧。
1）正如其他人所说 - 尝试将任务分解为更小的块。更明显的方法是尝试更详细地分解技术任务。如果可能的话，我鼓励您与产品负责人交谈，看看是否可以缩小范围或“精简”故事。我发现后者更有效。如果团队和产品负责人都了解正在讨论的内容，那么处理优先级和估计就会更容易。
我的一般经验法则是任何大于理想一天一半的估计都可能是错误的:-)
2）尝试进行较短的冲刺。如果您正在进行一个月的冲刺 - 尝试两周。如果您要锻炼两周，请尝试一周。
- 它限制了故事的大小——鼓励产品所有者和团队处理更容易准确估计的更小的故事
- 您会更频繁地获得有关您的估计的反馈 - 并且更容易看到您在冲刺开始时做出的决策与实际发生的情况之间的联系
- 通过练习一切都会变得更好:-)
3）利用站会和回顾来更多地了解起伏的原因。是当您花时间研究代码库的特定区域时吗？是因为人们对产品负责人的误解造成的吗？随机的紧急情况会占用团队的开发时间吗？一旦您对起起落落有更多的了解，您通常可以专门解决这些问题。再次强调——较短的冲刺可以让这一点变得更加明显。
4）相信你的历史。你可能知道这个...但无论如何我还是要说:-) 如果摆弄那个可怕的遗留 Foo 包花费的时间比你想象的持续冲刺时间长 3 倍 - 那么它也将花费你认为下一个冲刺的 3 倍的时间。无论您认为这次的效率有多高；-) 相信历史并使用“昨天的天气”等信息来指导您对明年春天的估计。
希望这可以帮助！
其他提示
我很高兴听到 Scrum 对您来说取得了很大的成功——这比让 sprint 燃尽图看起来理想更重要。冲刺燃尽图只是团队的一个工具，可以帮助团队了解是否正在实现冲刺目标。如果团队已经实现了冲刺目标，我就不会太担心图表看起来像过山车。一些建议
- 在冲刺回顾期间询问团队额外的工作来自哪里
- 额外的工作可能来自于冲刺早期没有良好的验收测试
- 没有精心整理的积压工作可能会带来额外的工作。一个好的经验法则是，团队至少花 5% 的时间提前思考下一个冲刺的故事。
- 监控正在进行的工作 - 团队是否并行做太多事情？
- 在冲刺计划期间——团队对构成故事的任务分解有何看法？
如果您尚未实现冲刺目标 - 使用既定的团队速度在下一个冲刺期间减少承担。在你能跑之前，你必须先学会走路。
根据我的经验，Scrum 肯定更适合新开发而不是维护。新的开发比维护旧的大型代码库更可预测。
话虽如此，一个可能的问题是您没有将任务分解成足够小的块。人们在进行软件规划时遇到的一个常见问题是，他们认为“哦，这个任务应该需要我 2 天的时间”，而没有真正考虑完成该任务需要做什么。通常，您会发现，如果您坐下来思考，该任务由 A、B、C 和 D 组成，最终需要超过 2 天的工作时间。
正如其他人所说，我预计烧毁会是上下的。出事了！您应该使用“向上和向下”的部分作为回顾的素材。
确保每个人都清楚“正在完成”的含义，并利用这种共同理解来帮助推动您的计划会议。通常，列出可用的已完成内容将（a）帮助您记住可能忘记的事情，（b）可能会激发更多关于稍后会出现的任务的想法。
需要考虑的另一点是，如果您月复一月地使用不可预测的代码库工作，我仍然希望您的速度正常化到相当稳定的速度。只需根据计划的工作跟踪您的成功情况，并在计划时仅使用已完成的项目作为最大数量。然后专注于计划外的任务，看看是否有任何模式表明您可以采取不同的措施，将这些事情纳入计划的工作中。
我也遇到过类似的问题。我之前的团队（在这方面工作了一年多）规模很大，我们为一系列初始产品发布维护了一个非常庞大、快速变化的代码库。我们的烧毁看起来很可耻，但这是我们能做的最好的事情。
可能有帮助的一件事（让你的图表看起来更好）是坚持保持恒定的小时数/点数。如果您低估了一项任务，并且必须加倍工作时间，请从冲刺中提取一些内容。如果您引入了一项新任务，那么它显然比您的团队承诺的任务具有更高的优先级，因此可以将其他任务拉出来。
我们尝试在计划中和计划之前将任务分解为许多任务，但这似乎没有帮助。事实上，它只是给了我们更多该死的票来在冲刺期间跟踪。需求开始转移到门票上，并且（毫不奇怪）在所有的混乱中迷失了。
在我的新团队中，我们采用了一种非常激进的方法，并开始创建大型门票（有些超过一周），其中说“在ProjectX中实现V1.2功能”之类的东西。 ProjectX的要求/功能列表（包括1.2版）保存在Wiki上，因此机票非常干净，并且仅跟踪执行的工作。这对我们帮助很大——我们有 方式 需要跟踪的票数更少，并且能够完成所有的冲刺，即使我们不断地完成冲刺任务以帮助其他团队或扑灭火灾。
当（且仅当）我们被迫（被人）引入新项目时，我们才会继续将项目从冲刺中推出。
另一个对我们有帮助的简单提示：将“冲刺总时间”添加到您的燃尽清单中。这应该是所有估计值的总和。努力保持这条线平坦可能会有所帮助，并提高您的团队可能面临的问题的可见性（假设这不会让您降级......）
-ab
我在倦怠中也遇到了类似的问题。我通过改进燃尽图中包含的内容来“修复”它。
SiKeep 评论道：
它与选择该冲刺的积压的进展，该冲刺可能会或可能不会以释放的方式最终出现。
由于您为冲刺选择了某些内容，并且这就是燃尽图上的内容，因此我不知道所有“新工作”都应该出现在燃尽图中。我会看到它进入积压工作（不影响燃尽），除非它足够重要，可以进入当前的冲刺（然后在燃尽中显示为上升趋势）。
也就是说， 轻微的上升和下降是正常的, ，如果趋势线基本上遵循您的预期速度。我会担心你提到的过山车趋势。然而，通过仅向当前冲刺添加高优先级项目来隔离燃尽的想法可能有助于抑制燃尽的波动。
正如其他人所说，冲刺开始之前的计划应该很短......（不超过4小时).
我们对计划外任务使用“限时”任务。每当高优先级工作到来或突然出现错误时，我们都可以使用时间盒的时间（但是，我们永远不能低于零）。这种方法还有一个额外的优点，那就是我们可以轻松跟踪哪些任务是不可预见的，并在下一个冲刺计划中将这些事情考虑在内。
您可以在冲刺的开始日期整合新工作，以获得漂亮的燃尽图。
您可以使用特定标记来标记额外的工作，并在冲刺结束时评估您之前无法识别这些任务的原因。
我们现在使用burn UP图表。我们不只是绘制剩余工作量的图表，还绘制了两件事：已完成的工作量和总工作量（即已完成+未完成）。
这会在图表上为您提供两条线，当所有工作完成后，两条线应该相交。它还具有一个很大的优势，因为它可以清楚地显示何时进度缓慢，因为添加了更多工作。
如果您愿意，PO“拥有”一条线（全部工作），而开发人员/测试人员“拥有”另一条线（已完成的工作）。
当采购订单添加/删除工作时，其行会上下移动。
开发/测试人员线只会在他们完成工作后才会上升。
这是应该的。如果您的燃尽图看起来像模型图，那么您就有麻烦了。该图表将帮助您了解您是否能够做出承诺并完成所有故事。
在冲刺期间发现故事总是会发生。理想情况下，您能够预先设计并找出任务，但如果它们有效，为什么大型的预先设计不起作用呢？为了回答你的最后一个问题，冲刺计划应该采取 最多四个小时.
