我的公司试图采用scrum方法并取得了成功。论文是我们遇到问题的一些领域。你怎么处理这些？
答案 0 :(得分：4)
让我们看看我的拍摄是否会增加任何东西（不确定无论如何......）
我不确定“为每个人分配一个发布”的事情。我认为这个想法是在每个故事/功能点/开发单元上加上“价格”，并选择当前冲刺中的内容。其他一切都是积压 - 您可以提供一些剩余工作的指示（请参阅FogBugz中的evidence based scheduling），但我认为您不应该分配给特定的冲刺 - 您不知道积压的内容是什么一次到达那里的时间。你所知道的是，它会发生变化，为什么要浪费时间呢？
应该有指定的用户代表。或者不止一个，如果领域知识不能集中在一个人身上。但是，当然，根据可用的努力，来自业务领域的某个人应该负责决定什么进入冲刺。可以有一个商业分析师类型的地方，但他们需要是领域专家。如果你的用户不能写故事，即使你的帮助（这是一个合作的事情，或应该是），那么你们都需要帮助。考虑让一名教练参与一两个冲刺。
您不会在敏捷环境中编写功能规范。你会写代码。您的用户将随时待命（或者您已经面临重大风险）并且他们是您的规格。这个故事告诉你“什么”，并且将是一个足够小的工作单元，你应该能够很快地决定“如何”。并重构。总是重构。这不是开销，它是流程的一部分，没有它，你的设计就不会令人满意地发展。
如果你有副总裁（嘿，我是副总裁，我们并非都不好！），他们会问这样的问题，那么贵公司的部分内容还没有得到。选择一个人（最能够与非技术人员打交道的人，或者也许是那些能力最差的人，因为他们显然需要这种做法）向他们解释。如果构建的内容对他们很重要，也许他们的问题表明某人没有参与其中。
答案 1 :(得分：4)
有关Atlassian（JIRA的创建者）如何使用其产品进行敏捷开发的一些信息：
答案 2 :(得分：1)
您应该将您的需求转换为产品Backlog。此待办事项用于确定为每个Sprint迭代选择的Sprint Backlog项目。管理层决定产品Backlog上的内容，但团队需要同意他们在Sprint中可以产生的内容（这是在每个sprint中进行的协商）。
您的产品负责人（通常是产品经理）负责创建故事。故事很简单（作为系统管理员，我需要能够添加用户）。如果您的产品管理层不了解您的产品，则您遇到了麻烦。
敏捷是指按要求进行设计。设计永远不会出现在故事中。规范可以是每个故事，也可以是每个功能。您可以在一个规范中设计所有CRUD，其中包含多个故事。
产品负责人在每个Sprint结束时都会获得产品演示。因此，每个周期都会证明价值。因此，您的副总裁将每月获得报告（通常为3周的开发+ 1周，以准备Sprint演示）。
答案 3 :(得分：1)
关于功能规格 - Scott Ambler's "Agile Modeling" site有一些很好的样本。对于敏捷需求，一般还有很多简明实用的建议。
值得一看！
答案 4 :(得分：0)
如果您打算在编写或设计代码方面做任何事情，那么您应该经常做的事情就是编写规范，无论您使用何种方法，Scrum，XP，Agile或SDLC都是如此。许多人说编写规范是如此不合理，并且是浪费官僚文书工作的纪念碑。简单的事实是，当他们说代码是规范时，他们被误导了。
明确的事实是，规范允许您事先制定您的想法和设计，并且更改规范比更改程序更容易，特别是如果您在简单的LOB应用程序范围之外工作。规范可确保您更清楚地了解开始编码时所需的内容。
一次又一次地展示了使用规格的团队，设计出更好的软件。 在我看来，如果你听到有人说代码是规范，那就是教条，简单明了，并且存储着巨大的可维护性问题。
顺便说一句，我没有任何反对敏捷宣言或光线管理过程的中心方法，如Scrum。过去几年我曾经多次使用它， 它提供了。我也看到了很好的软件，敏捷的焦点可以保存它。但它不是灵丹妙药或银弹。