在Sprint Backlog中，哪些类型的任务可以被包含和跟踪作为工作项？
分析、审查和单元测试（针对用户故事）可以被包含吗？或者只有核心编码任务可以被包含和跟踪在Sprint backlog中？
基本上，我正在将用户故事分解为技术任务以更新Sprint backlog，并想知道非编码角色的任务是否可以更新和跟踪在Sprint backlog中。
Sprint工作项 - 敏捷Scrum
11
- jcs
5
我可以建议：http://area51.stackexchange.com/proposals/9543/development-methodologies - gbjbaanb
为了表示同情，我给你点个赞。不过你的问题表述方式可能会招来其他成员的抨击，特别是最后一段 :) - sjt
1@gbjbaanb 你可能会建议，但在SO上提出这个问题没有任何问题。 - Pascal Thivent
此问题不适合本站的问题范围，因此被视为不符合规定。请参阅哪些主题适合在这里提问？和应避免提出哪些问题？。您可以尝试在其他 Stack Exchange 网站上获得帮助。 - Makyen
4我投票关闭这个问题，因为它与编程无关。 - Vadim Kotov
5个回答
7
你有一些工作项目需要跟踪。但是要小心，因为这样做会具体化一个过程，存在滑坡的风险。一旦你开始具体化过程，就不再真正敏捷，而是创造了一个不灵活的强制性顺序步骤的瀑布模型。
如果你认为这些事情非常重要，必须写下来，否则开发人员会忘记，那么你就没有给予开发人员敏捷性的责任和自主权。
你在对待他们时是不信任的。
以下是需要跟踪的任务：
1.用户故事的分析。他们无论如何都会这样做。为什么要写下来？他们会忘记吗？关键是理解，而不是文档或时间管理。
2.代码审查。你希望他们这样做，你必须创造这种文化，并让结果变得有价值。如果代码审查的结果是“你的代码很烂，再做一遍”，那么没有人参与，除非是强制性的。如果代码审查的结果是“每个人都可以从中学习到新的最佳实践”，以及“也许你应该根据其他最佳实践重新考虑这个问题”，那么也许人们会参与其中。
3.单元测试是一个迭代过程中不容置疑的一部分。确实，它可能是迭代过程中最重要的部分。单元测试几乎是在任何其他代码之前进行的。你不需要说这个。事实上，说出来会声称你的开发人员不能信任去测试。
当你感到有必要为程序员写下任务时，你也必须思考这个问题：为什么？为什么你必须把这个写下来？他们为什么不做？
以下是重要的部分：
为什么他们一开始就不做呢？
他们没有分析吗？为什么？你是否让分析变得困难了？用户是否没有使自己可用？
他们没有进行代码审查吗？为什么？代码审查的障碍是什么？时间不够？合作不够？奖励不够？是什么阻止了他们？
他们没有进行单元测试吗？为什么？测试的障碍是什么？时间不够？灵活性不够？对于首先进行测试没有足够的积极反馈？
为什么你感觉需要“控制”和“强迫”你的开发人员？他们为什么不自己做这些事情？
如果你认为这些事情非常重要，必须写下来，否则开发人员会忘记，那么你就没有给予开发人员敏捷性的责任和自主权。
你在对待他们时是不信任的。
以下是需要跟踪的任务：
1.用户故事的分析。他们无论如何都会这样做。为什么要写下来？他们会忘记吗？关键是理解，而不是文档或时间管理。
2.代码审查。你希望他们这样做，你必须创造这种文化，并让结果变得有价值。如果代码审查的结果是“你的代码很烂，再做一遍”，那么没有人参与，除非是强制性的。如果代码审查的结果是“每个人都可以从中学习到新的最佳实践”，以及“也许你应该根据其他最佳实践重新考虑这个问题”，那么也许人们会参与其中。
3.单元测试是一个迭代过程中不容置疑的一部分。确实，它可能是迭代过程中最重要的部分。单元测试几乎是在任何其他代码之前进行的。你不需要说这个。事实上，说出来会声称你的开发人员不能信任去测试。
当你感到有必要为程序员写下任务时，你也必须思考这个问题：为什么？为什么你必须把这个写下来？他们为什么不做？
以下是重要的部分：
为什么他们一开始就不做呢？
他们没有分析吗？为什么？你是否让分析变得困难了？用户是否没有使自己可用？
他们没有进行代码审查吗？为什么？代码审查的障碍是什么？时间不够？合作不够？奖励不够？是什么阻止了他们？
他们没有进行单元测试吗？为什么？测试的障碍是什么？时间不够？灵活性不够？对于首先进行测试没有足够的积极反馈？
为什么你感觉需要“控制”和“强迫”你的开发人员？他们为什么不自己做这些事情？
- S.Lott
3
感谢您的回复。我的意思是需求分析、代码审查和单元测试代码。是的，它们在敏捷开发的意义上不是可交付成果，但在我看来，它们对于确保代码质量是必不可少的，我们需要花费精力去做这些工作。 - jcs
@jcs：请更新您的问题，以使其变得非常清晰明了。 - S.Lott
+1 我喜欢你将所有内容都以问题的形式表达，非常适合回顾材料。 - DancesWithBamboo
4
在Sprint Backlog中，哪些任务可以被包括和跟踪作为工作项呢？
根据Scrum指南，在规划会议的第二部分，团队确定任务。这些任务是将产品Backlog转换为可工作软件所需的详细工作。任务应该已经分解，以便可以在不到一天的时间内完成。这个任务列表被称为Sprint Backlog。
因此，只要符合上述准则的任务都需要被包括在内。
分析、审查和单元测试（用户故事）是否可以被包括或者只有核心编码任务可以被包括和跟踪在Sprint backlog中呢？ 是的，如果做这些任务有助于将Backlog转换为可工作软件，则应该包括并跟踪它们。Scrum从来没有建议仅在Sprint Backlog中包括编码任务。实际上，Scrum要求团队具备跨职能性。
基本上我正在将用户故事分解为技术任务，以更新Sprint backlog，并想知道具有非编码角色的任务是否可以更新和跟踪在Sprint backlog中。 这听起来让我感到怀疑。是只有“你”在分解任务吗？在规划会议的第二部分，应该是整个团队一起分解任务。同样，非编码任务可以包括在Sprint中。 只是为了给你一个现实的例子：在我的Web开发团队中，典型的Backlog包括以下任务。 1.定义和发现 2.设计和创建测试矩阵 3.编写单元测试以测试矩阵 3.编码使单元测试通过 4.测试 5.回归测试 6.调试 7.与PO一起查看“可工作软件”（如果需要确保这是PO想要的）
关于任务分解还有一个要点。 在规划期间添加的任务应该不断地进行分解/更新/重命名。这样做的整个目的是添加一个透明的分解后的事项清单，当完全完成时，最终会产生符合QA标准的可工作软件，最高效和最有效。这些任务应该被跨职能地拾取并处理，并且不应该在团队成员之间被阻塞。
希望这有所帮助！
分析、审查和单元测试（用户故事）是否可以被包括或者只有核心编码任务可以被包括和跟踪在Sprint backlog中呢？ 是的，如果做这些任务有助于将Backlog转换为可工作软件，则应该包括并跟踪它们。Scrum从来没有建议仅在Sprint Backlog中包括编码任务。实际上，Scrum要求团队具备跨职能性。
基本上我正在将用户故事分解为技术任务，以更新Sprint backlog，并想知道具有非编码角色的任务是否可以更新和跟踪在Sprint backlog中。 这听起来让我感到怀疑。是只有“你”在分解任务吗？在规划会议的第二部分，应该是整个团队一起分解任务。同样，非编码任务可以包括在Sprint中。 只是为了给你一个现实的例子：在我的Web开发团队中，典型的Backlog包括以下任务。 1.定义和发现 2.设计和创建测试矩阵 3.编写单元测试以测试矩阵 3.编码使单元测试通过 4.测试 5.回归测试 6.调试 7.与PO一起查看“可工作软件”（如果需要确保这是PO想要的）
关于任务分解还有一个要点。 在规划期间添加的任务应该不断地进行分解/更新/重命名。这样做的整个目的是添加一个透明的分解后的事项清单，当完全完成时，最终会产生符合QA标准的可工作软件，最高效和最有效。这些任务应该被跨职能地拾取并处理，并且不应该在团队成员之间被阻塞。
希望这有所帮助！
- sjt
1
简短回答是-选择最适合您的团队和相关用户故事的方法。例如，如果我们正在重构代码并作为用户故事的一部分进行处理，我们可能会拆分出一个单独的任务来处理首先将其放入测试中。但是，如果它是新开发，我们推断它将在我们的过程中（通常与TDD一起）进行测试。其他例子包括有时拆分出一个单独的任务以涵盖协调时间与编码、与外部供应商进行集成测试等-基本上任何离散且可衡量的任务都有助于组成特定故事（包括您上面列举的一些示例）。底线是，并没有固定的公式适用于每个故事，而是根据每个故事的个体需求量身定制任务（即使这些任务与代码无关）。
- Bob Palmer
1
谢谢。感谢您的回复。 - jcs
1
如果您在每个用户故事中创建分析、编码、审查、测试等任务，那么您将接近于所谓的Scrumfall（每个迭代被划分为瀑布阶段）。这是Scrum的一种不良现象。基本上，这些活动应该包含在单个任务中：“做某事”意味着做完成“某事”所需的所有事情=您是专业开发人员，您知道（或者政策规定）完成任务需要做什么。
这是一般情况。有时确实需要将任务分成“活动”，但首先您应该从常规流程开始，并仅在真正需要时使用此工具-例如，在一个迭代中进行尖峰任务，在第二个迭代中进行真正的任务。
编辑：我曾经使用过将任务分解为活动。我们没有进行TDD，但是在完成任务后编写了测试。因此，每个开发任务都与测试任务配对，以显示它可以由另一个开发人员完成，有时与开发同时进行。但是，由另一个开发人员进行测试的责任是团队决定的，对于复杂的任务，他们确实这样做了。
这是一般情况。有时确实需要将任务分成“活动”，但首先您应该从常规流程开始，并仅在真正需要时使用此工具-例如，在一个迭代中进行尖峰任务，在第二个迭代中进行真正的任务。
编辑：我曾经使用过将任务分解为活动。我们没有进行TDD，但是在完成任务后编写了测试。因此，每个开发任务都与测试任务配对，以显示它可以由另一个开发人员完成，有时与开发同时进行。但是，由另一个开发人员进行测试的责任是团队决定的，对于复杂的任务，他们确实这样做了。
- Ladislav Mrnka
3
我只同意你的观点，即不应该为每个待办事项遵循模板形式。但有时候，待办事项可能确实需要分析、编码、测试，这并不是瀑布式开发的特点。我的理由是，在瀑布式开发中，整个组织结构是不同的——分析团队、编码团队、质量保证团队都是孤立的。在Scrum中，团队是跨职能的，理想情况下，每个人从开始到结束都参与了每个阶段。 - sjt
只有当任务被团队内的其他成员阻塞并且没有让每个人都参与透明度时，才能称之为Scrum味道。我可以给出真实的例子，说明其实施方式与瀑布模型大不相同。而且它绝对不能被称为Scrumfall或mini waterfall。 - sjt
@sjt：我没有写他正在做Scrumfall，我写的是他正在接近。但非常好的一点是，问题没有提到每个任务是否可以由任何成员或特定成员完成。我的答案只是关于敏捷开发的主要原则之一=授权人员。创建高级任务，并将选择活动的责任交给将执行任务的人。 - Ladislav Mrnka
0
如果你把所有关注点都放在将任务拆分成更小的故事（1-3个点）上，而不是追踪任务，那么你就会更加敏捷。小故事几乎不需要任务级别的估算或跟踪。你的PO可以获得优先处理较小功能集的好处，而你可以专注于提供价值，而不是重复记录明显的步骤。当然，按小时每个故事跟踪团队达成一致的标准做法根本没有用处。
- DancesWithBamboo
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接