在敏捷开发scrum中,用户故事和任务有什么区别?

用户故事和任务之间有什么区别?

 

嗯,这是一个简单的问题,我想。“差别是......,”我开始回答,团意识到它毕竟不是那么容易的差异。

 

这两个术语“ 用户故事 ”和“任务”,他们看起来非常独特。


用户故事在产品待办事项上,任务在sprint计划期间被确定,并成为sprint backlog的一部分。

 

这很好,但不是很有帮助 - 它就像是说“盐是盐罐中的盐,胡椒粉是胡椒研磨机中的东西。”当然,故事继续在产品代办事项上,而任务继续在冲刺代办事项上。

 

但两者之间的本质区别是什么?

 

我第一次被问到这个问题时,我停顿了一秒钟,并意识到我确实知道差异是什么。

 

故事通常由不止一个人来处理,而任务通常只由一个人来处理。

 

让我们看看是否有效:

用户故事通常是最终用户可见的功能。开发它通常涉及程序员和测试人员,可能是用户界面设计者或分析师,可能是数据库设计者或其他人。

 

用户故事由一个人完全开发是非常罕见的。(当确实发生这种情况时,这个人将填补其中的多个角色。)

 

另一方面,任务通常类似于代码、设计,为此类创建测试数据,自动化等等。这些往往是由一个人完成的事情。

 

你可以争辩说,其中一些是或者应该通过配对来完成,但我认为这只是我对用户故事和任务之间区别的细微差别。配对实际上是两个大脑在做一种工作时共用一双手。这仍然与典型故事中发生的多种类型的工作不同。

 

然而,我使用了一些摇摆不定的术语,比如说任务通常是由一个人完成。这就是我犹豫的原因:一些任务是会议——例如,在三个团队成员之间进行设计审查—— 我仍然会认为这是一个任务而不是用户故事。

 

因此,或许更好的区别是用户故事包含多种类型的工作(例如,编程,测试,数据库设计,用户界面设计,分析等),而任务仅限于单一类型的工作。

其他