我的公司尝试采用 Scrum 方法，但取得了不同程度的成功。这些是我们遇到问题的一些领域。你如何处理这些？
- 跟踪要求来自
产品营销贯穿于产品。我们正在尝试使用 JIRA 来单独跟踪所有需求，并在选择实施时为每个需求分配一个版本。
- 谁创造故事？产品
管理层认识不够
有效地创作小故事，
可能没有域的开发人员
知识，介于两者之间的分析师？
- Functional specs
- 你会写它们还是只是尝试将它们放入故事中
定义？
- 你写的是函数式的吗
每个故事的规格？每个功能？
- 您如何看待功能规格和故事之间的关系？
- 回答人们的问题
副总裁的头衔是“我们是什么
将会过去[8个月
现在]？”
让我们看看我的看法是否增加了任何东西（无论如何都不确定......）
我不确定“为每个人分配一个版本”的事情。我认为这个想法是为每个故事/功能点/开发单元设定一个“价格”，并选择当前冲刺的内容。其他一切都是积压的 - 您可以提供一些剩余工作量的指示（请参阅基于证据的调度 http://www.fogcreek.com/FogBugz/learnmore.html?section=PredictShipDates在 FogBugz 中），但我认为您不应该分配给特定的冲刺 - 一方面，您不知道到达那里时积压的内容是什么。你只知道它会改变，那为什么还要浪费时间呢？
应有指定的用户代表。如果领域知识不能集中在一个人身上，或者不止一个。但是，来自业务领域的人员应该全面负责决定冲刺的内容，当然，这取决于可用的努力。业务分析师类型可能有一席之地，但他们需要是领域专家。如果您的用户无法编写故事，即使在您的帮助下（这是合作的事情，或者应该是），那么你们都需要帮助。考虑让教练参与一两次冲刺。
您不会在敏捷环境中编写功能规范。你将编写代码。您的用户将随时待命（或者您已经面临重大风险），他们是您的规格。这个故事告诉您“什么”，并且将是一个足够小的工作单元，您应该能够相当快地决定“如何”。并重构。始终重构。这不是开销，而是流程的一部分，如果没有它，您的设计将无法令人满意地发展。
如果你的副总裁（嘿，我是副总裁，我们并不都是坏人！）问这类问题，那么你公司的部分人还没有明白。选择一个人（也许是最有能力与非技术人员打交道的人，或者可能是最没有能力的人，因为他们显然需要这种练习）向他们解释。如果所构建的内容对他们来说很重要，那么他们的问题也许表明有人没有像他们应该的那样参与其中。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
