你好，我是宋宁。

上节课我给你讲了怎么做敏捷推进前的评估诊断，也帮你做了推进敏捷的短期计划。接下来我要用两节课时间给你讲讲推进敏捷实践的第二个步骤，也就是团队敏捷试点。

试点工作的展开可以分为试点前准备和试点推进过程两步。今天我先来讲在做团队敏捷试点前，你需要做哪些准备，试点推进过程我在下一节课会再做详细讲解。

说到这里你可能要问了：直接给公司所有团队都直接导入敏捷不就得了，为什么还要费精力先搞个敏捷试点？

这是因为，敏捷实践毕竟属于一场变革，与其他所有变革一样，都需要先从局部试点试水，只有在试点中积累了切实的经验教训，确定了可行性后，才能去大规模推广。如果不先在试点试水，就贸然在全局上推广，一旦在推进过程中遇到水土不服等问题，不只阶段性的成果会前功尽弃，想倒回去做新的改变也更不容易，最终整个变革大概率会走向失败。

为什么要做试点前的准备？

现在你知道了为什么要做敏捷试点，那是不是在毫无准备的情况下，立马就着手做呢？

我先来带你看一家创业公司推进敏捷的故事。因为是创业公司，工作节奏本来就非常快，老板希望他们推进敏捷时也能够“短、平、快”：快速行动、快速见成果。于是，推进敏捷的负责人只对团队成员进行了简单的两小时培训，直接就要求所有团队上 Scrum。

但效果极其不好，问题更是显而易见。因为此时，大家连 Scrum Master 是谁都不知道，况且没有任何前期铺垫，直接就要求团队改变熟悉的工作模式，团队既不理解为什么要改变，也不知道这种新模式到底该怎么做。大家很快就接受不了这种工作方式，做得一塌糊涂，连个形式上的敏捷都没做到，更别提见收效了。此时，推进敏捷的负责人到处救场，劳累不说，团队也不满意，老板更不满意，最后整个敏捷实践就这么灰头土脸地草草收场了。

这家创业公司的敏捷为什么会失败？原因就是他们在推进敏捷试点之前，没有做好试点前的准备工作。俗话说“凡事预则立，不预则废”，敏捷也是如此，只有做好详细、充足的准备，我们才能在推进敏捷试点时真正做到有备无患。有人还给敏捷试点前的准备工作起了个名字，叫迭代 0（Iteration 0），更足以见得这些准备工作的重要性。

如何做好敏捷试点前的准备？

现在你知道了为什么要做敏捷试点前的准备，那么你到底该如何做，才能为你的试点打开一个好局面呢？下面我将结合一个我接触过的实际案例，为你讲解做好试点前准备工作的基本要点。另外，简单介绍一下这个案例的主角，它是一家拥有一千多名研发人员的银行，我们姑且叫它 B 公司。

1. 选择试点团队

首先，你需要挑选试点团队，让他们充当推进敏捷的排头兵，快速打赢敏捷变革的第一仗。一般来说，有以下这些特征的团队会成为我们的首选：

  1. 采纳敏捷的意愿相对强烈
  2. 业务价值高或采纳敏捷会在短期内给团队带来很大收益

为什么要选择这样的团队？

这是因为，相对强烈的敏捷意愿，是团队落地敏捷的优渥土壤。如果团队愿意接纳敏捷，那么在推进过程中，团队成员会很容易发挥他们的主观能动性，成员之间的配合度也会相对较高，更易于产生良好的化学反应，也更有利于克服推进过程中遇到的困难与不适，使敏捷顺利推进并获得成效。

另外如果团队做的产品业务价值高，或者敏捷能在短期内给他们带来很大的益处，那么团队排头兵的示范效应就会比较好。一般而言，这样的项目比较重要，公司会高度关注，团队做起来也会更认真，也就更重视自己的敏捷实践活动是否能能取得成果。况且如果敏捷能在这些团队里率先取得胜利，那么敏捷在公司里的影响力就会更大，也会让其他团队更加信服，为进一步推进敏捷打下良好基础。

此外，我建议你选两个或两个以上团队来进行试点。如果只选一个团队，孤品风险太大，也没有竞争效果；而两个或两个以上团队容易产生竞争性，对比效果明显，大家都会争着把事情做到最好。当然，这也要看敏捷教练的数量，一般一个教练一次只能带 2～3 个团队，否则一个教练的精力是没有办法照顾到每个团队的。

例如 B 公司，他们希望通过导入敏捷提高研发效能。在试点时，我们选择了两个试点团队，手机银行产品团队和直销银行产品团队。对于 B 公司这样的银行来说，这两个产品都是公司的核心产品，在互联网的冲击下，业务压力很大，所以他们要求研发团队能够快速响应，因此团队有相对强烈的敏捷实践意愿。

2. 前期准备工作细则

选好了团队，就要配合团队做一些前期准备工作，你需要从这几个方面去准备：

  1. 组织和人员
  2. 管控治理规则
  3. 需求范围
  4. 架构
  5. 敏捷方法和工具
  6. 办公环境设施

