本篇转载自公众号：码斯基之矛。阅读原文：敏捷，套路先行还是干了再说？

敏捷(Agile)，从字面理解是轻量、快速、灵活之意。在软件研发中，敏捷代表着软件研发中一整套价值观和方法论原则，它既是管理方法，也含有技术策略。其目标是为了更好地应对快速变化的需求和日益复杂的规模化的软件系统开发。 在近20年的发展中，敏捷已逐渐取代传统“瀑布式开发”成为当代软件开发的主流模式，为现代软件工程效率和质量提供了保障。

“自底向上”还是“自上而下”？

敏捷的理念，有某种程度的通用性和普适性。可用于个人事务管理，也更适用于软件项目的协作开发，在非IT领域或传统行业也有大量应用实例。要在组织内推动敏捷实施，首先你需要是一位激情的变革者、学习者，并愿意冒风险去打破一些东西。以下几点是需要预先考虑的：

明晰组织的特性和业务类型

搞清楚组织特性和业务类型，是决定要不要推行敏捷、怎么推行的先决条件。常见的情况，新创小团队比成型大企业更容易推行敏捷，科技公司比传统型公司更有先天优势采用敏捷，敏捷在外资、民营企业中普及率则比国企、央企等高得多，等等。

对这个问题的思考和判断，常常成为一个组织敏捷推进成败的最决定性的力量，而往往基层的技术Leader或项目管理者不太需要思考这个问题。因为敏捷的推行，对企业管理文化和业务流程的变革冲击也是巨大的。

正确认知自己在组织内的角色和资源权限

毋庸置疑，一个人在组织内的资源调度权限越大，越容易实施敏捷。因为敏捷影响的不仅是做事方式方法，更会引起组织或团队文化的重构、业务流程的变化，甚至许多时候它要抗争传统的许多东西。所以，你至少是一位在组织或团队内有一定话语权的leader角色（技术经理或项目经理），至少能协调2-3个人一起做事。

认清自己所在团队状况及能力成熟度

敏捷的团队管理目标，旨在打造一个自驱动、相互补位、强战斗力的团队。这对团队成员素养提出了很高的要求。理想情况下，我们都希望团队成员个个能力强、态度好，但现实往往残酷。所以我们更应该关注团队成员是否有拥抱变化的心态和愿意不断尝试、接受挑战的勇气。我们视这样的气质会是一个团队是否适合尝试敏捷的关键因素。

朋友大飞曾给我分享过他在某航空公司的案例：

大飞是计算机硕士，那时刚加入该航空公司不久，已有２－３年工作经验。对敏捷的理解，着重于前几年自己一些极限编程的学习实践（用户故事、重构及领域驱动开发等），曾参与过一次以前公司的Scrum内部培训，同时正在进行敏捷/Scrum更系统化的学习。

航空公司属于典型的体制内传统企业，主营业务与机票机务相关。大飞所在的信息服务部，属于运营支撑部门，负责全公司信息系统、网络等运维或二次开发及内部一些信息服务软件的开发。

部门领导安排大飞带领５－６个新人，完成一个有关配置信息管理的小型项目。团队成员大部分刚毕业不久，具备基础的技术开发能力，充满活力、对新事物满怀热情。

项目的主要目标，一为训练和整合团队，二是让新人有一个展现能力的机会，以期后有大用。同时，该项目也分配给了另外一个同样结构和规模的团队来开发。这样，２个团队就有了一种默契地竞争和赛跑意识存在。

怎样管理这个小团队、用什么样的流程和规范、技术架构等，都是大飞可以自主决定的，并且不需要上报给部门领导，只需按要求交付最终项目结果即可。

大飞根据项目特点、团队状况及自身兴趣所在，选择了敏捷和Scrum。项目的过程，让这些年轻的同事大开眼界，这次经历也成为了他们在软件工程领域、软件开发协作方面启蒙教育一般的存在。团队从敏捷的宣讲与认知开始，经历需求分析与需求故事化、迭代式开发，不断学习进步，逐步踏入敏捷之门径。

项目最终进行了１个多月，交付结果表现出的高效率和质量远达预期。相比而言，另一个团队的产出就逊色许多，该团队所用流程更偏向传统瀑布式软件过程，或者也可以说并没有什么章法可循。差异的产生，一方面因团队带队人经验有差别，也与团队所使用的协作和开发模式大有关系。

