随着软件行业的发展，越来越多的企业开始进行敏捷转型，在软件开发过程中采用敏捷的方式，期望敏捷可以提升效率，改善质量。敏捷也不再局限于互联网行业，很多传统行业——包括银行、保险、证券、电信等等也逐渐开始认同敏捷的开发方式和流程，在企业内部的系统开发过程中把敏捷与原有的流程相互融合，以更好地适应高速、快节奏所带来的不确定性，从而达到更好地体现 IT 部门价值的目的。

转型前客户M和大多说传统开发一样面临着大量的问题：

组织架构按产品分层，各层研发团队分散于不同部门，如何有效的协调各部门协作？

各种固化的流程、KPI数据度量、详尽的文档却无法继续推动产品质量提升和开发效率持续提高。

业务需求端到端交付周期长，已经无法满足市场对需求快速响应的要求。

为了改变现状，客户M决定实施敏捷转型，希望用业界领先的方法论指导企业生产力提升。项目从2017年1月份正式启动，到2017年9月底一期大致收尾，共历时9个月的历程，主要经历了调研分析，设计规划，试点改进，总结推广，结项总结等阶段，已经初步完成了敏捷的转型的第一阶段，9个月的转型转型犹如刮骨疗伤，实践中有很多收获，也因为种种原因，留下很多遗憾。不过回头看来，还是有很多可以分享：

一：敏捷转型，意识先行：

在大型组织转型过程中会碰到的各种阻力、因为每个人都喜欢停留在自己的舒适区，想要让人从舒适区中出来，是个技术活。如何有效改变这个组织中的“人”？是否先从改变每个人的“行为”开始，进而形成”新的习惯”，还是先转变“观念”，然后改变行动。实践证明，对敏捷的推广，必须做到意识先行。对敏捷的误解很容易造成管理人员，团队成员对敏捷的抵触，任何组织的变革中，总会有小部分“抵触者”的存在，碰巧如果这些人影响力很大，对项目的推广非常不利。转变这些”抵触者”为"支持者”是我们的工作重点之一。

下面就是我们在项目中听到的，大家对敏捷典型的误解：

“敏捷就是快”，

这是对敏捷不了解的人对敏捷最深刻的误会。

敏捷二字其实是针对需求变化的快速反应而来，而不是过去所谓的快速应用程序开发。敏捷开发为何会比传统开发方法快？传统开发法依循计划、分析、设计、程序开发、测试再进行修改整合后发布的步骤进行，是一种顺序性的开发模式，也就是说当前一个步骤还没完成之前，后面的步骤就会位在等待的行列，当前一个步骤用掉越多时间时则后面步骤的前置时间就会越长，而形成时间上越多的浪费。也就是说传统开发浪费了太多的时间，在前置作业上的意思。前置时间造成了一种没有充分运用资源的现象，当进行到分析或设计的步骤时，程序设计人员仍然处于等待的状态，因此形成了时间的浪费。

以下是客户M原有的产品开发流程

反观敏捷开发，实行的是一种务实的做法，例如:在进行需求搜集的步骤时，当收集到足够一次迭代开发的需求时即向下一个步骤前进，尽量缩短前置时间的浪费，然后将”分析、设计、开发与测试“形成一个开发步骤，减少了步骤与步骤之间的衔接时间，这种开发方式形成了一种所谓的「衍生式的设计」，也就是遇到实质上的问题时才采用设计方法来克服它，而不是预先作好设计的方式。 因此让起步显得轻量化了，再加上只有少少的规范，所以敏捷才有了轻量化的开发方法的称谓。

这是敏捷的理念也是精髓：迅速响应需求，快速反馈结果。agile 的引入像一股活水冲击着老气横秋的瀑布流模型，速度上跑赢几条街，如下图所示。

“敏捷会议多”，

Scrum定义了5大活动：产品待办事项列表梳理，Sprint计划会议，每日Scrum会议，Sprint评审会议，Sprint回顾会议。初接触敏捷的人，会认为突然多出很多会议，而开发测试更愿意专注于可以看到结果的开发工作，而认为会议是一种浪费。

