Requirements, Specs, and Managing Up in an Agile Environment我的公司尝试采用Scrum方法取得了圆满成功。这些是我们遇到问题的一些领域。您如何处理这些？ 从产品行销到产品。我们正在尝试JIRA来分别跟踪所有需求，并为每个需求分配一个发布，以供实施之用。 管理层不够了解 创造有效的小故事， 可能没有域的开发人员 知识，分析师之间？ 定义？ 每个故事的规格？每个功能？ 副标题为"我们是什么 距离[从8个月后 现在]？" 有关Atlassian(JIRA的创建者)如何使用其产品进行敏捷开发的一些信息：
让我们看看我的拍摄是否添加了任何东西(无论如何都不确定...) 我不确定"将发布分配给每个人"的事情。我以为这个想法是在每个故事/功能点/开发单元上加一个"价格"，并选择当前冲刺的内容。其他所有事情都是待办事项-您可以提供一些剩余工作量的指示(请参阅FogBugz中基于证据的计划)，但我不认为您应该分配给特定的sprint-您不知道当时的待办事项你到达那里，是一回事。您所知道的是它将要改变，那么为什么要浪费时间呢？ 应该有一个指定的用户代表。如果领域知识不能集中于一个人，则不止一个。但是，业务领域中的某个人应该总体上负责确定冲刺的内容，当然要视可用的努力而定。可以有一个业务分析师类型的地方，但是他们必须是领域专家。如果您的用户即使在您的帮助下也无法写故事(这是合作的事情，或者应该是这样)，那么您都需要帮助。考虑让一名教练参加一两次冲刺。 您不会在敏捷环境中编写功能规范。您将编写代码。您的用户将随时待命(或者您已经面临重大风险)，这是您的要求。这个故事告诉您"是什么"，并且它将是一个足够小的工作单元，您应该能够相当快地决定"如何"。并重构。始终重构。这不是开销，它是流程的一部分，没有它，您的设计将无法令人满意地发展。 如果您有问类似问题的副总裁(嘿，我是副总裁，我们还不错！)，那么您公司的某些部门还没有得到解决。选择一个人(可能最擅长与非技术人员打交道的人，或者可能是最不擅长与非技术人员打交道的人，因为他们显然需要实践)向他们解释。如果构建的内容对他们来说很重要，那么也许他们的问题表明某人并未像他们本应的那样参与其中。 关于功能规格-Scott Ambler的"敏捷建模"站点上有一些很好的示例。总的来说，还有很多关于敏捷需求的简洁实用的建议。 值得一看！ 您应该将需求转换为产品待办事项列表。您可以使用此积压决定为每个Sprint迭代选择哪些Sprint积压项目。管理层决定产品待办事项列表上的内容，但是团队需要同意他们可以在Sprint中产生什么(这是每次Sprint都会进行的协商)。 您的产品负责人(通常是产品经理)负责创建故事。故事很简单(作为系统管理员，我需要能够添加用户)。如果您的产品管理人员不了解您的产品，那么您就有麻烦了。 敏捷是指根据需要进行设计。设计绝不是故事。规范可以按故事或按功能。您可以在一个涵盖多个故事的规范中设计所有CRUD。 产品负责人在每次Sprint结束时都会获得产品演示。因此，价值在每个周期都得到证明。因此，您的副总裁将每月获取报告(通常是3周的开发时间，即1周的时间为Sprint演示做准备)。 如果要在编写或设计代码方面做任何事情，那么无论使用何种方法，Scrum，XP，Agile或SDLC都是您应该始终写的规范。许多人说，编写规范是如此敏捷，并且是浪费性的官僚文书工作的纪念碑。一个简单的事实是，当他们说代码是规范时，他们会被误导。 一个明确的事实是，规范允许您预先制定想法和设计，并且与更改程序相比，更改规范要容易得多，尤其是在不受简单LOB应用程序限制的情况下。规范可确保您对开始编码时所需要的内容有更清晰的了解。 使用规格，设计更好的软件的团队一次又一次地表现出来。 顺便说一句，我没有反对敏捷宣言或以Scrum之类的以光管理过程为中心的方法的任何东西。在过去的几年中，我已经多次使用它， |
