敏捷团队中的一体式流程
遵循上一篇文章中介绍的为什么需要小型团队敏捷的概念，本文将着眼于为什么这些团队应该跨职能 。
不同的团队使用不同的术语来解释角色。 例如，如果团队不使用Scrum，则Scrum Master通常称为敏捷教练。 一样，只是它不仅限于使用Scrum，还包括精益和看板等方法。 为简单起见，我将参考Scrum和《 Scrum指南》中定义的角色来解释我的意思。
简而言之，产品交付
在《 Scrum指南》中，Scrum团队定义为产品所有者，开发团队和Scrum主管的组合角色。 从本质上讲，这意味着这些人拥有将想法（输入）转换为可通过开发过程对客户（输出）有价值的工作软件所需的一切，如下图所示。
那就是开发的过程，无论您是否敏捷。 开发的目的是接受一个想法并以此为基础，使客户愿意为之付出代价。
但是，我们还需要了解敏捷性的目的，以及这如何改变黑盒子内部发生的齿轮和齿轮背后的思维方式。
敏捷就是快速交付价值并响应变化（在本文中，我只关注快速）。 这是关于提高效率和生产力。 您可以更快地将创意转化为已售出的产品或服务，您的利润就更高。
因此，提高利润率需要提出的问题是：“我们如何提高向客户交付价值的速度？”
Scrum之所以如此出色的原因之一是因为内置的精益原则。 因此，为了找到这个问题的可能答案，让我们看一下精益制造中使用的“单件流程”的概念。
单件流程
One Piece Flow旨在从头到尾一次高效地生产一种产品。 在敏捷中，这意味着从头到尾以最少的浪费提供了一个完整的功能或用户故事。 One Piece Flow本质上与拥有跨职能团队相同，这就是它起作用的原因。
在典型的组织中，或在敏捷过渡开始时，组织结构可能类似于下图中的过程一。
产品负责人负责管理产品积压订单，设计师团队从中选择最重要的故事并进行设计。 一旦设计完成，就被认为是“准备就绪”的开发，这是由一个单独的团队进行的，根据复杂性，有时可能需要一个以上的团队。 一旦“完成”开发，就将其移交给测试团队，一旦他们验证了软件，就可以将其交付给客户，也就是“完成”。
Scrum和敏捷的另一个原则是限制分心，因此每个团队都有单独的计划和冲刺积压。 一个团队完成的故事并不能保证该故事会立即被价值链中的下一个团队选择。
但是，如以上流程二所示，跨职能团队在不同团队之间没有任何交接，因为所有所需的技能（如各种颜色所描绘）都在同一团队中。 他们不需要单独的“完成的定义”和“完成的定义”。 也无需等待完整的故事被添加到价值链中下一个团队的sprint待办事项列表中。
可以将顶行或过程一与批量生产进行比较，并将上图中的底线或过程二与单件生产进行比较。
在下面来自Gemba学院的Ron Pereira的视频中，他说明了为什么单件流比批量生产更有效。 这也是Scrum建议建立跨职能团队的原因。
在一个没有全部能力和技能来完成工作的团队中，您不仅在增加产品生产时间，而且在增加等待时间，从而减少了周期时间，从而减少了向企业交付产品的能力。客户，或接收反馈。
结论
拥有跨职能团队的目的是提高效率，从而减少周期时间。 这不是提高效率的唯一方法，但它有可能从根本上减少等待时间，同时增加团队内部的信任和沟通。
反馈，问题或意见？ 请给我发 邮件 或发表评论 让我知道 。
