管理大型项目的用户故事

Question

我们刚刚开始一个包含大量子项目的大项目。我们目前没有使用任何类型的命名过程，但我希望在后门获得某种敏捷/ scrum类过程。

我将重点关注的领域是整个项目的积压，至少在我的脑海中，迭代的想法是从积压中获取一些东西，更详细地查看并发展到合理的截止日期。

我想知道人们使用什么技术将项目分解为积压的东西，并且一旦创建了积压，就会如何维护和订购。还要如何保持元素之间的关系（即必须在可能的情况下完成，或者这是一个故事，现在是五个）

我不确定我希望这个问题的答案看起来像什么。我认为可能最有用的是，如果有一个开源项目以某种方式保持其在线备份，那么我可以看到其他人如何做到这一点。

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

感谢。

Answer 1

我会建议你在采用工具之前仔细考虑，特别是因为听起来你的工艺在你找到你的脚时起初可能很流畅。我的感觉是，在这个阶段，一个工具可能更有可能限制你，并且你会发现它不能代替good card-wall in physical space。我建议你把精力集中在手头的任务上，当你觉得自己真的需要时，就抓住工具。在那个阶段，您可能更清楚地了解自己的要求。

我现在已经运行了几个敏捷项目，我们从来没有需要比电子表格更复杂的工具，而且在预算超过一百万英镑的项目上也是如此。大多数情况下，我们发现白板和索引卡（每个用户故事一个）绰绰有余。

在识别您的故事时，请确保始终以对用户有意义的方式表达它们 - 一些（可能只是很小的）表面功能。永远不要让自己写下关于您无法向用户展示的技术细节的故事。

安排故事时的技巧是尝试优先考虑您最不了解的事项（计划您想要学习的内容，而不是您想要做的事情），同时从可以开发的故事开始应用程序的核心功能，使用后续故事来包装它们的功能（和技术复杂性）。

如果你有信心可以留下一些难题直到以后，不要为了弄清楚这一点的细节而烦恼 - 只要写一张单独的故事卡片代表你以后需要的大谈话，继续处理更重要的事情。如果您需要了解将来的大小，请查看名为planning poker的宽带delphi估计技术。

Mike Cohn的书籍，尤其是Agile Estimating and Planning，将在这个阶段为你提供很多帮助，并为你提供一些有用的技巧。

祝你好运！

Answer 2

像DanielHonig一样，我们也使用RallyDev（小规模），听起来它至少可以成为一个有用的系统。

此外，Mike Cohn撰写的一本关于用户故事发展方法的好书是User Stories Applied。如果你还没有，我当然建议你阅读它。它应该回答你的很多问题。

Answer 3

我不确定这是否是您正在寻找的，但它可能仍然有用。来自codesqueeze的Max Pool有一个视频解释他的“敏捷墙”。看到他的过程很酷，即使它可能不一定与你的问题有关：

My Agile Wall (Plus A Few Tricks)

Answer 4

所以这里有一些提示： 我们使用RallyDev 我们创建了一个包含我们要求的包的视图。 大型故事被标记为史诗，并被放入他们打算发布的发布积压中。儿童故事被添加到史诗中。我们发现最好保持故事的细节。粗粒度的故事使得难以现实地估计和执行故事。

总的来说：

1. 按发布组织

2. 请 2-4周之间的迭代

3. 产品所有者和项目 经理们在发布中添加故事 积压

4. 开发团队估计 基于TShirt尺寸的故事， 点等...
5. 在春季计划中 开发团队选择的meeetings 为从事的迭代工作 发布积压。

这是我们过去4个月一直在做的事情，并且发现它运作良好。非常重要的是要保持故事的规模小而粒度。

记住用于评估用户故事的Invest和Smart缩略词，一个好故事应该是： 我 - 独立 N - 面议 V - 有价值 E - 估计 S - 小 T - 可测试

智能：

S - 具体 M - 可衡量 A - 可实现 R - 相关 T - 时间框

Answer 5

我首先说保持简单..使用带跟踪（和备份）的共享电子表格。如果您看到扩展或同步问题，以便将积压保持在一致状态变得越来越耗时，那么就要进行交易。这将自动验证并证明支出/再培训费用。

我读过Mingle from Thoughtworks的一些好消息。

Answer 6

这是我对类似问题的回答，可能会给你一些想法

Help a BA! Managing User Stories ...

Answer 7

很多这些回复都是关于使用工具的建议。但实际情况是，您的流程将比您用于实施流程的工具重要得多。远离试图将方法塞进喉咙的工具。但是，要小心使用新工具简单地实现旧的非敏捷流程。在确定流程工具时，需要考虑以下一些重要事实：

1. 使用软件工具检测的错误流程会导致错误 软件工具实现。
2. 流程将根据您管理的群组进行更改。该 重要的是人，而不是过程。实施一些东西 他们可以成功地工作，您的项目将会成功。

所有这些说明，以下是一些可以帮助您的指南：

• 从文档化流程的纯实现开始，
• 让你的迭代变小，
• 每次迭代后与您的团队交谈并询问他们是什么 会改变，实施有意义的改变。

对于大型组织，如果您使用的是SCRUM，请使用级联站立机制。 Scrum大师与他们的团队见面。然后，Scrum大师以6比9的单口相遇，超级Scrum-MAster负责将Scum-Master的scrum中的项目报告到下一级......等等......

您可能会发现每周超级scrum会议就足以满足您层次结构的最高级别。