问题标签 [user-stories]

I've been applying agile for a few months now on my project. However we are seeing a steady problem with our iteration burndowns. We aren't hitting zero each iteration.

The tasks remaining are QA tasks. Things like writing tests, testing, etc.

Now, there is some organizational resistance to the "cross-functional team" idea of agile. Dev's develop for single projects but Testers are shared for multiple projects. Which is quite contrary to the agile idea of Dev's and QA working together.

The fact that my tester's time is split across so many other projects is the cause of our slowdowns. The developers are testing to pick up as much slack as they can, but some tasks are still not getting done.

From what I see, I can do two things:

1. Persuade the organization to move towards "each project having a dedicated QA person"
2. Change my definition of "Done" to not include QA/Testing work. Things would still be unit tested though.

I'd much rather avoid doing #2, since I value the testing collaboration we're doing.

What advice do you have for my predicament?

我们刚刚开始一个包含许多子项目的非常大的项目。我们目前不使用任何类型的命名流程，但我希望通过后门获得某种敏捷/类似 scrum 的流程。

我将最关注的领域是整个项目的积压工作，至少在我的脑海中，迭代的想法是从积压工作中提取一些东西，更详细地研究并开发到合理的截止日期.

我想知道人们使用什么技术将项目分解为待办事项，以及一旦创建了待办事项，它是如何维护和排序的。以及如何维护元素之间的关系（即必须在可以这样做之前完成，或者这是一个故事现在是五个故事）

我不确定我期望这个问题的答案是什么样的。我认为最有帮助的是，如果有一个开源项目以某种方式保持其积压在线，以便我可以看到其他人是如何做到的。

其他可以从我那里得到+1的东西是来自真实项目的真实用户故事的例子（“用户可以登录”的故事并不能帮助我描绘我的项目中的事物。

谢谢。

We attempt to do agile development at my current job and we succeed for the most part. The main problem seems to be that the developers on the project are always waiting for requirements at the beginning of the sprint and rushing to get get things down by the end. The business analysts who are delivering the requirements are always working non-stop to get the requirements done.

EDIT: Additional Information: We are customizing a COTS application for our internal use. Our 'user stories' just consist of what part of the application we will be customizing in the specific sprint and also what systems we will integrate with internally. The integration with different systems normally works pretty well because we can start working on that right away. The 'customize x screen' are the main problems areas because the developers can't do anything from that. We have to wait until we get the requirements from the BAs before we can really do anything.

EDIT: More insight/confusion perhaps: I wonder if part of the problem is that the screen that are being customized are already there as this is a COTS product that is being heavily customized. People suggest that the user stories should be along the lines of 'make a screen that does X'. That's already done. Maybe there isn't a good way to do user stories for these requirements... maybe this need to be a whole new question.

如果有人试图做敏捷，我正在想办法为此使用 JIRA / Greenhopper。我们是一个全球开发团队，因此分布式特性在这里至关重要。

我们最初使用 Scrumworks，但团队抱怨他们在 JIRA 和 scrumworks 中一直有重复的信息，并认为这是多余的。

我们得到了 Greenhopper，并认为这可以解决我们的问题，但我遇到的问题是：

1. JIRA 中没有用户故事概念
2. Greenhopper 过于专注于“任务”而没有在用户故事级别进行聚合。

有没有人在 JIRA 中成功地做到了这一点，或者我们是否应该考虑回到其他工具，如 scrumworks，只使用 JIRA 来解决我们支持团队提出的错误。

我正在为我朋友的业务编写一个小应用程序，并想借此机会复习我在年初进行的一些敏捷项目管理培训。

我（我认为，我现在的组织！）一直在努力以用户故事的形式收集需求，其形式如下：

作为 [用户类型] 我想要 [功能] 以便 [一些好处]

我总是很想错过开始和结束，然后离开这个功能——但这只是变成了收集旧方法的需求！

但我不想让它适合，这样我就可以说“我正在做敏捷”......例如，如果我知道要向用户展示一个项目列表，那么原因不言而喻，不是吗？

例如

作为[商店经理]，我想[查看库存商品列表]，以便...？

省略 [so that] 子句是正常的做法吗？

您如何估计实施用户故事所需的时间？如果这是您在知道需要多长时间之前就已经完成的事情。但是，如果它对您来说是全新的呢？你为“惊喜”预留了多少时间？

在 Scrum 中有几种方法可以做燃尽图。

有些人建议使用未完成故事的故事点作为 Scrum 中的燃尽图。

优点：只有完成的故事才能降低图表

对比：图表一开始没有向下移动，然后迅速下降

其他人建议使用剩余的任务数

Pro : 图表会向下移动，你可以看看它是否在终点线之上

反对者：你可以向下移动到最后说剩下 10 个任务（困难任务），但仍然没有完成一个故事。你失败了，因为只有完成的故事才对你的产品负责人有益。

解决方案是否同时具有未完成的故事点和未完成的任务图表？

用例只是多个用户故事吗？

使用用户故事而不是用例有什么好处……反之亦然……何时使用一个而不是其他……所有敏捷方法都使用用户故事吗？

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

如果你保留它们，你以后如何处理它们？

有谁知道任何可以用来创建敏捷用户故事而不是使用 3M 便笺手动创建的软件。我正在努力变得更环保，成为一个好的应用程序，我可以用它来收集用户故事，然后创建一个漂亮的文档来交给客户。

谢谢！