全球经济已经进入数字化和VUCA时代，充满变化和不确定性，敏捷方法—Scrum以其能够快速响应市场变化，提升研发效率等特点逐渐成为主流研发管理模式，越来越多的传统企业认识到改革的必要性，并开始准备引入敏捷的概念用于软件开发团队的管理。

但是转型就意味着一场变革，变革就意味着阵痛，转型过程中肯定会遇到一定的阻力和问题。那么敏捷转型是否需要先决条件呢？当在这些条件不能满足时，是否就不能完成敏捷转型呢？如果敏捷转型如何获取外部支持？本文将对敏捷转型常见的担忧和疑虑进行分析和解答。

1. 敏捷转型是否需要先决条件？

有些传统企业，在决定进行敏捷转型之前，通常会存在这样的疑虑，敏捷转型是否需要先决条件？也就是我们常说的敏捷基因，答案是肯定的，下面总结敏捷转型的6个关键因素帮助您的转型有个正确的开始。

• Scrum团队

敏捷开发有着清晰的管理逻辑和规范，它需要建立在Scrum团队之上，团队成员需充分理解和认可敏捷开发，并能在工作中实际落实敏捷开发理念。Scrum团队具有以下几个特点：

• 团队规模小：5~9人，小于5人生产力下降，多于9人则增加协调和沟通成本。

• 跨职能团队：完全具备交付产品增量的各项技能。

• 自组织团队：团队被授权自己管理自己的工作过程和进度，并自己决定如何完成工作。

• 全职工作：保证项目成员专注于单个项目。

• 集中办公：便于面对面交流，消灭信息孤岛，信息通畅。

• 一个明确的指标

在开始敏捷转型之前，团队需要知道转型成功会是什么样的。管理层和团队都需就将要采取的措施达成共识，以确认新工作方式是否确实有效。这个指标不应该从某个职能角色，比如测试人员、开发人员等出发，而应该从项目管理全局，比如说用户的满意度，从版本的交付频率等角度去考虑敏捷开发带来的绩效优化。

• 合适的Scrum Master

Scrum Master的专业度、情商、控制力、逻辑思维能力和计划策略执行力、业务熟悉度、IT专业知识储备度、部门权限等，都是决定敏捷转型是否成功的关键因素。优秀的Scrum Master是敏捷项目的推动人，在促进敏捷活动开展，方向把控，保持进度，调节团队氛围，获取外在支持等方面都起着重要的作用。

• 合适的产品负责人

产品负责人（PO）是敏捷开发中至关重要的角色 ，是团队和敏捷转型的关键。产品负责人可以有效激励团队，对团队有强烈的信任。他清楚的知道团队的愿景和目标，以及需要做什么，怎么做能够带领团队达成这个愿景和目标。产品负责人一定是全职的，每个团队一个PO并不能保证敏捷转型成功，但多个团队一个PO无疑是一场灾难。

• 外在的支持度

来自企业内部高层、客户、跨职能部门的支持，支持的力度越大意味着我们在敏捷转型过程中提出的诉求会得以满足，保证敏捷活动的正常开展，甚至能够得到试错和经验积累的机会。

• 研发流程的自动化

敏捷开发每个迭代就要交付一个可运行的产品增量，也就是说理论上至少在每个迭代结束之前需要集成和发布一次应用，而在实际敏捷开发过程中为保证产品是可集成可交付的，其实是每天一次，甚至是每天多次的去集成和发布，就要求具备端到端无缝集成，实现源代码的自动拉取构建、代码自动扫描检查、测试环境的自动部署、API测试自动化等去保证高频率的交付。

2. 组织文化如果没有敏捷基因的话，那这个组织是否适合继续推进敏捷转型？还是应该放弃？

“没有一个时代像现在这样，变化如此之快，转型升级已不再是选择，而是必须。在这个飞快向前的时代，每个人、每个组织只有超越外部变化的速度，才有可能在这个时代致胜未来。”——拉姆·查兰在8月9日《哈佛商业评论》中文版举办的第四届“人才经济论坛”上如是说。当你在了解并想尝试敏捷转型的时候，是不是就意味着你所在组织的研发模式已经跟不上瞬息万变的市场需求了呢？不管是企业、组织还是个人都需要与时俱进，才不会被时代淘汰，拥抱变化、响应变化才是应万变的诀窍。那么有人就会提出这样的质疑，上面说了敏捷转型时需要前提条件的，我们的组织不具备这样的条件，如何实现敏捷转型？

一般来说，不具备敏捷转型条件的组织不适合大刀阔斧的去转型，一切盲目的行动大部分都不会有好的效果。首先我们意识到敏捷转型的必要性，在不确定的情况下，可以尝试选择一个项目、一个业务做试点，或者组建一个团队，实现新的运营及决策机制，这是非常重要的探索尝试敏捷开发的方法。这么做的一个原因是小范围试点比较灵活可控，敏捷环境比较好搭建，即便不成功，造成的伤害也比较少。另一个原因是小范围尝试成功后可由点及面循序渐进的辐射到整个组织内部的开发中去，这也正符合了敏捷小步快跑交付的思想理念。

组建敏捷团队时如果内部人员Scrum经验不足，目前业内有丰富的敏捷支持服务可供选择，在专业的敏捷指导下进行敏捷试点落地，学习业界标准做法、获取实践经验，从而可以和企业实际情况和需要结合，以便制定更有针对性、更适合企业自身的下一步的推广和落地方案。

3. 如何获取团队或部门的支持？

还有另外一个大家比较关心的问题是，推动敏捷过程中遇到团队或部门的抵触要如何处理？

一般来说抵触敏捷开发转型的人都对敏捷存在错误看法或观念，比如：

•    敏捷没有过程控制。

•    敏捷意味着不确定性，不可预估，存在风险。

•    敏捷团队不做计划，因此无法对客户做出承诺。

•    敏捷对于简单的项目是可行的，但我们的系统过于复杂不适合敏捷开发。

同时，对敏捷存在误解的领导可能会认为敏捷团队是自组织团队，敏捷转型后自己将无事可做；对敏捷存在误解的成员可能不喜欢变化，对新的工作方式缺乏安全感，觉得如果有人告诉我该做什么，会更有安全感。

基于以上问题，我们在引入敏捷开发要预见性的抵触问题，而避免用领导者的权力蛮横改革。我们可以采用包括但不限于以下措施：

•    运行一个试点项目，团队包括抵触敏捷开发人员，让他们参与新过程的设计中，这是减少抵触的一个不错方法。

•    确保试点项目之外的人员能够看到采取敏捷开发的效果。

•    提供培训，讲述Scrum成功故事，通过参加讨论会或区域间的敏捷兴趣小组等。

•    改变团队人员组成。

•    鼓励正确行为，树立模范。

•    找到真正阻碍，判断个体抵触Scrum的深层原因

最后，要知道即便你能证明自己是正确的，赢得别人的支持也是比较困难的，尽管当前的开发环境存在很多问题，但是在真正相信有更好的方法可以替代之前，大多数人是不愿做出改变的，给团队足够的耐心，了解他们的担忧和顾虑，帮助解决问题，消除顾虑。价值高的事情总是需要花大量时间的。

以上解答了敏捷转型中的担忧和疑虑，希望对您的转型之路有所帮助，但是没有一条成功的道路是可以完全复刻的，我们就要结合自身的公司文化、管理层以及人员本身等情况探索自己的转型成功之路。

本文由DevSecOps专家服务团队出品，前往 专家服务 ，获取更多DevSecOps工程方法、工具平台、最佳实践等干货。