如果我们计算一下所有与会人员的开销及管理费用是很高昂的。因此，务实的做法是，会前做好充足的准备，以确保敏捷会议尽可能的高效。

而其实所有的会议，都是为了围绕着开发进行的团队沟通，敏捷的四大原则之一就是个人和互动高于流程和工具。

虽然会议是昂贵的，但它们也是必要的。关键是高效的进行，最大化的利用现有资源并培养良好的沟通。

”敏捷不需要文档“

 长久来看，文档是提高效率的一大利器。虽然《宣言》中明确地放低了文档的地位（“工作的软件大于详尽的文档”），敏捷强调互动和变化，以及对变化的及时响应。诚然文档恰恰做不到如此灵活。但敏捷真的完全排斥文档吗？

文档的时效性和灵活性远低于口头沟通，但却有它实在的好处。

1.空间上，文档传播范围更广。规范化和常规化的内容形成文档可以大大减少沟通成本。尤其在多个系统协作的情况下，跨 scrum 、跨团队甚至跨部门的沟通时有发生，文档的重要性和便捷性不言而喻。

2.时间上，文档流传性更好。团队不是一成不变的，有人离开有人加入。更新换代中，新人快速了解系统，老兵传承研发理念；在更大的时间跨度上，团队可能成为忒修斯之船，文档的存在就是对产品历程的完整追溯，你将不用他人帮助就可以了解到产品的大部分面貌甚至全貌。

而如何提高文档的有效性是团队需要考虑的，比如测试代码即文档可以有效的减少团队重复工作，和提高文档的实时有效性。

二：外练肌肉，内练经脉：

外功练的是肌肉，内功练的是经脉；转型必须先形似，辅以心法修炼；外功会随着年龄的老化而衰退，内功随着年龄增长而日益深厚，老了也会深化，只是速度越来越慢而已。

重塑敏捷团队架构组织

问题：敏捷的产品团队，产品经理、产品负责人、开发团队、ScrumMaster是一个整体团队，俗话说是一条船上的人。如果这些人分乘几条船，方向也不同，结果可想而知。

这是技术支撑部的组织架构图，他们是三周一个版本，每个版本配属一个版本经理，负责统筹协调各个团队的工作和节奏、解决各个团队的内部问题、负责协调外部门的沟通。这里的外部门是指前端和客户端。

版本发布流程是技术支撑部先上线，发布到现网，然后前端、客户端分别上线，上线时间就看他们的开发进度。一个产品上线，由三个部门负责，而且呈流水线工序。

罗马不是一天建成的，欲速则不达。部门的变化或者融合很难一下子达成，强行去改变只会遇到更大的阻力，有可能会导致敏捷转型失败。所以经过协商，将前端和客户端一起拉入敏捷团队，虽然行政上人员隶属不同部门，但是沟通变得开始简单、工作节奏也可以保持一致。版本经理的岗位依然保留着，协调三部门统一行动。

这是经过调整后的敏捷团队架构。

不过略微遗憾的是，企业敏捷很强调业务验收测试的作用，但是因为多方面的原因，一个总体的、上层的业务验收团队没有能够形成。目前还只是以重点需求抽检模式，对产品质量的保障还没有达到预期的目标。

组建跨特性团队

问题：当前团队每个版本采用小瀑布式的开发方式，需求下发到多个组件团队，在所有组件团队完成工作之后，才能集成并测试，整个开发过程需求不可见。开发过程中以及现网问题难以解决，组件之间往往互相推诿，解决周期长。

组件团队专注于开发组件或者子系统，这些组件或子系统只能实现最终客户想要的部分特性，组件团队所有成员由技能相近的人组成，所有成员可能都向同一个职能经理汇报工作，这种情况在客户M尤为明显。

如何解决沟通不畅的问题？如何加速问题的解决？是开发部面对的最棘手问题。

组建跨职能特性团队，由特性团队完成特性所需的全部工作是敏捷转型的第一步。有效的特性团队需要团队成员具备完成多种特性的技能和能力，以完成特性的全部工作。对于这种完全共享代码所有权的多特性团队模式，有一种解决方案如下：

