关闭。这个问题是off-topic .它目前不接受答案。
想改善这个问题吗？ Update the question所以它是 on-topic对于堆栈溢出。
8年前关闭。
Improve this question
我们刚刚开始一个相当大的项目，有很多子项目。我们目前不使用任何类型的命名流程，但我希望通过后门获得某种敏捷/类似 Scrum 的流程。
我最关注的领域是为整个项目准备一个好的待办事项，至少在我的脑海中，迭代的想法是从待办事项中取出一些东西，更详细地查看并制定合理的截止日期.
我想知道人们使用什么技术将项目分解为待办事项，以及一旦创建待办事项，如何维护和排序。还有元素之间的关系是如何保持的(即必须在可能之前完成，或者这是一个故事，现在是五个)
我不确定我期望这个问题的答案是什么样的。我认为最有帮助的可能是，如果有一个开源项目以某种方式将其积压工作保持在线状态，以便我可以看到其他人是如何做到的。
从我那里得到 +1 的其他东西是来自真实项目的真实用户故事的例子(“用户可以登录”故事并不能帮助我描绘我的项目中的事物。
谢谢。
最佳答案
我建议您在采用工具之前仔细考虑，特别是因为听起来您的过程在您找到自己的脚时一开始可能是流畅的。我的感觉是，在这个阶段，工具可能更可能限制您而不是启用您，并且您会发现它无法替代 good card-wall in physical space .我建议你把精力集中在手头的任务上，当你觉得你真的需要一个工具时，捕获一个工具。到那个阶段，您将更有可能清楚地了解您的需求。
我现在已经运行了几个敏捷项目，我们从来没有需要比电子表格更复杂的工具，而且在一个预算超过一百万英镑的项目中。大多数情况下，我们发现白板和索引卡(每个用户故事一张)就足够了。
在确定您的故事时，请确保您始终以对用户有意义的方式表达它们 - 一些(可能只是一小部分)浮出水面的功能。永远不要让自己陷入编写无法向用户展示的技术细节的故事中。
安排故事的技巧是尝试优先考虑您最不了解的事情(计划您想学习的内容，而不是您想要做的事情)，同时也从允许您开发核心功能的故事开始的应用程序，使用后续故事将功能(和技术复杂性)包装在它们周围。
如果你确信你可以把拼图的一部分留到以后，不要费劲去深入了解它的细节——只需写一个故事卡片，代表你以后需要进行的重大对话，然后得到处理更重要的事情。如果您需要了解即将发生的事情的大小，请查看名为 planning poker 的宽带德尔福估算技术。 .
Mike Cohn 的书，特别是 Agile Estimating and Planning将在此阶段为您提供很多帮助，并为您提供一些有用的技巧。
祝你好运!
关于project-management - 管理大型项目的用户故事，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/118064/