敏捷冲刺/迭代应该是背靠背的吗？

Question

我知道--这要看情况了，对吧？

我想问的是，敏捷开发中的sprint/iterations应该始终是背对背的，只有一个评审和计划会议才能将它们分开，这对团队来说是否正确和/或好呢？现在，我为不同的公司做了很多项目，我们不断地在产品上添加和/或维护功能。没有休息。我们冲刺，然后再冲刺，然后继续，据说是永远的。当我们“放慢速度”来管理科技债务时，我们会用"Sprint“来实现。搞什么鬼?我们不是在这里错误地使用了sprint的概念吗？我们不能做几个sprint来获得一个核心特性/产品交付，然后再不冲刺，直到我们真的准备好承担下一个大的部分？

你们怎么想的？

Answer 1

敏捷开发中的sprint/iterations的概念是否总是背靠背的？

是。一个Sprint是时间框，下一个sprint在上一个时间框结束后就开始了。这提供了sprint的节奏和节奏。

只有一次审查和计划会议来把他们分开

回顾和回顾在冲刺结束时进行。Sprint计划是在Sprint开始时完成的。这些Scrum事件记录了实际的Sprint，而不是发生在中间的Sprint。

没有休息。我们冲刺，然后再冲刺，然后继续，据说是永远的。当我们“放慢速度”来管理科技债务时，我们会用"Sprint“来实现。

偿还技术债务是在斯普林特内完成的故事的一部分。理想情况下，如果我们执行大多数XP实践(即:先测试，无情地重构)，那么技术债务就不会增加太多。

当然，在现实世界中，债务确实会累积起来。一种很好的策略是在用户故事分解为子任务时分配一些时间进行重构。例如，编写来自Product的用户故事，以便声明对业务的价值，但当我们将其分解为组成任务时，我们正确地估计，必须更改现有代码才能将新功能集成到其中。在Sprint的末尾，开发人员在更好的代码中获得了他们的价值，而业务在工作的软件中得到了他们的价值。

我们不能做几个sprint来获得一个核心特性/产品交付，然后再不冲刺，直到我们真的准备好承担下一个大的部分？

我会邀请开发团队回顾他们的编码实践，如果可能有一些改进，这样质量就可以内置。也许成对编程？代码评审？高级成员需要更多的时间来指导别人？测试驱动-设计，以尽量减少错误，并确保他们不是过度设计/镀金？

斯普林特回顾如何？是否提出了团队问题，并尝试了改进？日常的Scrum僵持是否会演变成旧的项目经理的“状态报告”？产品负责人是否尊重开发团队关于在Sprint中完成故事的能力的决定？

有很多可能的方法可以调整Scrum来优化性能。只要团队坚持Scrum的核心支柱透明性(人们对正在发生的事情有先见之明)、检查(工作和工作流程都被公平而现实地评估)和适应(做一些事情来改善一个情况)，每个迭代最终都应该整理成一个更好的迭代。

官方Scrum指南的进一步解读

Answer 2

sprint只是要完成的工作(待办事项)的集合，它为产品提供了一些价值。它可以添加一个新特性，也可以重构现有代码，以便更容易地维护、修复bug或两者之间的任何东西。每次冲刺的时间都是有限的，通常为1到4周。在开始时有一个计划，在结束时有一个演示/评审，以区分一个sprint和另一个sprint，但否则它们会一个接一个地运行。

如果您做了几个sprint来开发一个核心特性，然后在准备好接受下一个大特性之前没有sprint，那么在这段时间里您会做什么呢？

如果你在短跑过程中做的太多了(所以你觉得自己总是在冲刺，而不是跑马拉松)，你可能会想要重新审视你在每一次冲刺中的故事点数；你可能做的太多了。偶尔的忙忙碌碌也许可以，但如果这是正常的话，它很快就会导致精疲力竭。当你的冲刺开始和结束的时候，你也可能希望改变-星期一的冲刺计划，周五的演示/复习让你在冲刺之间有一个自然的休息。

Answer 3

对于敏捷Scrum的开发人员来说，这是一个很常见的问题，下面是你不想听到的事情:你在很大程度上导致了你自己的精疲力竭，因为工作还在进行中，如果有人因为任何原因而终止了关系，那么很小程度上帮助公司也于事无补。

我想提到的另一件事是，将sprint作为优先顺序的饼图来处理可能是有帮助的，这样您就可以将10%的饼用于技术债务。给冲刺一个主题可能会对设定目标有太大帮助，而不会使它变得单调。

或者只是切换到kanban，scrum并不适合所有的场景，尤其是在维护上有点不稳定。