Sprint工作项目 - 敏捷Scrum

什么类型的任务可以作为Sprint Backlog中的工作项包含和跟踪? 是否可以包含分析,审核和单元测试(用户故事),或者只能在Sprint积压中包含和跟踪核心编码任务? 基本上我将用户故事分解为技术任务以更新Sprint积压,并想知道是否可以在sprint backlog中更新和跟踪具有非编码角色的任务。     
已邀请:
  在Sprint Backlog中可以包含和跟踪哪些任务作为工作项? 根据Scrum指南 - >在计划会议第2部分中,团队确定任务。这些任务是将产品Backlog转换为工作软件所需的详细工作。任务应该已经分解,因此可以在不到一天的时间内完成。此任务列表称为Sprint Backlog。 因此,无论满足上述指南的任何任务都需要包括在内。   是否可以包含分析,审核和单元测试(用户故事),或者只能在Sprint积压中包含和跟踪核心编码任务? 是的,他们可以而且应该被包括在内,如果这样做会导致Backlog转换为工作软件。 Scrum NEVER建议仅在Sprint Backlog中包含编码任务。事实上,Scrum要求团队实现跨职能。   基本上我将用户故事分解为更新Sprint积压的技术任务,并想知道是否可以在sprint backlog中更新和跟踪具有非编码角色的任务。 这听起来很可疑。只是'你'谁打破了任务?应该是整个团队在计划会议的第二部分中分解任务。同样,非编码任务可以包含在Sprint中。 只是为了给你一个现实的例子:在我的Web开发团队中,典型的Backlog具有以下任务。 1.定义和发现 2.设计和创建测试矩阵 3.将单元测试写入测试矩阵 3.使单元测试通过的代码 4.测试 5.回归测试 6.调试 7.查看'使用PO的工作软件(如果需要确保这是PO想要的) 编辑 还有一点关于任务。 计划期间添加的任务应在必要时不断分解/更新/重命名。这一点的重点是添加一组透明的分解事件,完成后,最终会导致按照QA标准运行的软件,最有效和最有效。这些任务应该在跨职能部门进行挑选和处理,不应在团队成员之间阻止。 希望这可以帮助!     
您要将这些任务作为工作项进行跟踪。这样做要小心。 为什么?你开始具体化一个过程。这里有一个滑坡。一旦开始具体化流程,就会停止实际敏捷,并开始创建一个强制性顺序步骤的僵化瀑布。 如果你认为这些事情非常重要,你必须把它们写下来,或者开发人员会忘记它们,那么你就不会让开发人员有责任保持敏捷,或者有权做出自己的决定。 你认为它们不值得信任。 分析用户故事。他们无论如何都会这样做。为什么写下来?他们会忘记吗?关键是理解。不是文件。不是时间管理。 审查代码。你希望他们这样做。你必须创造这样的文化,结果是有益的。 如果代码审查的结果是“你的代码很糟糕,再做一次”,那么没有人参与,除非通过命令,否则不会完成。 如果代码审查的结果是“每个人都可以学习的新的最佳实践”加上“也许你应该根据其他最佳实践重新思考”,也许人们会参与。 单元测试是sprint的一部分,没有任何问题或讨论。 实际上,它可能是冲刺中最重要的部分。在几乎任何其他代码之前,单元测试首先出现。你不需要说这个。事实上,说它的行为声称你的开发人员不能被信任进行测试。 当你感觉到为程序员写下任务的冲动时,你也必须仔细考虑问题的原因。 你为什么要把它写下来?他们在做什么? 这是重要的部分。 他们为什么不首先这样做? 他们没有分析?为什么不?你难以分析吗?用户是不是自己可用吗? 他们没有进行代码审查吗?为什么不?代码审查的障碍是什么?不够时间?没有足够的合作?没有足够的奖励?什么阻止他们? 他们没有进行单元测试吗?为什么不?测试的障碍是什么?不够时间?灵活性不够?没有足够的积极反馈进行测试? 为什么你觉得需要“控制”和“胁迫”你的开发者?他们为什么不自己这样做呢?     
简短的回答是 - 无论哪种方式最适合您的团队和相关的用户故事。 例如,如果我们正在努力将一段代码重构为用户故事的一部分,我们可能会分出一个单独的任务来处理它首先进行测试。但如果它是新开发者,我们推断它将作为我们过程的一部分进行测试(通常使用TDD)。 其他示例包括有时会分解单独的任务以涵盖协调与编码所花费的时间,与外部供应商的集成测试等等。 - 基本上,任何谨慎且可衡量的任务有助于弥补特定的故事(包括您拥有的一些示例)包括在上面)。 底线是每个故事应该没有一套公式,而是根据每个故事的个别需求定制任务(即使这些任务与代码无关)。     
如果您在每个用户故事中为Analysis,Coding,Review,Testing等创建任务,您将接近称为Scrumfall的东西(每次迭代分为瀑布阶段)。这是Scrum的一种气味。基本上这些活动应该包含在单个任务中:“做某事”意味着做你需要的一切来完成“某事”=你是专业的开发人员而你知道(或者政策说)完成任务需要做些什么。 这是一般情况。有时您确实需要将任务划分为“活动”,但首先您应该从常见过程开始,并且只有在您有真正原因时才使用此工具 - 例如一次迭代中的尖峰任务和第二次迭代中的实际任务。 编辑:我曾将任务分成活动一次。我们没有做TDD,但测试是在完成任务后编写的。因此,每个开发任务都与测试任务配对,以表明它可以由另一个开发人员完成,有时与开发并行。但是,另一个开发人员测试的责任是团队决策,对于复杂的任务,他们确实做到了这一点。     
如果您将所有应用于任务跟踪的工作集中在将故事分割得更小(1-3分),那么您将努力变得更加敏捷。小故事几乎不需要任务级别估计或跟踪。您的PO的优势在于能够优先处理较小的功能集,并且您可以专注于提供价值,而不是重复记录明显的步骤。当然,按照每个小时的小时跟踪一个团队商定的标准做法并不是很有用。     

要回复问题请先登录注册