功能团队或组件团队？
好的......为了这篇文章，我们将抛开我们对敏捷产品所有者的讨论。
现在，我们需要讨论一些扩展敏捷项目的基本模式。为了讨论如何扩大规模，我们需要讨论如何组织。我们会在一两个帖子里把它们都聚在一起。
敏捷软件开发都是关于小组的。所以......理想的敏捷团队大小是什么？据我所知，没有艰难的规则，但大多数人我与在六到八个人之间的某个地方谈话。较小的是......更大，不是那么好。六到八个人可以真正互相沟通的限制。
那么，当你有一个需要超过6到8个人的项目时，会发生什么?你把一个大团队分成几个小团队。很有道理,对吧?
对我来说，这是敏捷开始变得非常有趣的地方。当您有一个以上的团队在单个项目上工作时，甚至可以单个代码库，拆分团队的最佳模式是什么？有两个小学的思想。
组织各地特色
传统上教授......几乎普遍接受的......组织方法敏捷团队是组织周围特征。有关特色团队的一个非常彻底的解释，请通过Craig Larman和Bas Vodde找到“缩放精益和敏捷开发”的书籍。根据Larman和Vodde的说法，一个功能团队是一个“长期跨职能的团队，一个逐个完成了许多端到端的客户功能”。
Highsmith状态在“敏捷项目管理”中......
我在这里欺骗了一点，抓住了来自马兰和伏迪德书的高稳定报价。我认为这没关系，因为我也读了高稳定的书;-)
Larman和Vodde将理想的功能团队概括为跨职能、跨组件和同处一地。他们致力于完整的用户功能，团队由一般化专家组成，通常有6到8个人。换句话说，就是我们的原型Scrum团队。
作者还指出了功能团队方法的几个挑战......我真的很感激。常见的障碍包括......同时访问代码，对设计的共同责任，难以学习技能和组织结构。他们的断言是，现代化的工具可以克服这些挑战......但它可能需要数年。
我必须承认......这显然是最简单的......以及组织敏捷团队的最有效的方式......但它对您的团队和工程实践构成了一些假设。与所有假设一样，这些都需要验证。为了完全治疗特征团队概念，找书......这是一个很好的阅读。
整理架构
在Leffingwell的书“缩放软件敏捷性”的书中可以找到更具争议的戏剧团队的方法。
Leffingwell引入了设计/构建/测试组件团队的理念。组件团队与特性团队共享许多相同的属性，因为组件团队很小，并且包含交付用户故事所需的所有技能集。Leffingwell的组成团队是授权、自组织和自我管理的。简而言之，他们是典型的Scrum团队。但是，这是一个很大的但是，他们正在开发组件特性，而不是终端用户特性。
这实际上是与马兰和vodde推荐的完全相反。一个特征团队将由来自每个组件团队的专业集团组成。这些专业总体将具有集体责任，即提供以客户为中心的功能结束。与组件团队没有完全相同的，呵呵？我告诉过你这会变得有趣。
Leffingwell的想法是……在某种程度上……在某些项目中(让你的想象力自由发挥吧)……系统会变得足够大，以至于单个Scrum团队无法包含足够多的专才来覆盖单个功能。在某些系统中，不是所有系统，但在某些系统中，我们处理的是系统中的系统。一些组织，一些产品，需要系统的系统。
为了公平起见，也去读读Leffingwell的书吧，这本书也不错。
这是一个艰难的电话
所以......我们的第一个非常重要的决定是弄清楚功能团队方法是否会在我们的环境中工作，或者我们需要使用组件团队模型。个人......我倾向于从特征团队方法开始，如果我必须......但是决定是非常具体的。
To make this decision you’ll have to explore the diversity of your technology… how well your system is designed… what tools you have to manage your code base… the size and competence of your team… how much work the organization is running concurrently… and the quality of your automation.
您需要真实地了解组织中的政治和电源结构。您需要看看有多良好，以及如何赋予授权，所有的跨职能功能团队都可以运行。你需要努力看看你的功能团队将分解的范围是什么意思......在某种程度上，他们会分解。缩放到这个级别，我们现在需要地址或它可以等待吗？
下一篇文章我们将探讨敏捷对你意味着什么。我们将考虑您想要或需要多敏捷。在我们决定如何扩大规模之前，有几个关键问题是你必须要问和回答的。在那之后我们将计划把它全部拉在一起
评论(9)
德里克贝利
你能否明确地描述(或链接到你现有的描述)“组件”和“功能”，以确保我理解你的观点?
当你开始谈论规模时，我知道你所说的组件和功能是什么意思，但我想确保自己在深入思考这个问题之前有一个清晰的理解。
谢谢。
Mike Cottmeyer
当您认为功能......思考用户故事。您可能会扩展到用户故事（史诗？）或一个要素组的集合。组织团队可提供一系列最终用户功能。
当你想到组件时，想想大块架构。企业架构。
当我将此描述给我通常绘制具有重要大型机处理引擎的系统时...一个Web服务产品......一个非常大的数据仓库......和业务对象层......和演示层。亚博vip9通道您也可能包含您呼叫的第三方服务......也许甚至会随着提供产品提供的一部分而变化。
如果以前没有在这个大型环境中工作过的，他们通常认为我的意思是介绍人...... API GUY ...和数据库家伙。在那种环境中，再次出现特定于......我会开始寻找是为了讨论架构的人。
有道理？这是我能得到的明确;-)
德里克贝利
是啊，说得通，我以为你指的就是这个。谢谢你的澄清!
杰里米克里格尔
在我的上一家初创公司，我们围绕功能进行组织，但是在史诗级的水平上。两个团队一般支持主要的社区应用程序，另一个团队支持该应用程序的主要部分，第三个团队支持客户端应用程序。总的来说，它运行得很好。
对我来说，有趣的是，这两个具有重叠支持的团队实际上共享了一个待办事项列表。我一直在想，如果有多个团队从相同的待办事项列表中被驱动，能够转移到具有最高优先级的工作，那会是什么样子。这是适应性的还是混乱的?
Mike Cottmeyer
这是Dean Leffingwell的注释。他发布了关于Blog.versionone.com的评论。
嗨迈克，
嗯添加一点颜色：
1）公平进入，我的书我使用了“组件团队”隐喻，但我也指出，敏捷团队可以在功能，组件或服务周围组织。
2)如果你是接近企业的规模,例如500从业人员,他们已经组织(最有可能成组件或子系统团队),试图重组成集中的特性团队或任何其他你喜欢敏捷思维模式可能会杀死主动或者至少延迟结果。谁愿意发布这样的备忘录:“你们中的150个人和你们的家人将搬到新的敏捷特性团队中生活?”
3）我正在使用它需要数百个开发人员的项目，以向市场提供单一的增值功能。您如何使用7 + -2敏捷团队构建协调？
张贴:Dean Leffingwell |星期三，2009年3月11日下午07:24
以下是我的回复....
谢谢你的迪恩！我很感激你回复我的帖子。
1.）不是试图表征整个观点。你有400页，我拿了两个段落;-)你拥有我所阅读的组件团队的最佳关节，所以我想让人们知道你的书出来......并且组件团队是一个有效的模型。我的大多数Agilists我用完全忽视了组件模型作为有效的敏捷方法。
2.）我不能说我已经跑到500的任何东西，但我已经完成了一个有100多人的重要项目。我们使用了您的功能团队方法（实际上是在我读完书时做到了），我认为在您谈论的范围内，鉴于现有组织的结构，方法是必不可少的。
3.）现在有一天......我主要与子100系列的团队一起工作。当他们不需要时，他们通常希望通过组件方法进行。我寻找任何理由让一个基于功能的团队在一起。采取组件方法有许多有效的原因......这不是我通常带来的。
下一篇文章我将在您提到的服务模型上花费一点时间，并使用每天敏捷语言的一些简单的缩放方法。
感谢您阅读VersionOne的博客。我很感激你花时间给我留了便条。
丹尼斯·史蒂文斯
麦克风，
好贴。讨论业务组织，技术和开发和支持团队之间的对齐真的很有趣且越来越重要。亚博vip9通道我一直在使用的方法涉及业务能力的概念。亚博vip9通道
业务亚博vip9通道能力是“该业务为其客户创造价值的”什么“。您可以在2008年6月哈佛商业审查文章中详细介绍此详细信息“生产力下一步革命”。亚博vip9通道Microsoft的Ric Merrifield有一本书在可能叫做“Rethink”的书，谈论了解业务的“什么”。亚博vip9通道
在大规模的敏捷实现中，将有围绕能力组织的团队。将在业务基础架构功能周围定义一个或多个团队。亚博vip9通道这些将提供管道，安全服务等。然后将有客户面临团队和业务面临的团队。亚博vip9通道团队的业亚博vip9通道务正在支持会计，销售和营销，技术支持，客户服务等内部特征。客户面临的团队队伍正在为客户组成。
这种安排做了几件事。首先，它将在业务组织，技术和开发和支持团队之间存在不匹配时，它脱离了很多复杂性。亚博vip9通道其次，它创造了通过开发团队的流动。工作可以优先考虑客户价值。第三，概不是普遍存在的专家可以竞争地解决复杂技术环境的所有层。最后，重要的是，这种方法使我们能够利用我们在业务结果级别的能力迅速提供软件。亚博vip9通道
这种调整看起来很有挑战性。这不是企业重新工程播放。亚博vip9通道现实情况是，只需要发生大约20％的业务能力。亚博vip9通道这些是快速响应有助于在其战略上执行业务的功能。亚博vip9通道
我们正在真正学习如何快速和可预测地交付软件，这是一件很棒的事情。我们应该能够利用这种能力为我们的客户和业务创造新的价值。亚博vip9通道然而，如果没有业务模型、技术本身以及开发和支持团队的统一，我们在响应不断变化亚博vip9通道的客户需求、利用外部服务以及根据市场修改运营模型方面的机会就会受到限制。
丹尼斯
V. Lee Henson.
我必须承认我发现这篇文章最有趣！我最近与大型组织的历史较近越来越靠近Leffingwell理论。在我看来，大型组织发现在我看来更容易以组件团队的形式利用他们的主题专家，了解他们工作的项目是巨大的，并将继续增长。
作为一名经过认证的Scrum培训师，如果我没有提到那个小于中等大小的大多数组织，那么特征团队仍然最有意义。随着功能集的增长并且缩放变得更加困难，团队开始转换到更多的组件方法。
我看到真正的大型组织使用任何一种方法并成功。
我真的很感谢Mike Cottmeyer将这样的想法带到最前沿。它真的让我们成为一个更丰富的社区！
好的文章!
Mike Cottmeyer
谢谢你的评论李。
我同意从Feature team开始是正确的做法。当特性团队无法扩展时，我们需要有组件团队，或者服务团队(用Dennis Stevens的话说)。
杰夫安德森
我从未使用的最大敏捷团队有大约有30个资源，在特定程序中的多个项目并行工作。亚傅体育app
我的个人经历是，组织各种特征的团队对于确保特定职能/故事的责任至关重要。
据说，拥有核心“斯瓦特 - 组件”团队，可以将其他一些横切组件（例如DAL，WEB导航等）的核心“SWAT-Component”团队同样至关重要
这个斯瓦特队将花一半的时间将一些共同的可重复使用的作品放在一起，另一个半一半从团队转移到团队教学和整合......
此组件团队基本上将其他团队的发展导线视为其产品所有者，这意味着架构未授权授权，而是将作为供应商服务的送达组织的供应商服务
甚至更大的项目我可以想象多个“组件团队”扮演相同的角色......
希望这是有道理的
问候
杰夫
http://agileconsulting.blogspot.com.