基于团队的Scrum的基础机制

走进他们认为他们正在做斯克里姆的组织，这一切都太常见了，但没有看到他们的努力中的任何真正的利益。他们会认为他们正在做Scrum，因为每个人每天都在每天都有一次，每两周计划一次，有人称为产品所有者，另一个称为Scrummaster。他们知道仪式。他们知道角色。他们知道文物。但有些东西不起作用。

Scrum不为他们工作的原因是，它不是日常的站点，或角色，或使Scrum工作的伪影。It’s the shared understanding that comes from the backlog, the visibility that happens as a result of the artifacts, the accountability that comes from having complete cross-functional teams, and the ability to measure an increment of working tested backlog every couple of weeks so you know how you are progressing.

好的scrum团队拥有所有的伪影，角色和仪式......但是很多坏事。所以，让我们稍微打破一下，看看Scrum工作好，当Scrum变坏时，何时遇到什么样的差异。

积压

有很多方法可以成功创建产品积压。我看到产品所有者与团队创建积压，我也看到他们独奏。我已经看到团队根据实时客户反馈，每两周让积压每两周一次。我的小组专家团队创造了由滚动三个月，风险调整和估计的用户故事支持的令人欣慰的路线图。所有这些方法都在工作。

我亲自执教团队使用“作为用户，我想要一个功能，这样我就可以获得一些商业价值公式”。亚博vip9通道我还教授团队使用简短，高级别的需求描述，这已经足够了。我还与团队一起创建了这样的全面用户故事，他们开始看起来像正式用例，比用户故事。这一切都取决于团队了解所要求的内容所需的内容。

这真的是通过积压来到问题的核心。积压必须清晰地对团队来说，他们可以从Sprint Planning会议中出来，这是一个漂亮的Darn好主意构建软件所需的内容。这两个最常见的反模式是当故事太大而模糊的球队毫不含糊地，在被问到的是什么，紧随其后的是开发人员组成的技术任务。

没有分享理解我们要去哪里，Scrum团队将失败。

团队

团队有各种形状和大小。我看到由2名开发人员和测试人员组成的团队。我似乎似乎由5名开发人员和5个测试人员组成的团队。我也见过......但不推荐......由20名开发人员，5个测试人员和一些分析师组成的团队。有些团队让每个人都有必要提供工作测试的产品增量，有些团队从外面的人们依赖于外面，有些人必须与其他球队协调。

共同的指导是必须在特征或产品周围组织SCRUM团队，以便可以有用于交付用户故事的最终对问责制。在大型组织中，模式将突破，您必须考虑使用组件团队或能力团队，并在更复杂的交付框架中使用这些团队的输出......绝对不是Scrum所涵盖的东西。

真正重要的是......是，无论你分配的团队都有什么，他们都有什么作品，他们负责......球队拥有每隔几周建立工作测试增量所必需的一切必要。该团队基本上是一个问责制结构。如果团队没有必要提供他们积压的工作测试的一切......他们不能持有负责任，整件事将开始侵蚀。

产品增量

这可能是Scrum过程中最重要的部分。如果您正在研究一个不能在Sprint结束时无法生成产品的工作测试增量的团队......你真的没有做Scrum。也就是说，就像团队一样都有各种形状和大小......产品增量可以达到大量的形状和大小。并非每两周都每两周向最终用户提供某些东西。

有些团队负责将软件投入生产每次和每个Sprint ...有时更常见。有些团队无法快速发布，并且必须在季度释放结束时批量冲刺结果和船舶。一些团队......一些产品......甚至无法释放季度边界，并且必须批量批量批量释放额年份（思考税务软件和ERP系统）。

对产品增量的重要事项是您拥有可衡量的产品块，允许您明确衡量您实现目标的数量。增量不应该具有技术债务。它不应该有缺陷。它不应该等待团队以外的人在拥有价值之前完成他们的部分。您推迟到以后冲刺的任何东西都会在项目的背面创造隐藏的不确定工作。

总之

Scrum是一个简单的过程......但不是那么容易做得很好。您可以拥有产品所有者，Scrimmasters，每日站立会议，Sprint Planning，Sprint评论和Sprint回顾。您可以有积压和刻录图表，仍然不知道您要去的位置。

要做Scrum，你必须共享理解......你必须有一个被破坏到小块的积压，可以由团队理解，并满足比尔唤醒的投资标准。注意：当我开始谈论缩放后台时，请记住这一点......许多积压令的原因是因为它们不符合e标准。

要做好克拉姆，你必须有一个团队，你可以持有责任。该团队必须拥有产生工作测试增量的一切必要。如果他们没有，他们应该非常容易地访问他们需要时所需的人。如果这是不可能的，不可能致力于交付。

要做好克拉姆，你必须能够每隔几周实际生产经过工作的工作测试增量。不能做到这一点的球队不知道他们建造了什么，他们要快速度，或者在项目结束时堆积了多少工作。不能做到这一点的团队，无法获得反馈，以确保它们在正确的轨道上的建筑物。

我建议，如果你有共同的理解，完整的团队，以及每隔几周的时间创建工作测试的经过工作的能力......你可能正在做好。如果你有那个和scrum的所有角色，仪式和文物......你可能是一个非常纪律的scrum团队。

如果您没有共享的理解，完整的团队，以及每隔几周创建工作测试的能力的能力...那就是问题，这就是你必须去的问题。

查看上一篇文章，敏捷转型基础。