关于scrum：在敏捷环境中的要求，规范和管理

我不确定"将发布分配给每个人"的事情。我以为这个想法是在每个故事/功能点/开发单元上加一个"价格"，并选择当前冲刺的内容。其他所有事情都是待办事项-您可以提供一些剩余工作量的指示(请参阅FogBugz中基于证据的计划)，但我不认为您应该分配给特定的sprint-您不知道当时的待办事项你到达那里，是一回事。您所知道的是它将要改变，那么为什么要浪费时间呢？

应该有一个指定的用户代表。如果领域知识不能集中于一个人，则不止一个。但是，业务领域中的某个人应该总体上负责确定冲刺的内容，当然要视可用的努力而定。可以有一个业务分析师类型的地方，但是他们必须是领域专家。如果您的用户即使在您的帮助下也无法写故事(这是合作的事情，或者应该是这样)，那么您都需要帮助。考虑让一名教练参加一两次冲刺。

您不会在敏捷环境中编写功能规范。您将编写代码。您的用户将随时待命(或者您已经面临重大风险)，这是您的要求。这个故事告诉您"是什么"，并且它将是一个足够小的工作单元，您应该能够相当快地决定"如何"。并重构。始终重构。这不是开销，它是流程的一部分，没有它，您的设计将无法令人满意地发展。

如果您有问类似问题的副总裁(嘿，我是副总裁，我们还不错！)，那么您公司的某些部门还没有得到解决。选择一个人(可能最擅长与非技术人员打交道的人，或者可能是最不擅长与非技术人员打交道的人，因为他们显然需要实践)向他们解释。如果构建的内容对他们来说很重要，那么也许他们的问题表明某人并未像他们本应的那样参与其中。

您应该将需求转换为产品待办事项列表。您可以使用此积压决定为每个Sprint迭代选择哪些Sprint积压项目。管理层决定产品待办事项列表上的内容，但是团队需要同意他们可以在Sprint中产生什么(这是每次Sprint都会进行的协商)。

您的产品负责人(通常是产品经理)负责创建故事。故事很简单(作为系统管理员，我需要能够添加用户)。如果您的产品管理人员不了解您的产品，那么您就有麻烦了。

敏捷是指根据需要进行设计。设计绝不是故事。规范可以按故事或按功能。您可以在一个涵盖多个故事的规范中设计所有CRUD。

产品负责人在每次Sprint结束时都会获得产品演示。因此，价值在每个周期都得到证明。因此，您的副总裁将每月获取报告(通常是3周的开发时间，即1周的时间为Sprint演示做准备)。