首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >Sprint工作项-敏捷Scrum

Sprint工作项-敏捷Scrum
EN

Stack Overflow用户
提问于 2010-10-22 20:13:29
回答 5查看 5.9K关注 0票数 11

在Sprint Backlog中可以包含和跟踪哪些类型的任务作为工作项?

是否可以在Sprint backlog中包含分析、评审和单元测试(用户故事),或者只能包含和跟踪核心编码任务?

基本上,我将用户故事分解为技术任务,以更新Sprint backlog,并想知道是否可以在sprint backlog中更新和跟踪具有非编码角色的任务。

EN

回答 5

Stack Overflow用户

回答已采纳

发布于 2010-10-23 00:05:32

哪些任务可以作为工作项包含在Sprint Backlog中并进行跟踪?

根据Scrum Guide ->In the planning meeting part 2,团队确定任务。这些任务是将Product Backlog转换为工作软件所需的详细工作。任务应该已经分解,这样才能在一天内完成。这个任务列表被称为Sprint Backlog。因此,任何符合上述准则的任务都需要包括在内。

是否可以在Sprint backlog中包括(用户故事的)分析、审查和单元测试,或者只能包括和跟踪核心编码任务?

是的,如果这样做会导致将待办事项转化为工作软件,那么它们可以而且应该被包括在内。Scrum从不建议在Sprint Backlog中只包含编码任务。事实上,Scrum要求团队是跨职能的。

基本上,我正在将用户故事分解为更新Sprint backlog的技术任务,我想知道是否可以在sprint backlog中更新和跟踪具有非编码角色的任务。

这听起来很可疑。是不是只有“你”才能分解任务?它应该是整个团队在计划会议的第二部分分解任务。同样,非编码任务也可以包含在Sprint中。给您一个实际的例子:在我的Web开发团队中,典型的待办事项具有以下任务。1.定义和发现2.设计和创建测试矩阵3.将单元测试写入测试矩阵3.使单元测试通过的代码4.测试5.回归测试6.调试7.使用PO检查工作软件(如果需要,以确保这是PO想要的)

编辑

关于任务的另一点。在规划期间添加的任务应在必要时不断分解/更新/重命名。这样做的全部要点是添加一组透明的分解后的事情要做,当完全完成时,最终导致工作软件遵循QA标准,最有效和最有效。这些任务应该被挑选出来,在交叉职能上工作,而不应该在团队成员中被阻止。

希望这能有所帮助!

票数 4
EN

Stack Overflow用户

发布于 2010-10-22 20:23:38

您希望将这些任务作为工作项进行跟踪。执行此操作时要小心。

为什么?你开始具体化一个过程。这里有个滑坡路。一旦你开始具体化这个过程,你就不再是真正的敏捷,而是开始创建一个由强制顺序步骤组成的僵硬的瀑布。

如果你认为这些事情很重要,你必须把它们写下来,否则开发人员会忘记它们,那么你就没有给你的开发人员敏捷的责任,或者给他们自己做决定的权力。

你把他们当做不值得信任的人。

用户故事的

  1. 分析。他们无论如何都会这么做的。为什么要写下来呢?他们会忘记吗?重点是understanding.而不是文档。不是代码的time management.
  2. Review。你想让他们这么做。你必须创造这样的文化,这样做的结果是奖励

如果代码审查的结果是“你的代码很烂,再来一次”,那么没有人参与,除非通过fiat.If,否则它不会完成。代码审查的结果是“每个人都可以学习的新的最佳实践”加上“也许你应该根据其他最佳实践重新思考”,也许人们会认为participate.

  • Unit测试是冲刺的一部分,没有任何问题或讨论。

实际上,它可能是中最重要的部分。单元测试是第一位的,几乎在任何其他代码之前。你不需要这么说。事实上,说它的行为表明你的开发人员不能被信任来进行测试。

当你感觉到要为程序员写下任务的冲动时,那么你也必须思考为什么这个问题。

你为什么要把这个写下来?他们有什么没做的?

这里是重要的部分。

为什么他们一开始就不这么做?

他们不是在分析吗?为什么不行?你是不是让它很难分析?用户是不是不能让自己可用?

他们不是在做代码审查吗?为什么不行?代码审查的障碍是什么?时间不够吗?没有足够的合作?奖励不够多?是什么阻止了他们?

他们不是在做单元测试吗?为什么不行?测试的障碍是什么?时间不够吗?灵活性不够吗?没有足够的积极反馈来先做测试?

为什么你觉得有必要“控制”和“强迫”你的开发人员?为什么他们不自己做这件事?

票数 6
EN

Stack Overflow用户

发布于 2010-10-22 20:26:13

简短的答案是--只要对你的团队和用户故事最有效。

例如,如果我们正在重构一段代码作为用户故事的一部分,我们可能会分开一个单独的任务来处理首先对其进行测试。但如果它是新的开发,我们推断它将作为我们过程的一部分进行测试(通常使用TDD完成)。

其他的例子包括有时分开一个单独的任务来涵盖协调与编码,与外部供应商的集成测试等花费的时间-基本上,任何谨慎和可衡量的任务,帮助构成特定的故事(包括你上面包括的一些例子)。

底线是,对于每个故事应该有什么,没有一个固定的公式,而是根据每个故事的个人需求来定制任务(即使这些任务与代码无关)。

票数 1
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/3996654

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档