我公司尝试采用Scrum方法取得了不同的成功。这些是我们遇到问题的一些领域。我们如何处理这些？

• 跟踪从产品营销到产品的需求。我们正在尝试JIRA来分别跟踪所有需求，并为每个需求分配一个发布，以供实施之用。
• 谁创造故事？产品管理人员谁不足够有效地创建小故事，谁可能没有领域知识的开发人员，或者介于两者之间的分析师？
• 我们是否为每个故事编写功能规范？每个功能？
• 我们如何看待功能规格与故事之间的关系？
• 回答副总裁的标题为"从现在起8个月后我们将获得什么？"的问题？

解决方案

回答

• 我们应该将需求转换为产品待办事项列表。我们可以使用此积压决定为每个Sprint迭代选择哪些Sprint积压项目。管理层决定产品待办事项列表上的内容，但是团队需要同意他们可以在Sprint中产生什么(这是每次Sprint都会进行的协商)。
• 产品负责人(通常是产品经理)推动故事的创建。故事很简单(作为系统管理员，我需要能够添加用户)。如果产品管理人员不了解产品，那么我们就有麻烦了。
• 敏捷就是要按要求进行设计。设计绝不是故事中的故事。规格可以是每个故事或者每个功能。我们可以在一个涵盖多个故事的规范中设计所有CRUD。
• 产品负责人在每次Sprint结束时都会获得产品演示。因此，价值在每个周期都得到证明。因此，副总裁将每月获取报告(通常需要3周的开发时间+ 1周的时间来准备Sprint演示)。

回答

让我们看看我的举动是否添加了任何内容(无论如何都不确定...)

• 我不确定"将发布分配给每个人"的事情。我以为这个想法是在每个故事/功能点/开发单元上加一个"价格"，并选择当前冲刺的内容。其他一切都是积压的-我们可以提供一些剩余工作量的指示(请参阅FogBugz中基于证据的计划)，但我不认为我们应该分配给特定的sprint-我们不知道当时积压的情况你到达那里，是一回事。我们所知道的是它将要改变，那么为什么要浪费时间呢？
• 应该有一个指定的用户代表。如果领域知识不能集中于一个人，则不止一个。但是，业务领域中的某个人应该总体上负责确定冲刺的内容，当然要视可用的努力而定。可以有一个业务分析师类型的地方，但他们必须是领域专家。如果用户即使在帮助下(或者是应该合作)也无法编写故事，那么我们都需要帮助。考虑让一名教练参加一两次冲刺。
• 我们不会在敏捷环境中编写功能规范。我们将编写代码。用户将随时待命(或者我们已经面临重大风险)，这是要求。这个故事告诉我们"是什么"，并且它将是一个足够小的工作单元，我们应该能够相当快地决定"如何"。并重构。始终重构。这不是开销，而是过程的一部分，没有它，设计将无法令人满意地发展。
• 如果我们有问类似问题的副总裁(嘿，我是副总裁，我们还不错！)，那么我们公司的某些部门还无法解决。选择一个人(可能最擅长与非技术人员打交道的人，或者可能是最不擅长与非技术人员打交道的人，因为他们显然需要实践)向他们解释这一点。如果构建的内容对他们来说很重要，那么他们的问题也许表明某个人没有像他们应该的那样参与其中。

回答

有关Atlassian(JIRA的创建者)如何使用其产品进行敏捷开发的一些信息：

• 我们如何使用JIRA和Confluence
• Atlassian敏捷过程第1部分
• Atlassian敏捷过程第2部分
• Atlassian敏捷过程第3部分
• Atlassian敏捷过程第4部分

回答

如果我们打算在编写或者设计代码方面做任何事情，那么无论我们使用哪种方法，无论编写的是Scrum，XP，Agile还是SDLC，我们都应该始终编写规范。许多人说编写规范是如此敏捷，是浪费官僚文书工作的纪念碑。一个简单的事实是，当他们说代码是规范时，他们会被误导。

明确的事实是，规范允许我们事先制定想法和设计，并且与更改程序相比，更改规范要容易得多，尤其是在不使用简单LOB应用程序的情况下。规范可确保我们对开始编码时需要的内容有更清楚的了解。

使用规范的团队不断设计更好的软件，这是一次又一次的证明。
我认为，如果我们听到有人说代码是规范，那是教条，简单明了，并为将来存储了巨大的可维护性问题。

顺便说一句，我没有反对敏捷宣言或者以Scrum之类的以光管理过程为中心的方法的任何东西。在过去的几年中，我已经多次使用它，
它提供了。我还看到优秀的软件无处不在，敏捷的焦点本可以节省下来的。但这不是万能药或者灵丹妙药。

回答

关于功能规格，Scott Ambler的"敏捷建模"站点提供了一些很好的示例。总的来说，还有很多关于敏捷需求的简洁实用的建议。

值得一看！