企业选择什么样的团队做试点比较合适呢？迈克·科恩提出了一个试点团队的选择模型，选择试点团队可以从以下几个维度考虑（如图3-4所示）。

图3-4试点团队选择模型

资料来源：《Scrum敏捷软件开发》（SucceedingwithAgile：SoftwareDevelopmentUsingScrum），2010年

1.项目规模

企业最好选择那些独立的，规模在5~9人的试点团队。第一个试点不要选择规模大的团队，比如几十人规模的团队不适合做团队级敏捷的试点。试点的目标虽然是探索敏捷在企业里如何落地，但是全公司的人都在关注试点团队实施敏捷的效果。因此对于第一个试点来说，企业应尽量避免选择团队之间交织依赖的项目，避开不必要的复杂性，增加试点成功的概率。需要多个团队协作的大型项目，则适合在企业开展产品级敏捷的时候做试点。

如果企业里没有小规模的项目，那么退而求其次，企业可以选择大项目中的一个小团队做试点。

2.业务人员的参与度

如果缺少具有业务决策权的人参与试点，那就只能在研发范围内开展敏捷，但是业务人员在价值流的最上游，没有他们的参与就无法开展真正的敏捷。如果你选择的是Scrum框架，那么具有产品决策权的人应该参与到Scrum流程中承担产品负责人的角色。

3.项目周期

很多企业的管理层期望敏捷开始试点后马上收到立竿见影的效果。但是，凡是经历过组织变革的人都知道，这是几乎不可能的事情。一种新思想、新方法被引入后，团队需要先学习和适应才能进入状态。凭我的经验来看，至少需要一个迭代的时间才有可能看到一个透明化、沟通协作高效、士气高昂的敏捷团队。如果要通过数据量化看结果，则需要4~6个迭代的时间，待团队的迭代速率稳定后，团队效率才可能会有所提升。

因此，项目的周期不能太短。有些公司的一些项目，团队人员不固定，每个迭代都是临时组队，交付完规划的产品特性后，人员解散，下个周期重新组建团队，这样就没有办法看到持续的效果。但是，项目的周期也不需要太长，因为那些长到1~2年的项目往往节奏慢，缺乏变革的紧迫感。

4.项目重要性

一些企业的管理层担心敏捷转型会影响项目的进度，因此喜欢选择那些内部产品，原因是内部产品的进度可松可紧，没有外部客户和市场的压力；或者倾向于选择那些不在公司主航道上的项目，原因是如果这些项目失败或延期，对公司的核心业务没有影响。但是，这样的项目即使试点成功，对公司的主航道项目人员也没有说服力，因为他们会觉得这些项目不重要。

因此，企业要选择那些在业务主航道上的项目做试点。但是，不要选择那些最关键的项目，比如对企业生死攸关的项目，或处于救火状态的项目，因为抛开敏捷转型因素不谈，一旦这些项目自身运作有了问题，大家就会认为“都是敏捷的错”。所以，企业要选择那些在主航道上重要程度为中等的项目。

除了图3-4的模型里提到的几个因素外，企业还需要从以下几个角度考虑。

1. 物理距离

企业要尽量选择团队能够在一起的项目，尽量不要选择那些团队分布在不同的地区甚至国家的项目，除非这些团队是企业的主流团队。

2.项目类型

维护类型的项目往往不能够引入太多的变化，比如，你无法用敏捷的方式实践新的想法从诞生到上线的整个过程。此外，一般来说，

维护类型的项目遗留代码的包袱比较重，在遗留代码上尝试敏捷工程实践尤为困难。因此，企业最好选择新产品开发的项目，而不是维护类型的项目。

3.优选项

如果企业有软件、硬件集成的项目，要先选择纯软件项目来做试点，试点见效后再考虑硬件项目。虽然有很多报道、案例证实敏捷完全可以应用在硬件项目中，我也做过硬件项目的敏捷辅导，但是相对来说，软件的本质决定了软件项目更加适合敏捷，也更容易让企业看到变化。

如果你找不到以上条件都满足的项目，那么要权衡利弊，结合企业自身情况选择最合适的项目。

