4

我的公司曾尝试采用 Scrum 方法，但效果好坏参半。这些是我们遇到问题的一些领域。你如何处理这些？

  1. 跟踪从产品营销到产品的需求。我们正在尝试 JIRA 来单独跟踪所有需求，并在选择实施时为每个需求分配一个版本。
  2. 谁创造故事？没有足够知识来有效创建小故事的产品管理人员，可能没有领域知识的开发人员，介于两者之间的分析师？
  3. 功能规格
    1. 你是写它们还是只是试图将它们纳入故事定义？
    2. 您是否为每个故事编写功能规格？每个功能？
    3. 您如何看待功能规格和故事之间的关系？
  4. 回答标题为 VP 的人提出的问题“我们将在 [8 个月后] 之前得到什么？”
4

3 回答 3

4

让我们看看我的看法是否增加了任何东西（无论如何都不确定......）

  1. 我不确定“为每个人分配一个版本”的事情。我认为这个想法是为每个故事/功能点/开发单元设置一个“价格”，然后选择当前 sprint 中的内容。其他一切都是积压的——你可以提供一些剩余工作量的指示（参见FogBugz 中基于证据的调度），但我认为你不应该分配给特定的 sprint——你不知道到时候积压会是什么你到达那里，一方面。你所知道的是它会改变，所以为什么要浪费时间呢？

  2. 应有指定的用户代表。或者不止一个，如果领域知识不能集中在一个人身上。但是，业务领域的人应该全面负责决定冲刺的内容，当然，这取决于可用的努力。业务分析师类型可以有一席之地，但他们必须是领域专家。如果你的用户不能写故事，即使有你的帮助（这是一个合作的事情，或者应该是），那么你们都需要帮助。考虑让教练参与一两次冲刺。

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

  4. 如果您有副总裁（嘿，我是副总裁，我们并不都是坏人！）提出这类问题，那么您公司的某些部分还没有得到它。选择一个人（可能是最能与非技术人员打交道的人，或者可能是最没有能力的人，因为他们显然需要练习）向他们解释。如果建造的东西对他们来说很重要，也许他们的问题表明有人没有像他们应该的那样参与。

于 2008-08-19T09:26:44.023 回答
1

  1. 您应该将您的需求转化为产品待办列表。这个 backlog 用于决定为每个 Sprint 迭代选择哪些 Sprint Backlog 项目。管理层决定产品待办列表上的内容，但团队需要就他们在 Sprint 中可以生产的内容达成一致（这是在每个 sprint 中发生的协商）。

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

  3. 敏捷是根据需要进行设计。设计从未出现在故事​​中。规范可以是每个故事或每个功能。您可以在一个涵盖多个故事的规范中设计所有 CRUD。

  4. 产品负责人在每个 Sprint 结束时都会获得产品演示。因此，价值在每个周期都得到体现。所以你的副总裁会每月收到报告（通常是 3 周的开发 + 1 周的时间来准备 Sprint 演示）。

于 2008-08-19T02:44:26.393 回答
0

If you are going to do anything in regards writing or designing code, one of the things you should always do, is write a spec, irrespective of whatever methodology you are using, wether it is Scrum, XP, Agile or SDLC. Many people who say that writing specs is so unagile and a monument to wasteful bureaucratic paperwork. The simple fact is that they are misguided when they say that code is the spec.

The clear fact is that a spec allows you to formulate your ideas and designs beforehand, and its much easier to change a spec than it is to change a program, especially if you are working outside the confines of simple LOB application. Specs ensure you have a clearer understanding of what is required when you start coding.

Its been show time and time again that teams that use specs, design better software. In my opinion, if you hear anybody say the code is the spec, that is dogma, plain and simple, and is storing up huge maintainability problems for the future.

As an aside, I don't have anything against the Agile Manifesto or light management process centric methods like Scrum. I've used it in the past few years a number of times, and it delivers. I've also seen good software down the drain, where an agile focus would have saved it. But it is no panacea or silver bullet.

于 2009-04-17T12:10:18.083 回答