问题标签 [requirements]

We are a small team of 3 developers (2 experienced but new to this particular business sector) developing a functionally complex product. We're using Scrum and have a demo at the end of each sprint. Its clear that the functional team have plenty of ideas but these are not well communicated to the development team and the demo poses more questions than answers.

Have you any recommendations for improving the the quality of input from the functional people?

Further info: I think part of the problem is that there are no specs or User Stories as such. Personally I think they need to be writing down some sort of requirements - what sort of things should they be writing down and to what complexity given its an agile process?

我正在寻找一个可用于跟踪项目需求的 wiki，但我们希望能够将 wiki（带格式）导出到 Microsoft Word。有谁知道这样做的wiki？

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

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

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

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

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

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

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

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

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.

我是一家金融公司内部小型 IT 部门的开发人员，曾参与过许多中小型项目，这些项目自始至终几乎没有或根本没有项目管理。这似乎总是导致范围蔓延，因此无法满足最后期限，并且不得不牺牲良好的设计/代码来满足用户/经理的短期需求。

作为一名开发人员，我可以做些什么来确保在编写任何代码之前确定用户需求，并考虑到用户/经理的需求和期望，妥善管理任何变更请求。

谢谢。

我们的团队如何以尽可能低摩擦但可用的方式从我们的“产品负责人”那里收集需求？

现在这是指导方针 - 没有无法完成或业务需要做出决定它关心质量的决定的帖子，yada yada。我工作的产品是一个成功多年的小团体。我只是想帮助他们提高一个档次。

基本上，我在一个 6 或 7 人的团队中，只有一个产品负责人。她做得很好，但同时兼顾了几个不同的角色（我相信这在极小的团队中很常见）。通常会在零星的时间给出要求（电子邮件会议、面对面的讨论、会议等）。它们永远不会进入系统，有时这会导致功能缺少发布或发布被推迟，因为每个人都忘记了必要的功能。

如果您处于类似情况，但您找到了克服此问题的方法，我很想听听。我很高兴编写代码来帮助缓解这种情况，但它不能是产品负责人必须访问才能完成任何事情的网站。她非常忙，我们需要某种方式作为一个团队一起工作，以收集这些要求。

我目前正在考虑这样的事情：开发人员和团队成员收集面对面会议上讨论的需求，并就 wiki 页面上讨论的功能写一些简短的笔记。每当这些页面更新时，产品所有者都会收到通知，然后确保准确性成为她的责任。

优点：我们将记录一些功能。缺点：开发人员要为他们通常不会承担的责任。我在这里没问题。我认为在这种情况下，这是团队合作。

当然，一旦我们这样做了，我们就会看到产品负责人可能没有足够的时间来确保功能的准确性。最终她负担过重，我认为这将有助于展示这一事实，但我只需要能够首先引起人们的注意。

那么有什么建议吗？

PS她的时间非常有限，因此期望她在讨论后需要输入要求被认为是不合理的。她只有时间讨论一次然后继续前进。

假设我正在模拟一个涉及两个演员之间对话或交流的过程。对于这个例子，我将使用一些容易理解的东西：-

1. 供应商创建价目表，
2. 买方选择一些要购买的物品并发送采购订单，
3. 供应商收到采购订单并发送货物。
4. 供应商发送发票
5. 买方收到发票并付款

当然，这些步骤中的每一个本身都可能很快变得复杂。您将如何在需求文档中将其拆分为用例？

如果这个过程被视为一个单一的用例，它可以写满一本书。

或者，从上述每个步骤中创建一个用例将隐藏一些应该捕获的基本交互和流程。是否有一个用例从“收到采购订单”开始，到“发送发票”结束，然后另一个用例从“接收发票”开始，到“付款”结束？

有什么建议吗？

假设您正在处理一个企业项目，您必须在该项目中获得管理层批准才能开发新功能集。通常，您的管理层签署一些明亮闪亮的新 UI 功能是没有问题的。不幸的是，他们很难理解一些对应用程序的健康至关重要的幕后问题，例如事务、数据完整性、工作流路由、可配置性、安全性等。因为它们不是技术性的，而且这些问题是不是立即可见的，对他们来说这并不明显，这是至关重要的。

您如何说服他们必须处理这些基础设施问题并且这对他们的业务流程很重要？

1. 开发已经存在并可重复使用（商业或开源）的软件解决方案。又名“重新发明轮子”。
2. 与上述相同，但您的解决方案已被破坏。又名“重新发明方轮”。
3. 为不存在的问题制定解决方案。

同样，我对更正式的方法感兴趣，例如TRIZ

如果客户请求不在项目范围内的需求，程序员应该有多灵活？