不完整的开发团队

sprint确实应该一个接一个地立即发生，但是Scrum团队的人员配备也应该允许增量交付到达成一致的“完成定义”。如果这不是现实，那么团队就不能开始Sprint，他们有责任向涉众明确说明这一点。

谢谢你伊恩。这是有道理的，我认为这就是我们要做的。

这引发了一个有趣的问题:如果没有意义，谁应该最终决定是否开始Sprint ?

对我来说，这似乎最有可能是PO，因为他代表利益相关者，负责价值最大化。
不过最好能确定一下。

没有三个Scrum角色(开发团队、产品负责人和Scrum管理员)的同意，Sprint就不能开始。如果他们中的任何一个人不愿意参与，那么进行Scrum Sprint将是不可行的。所以从某种意义上说，这三个国家都有“最终决定权”。

在我看来，你的团队可以提高知识的传播，这是一个常见的场景，当一个人巩固了知识，而团队的其他成员无法继续。我会鼓励知识共享，这样在未来任何人都可以做一份没有依赖性的工作。

我同意鼓励重叠是很重要的，这也是我们一直在努力改进的。
然而，我们正在进行的项目需要各种各样的专业。这里的开发人员是T型的，我们有重叠，但是有些领域太专业了，这样工作并不总是有效的。

你的观点是正确的，我相信这种情况经常发生。谢谢你的建议。

我建议你读一读Joy, Inc.，看看他们的编程技术是如何发挥作用的。他们和你刚才说的形成了鲜明的对比，卡尔。

先以开放的心态阅读它!看看他们的网站http://www.menloinnovations.com/our-method/

嗨，蒂姆，谢谢你的推荐，但你能详细说明吗?我不太明白你的意思。

你好卡尔,
我同意关于在你的团队中传播知识的答案。
回答你的问题“我是否在Scrum指南中遗漏了一些解释这个问题的内容?”：

Sprint计划:“这次会议的输入是产品Backlog，最新的产品增量，开发团队在Sprint期间的预计能力，以及开发团队过去的表现。从Sprint的产品待办事项列表中选择的项目数量完全由开发团队决定。只有开发团队才能评估在即将到来的Sprint中能够完成什么。”

团队考虑到容量了吗?如果是这样，他们可能会交付一个增量。

我也同意在团队中传播知识的重要性。但是我们应该期望任何团队成员执行交付增量所需的任何任务吗?例如，图形设计师应该从事后端工作吗?反之亦然?在我看来，这是不现实的期望。

在接下来的文章中，我相信你已经很好地展示了这个问题在Scrum指南中的处理方式。所以，是的，我们评估了团队目前交付增量的能力，我们发现我们没有这个能力，所以Sprint没有开始。

所以你评估的是目前的产能而不是预计的?还是实际容量与计划不同?我们应该期待这个团队能够完成任务。如果有些任务只有一个人(例如平面设计师)可以完成，这就代表着风险(即稀缺技能)，就像你现在看到的那样。跨职能并不意味着每个人都可以做任何事情，但团队不应该依赖于一个人。如果一个人生病了，但仍然交付了一些东西，他们应该重新组织，也许是与产品负责人协商的权衡。

我的观点是，如果任务A需要完成，但通常负责这类任务的人去度假了3周，那么其他人应该接手这项任务，学习如何完成它，即使它需要稍长的时间。

一旦你读过Joy,inc和他们的开发哲学，你就会明白这个答案的真正详细版本。他们可能在开发方面有专长，但他们了解交付价值增量所需的内容。

如果客户X说他们需要Java工作，但只有。net人员可用，那么这些。net人员就会有效地边走边自学Java——这最终证明是非常实用的——因为现在他们有了既懂Java又懂。net的人。这是一个简短的例子。这是一项长期投资，从长远来看对每个人都有好处。

啊，是的，我应该说的是计划，而不是目前。

谢谢你，路德维希。我觉得你以冷静和务实的方式处理了这个困难的局面。如果这种情况再次发生，我将尝试这种方法。