企业选择什么样的团队做试点比较合适呢？迈克·科恩提出了一个试点团队的选择模型，选择试点团队可以从以下几个维度考虑（如图3-4所示）。

图3-4试点团队选择模型

资料来源：《Scrum敏捷软件开发》（SucceedingwithAgile：SoftwareDevelopmentUsingScrum），2010年

1.项目规模

企业最好选择那些独立的，规模在5~9人的试点团队。第一个试点不要选择规模大的团队，比如几十人规模的团队不适合做团队级敏捷的试点。试点的目标虽然是探索敏捷在企业里如何落地，但是全公司的人都在关注试点团队实施敏捷的效果。因此对于第一个试点来说，企业应尽量避免选择团队之间交织依赖的项目，避开不必要的复杂性，增加试点成功的概率。需要多个团队协作的大型项目，则适合在企业开展产品级敏捷的时候做试点。

如果企业里没有小规模的项目，那么退而求其次，企业可以选择大项目中的一个小团队做试点。

2.业务人员的参与度

如果缺少具有业务决策权的人参与试点，那就只能在研发范围内开展敏捷，但是业务人员在价值流的最上游，没有他们的参与就无法开展真正的敏捷。如果你选择的是Scrum框架，那么具有产品决策权的人应该参与到Scrum流程中承担产品负责人的角色。

3.项目周期

很多企业的管理层期望敏捷开始试点后马上收到立竿见影的效果。但是，凡是经历过组织变革的人都知道，这是几乎不可能的事情。一种新思想、新方法被引入后，团队需要先学习和适应才能进入状态。凭我的经验来看，至少需要一个迭代的时间才有可能看到一个透明化、沟通协作高效、士气高昂的敏捷团队。如果要通过数据量化看结果，则需要4~6个迭代的时间，待团队的迭代速率稳定后，团队效率才可能会有所提升。

因此，项目的周期不能太短。有些公司的一些项目，团队人员不固定，每个迭代都是临时组队，交付完规划的产品特性后，人员解散，下个周期重新组建团队，这样就没有办法看到持续的效果。但是，项目的周期也不需要太长，因为那些长到1~2年的项目往往节奏慢，缺乏变革的紧迫感。

4.项目重要性

一些企业的管理层担心敏捷转型会影响项目的进度，因此喜欢选择那些内部产品，原因是内部产品的进度可松可紧，没有外部客户和市场的压力；或者倾向于选择那些不在公司主航道上的项目，原因是如果这些项目失败或延期，对公司的核心业务没有影响。但是，这样的项目即使试点成功，对公司的主航道项目人员也没有说服力，因为他们会觉得这些项目不重要。

因此，企业要选择那些在业务主航道上的项目做试点。但是，不要选择那些最关键的项目，比如对企业生死攸关的项目，或处于救火状态的项目，因为抛开敏捷转型因素不谈，一旦这些项目自身运作有了问题，大家就会认为“都是敏捷的错”。所以，企业要选择那些在主航道上重要程度为中等的项目。

除了图3-4的模型里提到的几个因素外，企业还需要从以下几个角度考虑。

1. 物理距离

企业要尽量选择团队能够在一起的项目，尽量不要选择那些团队分布在不同的地区甚至国家的项目，除非这些团队是企业的主流团队。

2.项目类型

维护类型的项目往往不能够引入太多的变化，比如，你无法用敏捷的方式实践新的想法从诞生到上线的整个过程。此外，一般来说，

维护类型的项目遗留代码的包袱比较重，在遗留代码上尝试敏捷工程实践尤为困难。因此，企业最好选择新产品开发的项目，而不是维护类型的项目。

3.优选项

如果企业有软件、硬件集成的项目，要先选择纯软件项目来做试点，试点见效后再考虑硬件项目。虽然有很多报道、案例证实敏捷完全可以应用在硬件项目中，我也做过硬件项目的敏捷辅导，但是相对来说，软件的本质决定了软件项目更加适合敏捷，也更容易让企业看到变化。

如果你找不到以上条件都满足的项目，那么要权衡利弊，结合企业自身情况选择最合适的项目。