问题标签 [sprint]

我正在修改软件工程考试，其中一个问题让我想知道。它显示了一个燃尽图，其中团队在 10 天内没有在用户故事上取得任何进展。问题是“概述并证明 ScrumMaster 此时可能考虑采取的任何行动”。

我想过采取激烈的行动，比如停止冲刺。然后是分配结对编程来帮助用户，并考虑更多地分解用户故事。有人有其他建议吗？（这个问题在过去的论文中值四分）。

我的组织目前正在实施 Scrum。在处理产品待办事项以更改某些业务逻辑的处理方式时，我们意识到某些业务逻辑存在缺陷。PBI 及其验收标准目前面向修改现有业务逻辑的实现。PO 认为对业务逻辑本身的这种更改是一个高优先级，应该以某种方式进入 sprint，开发团队也同意，特别是因为从开发的角度来看，将这两件事一起做是很有意义的。

但是，我们不确定修改验收标准或创建新的 PBI 并立即将其拉入 sprint 是否更有意义。我个人倾向于新的 PBI，因为我觉得这是一个与原始 PBI 不同的故事和一组验收标准，而且我对在冲刺中期改变验收标准持怀疑态度。PO指出，这项新要求和原PBI将同时实施，如果没有新要求，原PBI毫无意义。因此，PO 认为调整原始 PBI 的验收标准会更合适，而不是创建两个独立的最终反映相同实施的标准。

这些方法中的一种是否比另一种更适合scrum？

TFS Scrum 模板似乎没有包含存储 sprint 目标的字段。我错过了什么吗？

我在 jira board 中命名 sprint 时犯了一个错误，现在我知道了。所以现在我想编辑那些 sprint 名称以避免将来出现歧义。有可能改变吗？

这不是正在进行的当前冲刺。这些冲刺已经完成，现在我想编辑它们。如何？

我可以通过悬停重命名当前的 sprint 到 sprint 名称，但如何更改以前的 sprint 名称

我们有一个小型 Scrum 团队，负责开发一个拥有大量用户的网站。我们想改进我们的开发和发布/部署过程，但是那里有很多概念，在我们看来并不完美。由于我们不是唯一一家开发网站的公司，因此我认为在这里询问可能是个好主意；）

首先，软件状况不佳，因此无法进行持续交付或持续部署等事情，因为测试覆盖率差，而且我们无法很快改变。

我们有两周的 sprint，所以我们在那段时间开发新功能或解决 bug，在最后的 sprint 会议之后，我们将功能分支合并到 master（我们使用 git 中的功能分支和 pull-request 进行审查和合并），做一些测试，并将 master 部署到公共 beta 环境中。在那里，我们通常会发现一些错误，解决它们，然后我们将主要的包含 beta 修复程序部署到生产环境中。之后，我们开始下一个 sprint。

但这个过程远非完美。首先，在我们的 sprint review 会议上展示所有这些分支的特性是很困难的，而且因为我们只有一个被部署的主分支，我们不能轻易地将修补程序部署到不同的环境中。有时我们需要更多时间在我们的 beta 环境中进行测试，因此我们无法将新功能合并到 master 或相同的生产中，一旦部署，如果我们已经在 beta 测试新功能，我们将无法部署修补程序。如果我们预计由于较大的变化而在测试版或生产中出现错误，那么开发也不得不将功能分支保留更长的时间，因此稍后合并功能分支变得越来越痛苦。

首先，我们考虑了长期运行的分支，例如用于开发、生产和测试版的 master。所以我们可以将我们想要的任何特性合并到三个分支之一中。但是我们真的很喜欢处理拉取请求（评论、反馈和合并后删除功能分支），使用起来真的很好，但我们只能将拉取请求分支应用到另一个分支。所以在这里，我们可以在不删除分支的情况下合并到 master，并且必须切换到另一个工具来将功能合并到 beta 或生产，或者为 beta 和生产创建新的 pull request。它以这种方式工作，但它不是一个很好的工作流程，只合并到一个主分支。

我们还考虑了 git-flow（Vincent Driessen 的分支模型），它看起来不错，但它似乎更适合具有传统发布周期和版本控制的软件，而不是 100% 用于 Web 应用程序，它没有真正的版本，但可以部署一切冲刺后准备就绪。它解决了修补程序问题，有一个额外的开发分支，但它需要发布版本。所以我们可以创建一个发布分支，解决问题，将其发布到生产环境并删除发布分支。我们可以使用发布分支打开合并到 master 的拉取请求，但是如果我们想将其发布到 beta 版（我们使用 capistrano 进行部署），就会出现问题，因为分支会在每个 sprint 中更改。如果我们想在我们的 beta 环境中测试功能怎么办？我们可以使用发布分支进行测试，但是这种方式发布到生产必须等到发布/测试分支中的所有功能都准备好。如果大型功能的测试需要很长时间，我们就无法将小型更新上传到生产环境。

