标签: user-stories

您如何估计实施用户故事所需的时间？如果你知道它需要多长时间,那就是你做过的事情.但是,如果它对你来说是全新的呢？你为"惊喜"预留了多少时间？

我们开始使用Scrum流程进行开发.我们现在有很多用户故事.我想知道,一旦用户故事完成,经过测试和部署,你还可以用它做任何其他事情吗？我们现在正在使用小索引卡,我认为将它们扔进垃圾桶会很好.

如果你保留它们,你以后会怎么做？

你如何组织用户故事？

我为Web应用程序做了这个:

为"index"这样的网页制作了标题,然后列出了用户可以在此页面上执行的所有商店.

我继续阅读所有页面.

这是最有效的方法吗？

我们开始了一个将使用Scrum/XP管理的项目.我们预先编写了整个产品backlog用于评估目的.我们确保所有故事都以客户为中心,我们正在评估它们

• 故事业务价值:MoSCoW技术 - 必须,应该,可能,将/不会实现这一点
• 故事努力/复杂性(=故事点):1,2,3,5,8,13,21,100 - 与故事复杂性/努力相关而不是理想的持续时间

100个故事点可能有一些故事与遗嘱/将不会有,因为它们实际上是更大的复杂故事,如果需要将在以后细分.

通过不重叠MoSCoW故事,计算故事的重要性基于价值和努力.

但是,如果没有100个故事,我们的故事到目前为止(也已经细分)的复杂程度在2到8之间,我们认为这是一个适当的故事大小,以避免微观管理.但有些故事相互关联或相互依赖.如果首先完成,我们的故事可能会花费更多,如果在他们之前完成其他故事则会减少.

问题
是否有可能在开发过程中稍后调整故事点,因为我们可以处理故事任务,我们可以在其中重新评估它们,添加新内容,删除现有故事或故事情况不是这样吗？因为改变它们的复杂性,也将根据计划的速度改变结束日期估计.在这种情况下,最佳做法是什么？

我来自XP背景.我非常了解这个过程,并且拥有扎实的工作经验.我发现它是开发软件的最佳方式.

我发现自己处于各种过程医生的位置,这对我自己的理解产生了很多自我检查和重估.

我听到一个非常普遍的事情是,有些作品不能成为故事.我个人不相信这一点.借口包括

1. 它太大了(开发人员在5周结束之前没有任何东西可以显示).
2. 这是一个复杂的算法或抽象概念(需要5周时间才能完成,无需显示).

这个问题是获得提示,提示或建议.

我正在寻找关于如何解决这些和类似的感知问题的提示,技巧和建议(如果你能想到它们,还有更多).

我将标记答案,其中包含有关如何绕过不会写故事的用户/开发人员的最多信息,并解决他们为什么不这样做的许多借口(我只列出了一些,还有更多).

我正在从事一个具有非常复杂的集成需求的项目，特别是接收和发送 EDI 数据以及发生在两者之间的所有“有趣”的事情。我绝对可以将精力集中在数据处理（验证、必填字段、转换）上，但我遇到的问题是如何在待办事项中构建故事和史诗以计划和跟踪工作。

很容易说“作为经理，我可以拒绝休假请求，这样我就可以确保我有足够的员工来履行我的承诺。” 实际上，我在这方面非常擅长，但我对这种集成工作还很陌生。

对于大型集成项目，更难指出用户是谁，以及价值是什么。EDI 集成只是接口（非功能性）需求，但实施起来却是一项巨大的工作。

任何人都可以就如何在我创建的产品待办列表中构建/构建这些类型的需求提供一些指导吗？

我正在搜索是否可以通过第三方应用程序将其发布到instagram故事中。在instagram开发人员文档中，我找不到有关此的任何信息。

另外，正如我在instagram文档中看到的那样，在iOS上，我只能将照片发布到instagram feed中，而不能发布视频。有什么办法发布视频吗？

如果一个故事正在进行中，然后泳道是代码审查和 QA 就绪，那么故事的分配应该如何工作？故事是否应该继续分配给开发人员，代码审查和 QA 任务应该作为其中的子任务创建，或者故事应该在开发人员将其移动到代码审查时重新分配给审查者，并且在代码审查完成后它被移动由审阅者分配到 QA 通道，并由审阅者重新分配给 QA。对我来说，将正在进行的票证重新分配给未来的状态似乎是反模式。在进入 sprint 之前而不是之后重新分配票似乎是可以的。

假设您正在编写一段遗留代码,该代码是在您的公司开始使用像Scrum这样的敏捷方法之前编写的.

现在让我们说你发现了一个需要修复的字段中的错误,并且从来没有写过该功能的故事.团队中的每个人都知道这个特殊功能是什么以及它应该如何表现但只是没有与之相关的故事.

现在,在当前的冲刺中,您将处理该缺陷,因为市场营销和支持部门已经厌倦了处理该问题.

你是否回想起要链接到的缺陷？您是否将您的缺陷重新标记为故事并修改格式以使其看起来像故事？如果你没有创建一个故事,你会得到缺陷的分数吗？如果您确实创建了一个故事,那么您是否可以获得修复缺陷的要点(通过故事的要点)？

处理这种情况的最佳方法是什么？

更新:假设安装过程突然在Windows 7 64位上开始蓝屏系统,并且始终要求应用程序安装在所有Windows平台上.由于Service Pack 1或类似的东西,新问题可能已经出现.

根据这篇Scrum文章:

故事点是相对值,不会直接转换为特定的小时数.相反,故事点可以帮助团队量化用户故事的总体大小.这些相对估计不太精确,因此它们需要较少的努力来确定,并且随着时间的推移它们会保持更好的状态.通过估算故事点,您的团队现在将提供用户故事的一般大小,并在团队成员即将实施用户故事后,开发更详细的工作小时数估算.

任何人都可以澄清:

1. 故事点的测量尺度应该是多少？它应该是在给定产品积压中分配的10,100或最高故事点吗？
2. (一点偏离主题)"产品积压项目"(检查附加图像)包含项目的所有用户故事,而sprint积压包含产品积压中的故事子集.话说回来; 如果一个产品积压足够,那么为什么TFS允许我们有多个产品积压项？