JIRA 中 Scrum“完成”概念的最佳实践 [关闭]答案

【问题标题】：Best practice for Scrum "done" concept in JIRA [closed]JIRA 中 Scrum“完成”概念的最佳实践 [关闭]
【发布时间】：2010-09-15 19:39:57
【问题描述】：

我在一家小型服务公司工作，我们开始实施 Scrum 实践，并且我们也开始使用 JIRA 和 greenhopper 进行问题跟踪。我们的团队将“完成”定义为：

编码
单元测试
集成测试
同行评审
qa 测试
文档已更新

我正在尝试确定是否应该为每个“任务”的上述列表中的每个项目使用单独的问题来完成，或者是否应该在工单工作流程中实施其中一些项目，或者是否只是集中将它们放在一个问题上是最好的方法。

我不愿意将这些子任务作为一个任务，因为问题只有一层嵌套，我担心该功能有更好的用途。

我对修改工作流程也不太感兴趣，因为事实证明这种方法在其他系统中对我们来说是一种负担。

如果所有这些项目都是同一张工单的一部分，那么这对我来说似乎很奇怪，因为工作可能分散在多个团队成员之间，并且很难完成包含所有这些项目的 16 小时以下的任务东西。

我觉得我了解所有问题，但到目前为止我还不知道最好的解决方案是什么。

有最佳实践吗？还是一些强烈的意见？

【问题讨论】：

如果您将“完成”定义为包括“集成测试”和“质量保证测试”并将其应用于所有问题，那么根据定义，由于相互依赖，您将永远不会完成。

标签： scrum jira

【解决方案1】：

完成了 - 它必须是您定义的所有这些事情，但是使用错误跟踪器明确地将它们视为步骤可能会产生不希望的副作用，即鼓励团队内部的分裂并将东西扔到墙上。因此，一旦工单被标记为“编码”和“单元测试”，测试人员标记为已测试等，编码人员就会声称他们已经完成了。

这与 Scrum 打算做的完全相反——整个团队致力于完成故事，以便最终满足完成的定义。因此，即使实现完成的某些元素确实是步骤，但在任何类型的已定义工作流中巩固这些步骤时应该非常小心。

（顺便说一句，这很好地说明了为什么将错误跟踪器用作 scrum 工具是一个坏主意。这些是应该针对不同事物进行优化的不同工具 - 即使通过某些 API 链接在一起。）

【讨论】：

对于使用 Jira 对包含许多非常专业的任务的各种生产管道中的任务进行日常管理的大型项目，您会推荐什么作为合适的“Scrum 工具”？在许多情况下，“整个团队”需要拆分为多个更小的“子团队”。在这些情况下；我认为 Jira 绝对可以作为这些小型团队的合适“Scrum 工具”，只要您以某种方式将它们“粘合”在一起以查看“全局”。我认为找到合适的“粘合剂”将大局凝聚在一起才是真正的挑战。

【解决方案2】：

我当然不会嵌套它们，因为它们是每个任务共有的步骤。使它们成为子任务只会增加系统的复杂性和样板。这些对我来说似乎是完美的工作流程阶段。

提交->分配->编码->审查->测试->完成。

如果编码需要“编码”、“单元测试”和“集成测试”，然后再进行审核，审核需要同行评审，然后再进行测试，测试需要 QA 测试，然后再进行完成。

这会很棘手的唯一原因是如果您允许同行评审和测试并行进行。我发现允许这样做存在问题，因为如果代码未能通过同行评审并随后被更改，它会使 QA 完成的测试工作无效。

【讨论】：

我正要在我的答案的早期版本中写这些子任务就像工作流状态:-)（然后我删除了它）。正如您所指出的，真正的工作流程方法可能有点不灵活。另一个问题是，在 JIRA 中，您仍然需要可以分配时间的具体任务。以某种方式结合两全其美会很好......
这可能意味着QA需要重新测试一些项目，但并不一定会使测试工作失效。测试在很大程度上是学习——如果你延迟学习直到一切都“完美”，那与瀑布有什么不同？