以上为一个典型的"自底向上"推行敏捷的例子。新的敏捷流程的采用，从基层团队开始（而非从公司上层宣传下达、基层执行），由基层自主选择。并且从这一个点的成功，可以逐步扩散、推广到更广泛的业务开发、更高层的组织架构中，甚而从非关键业务到核心业务。

新团队有较自由的发挥空间，没有既定规则和流程的束缚，可以放开手脚。管理层只关注最终结果，不关心团队用什么方法策略。这也说明，敏捷在新团队、新的或探索型项目中更容易推行。如果是组织内的关键业务，或者一个既有的成型团队、开发流程已经很成型，这反而加大推行难度，因为管理层的顾虑也更多了。 

另一个我曾经历的“自上而下”推行敏捷的案例：

我当时担任某集团公司下属分公司负责人，该分公司负责集团软硬件产品的自主研发工作。因自身资源调度权限许可及新重组的公司尚未建立完善的研发流程，我可以全方位、按敏捷的标准打造整个公司和各业务团队。

比如，为使管理简单高效、扁平化，将公司划分为几个全功能的研发小团队（如互联网组，硬件物联组，数据智能组等等），各团队内部都具备开发一个项目或产品的完整工种；将公司全局的目标管理及各团队之间的管理，统一到OKR之下，各团队内部采用敏捷/Scrum进行项目协作（需要先确认项目是否适合用敏捷）；建立统一的Saas协作平台：文档协作、流程规范、项目任务、代码等全面使用线上Saas进行管理和协同。诸如此类。

这次敏捷实施，我倾向于将自己定位为一个团队总教练的角色。经过前期团队的敏捷宣讲、流程与规范制定、技术分享与培训，到操作具体的项目迭代、与产品经理梳理需求、担任项目经理(Scrum Master)角色、技术架构和开发等，逐渐过渡到放手让成长起来的团队成员接手部分管理工作和技术规划任务，再到仅需参与团队 展规划、OKR评审与制定、及时关注团队和项目状态、为团队管理和技术问题答疑等。

团队从中不断成长，我自身也得到更密集的敏捷实践和思考机会。通过这些实践，我们训练了更多的敏捷团队，锻炼出合格的Product Owner（类似产品经理）和Scrum Master（敏捷教练），以应对公司未来的快速发展。

所以，不同的场景下使用不同的推行策略，这也是敏捷强调应对变化的体现。是否可以“自上而下”，取决于实施者的敏捷实战经验、在组织中的影响及能获取的资源支持程度。

“套路先行”还是“干了再说”？

“套路先行”，即先向团队宣讲敏捷的理论、原则和方法，再考虑基于这些原则和方法指导团队实践。“干了再说”，则是指带着团队直接就开始做事，一开始别跟团队提敏捷提Scrum，直到用这套方法做出效果、团队自我觉得满意，再提出这是敏捷的方法论体系。

曾在一个创业型团队遇到这样的争论：

自己一上来就给团队PPT分享敏捷/Scrum、讲各种敏捷概念和定义，然后开动项目。进行了几个迭代之后，有团队成员提出置疑，说这些做事方式本来就是事物原本该有的样子—-随需而变、迭代开发、增量交付，何必给这些已有东西套各种新概念新名词，说我教条主义太明显、操作过程生硬，并告诉我，“你应该先按这些方法做事，所有能高效出活儿的做事方法都是敏捷，出了效果你自然就敏捷了”，等等。我当时感到惊讶，当然也由此打开了思路，引发很多对敏捷的思考。

以现在的理解和经验，是套路先行还是干了再说，都不需要再绝对化了。你如果有绝对的把握、足够的信心可以确认自己的宣讲足够打动人心，而且你在团队有这种权限和影响力，完全可以套路先行。"干了再说"， 或许更适合你在一个需要谨小慎微、自底向上推行的环境，你需要用实际的结果来说明一切。当然，在实操的过程中，团队成员自然会有各种疑问：你为什么要这样做？迭代计划该做哪些事情？用户故事怎么提取、整理？等等，这时你仍然需要停下来给大家解释各种概念和名词，绝对的"干了再说"是进行不下去的。

不凑巧的是，自那次的争论之后，我在后续所有的敏捷带队经历里都是"套路先行"。 

了解更多关于敏捷研发，请关注以下微信公众号：

公众号：码斯基之矛