作为一个刚接触敏捷的人,我不确定我是否完全理解用户故事、功能和史诗之间的关系或区别。
根据这个问题,一个功能是一个故事的集合。 其中一个答案表明,一个功能实际上是一个史诗。那么,特征和史诗是否被认为是同一种东西,即基本上是相关用户故事的集合?
我们的项目经理坚持认为有一个分层结构。
史诗 -> 功能 -> 用户故事
而且,基本上所有的用户故事都必须属于这个结构。 因此,所有的用户故事必须属于一个总的特征,所有的特征必须属于一个史诗。
对我来说,这听起来很别扭。 谁能澄清一下用户故事、特性和史诗之间的关系? 或者有一篇文章清楚地概述了这些区别?
它们实际上是非常通用的术语。有许多方法来解释它们,在文献中有所不同,人们如何看待它们。对我说的每句话都要抱着极大的信心。
通常情况下,Epic包括你的软件中一个非常全局的、不是很好定义的功能。它是非常广泛的。当你试图理解它并使其适合敏捷迭代时,它通常会被分解成更小的用户故事或功能。例子:
Epic
功能和用户故事是更具体的功能,你可以很容易地用验收测试来测试。通常建议它们的粒度要足够大,以适应单一的迭代。
特性通常倾向于描述你的软件做什么。
功能
用户故事倾向于表达用户想做什么。
用户故事 作为银行职员。 我希望能够修改客户的信息 这样我就可以保持它的最新状态。
我不认为这两者之间真的有层次之分,但如果你愿意或符合你的工作方式,你可以有一个层次。一个用户故事可以是一个功能的具体理由,或一个具体的方法。也可以反过来说。一个功能可以是实现用户故事的一种方式。或者它们可以表示相同的东西。你可以同时使用:用户故事来定义什么能带来商业价值,特征来描述软件的制约因素。
用户故事:作为一个客户,我想用最流行的信用卡付款。 功能支持政府的GOV-TAX-02 XML API。
还有一个场景的问题,这通常是一个功能/用户故事的执行方式。它们通常与特定的验收测试相吻合。比如说
场景。取钱 鉴于我的银行账户有2000美元 当我提取100美元时 然后我收到100美元的现金 而我的余额是1900元
这就是我们在我工作的地方对这些术语的定义。这些定义远远不是数学定义或标准化术语。这就像右翼政治家或左翼政治家之间的区别。这取决于你住在哪里。在加拿大,被认为是右翼的东西在美国可能被认为是左翼的。它是非常多变的。
说真的,我不会太担心这个问题。重要的是,团队中的每个人都同意一个定义,这样你就能理解对方。一些方法,如Scrum,倾向于更正式地定义它们,但选择适合你的方法,其余的就不用管了。毕竟,敏捷不是关于个人和互动而不是流程和工具,以及工作的软件而不是全面的文件吗?
Epic:一个非常大的用户故事,最终会被分解成小的故事。
用户故事:一个非常高层次的需求定义,包含足够的信息,以便开发人员能够对实现它的努力做出合理的估计。
http://www.telerik.com/agile-project-management-tools/agile-resources/vocabulary.aspx
特征:。一个软件应用程序或库的显著特征或能力(例如,性能、可移植性或功能)。