下一个问题是版本控制。我们使用 jira，jira 喜欢使用版本来发布。我们可以使用“1,2,3”之类的版本...，但是一个冲刺应该是一个版本吗？感觉不对，因为 sprint 计划与发布计划不一样，还是在开发 Web 应用程序时应该一样？因为有时我们会在一个 sprint 中开发功能，这些功能需要更长的时间，并且会在接下来的 1-2 个 sprint 完成后发布。使用 git-flow，这些更改在准备好之前无法合并到开发中，因为每个版本都是从开发分支分支出来的。所以这样一来，有些特征分支很长一段时间没有合并，合并变得越来越困难。这与持续集成相反。

最后但同样重要的是，部署和 QA 流程不太适合 scrum，我们没有自己的 Web 运营团队，当 sprint 准备好时，产品负责人必须审查故事，我们必须进行测试他们，将它们部署到 beta/production，并且必须立即解决其中的问题，这也会中断或下一个 sprint。我们不确定何时是合并功能分支的合适时间？在审查会议之前？这样我们可以将产品所有者不接受的特性合并到应该很快发布的分支中，但是如果我们不合并它们，我们必须在它自己的分支中演示每个特性并合并每个接受的特性分支，所以集成和测试只能在 sprint 评审会议之后开始。集成和测试可能需要几天时间并且需要开发资源，那么下一个sprint应该什么时候开始呢？发布到生产后？但是这样我们就不能每两周开始一个 sprint，也不是每个开发人员都需要进行集成和 QA，那么他们应该做什么呢？目前，我们在上一个 sprint 的审查会议之后立即开始下一个 sprint 的计划会议，但是如果我们这样做，我们不确定需要多少时间来发布从 sprint 中汲取资源的...

那么如何发布 Web 应用程序呢？您使用什么工作流程？如果我们想在工作流中集成拉取请求，最好的方法是什么？您如何将 QA 和部署集成到 Scrum 工作流程中？

我最近一直在阅读有关 sprint（敏捷方法）的内容，并且在工作流程中对测试有疑问。我知道您有 PBI（产品积压项目），它们被分解为任务。我也知道您应该一次专注于一个 PBI，而不是从不同的 PBI 中选择不同的任务。

我可能错误地假设了这一点，但是是否应该在该 PBI 的所有任务都准备好之后进行 PBI 的测试，或者这些任务是否应该相互独立地进行测试？此外，如果您确实单独测试任务，那么您会在完成所有任务之后再测试 PBI 吗？

可能没有正确的答案，我只是好奇其他人是如何做到的。

我的团队最近进行了冲刺，我们正在将用户故事分解为任务。分解用户故事的最佳实践是什么？

每项任务都应该包括开发、设计、测试等吗？还是可以单独分解任务？如果是这样，与测试无关的任务是否应该直接完成并跳过工作流程中的“验证”或“测试”列？

从我在网上阅读的内容来看，似乎没有“固定”的方式，人们的做法也不同。我很好奇人们是否对他们的方式有问题。

任何帮助都会很有用！

我们使用 Greenhopper/Jira 来规划我们的 Sprint。

一位同事想查看 sprint 期间发生的变化：完成了哪些任务；从 sprint 中添加或删除了哪些任务。

有没有一个很好的方法来做到这一点？

到目前为止，我们想到的唯一想法是在 sprint 开始和结束时导出 sprint 上下文并进行比较。

这种方法的局限性是：

• 如果我们忘记进行这样的导出，我们就失去了比较的能力，因为没有办法让时间倒流。
• 我们必须处理 excel 文件或类似文件

I want to require the Story Points field to be filled in, but only before starting all sprints. Our team doesn't evaluate the size when first creating issues so it shouldn't be required that early.

Story points will be optional at start, we'd just want it mandatory before the sprint is started.

Does anything on the Issue-level change when the Sprint starts that an issue is in?

Would this be a configuration change in Jira Agile (formerly Greenhopper) or would this exist elsewhere?

Does the Behaviours plug-in support this functionality?

我目前正在使用 Jira Agile 来管理我的项目。目前，我有 3 个项目：A、B 和 C。有什么方法可以创建一个包含来自不同项目的任务的 Sprint。例如，本周应该进行错误修复，因此项目 A 中可能会出现 2 个错误，项目 B 中会出现 3 个错误，项目 C 中会出现 2 个错误。我怎样才能做到这一点？