如果希望同时导入m中的所有成员_如何从 0 到 1 导入敏捷？

我们将站在完全实践的角度，学习如何从 0 到 1 导入敏捷。
01转型管理驱动因素
通常公司都是因为某种动机而选择导入敏捷，我们管这种动机叫 转型管理驱动因素 。根据我多年的项目管理经验，转型的动机主要有两种。

第一种是 与加速交付相关 的转型。企业往往都是从百人以下的小团队开始发展，随着成长人数会越来越多，曾经的工作方式愈发不合适，组织效率就会越来越低，尤其是人数过千以后，管理者意识到要提高交付效率，加速交付过程，而敏捷可以帮助企业达成此目标，所以他们就想导入敏捷。这种状况多发生在互联网行业或传统软件行业，他们一般会以业绩成果来度量敏捷导入的产出。
第二种是 与敏捷方法相关 的转型。敏捷在中国已经推广了十几年，已经有很多公司导入了敏捷并取得不错的效果，比如腾讯公司。这就引起了其他大型企业的关注，如果敏捷能够使公司发展得更好，那为什么我不试试呢？所以他们也想导入敏捷，而且通常以改变协作方式为切入口，因为他们希望敏捷能帮助自己的团队与其他部门、供应商之间更频繁地交流与协作。他们比较重视敏捷过程的度量，比如某些环节的效率是否提升，跟同行业佼佼者比较还有多大差距。这种状况多见于银行业中。
针对不同企业的动机，我们也应该有不同的转型方式。如果是与加速交付相关的转型，我们更需要重视敏捷导入产生的结果，比如敏捷导入之后，是否优化了价值的交付，收入是否比原来有所增加，用户数量是否有所增加，用户满 意 度是否增强。如果是与敏捷方法相关的转型，我们需要对企业的成熟度进行度量，给自己树立一个行业标杆，辅导团队做过程改进，努力达到或接近行业标杆的水平。
02敏捷转型的影响因素
了解了驱动转型的动机，我们需要对它们进行分析识别，将其中的因素分为积极因素和消极因素，根据它们我们可以把握敏捷导入的困难程度，主要通过考虑到以下这些方面。
首先来了解不利于转型敏捷的消极因素，主要涉及这些情况：
1.工作被分解为部门孤岛，从⽽创造出阻碍加速交付的依赖关系，而不是构建在能⼒中⼼指导下的跨职能团队，也就是说，部门墙越厚就越不利于敏捷转型；
2.短期交付型的项目不适合用敏捷。比如我们承接甲方的需求开发，甲方要求交付的产品特别明确，其间产生变更也会以补充合同进行说明，交付时间也会清楚地写进合同中， 因为这个项目不存在频繁的变化，所以并不需要敏捷；
3.团队优化的依据是部分效率而不是端到端的项目交付流或整体优化情况， 因为如果只想着提升研发效率，那么敏捷转型带来的效果是有限的，而敏捷可以带来的是全方位的优化，所以在导入的过程中，我们要着眼于全局；
4.员工属于特定领域人才，实现技能多元化的工具或激励有限，不重视培养T型专家⼈才。因为敏捷是跨职能团队，每个人除了自己的领域之外，最好还有其他领域的专业知识，比如开发工程师具备产品思维。敏捷鼓励 T 型专家人才，即 在某一领域具有专长，同时又能在其他多个领域有一定的经验和见解的人 。如果团队只是强调培养特定领域人才，这就只是在培养螺丝钉， 并不能为跨职能团队带来很多收益；
5.分散化项目组合即使员工同时分配到过多的项目，而无法专注于单个项目。敏捷宣言提到“可工作的软件胜于面面俱到的文档”，说明敏捷团队提倡简化文档。正是因为这点，所以我们要使团队保持稳定，主要就是团队成员相对固定，如果员工分配到过多的项目，就会打破这种稳定的团队结构，敏捷转型也就很难获得成功。
1.其次，我们来看能够推动敏捷转型的积极因素，主要涉及这些方面：
2.管理层具有强烈的转型意愿。任何转型都是自上而下的，敏捷转型也不例外，管理层的转型意愿越强，企业的敏捷转型也越容易获得成功；
3.员工的认知和改变意愿。如果员工在认知上认可敏捷，认为 敏捷转型能解决自己目前的问题，且愿意在工作方式上作出改变。比如开始组建跨职能团队、开展晨会和回顾会，认知和改变的意愿越强，也就越容易获得成功；
4.组建跨职能团队。如果领导愿意把原来的组织结构调整为跨职能团队，为敏捷提供天然的适合生长的土壤，那么团队更容易转型成功。比如腾讯，就是按照跨职能组织的典型，产品、开发、测试和运营以项目为单位组织，大家共同背负业绩 KPI，树立共同的目标。除此之外，员工的涨薪并不直接由自己的职能领导给出评价，而是由通道委员会决定员工的职级 ，HR 再根据职级进行调薪。这样的团队只为达成产品目标服务，非常敏捷；
5.专注于短期目标而不是⻓期目标。敏捷团队需要不断试错以获得短期利益，所以敏捷团队更关注短期目标的达成，如果团队属于这种特性，那么更适合敏捷转型；
⼈才管理成熟度和能力。敏捷对于团队的要求是比较高的，一是由于敏捷鼓励自组织型团队，所以团队得有自我管理的能力，这就对团队成员要求较高；二是敏捷需要团队有很强的自动化能力，例如自动化测试、自动化构建和自动化部署。团队自我管理能力越强，团队的自动化能力越强，敏捷转型也越容易获得成功。
如果团队的积极因素大于消极因素，那么敏捷转型的成功率越高，反之则成功率越低，所以我们 在 转型前应该尽可能地先识别这些因素，为了推动敏捷导入，我们可以按照上述的关注点，避免消极因素，发展积极因素。