下面我就结合 B 公司这个案例，逐一把这些准备工作详细讲解给你。

**首先，是组织和人员的准备。说到底敏捷实践要靠人来执行和推动的，因此，我认为在所有准备工作中，这一条是最重要，也是最需要花费心力来做好的，它直接关乎了敏捷试点乃至整个敏捷推进工作能否成功。**从组织层面来说，你要查看当前的项目组织结构是否适合做敏捷，如果不适合，就要重新组织。从人员层面来说，你需要对参与试点的人员进行相关培训。

那具有什么特点的组织结构更适合做敏捷呢？**简而言之，就是“高内聚，低耦合”。**这本是软件开发中用来衡量软件设计好坏的词，一般而言，模块内部高度聚集和关联，而模块之间关联程度低，这样的软件才是好软件。

引申用在组织结构中，高内聚指的是日常工作中，全功能小团队内、小团队内部成员之间的沟通合作更紧密；低耦合则指的是，团队之间的沟通协作要远比团队内部的少。这样的组织结构才更适合推进敏捷。

那要怎样来划分组织结构呢？其实，业界如今已经有很多这样的组织结构框架，但在这里我想提醒你的是，框架虽然多，但本质都是一样的，都是为了让小团队内的沟通合作频度更多、更加顺畅，而团队之间的沟通协作尽量少一些。

这里我用 Spotify 框架来说一下，它是目前“高内聚，低耦合”组织结构的一个通用典范。

它分两层，下面一层是 Squad，指的是一个一个全功能小团队，每个小团队中都有自己的业务分析师、开发人员、测试人员和迭代经理（Iteration Manager），能够端到端负责一个需求或者产品。一般来说，团队中的人数被限制在 5～9 人，当团队人数超过 9 人时，就会被分拆成不同的 Squad。而当 Squad 超过 5 个，一般就要考虑将这些 Squad 划分到不同的 Tribe（部落）中去，这是组织结构的第二层。在敏捷中，我们就是按照从 Tribe 到 Squad 这样的线条去管理团队的。

参考这一组织结构框架，我们将 B 公司的研发团队进行了重新组织。以 B 公司的手机银行项目组为例，他们的项目团队有将近 30 人，且开发团队和测试团队分属不同的领导，也在不同的办公区办公。我们将其团队分成了 4 个小分队，每个小分队都是有开发、测试、业务分析人员和迭代经理的独立的功能团队。我们还在这四个团队之外设立了产品负责人的角色，用来把握整个产品。为了沟通方便，我们设法将小分队里的人都安排到了一起来办公。在组织重组完成以后，我们又定义了各个角色的描述和职责，并进行了宣讲，在团队内达成一致。

在完成团队组织结构的重组以后，接下来还需要给团队成员进行敏捷培训。在上面 B 公司重组好的团队中，我们是这样做的：

  1. 进行敏捷思想基础和敏捷实践基础两门基础课程培训；
  2. 组织拆书会，选择一些敏捷基础的书籍，每个人都来读一节，一起来分享，这样团队成员很快就有了一定的敏捷知识储备。

此外，除了对要参加敏捷试点的团队进行培训以外，我们还对相关项目的干系人也做了一些宣讲，例如兄弟公司是怎么做敏捷的，取得了什么成效等等。

以上这些都是试点启动前的培训，在试点运行过程中，我们也会根据团队实践情况，针对大家对敏捷认知模糊的部分，随时做出讲解。比如随着团队工作的推进，我们会深入讲需求条目化、怎么做用户故事以及怎么做拆分等等。

其次，是管理治理规则准备。相信你还记得，在前面的课程中我给你讲过，敏捷是有规则的，不是随意的、自由奔放的，不能想咋做就咋做。所以，在做好组织结构和人员的准备后，为了大家能更好地协同、配合，省掉管理和交流中不必要的争执，你也要做一些管理治理规则的准备，并在敏捷试点之前就跟大家明晰，保证整个试点工作有序运行。因此，在 B 公司，我们做了架构和设计的治理规则，质量管理策略规则等等。

再次，是需求范围的前期准备。要想顺利开展后续的迭代，前期需求的准备是必不可少的。但因为在敏捷中，需求是逐渐涌现出来的，所以在后面的每个迭代中，我们都会对下一迭代要做的需求进行新的梳理。

在前期我们做好这些准备就可以：

  1. 项目的高阶需求范围、高阶发布计划；
  2. 高阶的史诗级故事；
  3. 近期 2 个迭代要开发的用户故事，要有优先级排序

如何准备好这些用户故事呢？通常我们会开几个工作坊，一起来头脑风暴一下。例如在 B 公司，我们就做了几个工作坊，写好了几十个用户故事，并将其按照优先级排序。这里请你注意，用户故事不仅要准备好相应的故事描述，还要有验收标准。