【解决方案3】：

编码

单元测试

恕我直言，它们属于一起，因为两者都应该由同一个人处理（最好是 TDD，这确实使得它们无法分开）。

集成测试

在我们的团队中，这通常由同一开发人员完成，因此我们通常将其作为上述任务的一部分。其他团队可能会采取不同的做法。

已评论

你是说代码 cmets 吗？然后，对我来说，这不值得单独的任务。否则，请澄清。

同行评审

单独的开发人员（或更多）的单独任务。

qa 测试

测试人员/QA 人员的单独任务。

我会添加 documentation - 它可能并不总是需要，但经常需要。同样，这应该是一项单独的任务，通常由执行实施的同一个人完成（但并非总是如此）。

到目前为止，几乎所有与我合作过的 Scrum 团队最关心的一个问题是确保上面没有忘记任何重要的事情。划分为不同的任务可能会有所帮助。然后你可以清楚地看到你的积压工作还剩下什么要做。将所有这些都集中到一项任务中很容易忘记这个或那个小细节。对我们来说，忘记代码审查和文档是最常见的，这就是我们将这些变成独立任务的主要原因。

【讨论】：

【解决方案4】：

完成定义了团队在 Sprint 中承诺“执行”产品待办事项项时的含义。有些产品不包含文档，因此“完成”的定义不包括文档。一个完全“完成”的增量包括增量的所有分析、设计、重构、编程、文档和测试以及增量中的所有产品待办事项。测试包括单元、系统、用户和回归测试，以及性能、稳定性、安全性和集成等非功能性测试。

参考：Scrum 指南 - 由 Ken Schwaber 和 Jeff Sutherland（Scrum 的发明者）撰写

您声明您正在遵循“Scrum 实践”。在我看来，您只使用了 Scrum 框架的一部分而不是其他部分，这是真的吗？首先，Scrum 不一定是一种实践，它是一个框架，你要么使用框架，要么不使用。它是在检查和适应的基础上工作的，所以除了基本的 Scrum 框架规则之外，没有什么是一成不变的，所以你不会得到你问题的准确答案。知道答案的最佳方法是聘请经验丰富的 Scrum 专业人员、经验丰富的开发人员和测试人员，并在您的 Scrum 团队中尝试上述完成的计划。

请记住始终检查和调整。 Scrum中有三点检查和适应。 Daily Scrum 会议用于检查 Sprint 目标的进展情况，并进行调整以优化下一个工作日的价值。此外，Sprint 审查和计划会议用于检查发布目标的进展情况，并进行调整以优化下一个 Sprint 的价值。最后，Sprint 回顾用于回顾过去的 Sprint，并确定哪些调整将使下一个 Sprint 更加高效、充实和愉快。

不要花大量时间记录或寻找给定流程问题的解决方案，因为大多数时候问题的变化比您意识到的要快，只要您至少具备基本知识，最好检查和适应的 Scrum 并且您正在使用 Scrum 框架，而不仅仅是一些类似 Scrum 的实践。

【讨论】：

+1 Scrum 声称经验主义。尝试并反馈。 Scrum 确实是一个框架，不完全遵循 Scrum 的价值观、规则，就像在家里问你婆婆，让她告诉你你做错了什么。这有时会很烦人！（Ken Schwaber 自己的例子）。

【解决方案5】：

