我在一家小型服务公司工作，我们开始实施Scrum实践，我们也开始使用JIRA和greenhopper进行问题跟踪。我们的团队将“完成”定义为：
我正在试图弄清楚是否应该针对每个“任务”使用上面列表中的每个项目单独的问题，或者是否应该在故障单工作流程中实现其中一些项目，或者是否只是简单地集中他们在一个问题上是最好的方法。
我不愿意制作任务的这些子任务，因为只有一级问题嵌套，我担心这种能力有更好的用途。
我也对修改工作流程并不太兴奋，因为这种方法已被证明是我们在其他系统中的负担。
如果所有这些项目都属于同一张票，那么这对我来说似乎很奇怪，因为这项工作可能会在多个团队成员之间传播，并且很难制定16小时以内包含所有这些项目的任务的东西。
我觉得我理解所有问题，但到目前为止我还不知道最佳解决方案是什么。
有最好的做法吗？还是一些强烈的意见？
答案 0 :(得分：8)
这与Scrum打算做的完全相反 - 整个团队承诺做故事，以便他们最终满足完成的定义。因此，尽管实现完成的一些要素确实是步骤，但是应该非常小心地在任何类型的定义的工作流程中巩固这些步骤。
（这很好地说明了为什么使用bug跟踪器作为scrum工具是一个坏主意。这些是不同的工具，应针对不同的事情进行优化 - 即使通过某些API链接在一起。）
答案 1 :(得分：4)
我当然不会嵌套它们，因为它们是每项任务的共同步骤。使它们成为子任务只会增加系统的复杂性和样板。这对我来说似乎是完美的工作流程阶段。
像Submitted-＆gt; Assigned-＆gt; Coding-＆gt; Review-＆gt; Testing-＆gt; Finished。
如果编码需要“编码”，“单元测试”和“集成测试”，然后再转到审核，审核需要同行评审才能转到测试，测试需要进行质量保证测试才能转到完成。
唯一的原因是，如果您允许并行执行同行评审和测试，这将是棘手的。我看到允许这样做的问题，因为如果代码未通过同行评审并随后被更改，则它会使QA完成的测试工作无效。
答案 2 :(得分：3)
- 编码
- 单元测试
恕我直言这些属于一起，因为两者都应该由同一个人处理（最好是TDD，这实际上使得无法将它们分开）。
- 集成测试
在我们的团队中，这通常由同一个开发人员完成，因此我们通常将其作为上述任务的一部分来完成。其他团队可能采用不同的方式。
- 评论
你的意思是代码评论吗？然后，对我来说，这不值得单独完成任务。否则，请澄清。
- 同行评审
单独开发人员（或更多）的单独任务。
- qa测试
测试人员/ QA人员的单独任务。
我会添加文档 - 可能并不总是需要它，但通常是。同样，它应该是一个单独的任务，通常对于执行实现的同一个人（但并非总是如此）。
到目前为止，我一直与之合作的几乎所有Scrum团队的一个主要关注点是确保从上面不遗漏任何重要事项。分区到不同的任务可能有助于此。然后你可以在你的积压清楚地看到剩下要做的事情。将所有这些集中在一个任务中可以很容易地忘记这个或那个小细节。对我们来说，最常见的是忘记代码审查和文档，这是我们将这些转变为独立任务的主要原因。
答案 3 :(得分：1)
Done定义了Team在承诺在Sprint中“执行”Product Backlog项目时的含义。某些产品不包含文档，因此“完成”的定义不包括文档。完全“完成”的增量包括增量的所有分析，设计，重构，编程，文档和测试以及增量中的所有Product Backlog项目。测试包括单元，系统，用户和回归测试，以及性能，稳定性，安全性和集成等非功能测试。
参考：Scrum指南 - 由Ken Schwaber和Jeff Sutherland撰写（Scrum的发明者）
您声明您正在关注“Scrum Practices”。听起来像你只是使用Scrum框架的一些部分而不是其他部分，这是真的吗？首先，Scrum不一定是一种实践，它是一个框架，你可以使用框架，也可以不使用框架。它在检查和适应的基础上工作，因此除了基本的Scrum框架规则之外，没有什么是一成不变的，所以你不会得到你问题的确切答案。了解答案的最佳方式是聘请经验丰富的Scrum专业人员，经验丰富的开发人员和测试人员，并在Scrum团队中尝试上述完成的计划。
记住始终检查和适应。 Scrum中有三点需要检查和调整。每日Scrum会议用于检查Sprint目标的进展情况，并进行调整以优化下一个工作日的价值。此外，Sprint评审和计划会议用于检查发布目标的进度，并进行调整以优化下一个Sprint的价值。最后，Sprint Retrospective用于回顾过去的Sprint，并确定哪些改编将使下一个Sprint更高效，更充实，更有乐趣。
不要花费大量时间记录或寻找给定过程问题的解决方案，因为大多数情况下问题变化的速度比您意识到的要快，如果您至少具备基本知识，那么检查和调整就更好了scrum和你正在使用Scrum框架而不仅仅是一些类似Scrum的做法。
答案 4 :(得分：1)
我们在JIRA中使用了一个非常相似的系统，我在这里有一个开放的问题，在Atlassian板上提出了一个非常相似的问题。我们对done做了类似的定义。我们以描述性形式创建主要故事，即“损益图上的图例文本重叠”。然后我们定义子任务，它们是“技术”或“过程”类型。技术任务是实现故事“在供应商网站上研究可能的原因”，“在信息图表类中实施修复”的实际工作。流程项目包括“同行评审”，“制作建设”，“质量保证测试”，“合并”。正如一条评论所指出，您可能会在同行评审之前/期间进行质量保证。作为Scrum流程的一部分，我们几乎所有时间都在进行QA（他们是团队的一部分），有时他们会与开发人员坐在一起，有时候他们会在测试环境中运行'bootleg builds'。这是探索性测试，被认为是我们编码过程的一部分。 “QA测试”的子任务是用于集成和回归测试，并且是在完成同行评审后对整个故事的最终验证。到那时，质量保证团队已经有了一个完整的测试计划，他们在探索性测试期间进行了测试，这通常只是贯穿计划并“检查”的问题。
在跑步冲刺一年并在回顾期间做出改变之后，我们已经到了这一步。我愿意接受建议，因为我认为回顾会议的一个缺点就是你可以将自己集中在一个方向，没有希望一直支持并考虑不同的道路。
答案 5 :(得分：1)
为此，我们使用两块板。我们为Development Sprint设有一个董事会，其中＆＃34; Done＆＃34;准备测试了。你不能进入sprint，除非你已经做好并且真正准备好开始开发（所有的分析都完成了，做了估计，人们知道他们应该做什么 - 所有的对话都已经有了，我们应该说虽然我们的谈话往往发生在JIRA评论中给予分布式团队）......然后在完成开发时退出。这是跟踪我们的开发团队是否在不受质量保证影响的情况下实现自己目标的最佳方式。与此同时，QA使用看板式电路板，他们来自＆＃34;准备测试＆＃34; （这是他们的＆＃34;待办事项＆＃34;），通过In Testing准备发布。
我们之所以切换到这一点，是因为我们之前已将所有这些步骤放在一个单一的板上，而且我们并没有“满足我们的承诺”＃34;在任何冲刺中，因为没有办法发展和在一个sprint中测试所有内容，我们必须将代码迁移到QA环境以进行最终测试，尽管测试正在进行中。我们仍在努力弄清楚如何正确地做事，所以这可能不是正确的答案，但听起来它并不是你想到的，所以也许它对你有用。
答案 6 :(得分：0)
并且很难完成包含所有这些事情的16小时以内的任务。
这是你真正的问题;能够将故事分解为小的有用的垂直切片功能。通过此工作将使您的团队更加灵活，并为PO提供更大的灵活性。
相反，通过流程/机械步骤来分解工作只会让你不那么灵活，真的没有用处。要么你已经完成，要么你没有;如果你是开发人员并且没有经过测试，没有人关心，所以不要在一小时内跟踪它......它的浪费。
重新关注你的故事，而不是任务。
答案 7 :(得分：0)
我们使用子任务。
鉴于故事是一个共享项目（整个Scrum团队都在其上工作），我们使用子任务作为“便利贴”，允许跟踪个人需要解决的任务。
我们不要求每一小部分任务都表示为子任务。
我们不是簿记员，而是开发人员。
团队协议是，如果你不能立即执行任务，只需记下它作为故事的子任务。 （使用敏捷插件，非常简单）。即。我们永远不会系统地进行子任务“创建单元测试”，但在某些情况下，当有人努力让这个发动机运行起来时，你会在故事中看到这个子任务弹出窗口。拥有它可以让团队在Scrum中讨论它。
如果要自动生成清单，请查看转换插件上的创建子任务。 https://studio.plugins.atlassian.com/wiki/display/CSOT/Jira+Create+Subtask+for+transition 它允许您在故事提交时自动添加子任务。
BTW - JIRA不仅仅是一个bug追踪器。我们在各种应用中使用它， 包括管理我们的冲刺活动。 （作为Atlassian合作伙伴，我有偏见： - ）。弗朗西斯
答案 8 :(得分：0)
重要的是你使用子任务作为真正的任务;不是主要任务的活动。问题跟踪器主要用于您正在做的事情;不是你在做什么以及以什么顺序。