接着，是架构上的准备。做好需求，就要开始架构。关于敏捷里的架构，之前业界也有很多相关讨论。但总体来说，我们希望抛弃原有的瀑布模式，由于在敏捷中需求是分步提出来的，也是不断演进变化的，因此相应地，我们要求采用演进式架构，而不是做成一锤子买卖。正因为这样，在迭代 0 的时候，我们基于当时的信息做好足够的架构就好，后面会随着项目的深入及时来调整。

这时候我们做架构的方式，是在完成初始需求分析之后，根据初始需求来做架构建模。在项目早期，进行一些高层次的架构建模，会有助于团队与关键利益相关人商讨系统采取的技术策略，这样做的关键目标是快速识别出架构策略，快速完成架构建模。

在 B 公司，我们通过召开建模的头脑风暴会议，讨论了系统的功能特征，并思考了实现这些特征的高层设计策略，从技术图表、用户交互流程图、领域图和变更流程图四个方面做了建模。

**再来看敏捷方法和工具的准备。**做完上面的准备后，你还要根据我们在第一步评估诊断时的访谈结果，根据痛点选择合适自己团队的敏捷方法，当然方法的使用是灵活的，也许一开始选择的方法随着敏捷的推进不再适用，那你就要做出相应的调整或改变。

在 B 公司，起初我们在管理实践上选择了 Scrum 方法，在技术实践上则选择了单元测试、自动化回归测试，还有搭建 DevOps 流水线。然而在实际推进敏捷试点的过程中，我们发现在当时的情况下，由于团队的老旧代码过多，做单元测试的收益不大，所以我们及时调整，优先推进了自动化接口测试、自动化回归测试和搭建 DevOps 流水线，而选择在试点后再尝试单元测试。

“工欲善其事，必先利其器”，要把试点工作做好，工具方面也不能马虎。你需要在试点前选择、构建、测试、部署工作过程管理工具，并在测试后安装好；与此同时，也要选好自动化测试用的工具，如果自动化工具不到位，所有工作都靠手工处理，效率就会过于低下。

工作过程管理工具，主要指研发作业流程管理工具，比如 Jira 和 Trello 等，国内也有人用禅道。你可以根据实际情况，通过这样的原则来选择工具：

  1. 如果试点团队已经有自己的工具，那可以先自行试用、评估一下这种工具在敏捷中好不好用，也就是说，看看敏捷的过程在工具中是不是可视化的。比如说有的工具只有需求管理的作用，没法将后面的开发、测试过程囊括在内，这时你就要考虑是要将两种不同功能的工具合起来使用，还是重新选用新的工具；
  2. 如果试点团队没有自己的工具，那么无论是工作过程管理工具还是自动化测试等工具，都可以根据预算以及公司要求的安全性级别选择引进新的工具。一般来说，这些工具又可分为付费工具和开源工具，如 Jira、Confluence 等 Atlanssian 的付费工具，后续的服务要好一些；而免费的开源工具如 Jenkins，则能节省资金，这还是要结合自身情况来进行选择。

在 B 公司，由于他们的团队规模较大，考虑到后续可能需要 Atlanssian 的一部分插件来做管理工作，我们选择了 Jira 做工作过程管理工具。另外，考虑到目前 Jenkins 做持续集成的案例比较多，为了日后方便，我们又选择了 Jenkins 来做持续集成，并用 SonaQube 来做代码扫描。

要将敏捷做好，除了上面的“软”件，也离不开硬件的支持，所以**办公环境设施的准备也很重要。**如果项目中有人员是远程的，则需要准备必要的音视频设备，远程会议工具；如果项目都在一个区域，就还要有适用于敏捷开发的办公环境，如物理看板和开放式的工位等等。

在 B 公司，由于他们所有团队的员工都在一个区域办公，我们就在办公区域张贴了一些敏捷的宣传画报，也安放了物理看板，这可以方便团队学习和交流，提高工作效率。

总结

OK，说到这里，我们的试点准备工作就大功告成了，现在我来总结一下，以利于你更好的理解。

所谓“凡事预则立，不预则废”，在推进团队敏捷试点之前，你要挑选好试点团队，并做好试点工作前的充分准备。如何做好准备工作呢？一句话：**调整好结构、组织好人员、划定好需求、搭建好架构、选择好方法和工具、布置好办公环境。**你要注意，这些准备工作是相辅相成的，每一步都马虎不得。

俗话说“心急吃不了热豆腐”，在推进敏捷时，不能盲目地求快，不能省略掉该走的步骤。如果在做团队敏捷试点时，不做试点前的准备工作，就直接开展活动，那么团队成员既没有心理上的准备，也没有知识和技能上的储备，整个试点工作也会如同一团乱麻，达不到预期效果。做好了各项准备，未雨绸缪，才能让我们的团队敏捷试点工作“事半功倍”。

思考题

现在，我想请你来思考一下，在团队试点前的准备工作中，关于组织和人员的准备，你会怎么做呢？你有没有更好的方法呢？