敏捷新人的两个常见问题包括“敏捷团队中的角色是什么？” 和“你如何组织敏捷团队？”
本文的目的是通过研究如何为一个相对较小的敏捷团队（可能是15人或更少人）以及一个 大型敏捷团队（可能是50人或更多人）来解决这些问题 。对于介于这些规模之间的团队，您需要在两者之间的某个位置定制解决方案。
本文中描述的角色和组织结构具有代表性 - 您的方法可能略有不同，因为您处于不同的情况。但是，如果您认为您的方法需要有显着差异，那么您可能还没有完全放弃 传统IT角色背后的思考，并且可能会使您的敏捷采用处于风险之中。此外，本文不涉及 企业级角色。
敏捷的团队组织方法与传统方法之间存在几个关键差异。
- 敏捷团队是“整个团队”。整个团队是一项 极限编程（XP）实践，建议您在团队内部拥有足够的技能来完成工作。这意味着开发团队拥有必要的 测试 技能，数据库技能， 用户界面技能等等，并且不依赖于外部专家或专家团队来完成这些事情。
- 敏捷团队（大多数）是由广义专家组成的。一个 摹eneralizing专家，有时被称为工匠，是指具有一个或多个技术专长（例如Java编程，项目管理，数据库管理......）的人，这样他们可以为团队贡献一些直接的价值，至少具有一般知识软件开发及其工作的业务领域，最重要的是积极寻求在现有专业以及其他领域（包括技术领域和领域领域）获得新技能。显然，新手IT专业人员和经常专注于一个领域的传统IT专业人员需要努力实现这一目标。推广专家是专家的两个极端，对狭隘领域了解很多的人，以及对广泛主题有一点了解的通才的最佳点。
- 敏捷团队稳定。敏捷专家了解改变团队结构 - 这次迭代Sally是团队的一部分，但是下一次迭代她是为了帮助另一个团队 - 对项目的成功是不利的。我们努力使我们的团队尽可能保持稳定，如果人们推广专家，这个目标更容易实现。
小敏捷团队
有几个角色，根据所遵循的方法有不同的名称，敏捷团队通用。角色不是职位，任何给定的人担任一个或多个角色并且可以随着时间的推移切换角色，并且任何给定的角色在项目的任何给定点都可以有零个或多个人。常见的敏捷角色是：
- 团队领导。这个角色在 Scrum中称为“Scrum Master”， 或者是其他方法的团队教练或项目负责人，负责为团队提供便利，为团队获取资源并保护团队免受问题的影响。这个角色包括项目管理的软技能，但不包括技术，如计划和日程安排，最好留给整个团队的活动（稍后将详细介绍）。
- 团队成员。此角色（有时称为开发人员或程序员）负责创建和交付系统。这包括建模，编程，测试和发布活动，以及其他活动。
- 产品所有者。该 产品负责人，被称为现场客户在XP和 积极的利益攸关方在上午，代表的利益相关者。这是负责 优先工作项目列表（称为Scrum中的产品积压），及时做出决策以及提供信息的团队（或 大型项目的子团队）的 一个人。及时。
- 利益相关者。一个 利益相关者是人谁是直接用户，间接用户，用户的经理，高级经理，业务人员，“金老板”谁的资金项目，支持（帮助台）工作人员，审计师，你的程序/投资组合经理，开发人员在其他系统上工作，这些系统与正在开发的系统或可能受软件项目开发和/或部署影响的维护专业人员集成或交互。
图1概述了一个小型敏捷团队的结构。您在敏捷文献中通常阅读的内容是，由团队负责人领导的开发团队如何与产品负责人密切合作， 逐步构建高质量的工作系统。您经常听不到的是我称之为“支持演员”：
- 技术专家。有时，团队需要技术专家的帮助，例如构建主人来设置他们的构建脚本或 敏捷的DBA来帮助设计和测试他们的数据库。技术专家是根据需要临时引入的，以帮助团队克服困难问题并将他们的技能转移给团队中的一个或多个开发人员。
- 领域专家。正如您在图2中所看到的，产品所有者代表了广泛的利益相关者，而不仅仅是最终用户，并且在实践中期望他们成为您域中每个细微差别的专家是不合理的。因此，产品所有者有时会聘请领域专家与团队合作，可能是税务专家解释需求的详细信息，或赞助执行人员解释项目的愿景。
- 独立测试员。有效的敏捷团队通常会有一个 独立的测试团队并行工作，以验证他们在整个生命周期中的工作。这是一个可选角色，通常仅在非常复杂的项目（或大规模）上采用。
图1。一个小型敏捷团队的组织结构。
图2。产品所有者代表一系列利益相关者。
大型敏捷团队
当敏捷团队的规模达到20左右或更多时，您会发现需要分而治之并采取“团队团队”方法。典型的策略是将您的大型团队组织成一个较小团队的集合，最有效的方法是围绕您的系统架构。每个子团队应负责一个或多个子系统，使他们能够作为一个小型敏捷团队，负责及时交付工作软件。梅尔文康威在20世纪60年代后期引入该策略之后，这种策略通常被称为康威定律，并且是几种 精益发展治理策略之一。
大规模敏捷团队的其他角色包括：
- 架构师。此人负责促进子团队的架构决策，并且是架构所有者团队的一部分，该团队负责项目的整体架构方向。架构所有者通过其子系统的初始 架构来引导他们的子团队 ，并将参与整个系统的初始架构设想（作为架构所有者团队的一部分，见下文）。建筑所有者与传统建筑师的不同之处在于，他们并不单独负责设定建筑方向，而是促进其创建和发展。
- 子团队。子团队通常负责一个或多个子系统，整个团队越大，通常构建的系统越大，越复杂。在这些情况下，整个团队可能需要一个或多个担任集成商角色的人员，他们负责从各个子系统构建整个系统。这些人经常与独立测试团队密切合作，如果有的话，他们希望在整个项目中定期进行系统集成测试。
正如图3所示，在大型敏捷团队需要协调的几个关键问题：
- 项目管理活动。在规模上，仅仅关注项目领导并允许自组织来解决项目管理的技术方面是不够的。这可能适用于各个子团队，但在整个项目/项目中， 项目管理的技术方面 ，如依赖管理，合同管理，资源跟踪，供应商管理变得至关重要。图3的项目管理团队，有时称为项目管理团队，由各个子团队的团队负责人组成。他们的目标是协调整个团队的管理方面。该团队每天可能会举行一次简短的协调会议，称为Scrum方法中的“Scrum scrum”，其中共享当前状态并确定问题。
- 技术/架构问题。架构所有权团队由子团队的架构所有者组成，负责 架构构想在项目开始时确定初始技术方向并为组织子团队提供基础。在项目的第一周左右（有时在更复杂的项目上有几周），他们的目标是识别子系统及其接口，这种策略称为“管理接缝”，减少子系统之间的耦合，从而减少子系统的数量。子团队要求的协调。一旦接口定义良好，各个子团队就可以专注于实现这些子系统的内部结构。在整个项目中，该团队将定期召开会议，分享想法并解决技术问题，尤其是那些围绕子系统接口变化的问题。他们可能选择每天见面，
- 要求/产品所有权问题。产品所有权团队由每个子团队的产品所有者组成，负责协调子团队中的需求工作。他们需要与他们所代表的更多利益相关者协商要求，并在子团队中适当地进行分配。他们还需要就子团队之间不可避免的争议进行谈判，以确定谁应该做什么以及要求实际意味着什么。他们还管理子团队之间的需求依赖关系，并努力减少子团队之间的重叠工作。
- 系统集成。系统集成对于任何规模的项目团队都很重要，但它通常对大型团队（通常解决复杂问题）至关重要。大型项目的复杂性通常需要向团队添加一个系统集成商或几个（有时称为构建主人）。系统集成发生在整个 敏捷生命周期中，而不仅仅是在传统项目的系统集成测试阶段的项目结束时。在第一次开发迭代中，称为统一过程中的“精化阶段”，一个重要的目标是子团队根据之前商定的接口规范创建其子系统的模拟。目标是对模拟系统进行完整的端到端构建，以确保子团队能够实现相同的技术愿景。毫无疑问，当你遇到在迭代0期间没有想过的技术问题时，你需要发现你需要进一步改进接口。在项目早期制作子系统的模型有几个优点。第一，现在，各个子团队可以在他们自己的工作上前进，而对其他子团队的依赖性很小。每个团队都将在整个项目中发展他们的子系统，用真实的工作代码替换模拟的代码部分。这些新版本可供其他子团队使用，而这些子团队又会选择何时将这些新版本集成到他们自己的环境中。根据我的经验，早些时候比以后好，但是你要等到你知道新版本是稳定的，这是拥有一个独立测试团队的优势之一，直到你将它集成到你自己的工作中。其次，您的独立测试团队现在可以根据自己的需要对整个构建进行测试。当然，起初他们只有系统的模型，但他们至少可以在此时开始为系统组织他们的测试框架。第三，您可以类似地组合您的集成框架，以支持整个系统的持续集成工作以及各个子团队的集成工作。第四，个别子团队在他们在自己的环境中测试后会推广他们的代码。在大型敏捷团队中，这些新的子系统构建通常由您的独立测试团队在其他子团队可用之前进行审查，这个过程应该快速且经常地完成。测试团队通常会进行完整的系统集成测试，由于时间考虑（集成测试通常需要很长时间才能运行）或由于资源限制（测试团队通常有一个更复杂的测试平台），子团队可能很难做到这一点。子团队可能会选择使用预先批准的子系统，风险取决于您组织的文化。
图3。大型敏捷团队的组织结构。
我想分享一些意见：
- 图3的一个有趣特征是图1的两个支持演员，敏捷DBA和用户体验专家已经成为子团队的成员。这些角色是一些子团队普遍需要的例子，包括一些专门从事特定活动的技术专家。通过组织架构周围的团队，一些子团队专注于整个系统的某些方面，因此包含一些“过于专业化”的人来解决子团队正在处理的子组件的特定方面是有意义的。
- 随着团队规模的扩大，开发人员的日常活动几乎没有差异。它们通过协调员的活动与大型团队的复杂性隔离开来，甚至可能不知道这种情况正在发生。
所有传统角色 去哪儿了？
正如您在图1和图3中看到的 许多传统工作角色，例如项目经理，业务分析师和设计师（仅举几例）。项目经理的领导活动由团队教练负责，许多技术技能由团队成员通过自我组织执行。 敏捷分析发生，但不是由专业 业务分析师执行， 而是由产品所有者（许多BA选择 过渡到产品所有者的角色）和开发人员协作。 敏捷设计 发生，但不是由专业设计师执行，而是由敏捷开发人员执行，他们可能或可能不是由架构所有者领导。
关键在于，虽然角色可能已经改变，但我对传统角色的活动仍在发生。这并不完全准确，真正发生的事情是，传统角色的人们所采取的活动所解决的目标现在正由敏捷角色的人们所采取的活动来解决。例如，正在探索需求背后的细节，但它们是由产品所有者和开发人员以敏捷方式完成的，而不是由业务分析师以传统方式完成的。这一开始可能令人不安，特别是如果它违背了您多年来接受的培训和教育，更重要的是违背了您根据传统经验建立的信念体系。转向敏捷需要一种范式转换，
閱讀更多 大漠森林789 的文章