但是客户M的实际情况更为复杂：在客户M由于不同的组件团队来自不同的分包商，理想情况下分包商之间人员全部打散，组成跨职能小团队，每个团队具备多模块能力，可以快速的实现端到端特性开发团队；但多分包商组成的跨职能团队合作与管理复杂度走然提升：不同的分包商人员合作是否顺畅？SM谁来承担？人员的考核谁来定？最重要的多分包商以往按照完成工时计算工作量，打散之后各分包商工作量又该如何核算？

最终经过团队商过后，我们决定采用各组件团队直接切割为特性团队的模式，避免了跨分包商团队的情况出现，但是如此一来，每个特性团队都是能力储备不健全的，因为特性团队的成员只具备同一个组件的能力。很明显，这样特性团队与我们要求的具备各组件领域知识的团队相差甚远，但转型之初，我们就保证必须保证版本的开发能力，产品质量在转型期间不能有下滑，所以一边需要保障版本的开发交付正常进行，另一方面特性团队还没真正成长起来，理想和现实的差距又横在我们面前。

敏捷的落地就是理想和现实的碰撞，然后找到最佳的结合点。本着遇到问题解决问题的态度，我们协调团队之间形成临时合作伙伴的方式，不同能力的团队互为结对，相当于学习小组，对合作团队的开发手把手的指导，迅速帮对方建立各组件知识，以缓解能力的差距，带团队慢慢建立起相关的领域能力，等能力成长起来之后再慢慢独立开发。

以用户故事描述需求

问题：以需求分析文档为基础，由分析人员拆分到组件的任务，往往颗粒度较大。在试点前期，我们发现每个团队成员在一个迭代中，基本只能完成1到2个任务，团队成员之间没配合，团队成长缓慢，对项目进度的管理造成困难。

敏捷开发推荐以用户故事的方式对需求进行描述，用户故事可以帮助开发团队从用户的角度来理解需求，同时在交付的过程中按照用户可用的场景进行交付，确保了开发团队可以持续的交付用户关心的功能。原团队则以产品需求文档PRD传递需求，直接拆分到组件，由组件团队开发交付，在团队转型特性团队之后，迫切的需要转型为以用故事的方式管理需求。

需求拆分到单模块任务，颗粒度大，涉及多业务场景，容易发生遗漏，集成时间晚。而用户故事以用户角度描述系统需求，直观可见，验证方便，开发过程可见，颗粒度更小，风险可控。

需求分析方式的转变对MDE习惯来说还是有挑战的，因为按照工作习惯，通常都是MDE直接分析到接口，然后再交给团队做详细设计，用户故事引入之后，整个部门原有的分析流程并没有打破，试点团队拿到需求的时候，已经是MDE分析到接口的需求，为了适配新的用户故事，自然而然开始把拆分的任务映射到用户故事。

这种工作方式的本身属于本末倒置，先有了接口任务，才有到用户故事的映射，但是在整个部门大流程没有变化的情况下，试点团队的小流程也必须具备兼容性。为了保障试点团队开发的流畅性，试行了两个版本，期间就发现由于用户故事颗粒度较小，往往出现一个任务对应多个用户故事的情况。

此时的用户故事，徒有其形，没有发挥真正的描述需求的作用。我们在和团队进行多轮用户故事的培训之后，强调了废弃对接口分析后的需求文档，完全采用用户故事的方式描述需求，进而拆分到任务，任务的颗粒度有了明显的减小。

需求分析流程优化

问题：各组件MDE作为需求分析人员，每条需求需要多个组件MDE进行分析影响，长期成为需求分析的瓶颈；而团队成员只负责代码开发，对需求不了解，完全按照概要设计进行开发，一叶遮目不见泰山！

客户M原有的需求分析流程冗长，在产品经理和最终的开发人员之间还隔着PO和MDE(需求分析工程师)两层角色，这样的规划对敏捷转型造成了三方面的影响：

1、不符合我们敏捷开发模式下，PO/团队/SM通力协作扁平化的要求。

2、MDE只负责模块、接口分析，但不编写或者很少编写代码，时间长了之后，代码能力下降。

