如何在Scrum中管理规范[[关闭]

简单的回答是,你没有。

规范中的价值通常来自于与开发团队沟通业务的想法。Scrum旨在将业务(以产品所有者的形式)引入开发团队。通过频繁地与团队进行交互(记住,个人和交互超过了流程和工具),通过频繁地看到正在工作的软件,企业可以与开发人员携手合作,开发出能够更好地解决业务问题的软件,而不是在你开始试验之前就尝试详细说明整个过程。

也就是说,需要满足某些基本标准。我们可以对此进行测试,就像任何好的测试一样,我们可以将其自动化。

Cucumber . 除了你的用户故事,最好有一套基本的满足条件,最好是“给予/何时/然后”的形式。这些条件是 最低限度

例如,“假定我已登录,当我注销时,我将被带回主页”。

如果你要有验收标准,你会想自动化它。大多数规范中最糟糕的部分是,当项目完成时,它们往往会过时,并产生灰尘。

我认为最简单的方法是让规范成为任务本身中用户故事的一部分。清楚地列出每个项目中的验收标准(或者,如果问题跟踪软件允许,将它们创建为第一类工作项类型)。让用于工作项跟踪的任何内容中的问题成为活动文档。

也有缺点,比如在规格随时间变化时查找相关问题,但是这通常可以在工作项跟踪工具中进行管理,前提是您可以将问题相互关联。

和 更新甲板。我们所有的牌组都是有组织的(在SharePoint中),这样我们就可以很容易地在将来找到它们。

我们通常在电子表格上记录规格和任务,这样每个人都知道他们在做什么。我也尝试过一些软件来实现这一点,其中最有趣的一个是来自[VersionOne][1]和[Rally][2]。

但是我仍然发现使用一个简单的电子表格是最快最简单的解决方案。

据我所知,SCRUM并不关心规范管理。你必须将你的规格或规格更改分别分解/映射到故事和任务中。但您可以为此设置一个任务:)。

1. 因为敏捷说一切都应该 在索引卡上,这意味着你 适合 在索引卡上。 (例如,你必须知道这一切是怎么回事 去上班。)

2. 隔离(隔离有什么用 例如,上传的文件页。)

你不必一次设计整个应用程序,但你必须对整个应用程序有一个愿景。然后,特别是如果你有一个设计师和程序员分离,你做一次sprint大小的块功能设计。这些设计必须被分解成故事大小的块。

我发现最有帮助的是反击故事的规模。很多组织都疯了,说故事只需要几个小时。我认为,最初的scrum手册上说的是16小时,这个时间通常足够大,可以容纳一个web应用程序的整个屏幕。因此,“implementmanagemyaccount”可能是一个故事(与“implementusername”的数百个小故事不同),“实现密码”等),然后参考你的设计文档“管理我的帐户”,并确保有word完美的截图/原型/模型,使开发人员可以看看他们和复制/粘贴文本直接到他们写的代码,他们知道哪些领域需要有(或哪些链接,或哪些图片,或任何)。