我们在 JIRA 中使用了一个非常相似的系统，我在这里和 Atlassian 板上提出了一个非常相似的问题。我们对完成有类似的定义。我们以描述性形式创建主要故事，即“损益图上的图例文本重叠”。然后我们定义“技术”或“流程”类型的子任务。技术任务是实现故事“在供应商网站上研究可能的原因”、“在信息图表类中实施修复”的实际工作。流程项目包括“同行评审”、“制作构建”、“QA 测试”、“合并”。正如一条评论指出的那样，您可能在同行评审之前/期间进行 QA。作为 Scrum 流程的一部分，我们几乎一直都在进行 QA（他们是团队的一部分），有时他们与开发人员坐在一起，有时他们会得到“盗版构建”以在测试环境中运行。这是探索性测试，对我们来说是编码过程的一部分。 “QA 测试”的子任务用于集成和回归测试，是在同行评审完成后对整个故事的最终验证。到那时，QA 团队已经有了他们在探索性测试期间制定的完整测试计划，通常只需执行计划并“检查”即可。

经过一年的冲刺并在回顾会议期间做出改变，我们已经走到了这一步。我对建议持开放态度，因为我认为回顾展的一个缺点是您可以将自己集中在一个方向上，而几乎没有希望完全退出并考虑另一条道路。

【讨论】：

【解决方案6】：

我们为此使用了两块板。我们有一块板用于开发冲刺，其中“完成”已准备好进行测试。除非您已经完全准备好开始开发，否则您无法进入 sprint（所有分析完成、估算完成，人们知道他们应该做什么——所有的对话都已经进行过，容我们说，尽管我们的对话考虑到分布式团队，往往发生在 JIRA 评论中）......当你完成开发时退出。这是跟踪我们的开发团队是否在不受 QA 影响的情况下实现自己的目标的最佳方式。同时，QA 使用看板样式板，他们从“准备测试”（这是他们的“待办事项”），通过测试中到准备发布。

我们改用这个是因为我们之前在一个板子中完成了所有这些步骤，而且我们在任何 sprint 中都没有“履行我们的承诺”，因为没有办法在一个 sprint 中同时开发和测试所有内容，我们必须将代码迁移到 QA 环境才能进行最终测试，尽管测试一直在进行。我们仍在努力弄清楚如何正确地做事，所以这可能不是正确的答案，但听起来这不是你想到的，所以也许它对你有用。

【讨论】：

【解决方案7】：

而且很难在 16 小时内完成包含所有这些内容的任务。

这是你真正的问题；将故事分解成小的有用的垂直功能切片的能力。致力于此将使您的团队更加敏捷，并为 PO 提供更大的灵活性。

相反，按流程/机械步骤分解工作只会降低您的敏捷性，并且实际上没有任何用处。要么你完成了，要么你没有；没有人关心你是否已经开发完成并且没有经过测试，所以不要费心按小时跟踪它......它是浪费。

重新关注你的故事，而不是任务。

【讨论】：

【解决方案8】：

我们使用子任务。

鉴于故事是一个共享项目（整个 Scrum 团队都在处理它），我们将子任务用作“便利贴”，以便跟踪个人需要处理的任务。

我们不要求将每个小任务都表示为子任务。

我们不是簿记员，而是开发人员。

团队协议是，如果您不能立即执行某项任务，只需将其记为故事的子任务即可。（使用敏捷插件，真的很简单）。 IE。我们永远不会有系统的子任务“创建单元测试”，但在某些情况下，当有人努力启动并运行该动态时，您会在故事中看到这个子任务弹出窗口。将它放在那里可以让团队在 Scrum 期间讨论它。

如果您想自动生成清单，请查看过渡插件上的创建子任务。 https://studio.plugins.atlassian.com/wiki/display/CSOT/Jira+Create+Subtask+for+transition 它允许您在提交故事时自动添加子任务。

顺便说一句 - JIRA 不仅仅是一个错误跟踪器。我们在各种各样的应用中使用它，包括我们的冲刺活动的管理。（作为 Atlassian 的合作伙伴，我有偏见 :-)。

弗朗西斯

【讨论】：

【解决方案9】：

重要的是您将子任务用作实际任务；不作为主要任务的活动。问题跟踪器主要用于您正在做的事情；而不是你的行为方式和顺序。

【讨论】：