3、开发人员严重依赖MDE，对自己负责的业务内容并不了解。

在和团队协商过后，我们决定取消MDE的角色，分拆到团队进行分析指导，帮助团队能力建设，同时参与代码开发。

MDE和团队融合，扁平化开发团队角色，开发参与分析，省去反讲环节；数据显示，版本需求分析时长3周降至1.5周。

Scrum Master选拔

问题：ScrumMaster的选拔由分包商自行挑选，选拔标准不统一，导致推举的SM多为技术牛人，工作安排是命令控制型，很多会议变成SM的一言堂。

SM是转型到团队内部推动的关键，如何选择合适的SM是保障实施效果很重要的一环，技术牛人，意见领袖，都有可能被推举为SM，什么样的人适合做SM，那首先看下SM需要做什么？Scrum Master的职责简单的说可以总结为： 

作为团队教练，确保团队按照Scrum的方式运行，帮助团队更好的工作。

移除项目进度的障碍，保护团队成员被过度承诺等。

SM就像团队的一个大保姆，维护工作方式，保护团队，为团队和持续改进负责，而非技术或者业务的决定者；而技术大拿，意见领袖如果不具备倾听团队的特质，独断专行，经常帮团队拿主意，出方案，且不说解决方案质量如何，团队成员的参与度非常低，无法培养主人公的精神，长此以往团队没有平等对话的气氛，团队成员没有对团队的归属感，这是在敏捷团队中最不想看到的。

在客户M的敏捷推广的过程中，根据实际情况，优先能力突出的MDE担当SM角色，虽然从技术能力上得到保障，但在带领团队方面还存在能力不足的情况，在后续推广中大部分SM的能力得到了锻炼，个别出现了团队协作不通畅的情况，SM人选也及时做了调整。

岗位职责重新定义

问题：为了适应敏捷团队的开发模式，对现有团队人员进行了岗位职责的梳理和重新定义，重新调整了组织架构。

跨职能的团队是敏捷项目里的交付单元，但企业级的敏捷只有这些团队是玩不转的。如何围绕Scrum团队，打造周边的服务团队，是企业敏捷成功的关键。

围绕着新型的跨职能团队，我们组建了：

PO团队，包括了产品经理和系统分析师SA，主要为团队导入高价值的需求，负责需求验收。

代码看护团队：原各组件团队的负责人，对组件代码最为了解，继续发挥长项，转型为代码看护，优先识别团队之间依赖关系，把控模块整体质量。

TC测试控制团队：原各组件测试的负责人，对组件测试最为了解，转型为测试控制团队，负责团队特性测试方案的审核，确保测试质量。

解决方案验收测试团队：统一的验收测试团队，实现端到端的验收测试。

ETC：团队内部的敏捷推荐组织，主要是发现、解决团队在转型过程中的问题，组织必要的培训、分享等等。

敏捷转型不能一蹴而就，需要给团队成长容错的空间，但产品不等人，综合团队当前所面对的实际情况，确立该方案，团队间各司其职互相协作，适合在敏捷团队建设过渡期内，以质量为先决条件，保证迭代持续进行。

团队能力提升

问题：特性团队的成员由原单个组件团队组成，彼此技能相似，而特性团队需要各组件能力，如何快速建立，并保证产品质量？

团队能力提升是玩转敏捷的基础，没有优秀的团队成员，敏捷就是无本之木，无源之水。敏捷团队要求团队成员是一专多能的T型人才，而客户M开发团队因为长期按照组件的方式开发，团队成员能力单一。巧妇难为无米之炊，如何在现况下，最大化的支持高效的敏捷的开发，是我们必须考虑的。

我们组织各团队搞跨模块学习，制定详细的学习计划，建立起长效的学习机制，以保障团队能力成长。如下图，互动团队的跨模块学习规划。

能力提升的落实一定要在细处，比如我们采用1带1的方式，具备模块能力的成员做开发，需要提升该模块能力的成员配合做单元测试，这样通过特性的开发过程，熟悉代码结构，业务逻辑等。通过2个迭代的学习熟悉，开发人员已经可以开始在新的模块上进行开发。

