问题标签 [backlog]

我们在软件中积压了大量应该做的事情，有很多不同的类别，例如：

• 我们的产品需要解决的新问题领域
• 支持现有问题领域的新功能
• 我们现有用户要求的新功能
• 可用性和“外观”增强
• 后端架构升级
• Bug修复

以明智的方式管理所有这些是属于产品管理的工作，但由于很多原因，这很棘手。首先，我们有许多不同的系统来保存不同的东西（文件中的市场需求文档、错误数据库中的错误、我们的帮助台系统中的客户需求、我们内部网上的工程愿望清单等）。其次，许多项目的大小、范围、复杂性和价值都大相径庭，这意味着选择并不像按优先级排序那样简单。

因为我们现在相当大，拥有复杂的产品和大量的客户，基本的解决方案（电子表格、谷歌文档、basecamp 待办事项列表）不足以解决这个问题。我们需要一种以各种方式将事物组合在一起的方法，持续对它们进行优先级排序，明确我们正在做什么以及即将发生的事情——而不需要花费所有人的时间来管理某些工具。

您如何以一种允许企业始终做对现有客户最有价值的事情、帮助获得新客户并保持软件内部健全的方式来管理这一点？

请注意，这与开发方面不同，我认为我们已经做得很好。我们以迭代、敏捷的方式开发所有东西，一旦选择了某些东西进行设计和实施，我们就可以做到。这是我们需要弄清楚接下来要做什么的部分，这是最难的！

您是否找到了有效的方法或工具？如果有，请分享！（如果您也想知道答案，请对问题进行评分，使其保持可见:)

附录：当然最好先修复所有错误，但在实际安装在客户机器上的真实系统中，这并不总是实用的。例如，我们可能有一个很少发生的错误，并且需要大量的时间和架构巨变来修复 - 我们可能会暂时搁置它。或者我们可能有一个错误，有人认为某些东西很难使用，我们认为修复它应该等待对该区域进行更大的改造。所以，有很多原因我们不只是立即修复它们，而是保持它们开放，这样我们就不会忘记。此外，最难的是非 bug 的优先级；想象一下我们没有:)

诸如“将服务器从 v1 升级到 v2”或“提高启动性能”或“重构登录模块以降低代码复杂性”之类的技术项目是否应该进入产品 backlog，如果是这样，非技术产品所有者应该如何确定它们的优先级与其他功能更强大的积压项目相比？

是否应该有单独的技术资料积压？我们是否应该与两个可以在产品待办列表中优先考虑功能和技术内容的人共同担任 PO 角色？

在尝试将敏捷原则应用到我们的开发过程中，特别是 Scrum 原则和类似 XP 的用户故事时，我们遇到了架构方面的问题。

也许我们仍然过多地与以架构为中心的开发联系在一起，但是我们正试图保持一个强大的基于组件的开发，并与敏捷建模原则相结合。我们的目标是预先进行小型设计，在开发过程中易于演变。

我正在寻找的东西可以让我将关于我的架构和其中的组件的积压故事放入我的积压故事中：开发故事，而不仅仅是使用故事。系统故事可能是一种不同类型的用户故事，它讲述的内容与业务价值并不严格相关，而是与系统的架构和质量问题相关联。

编辑： 我发现了奥尔堡大学关于“开发者故事”的这项研究。

你有什么经验、想法或反对意见吗？

先感谢您！（这是我的第一个问题！：D）

我努力为我的 scrum 项目创建良好的可视化/跟踪，因此正在考虑几种替代方案。一个有趣的概念是Story Mapping。您对使用故事地图而不是平面积压有任何意见吗？

我们现在已经安装了 Agilo 来管理我们的 Scrum 项目，但我们遇到了一个问题：我们只能处理一个 backlog。我们怎么会有不同的积压？

谢谢你的时间！

我在一个巨大的项目上工作。在我们进行编程时，我们最终会召开无休止的积压调整会议，所有开发人员都会与团队坐下来调整用户故事的大小。

Scrum 怀疑者说这个过程花费的时间太长，而且开发时间被浪费了。

我的问题是平均需要多长时间才能确定用户故事的大小？有没有人有任何提示可以让这些尺寸调整过程更快？

Windows 端口上的积压队列似乎有 ~200 的上限。这是真的吗？如果是这样，我可以更改限制吗？

我在 Windows XP Professional 上执行 ServerSocket.accept(backlog)。

我应该迁移到 Windows Server 吗？

当使用 Socket 类时，在某个端口上与服务器建立 TCP 连接，但在服务器上，ServerSocket 能够为每个接受请求处理多个客户端连接，并将其委托给一个线程来处理请求。但是一个 ServerSocket 类怎么可能在同一个端口上接受多个 tcp 连接。

这是否意味着由操作系统决定它允许多少连接或允许的最大积压是多少，这是否可以由操作系统之上的应用程序控制（我的意思是java受操作系统支持的最大积压限制）并且是TCP规范中的积压连接有什么限制吗？

最好的问候，
凯沙夫

我最近采访了一家公司，该公司已经开始在他们的开发周期中引入 Scrum。我问其中一位开发人员他们的经验如何，听起来他们完全脱离了规划过程。他不被允许对给定 Sprint 的内容提供任何意见，也没有参与任何计划或修饰活动。

基本上，在最后一个（或两个）Sprint 开始时，他收到了一份待办事项清单。他必须将项目分解为各自的任务（以便可以在 Sprint 中处理它们），但没有参与任何计划活动；我怀疑他是否被允许对一个项目可能需要多少努力进行大量投入——我怀疑建筑师为团队决定了这一点。

这是应该如何处理 Scrum 的吗？我目前的团队完全参与了所有的规划活动，不断地添加我们关于如何处理功能以及它们可能需要付出多少努力的意见。对于一家简单地向开发人员提供待办事项清单而不征求他们意见的公司，我有点怀疑（和紧张）。

注意：我知道一旦 Sprint 开始，该列表实际上就是一个优先的待办事项列表。我担心的是没有从一开始就参与到规划过程中。

If I am grooming the backlog and I see a user story that is completely valid but is ultra low priority should it be deleted? Is the backlog supposed to be just the user stories that have a chance of getting worked on or should they be all user stories that are related to a product even if it is just some idea we got while brainstorming. What if the idea came from in as a customer request but it isn't a high priority item from the product owner's point of view?