通过上述的评估，我们可以确定当下是否可以进行敏捷转型，那么接下来我们就该正式导入敏捷了。在之前的课时也曾提到过，敏捷不是一蹴而就的，我们会选择试点项目切入。
03试点项目的选择
怎样选择试点项目呢？我们可以以下几个方面来考虑。
首先是 项目的重要性 。我之前接触的一些团队中，大部分一开始都倾向于选择不太重要，且风险比较低的项目作为试点项目，这是因为如果进展不好，也没有多少损失，人们可能甚至都不会注意到这种低重要性项目上的失败。也有一些团队会选最关键的项目开始转型，他们认为重要的项目可以得到公司和其他人的关注。
其实这两种项目都不适合作为试点项目，前者效果不为人知，但是后者存在巨大的风险。刚开始转型敏捷时，因为改变了原有的工作习惯，所以短期内工作效率会降低。如果备受关注的项目出现这种情况，就会对转型团队的士气造成较大的影响，甚至会影响后期敏捷的推广。所以，我建议选择次重要的项目进行转型，这样带来的影响是比较好的，而且比较可控。
其次是 项目的周期 。如果我们选择的项目持续时间太短，那些怀疑 Scrum 的人会认为 Scrum 只适用于短小的项目；但是如果该项目的持续时间太长，我们又面临直到项目结束才能宣告成功的风险。所以，我的经验是，最好选择持续 时间为企业内项目通常 的 持续时间一半左右的项目 ，这个周期大概为三四个月。这可以给团队足够的时间在 Sprint 中很好地工作，体会到 Scrum 带来的好处。而且这个项目周期能够充分证明 Scrum 可以在更长周期的项目中获得类似的成功。
还要考虑 项目的规模 。我建议选择只有一个团队的项目作为开始，并且要让团队成员都坐在一起，即便未来该试点项目会扩大到多个团队，我们也要从一个团队开始，这是因为：
1.可以节省多个团队间的沟通的成本；
2.第一个试点团队需要敏捷教练集中精力去处 理 的问题非常多；
3.一个团队的结果比较容易量化，便于最后转型效果的展示。
我们还要考虑 业务方或客户的支持和参与 。敏捷转型不仅仅是产研团队的事，业务团队或客户也需要一起改变。如果我们拥有来自业务方与团队一起工作的人是很关键的，并且时间和意愿上比较配合。尤其在团队需要推动改变那些不易改变的业务流程时，业务负责人的积极投入和支持是非常必要的。
同样，在得到了预期的结果以后，也没有人比这个角色更适合宣扬成功。比如他会跟其他人谈论“最近尝试敏捷转型的某项目比过去项目交付的更多一些”，这样效果更好，这也可能促使其他的业务负责人要求他们的团队尝试敏捷。
试点项目的成功还取决于项目团队的能力和意愿。我们组建最初的团队时需要关注大家的融合度，成员间建设性的辩论，学习和适应方面的主观意愿与能力，技术能力以及沟通能力等。在选择试点项目团队时，其中最需要考虑的是个人尝试用新事物解决现有问题的主观意愿。当然最理想的情况是，所有人都有意识和渴望转型敏捷。
对上述几个方面进行综合考量，我们就可以确定转型的试点项目了，之后就需要用三四个月的时间在试点团队中进行敏捷转型。在转型的过程中，我们需要培养人员输出文档，为后续全公司敏捷转型做准备，所以我们需要培养至少一位 Scrum Master，这个角色需要具备专业的敏捷教练能力，并可以结合公司实际情况落地适合的敏捷实践。另外，还需要输出“某某公司 Scrum Master 指导手册”，以便于指导公司的 Scrum Master 进行敏捷转型

最后，我们还需要有人定期对敏捷实践和产出的效果进行宣传，如果公司有 PMO （ Project Management Office ）团队，这个职责会落到他们身上；如果有 HRBP（ HR Business Partner ），那么他就有义务去做这件事情。如果我们都没有以上两种角色，那么就要从试点团队中选出至少一人来负责这件事情，只有不断让他人知道敏捷给团队带来的切实好处，才会激发公司其他团队的转型意愿。
04总结