管理可视化

问题：敏捷管理工具五花八门，客户M经过多年的发展，已经有了自己的工具，是推到重来？还是打通工具之间的墙，协同作战，形成工具体系？

敏捷管理工具主要还是为了过程可视化，增加透明度，提升管理效率。期间我们为客户M引入了基于Icescrum的白板管理工具，但是在经过3个版本的试点之后发现一个很严重的问题：与现有工具的不兼容。

客户M需求管理平台客户使用的是Redmine，已经集成很多流程和配置，PO的需求都是在Redmine上下发给团队，而我们给客户导入的开发迭代管理工具是Icescrum，需求需要重新建立，而不能直接由需求管理平台下发。两个平台无法的衔接，团队成员苦于在工具之间切换，效率太低，这样低效的状况有悖于我们的初衷：工具本身是为了提高团队效率，而不是增加团队负担。

团队在商议之后，决定拓展Redmine的白板管理功能，取代试点的Icescrum。工具的选择与推广是否能和客户的习惯有效结合是我们需要关注的，此举也得到了团队的一致欢迎。

另外工具使用习惯的培养也是一个漫长的过程，避免采用命令的方式强行要求团队配合使用，最好结合团队工作的流程，比如使用电子白板作为晨会的白板，以事件，流程驱动和培养大家使用习惯。

CI并不是一句口号而已

问题：俗话说，不做CI的敏捷都是在耍流氓。团队已经建立了一套CI的框架，Hudson、Maven等等工具都做了集成。不过再好的工具体系也得真正嵌入流程中使用起来，否则也只是摆放在那里的一个好看的花瓶而已。

企业转向高效开发运营，CI是必要的，其中自动化又是重中之重。CI框架的搭建是第一步，客户M已经完成，接下来就是使用的问题。教练团队对自动化测试的覆盖率做了一次评估。

客户M有零星的单元测试和接口测试，但更多的是手动测试，每次开发两周需要两周时间集成测试并验收，严重阻碍的交付效率。

单元测试、接口测试的自动化测试脚本并没有集成到Hudson上，开发团队都是本机跑这些用例，代码提交到Hudson上没有办法调用脚本进行测试。

问题暴露出来之后，转型团队一起努力提高自动化测试的覆盖率，并且将单元测试和接口测试的脚本集成到了Hudson上，开发团队只要提交代码，即可看到测试结果，及早暴露问题。

敏捷发布火车

问题：技术支撑部门交付产品，未经过前端客户端测试，产品上线后并未达到终端客户使用的要求。而技术支撑部，前端客户端顺序的开发节奏，开发节奏的不匹配也导致部门之间响应速度比较慢！

客户M的开发部门分为阅读事业部（包含前端开发测试），技术支撑部（后台），应用开发部（app开发测试），产品的交付主要由技术支撑部驱动，在改进之前，前端和客户端分别有自己的发布计划，任何部门的延迟都可能影响到一个功能的准时发布。

探讨分析之后我们引入敏捷发布火车，以技术支撑部计划为主导，前端和客户端协同参加技术支撑部计划的新工作方式。各部门分别完成单元测试，接口测试之后，统一进行集成测试，由以前异步式的交付节奏转变为同步式的交付方式。

这样的工作方式带来的最大的好处就是：

平台功能测试无需再自行搭建简易页面测试，在更接近现网的准测试生产环境上，直接与前端客户端对接，提前暴露了对接后有可能暴露的问题。

前端客户端在技术支撑部迭代计划内协同测试，发现需要联调的问题，可以第一时间安排技术支撑部门协调解决，缓解了部门之间开发节奏不一致，导致的问题解决缓慢。

遗憾：采用同步开发测试的交付方式也不是十全十美，因为集成测试的环境和准现网测试环境还有差距，前端客户端在火车发布后，还需要在现网环境进行重复测试以确保功能。该问题只有在彻底解决准现网环境后才能缓解。

企业敏捷转型社区

问题：试点团队经过3个版本的试点，催生了很多优秀的实践，如何在推广阶段有效分享到其他团队？如何在后续的推广中，互相分享踩过的坑，优秀的实践，让团队更快成长？

