问题标签 [scrum]

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

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

We are a small team of 3 developers (2 experienced but new to this particular business sector) developing a functionally complex product. We're using Scrum and have a demo at the end of each sprint. Its clear that the functional team have plenty of ideas but these are not well communicated to the development team and the demo poses more questions than answers.

Have you any recommendations for improving the the quality of input from the functional people?

Further info: I think part of the problem is that there are no specs or User Stories as such. Personally I think they need to be writing down some sort of requirements - what sort of things should they be writing down and to what complexity given its an agile process?

我是 PHP/MySQL 商店的第二个开发人员和最近的雇员。我之所以被录用，主要是因为我有从混乱中解决某种流程的经验。至少，这是我在上一家公司所做的。;)

自从我来到这里（现在已经几个月了），我已经邀请了我的老板、我的产品经理和其他几个关键人物（但大多数是鸡，如果你原谅基于 Scrum 的刻板印象的话）。我还帮助了解了一个已经滞后一年多的主要产品的开发周期。人们喜欢它！

但是，我的同事（目前唯一的其他开发人员）不喜欢它。她更喜欢关上门，专注于她的工作，一个人呆着。我？我喜欢协作、合作和开放的整个敏捷方法。没有她的意见，我开始了 Scrum 实践（每日 Scrum、燃尽图和其他我发现对我和我以前的团队有用的东西（ala H. Kniberg 的酷挂图）。在我们的日常站立期间，她偷偷溜走并忽略我们好像我们实际上并没有站在她的门外（我们实际上是）。这真是太神奇了。我从未见过这样的抵抗。

问题...我如何让她上船？同伴压力不起作用。

感谢 Scrum-borg 同事，

美丽的

需要一些关于制定 sprint 的团队速度的建议。

我们的团队通常由大约 4 名开发人员和 2 名测试人员组成。Scrum master 坚持每个团队成员都应该对速度计算做出同样的贡献，也就是说，在计算我们在 sprint 中可以做多少时，我们不应该区分开发人员和测试人员。根据 Scrum，这是正确的，但问题就在这里。

尽管有相反的建议，但测试人员从不帮助非测试任务，开发人员从不帮助非开发任务，所以我们根本不是跨职能的团队成员。此外，尽管有各种建议，但测试人员通常会在每个 sprint 的前几天等待要测试的东西。

最终结果是，通常我们承担的开发工作比我们在 sprint 中的实际能力要多得多。例如，开发人员可能会为速度计算贡献 20 天，而测试人员可能会贡献 10 天。但是，如果您在 sprint 计划之后将任务加起来，则开发任务加起来最多 25 天，测试任务加起来最多 5 天。

遇到这种情况大家怎么处理？

如果您的团队成员在 Scrum 会议期间不合作，您会怎么做？他们要么对他们目前正在从事的工作提供一个非常高级的定义（“研究功能 x”），要么进入极其不相关的细节，尽管他们在 SCRUM 方法方面受过良好的教育。这会导致 Scrum 会议无效且无聊。

作为一名 Scrum Master，你有什么技巧可以在会议期间充分发挥人们的作用？

编辑添加：

你用什么技巧来阻止一个说话太多的人，而不是冒犯？

您使用什么技术来鼓励某人提供更详细的答案？

当你发现自己是唯一一个倾听的人，而其他团队成员只是坐在那里甚至可能睡着时，你会如何反应？

我们已经使用 Scrum 大约 9 个月了，而且基本上是成功的。然而，我们的燃尽图很少看起来像“模型”图表，而更像是一个可怕的过山车，带有一些呕吐物引起的爬升和下降。

为了尝试解决这个问题，我们在 sprint 原型设计和设计之前花费了更多时间，但我们在 sprint 期间发现的工作似乎仍然比最初想象的要多得多。注意：我的意思是满足积压工作所需的工作比最初想象的要复杂得多，而不是我们已经确定了积压工作的新项目。

这是 Scrum 的一个常见问题吗？是否有人有任何提示可以帮助顺利进行？

我应该指出，我们的大部分开发工作都不是全新的，因此我们正在维护现有大型复杂应用程序的功能。Scrum 是否不太适合这种类型的开发仅仅是因为您不知道现有代码会抛出什么问题？

在 sprint 开始制定开发细节之前，我们应该花费多少时间？

更新：我们现在取得了更大的成功和更顺畅的旅程。这主要是因为我们在估计时采取了更加悲观的观点，这给了我们更多的喘息空间来处理没有按计划进行的事情。你可以说它让我们更加“敏捷”。我们还试图改变燃尽图是某种时间表而不是范围v资源指示的看法。

我们刚刚开始一个包含许多子项目的非常大的项目。我们目前不使用任何类型的命名流程，但我希望通过后门获得某种敏捷/类似 scrum 的流程。

我将最关注的领域是整个项目的积压工作，至少在我的脑海中，迭代的想法是从积压工作中提取一些东西，更详细地研究并开发到合理的截止日期.

我想知道人们使用什么技术将项目分解为待办事项，以及一旦创建了待办事项，它是如何维护和排序的。以及如何维护元素之间的关系（即必须在可以这样做之前完成，或者这是一个故事现在是五个故事）

我不确定我期望这个问题的答案是什么样的。我认为最有帮助的是，如果有一个开源项目以某种方式保持其积压在线，以便我可以看到其他人是如何做到的。

其他可以从我那里得到+1的东西是来自真实项目的真实用户故事的例子（“用户可以登录”的故事并不能帮助我描绘我的项目中的事物。

谢谢。

大多数 Scrum 团队都有某种白板或其他白板，可以在上面可视化当前 sprint 的故事/任务。

我很好奇人们是如何组织这个董事会的？你使用便利贴吗？它们是彩色编码的吗？你如何对任务进行分组？你如何区分任务的状态？ETC...

我们有 MS Sharepoint——这对于管理任务列表来说还不错。数据是公开的，人们会收到更改和分配的通知。

我认为 Bugzilla 对于管理和报告目的可能会更容易一些。虽然有一些不错的开源 Scrum 管理工具，但我已经用光了很多政治资本，不能要求比我们现在拥有的更多的东西了。金钱不是目标——显然——这是我的团队拥有太多专业工具的想法。

Bugzilla 是否会成为一个更通用的项目管理工具——在错误修复用例之外？

我会非常失望并希望我下载其他东西并为更好的项目管理工具辩护吗？

We attempt to do agile development at my current job and we succeed for the most part. The main problem seems to be that the developers on the project are always waiting for requirements at the beginning of the sprint and rushing to get get things down by the end. The business analysts who are delivering the requirements are always working non-stop to get the requirements done.

EDIT: Additional Information: We are customizing a COTS application for our internal use. Our 'user stories' just consist of what part of the application we will be customizing in the specific sprint and also what systems we will integrate with internally. The integration with different systems normally works pretty well because we can start working on that right away. The 'customize x screen' are the main problems areas because the developers can't do anything from that. We have to wait until we get the requirements from the BAs before we can really do anything.

EDIT: More insight/confusion perhaps: I wonder if part of the problem is that the screen that are being customized are already there as this is a COTS product that is being heavily customized. People suggest that the user stories should be along the lines of 'make a screen that does X'. That's already done. Maybe there isn't a good way to do user stories for these requirements... maybe this need to be a whole new question.