jcs*_*jcs 11 agile scrum sprint
什么类型的任务可以作为Sprint Backlog中的工作项包含和跟踪？
是否可以包含分析,审核和单元测试(用户故事),或者只能在Sprint积压中包含和跟踪核心编码任务？
基本上我将用户故事分解为技术任务以更新Sprint积压,并想知道是否可以在sprint backlog中更新和跟踪具有非编码角色的任务.
您要将这些任务作为工作项进行跟踪.这样做要小心.
为什么？你开始具体化一个过程.这里有一个滑坡.一旦开始具体化流程,就会停止实际敏捷,并开始创建一个强制性顺序步骤的僵化瀑布.
如果你认为这些事情非常重要,你必须把它们写下来,或者开发人员会忘记它们,那么你就不会让开发人员有责任保持敏捷,或者有权做出自己的决定.
你认为它们不值得信任.
分析用户故事.他们无论如何都会这样做.为什么写下来？他们会忘记吗？关键是理解.不是文件.不是时间管理.
审查代码.你希望他们这样做.你必须创造这样的文化,结果是有益的.
如果代码审查的结果是"你的代码太烂了,再做一次",那么没有人参与,它不只是菲亚特做得到.
如果代码审查的结果是"给大家一个新的最佳实践中学习,从"加"也许你应该重新考虑这个根据其他最佳实践",也许人们会参加.
单元测试是sprint的一部分,没有任何问题或讨论.
实际上,它可能是冲刺中最重要的部分.在几乎任何其他代码之前,单元测试首先出现.你不需要说这个.事实上,说它的行为声称你的开发人员不能被信任进行测试.
当你感觉到为程序员写下任务的冲动时,你也必须仔细考虑问题的原因.
你为什么要把它写下来？他们在做什么？
这是重要的部分.
他们为什么不首先这样做？
他们没有分析？为什么不？你难以分析吗？用户是不是自己可用吗？
他们没有进行代码审查吗？为什么不？代码审查的障碍是什么？不够时间？没有足够的合作？没有足够的奖励？什么阻止他们？
他们没有进行单元测试吗？为什么不？测试的障碍是什么？不够时间？灵活性不够？没有足够的积极反馈进行测试？
为什么你觉得需要"控制"和"胁迫"你的开发者？他们为什么不自己这样做呢？
哪些任务可以作为工作项包含在 Sprint 待办事项列表中并进行跟踪？
根据 Scrum 指南 -> 在计划会议第 2 部分中，团队确定任务。这些任务是将产品待办事项列表转换为工作软件所需的详细工作。任务应该分解，以便可以在一天之内完成。该任务列表称为 Sprint Backlog。因此，任何符合上述准则的任务都需要包括在内。
Sprint 待办事项中是否可以包含（用户故事的）分析、审查和单元测试，或者只能包含和跟踪核心编码任务？
是的，如果这样做可以将待办事项列表转换为工作软件，那么它们可以而且应该包含在内。Scrum 从来不建议在 Sprint Backlog 中只包含编码任务。事实上，Scrum 要求团队跨职能。
基本上，我将用户故事分解为用于更新 Sprint 待办事项的技术任务，并且想知道是否可以在 sprint 待办事项中更新和跟踪具有非编码角色的任务。
这对我来说听起来很可疑。只有“你”在分解任务吗？应该是整个团队在计划会议的第二部分分解任务。同样，非编码任务可以包含在 Sprint 中。只是给您一个现实的例子：在我的 Web 开发团队中，典型的待办事项列表具有以下任务。1. 定义和发现 2. 设计和创建测试矩阵 3. 将单元测试写入测试矩阵 3. 编写使单元测试通过的代码 4. 测试 5. 回归测试 6. 调试 7. 浏览“使用 PO 的工作软件”（如果需要）以确保这就是 PO 想要的）
编辑
关于任务分配还有一点。在计划期间添加的任务应在必要时不断分解/更新/重命名。这样做的全部目的是添加一组透明的分解的事情要做，当完全完成时，最终会导致最有效和最有效地遵循 QA 标准的工作软件。这些任务应该跨职能地承担和处理，并且不应该在团队成员之间阻碍。
希望这可以帮助！
| 归档时间： |
|
| 查看次数： |
5663 次 |
| 最近记录： |