企业转型社区（Enterprise Transformation Community）应运而生。它是为了创造一种文化、一个氛围——那些对企业的成功抱有满腔热情的人尝试做出改变，而这些人的成功又吸引更多的人产生更大的热情。ETC 不是通过给企业强加变革来做到这点，而是通过指导实施变革的小组，移去障碍以便做好Scrum，和为变革创造活力与激情来做到这点的。

企业范围内实施Scrum 时，对ETC 的成员组成可能更要深思熟虑。ETC 应至少包括PO和SM，以及敏捷推动的相关高层责任人，甚至相关部门干系人，资深开发测试都可以参与到ETC。在转型的初期，会议召开的频率可以达到每周一次，以尽快的发现问题，解决问题，以及分享经验。

ETC会议主题应该来自于各团队，而不应该简单的由会议组织者确定。可以针对内部团队实践中的问题，也可以是外部敏捷的分享。

ETC 与Scrum 开发团队一样使用Scrum，所以他们也通过sprints 取得进展。每个ETC sprint 以计划会议开始，以评审和回顾会议结束。这些会议和Scrum 开发团队的那些会议完全一样，也经常发生同样的问题。

重构，我们走在前行的路上

问题：客户M的系统架构是华为以前设计的，典型的组件式、强耦合，各个组件交织纠缠，牵一发而动全身。随着互联网的发展，强调价值快速交付的当下，越来越显得步履维艰。

客户M的系统架构是典型的组件式，一共有七大组件，各组件间强耦合，导致开发前置条件过多，发生现网问题也需要逐个组件排查，定位效率低，修复时间长，运维团队的压力也非常大。既然决心推动敏捷，最终、最难啃的骨头也是应用系统的架构设计，客户M也认识到了这样的问题，决心开始逐步改变。

当前业内炒的最火的微服务架构，是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。客户M也朝着这个方向去改造。

经过一段时间的梳理，48个特性已经被总结出来，最终还会体现在系统架构上，目的就是希望每个敏捷团队能够独立运作，解耦合，不再互相干扰。

目前门户已经开始进行重构，底层服务拆分也逐步启动，随着时间的推移，我们相信最终的结果一定是值得期待的。

三：种下行动，收获进步

经过两个版本的敏捷推广，我们得到来自团队各种各样反馈，比如团队参与度更强，交流更加通畅，开发效率更高了等。通过管理数据监控和分析，我们已经明显看到敏捷推广带来的一些改变趋势，包括交付质量，交付效率都有了明显的提升。

交付质量提升

通过127~130版本的数据收集，我们发现在版本需求承接能力不变的情况下，127(39条)、 128(41条)、 129(48条)、 130(43条) 。整体缺陷总数和缺陷密度下降约20%。

我们知道缺陷的成本曲线，越晚发现缺陷修复的成本越高。因此问题提前发现，也是也是我们测试质量提升的表现。通过下表我们发现，SIT1阶段缺陷比重上升约25%，说明端到端测试也有效果。

指标说明：

ST缺陷占比率=ST测试阶段的缺陷数/缺陷总数*100% 

SIT1缺陷占比率=SIT1测试阶段的缺陷数/(SIT1+SIT2+SIT3)*100% 

交付效率提升

技术支撑部上线后，一个关键的指标就是需求上线时长，准确的说就是该条需求和前端客户端集成测试开始到完成的时间，中间发现的问题越少，解决的时间越快，意味着上线时长越短。

相比非敏捷需求，单位敏捷需求在前端客户端集成测试阶段，缺陷密度下降约41%（0.56降低至033）。

质量的提升使敏捷需求的上线时长降至2.75天

经历了启程时的兴奋到收尾时的豁然开朗，深刻体会到企业敏捷的落地是理想和现实的激烈碰撞。敏捷转型不是一蹴而就，也没有银弹，所有的问题都要用心感受客户心声，探索最优的解决方案。敏捷是个过程，却没有终点，这其中最让人着迷的也就是在敏捷灯塔的指引下，一步步探索，不断靠近彼岸的过程。