敏捷开发模式在工程师团队的实践与落地

敏捷开发模式跟传统的开发差别之一是对变化的拥抱。传统的开发相对会拒绝变化，即计划制定好之后不希望有任何变化，有变化会对开发流程造成很大的影响。敏捷文化是拥抱变化，当有问题发生的时候需要会主动做调整，当然这对团队的组织和行为方式也带来了很大挑战。这里，FreeWheel有一些比较好的实践经验可以分享。

第一是团队的组织。FreeWheel一开始按照敏捷开发的原则将团队组织成Scrum，在这种管理方式下，所有相关人员（主要是测试人员、开发人员和在美国的产品团队）会形成一个比较紧密的团队，消除相互间的壁垒。所有人从一开始就会融入到产品的设计、开发、测试里去，通过快速反馈和及时沟通，能最迅速地解决项目过程中各种问题。

第二是团队的管理。敏捷开发与传统模式相比，最显著的特点就是人和流程的关系有很大不同。传统开发中会制定一个固定的流程和周密的计划，人被添在了这个流程和计划中。敏捷开发的变化多、迭代快，如果套用一种过去的管理模式并强加给团队，往往会带来生产力的倒退。所以管理的方式应该是给团队更大的自主性，注重引导而非控制。一个公司往往会有很多个敏捷团队，我们最终是让各个团队用他们的聪明才智解决问题，但同时各个团队之间又可以互通有无、取长补短。有的时候你会是第一个踩坑的人，但这个踩坑的过程是有价值的，得到的经验教训可以跟大家分享。

第三是做事的方式。当把任务拆分的更细时，反馈就能更及时。如果有一大块的东西挡在你的工作流里，会对你的敏捷性造成障碍。所以我们一开始就会对所做的事情进行拆分，把任务拆分得更细，使得任务更容易被排期。同时在技术上实现CI/CD，对产品持续不断地做测试，并且把它集成到研发流程中。当工程师做了某些改动后，整个系统会立刻产生结果评价，告知你做的是对还是错，然后大家基于这个结果再看如何继续推进。

1．SAFE（Scaled Agile Framework）模式的尝试

与此同时，上面提到的“Hire the Best”理念也会对团队建设和管理带来一定挑战。如果团队人员的水平和能力呈现为梯队型，自然而然管理会相对容易；但如果大家都处于较为平均的基线范围内，就会面临更多协调、平衡及取舍方面的工作。最近FreeWheel正在尝试SAFE，即将团队都分成不同的Squad，一个Squad即为对产品有贡献的垂直的功能性团队，需要挑选并重组在前端、后端、数据库方面具有差异化优势的小组成员。但将优秀的成员都放在一起做一件事，很容易有人做的多，有人做的少，有人满意，有人不满意，这就跟项目管理、软技能训练等相关。

通过实行敏捷模式，工程师团队的整体趋势会越来越扁平化，但是扁平化主要还是发生在一个模块内部。比如，目前FreeWheel中国的工程师主要被划分为五个分支技术团队——AdServing、Forecasting、Data、UI和SRE，其中，AdServing模块内部被大概分成了6、7个小型团队；Forecasting被分成3个小型团队。其他四大模块情况也类似。在团队组织上，部分小型团队成员可以直接汇报给一线研发经理，例如，UI（负责核心业务系统的研发与测试）模块的80人团队大概有6个研发经理，他们各自领导着十多人的团队。因此，分支技术团队总负责人和普通工程师之间只有一级，向上的沟通和汇报会更加通畅。而且，负责管理的同事有更多的机会直接与小型业务开发团队进行协作，第一手掌握他们真实的想法、他们的困难和反馈意见，以便缩短做决策的时间周期。

2．对Full Life Cycle Engineer理念的倡导

对于Full Life Cycle Engineer，现在业界有两种声音，一种是Full Stack（全栈）Engineer，指能够掌握前端，能写Web，能写后端服务器，还能开发Mobile程序等，要掌握不同的技术。这种声音存在一定的争议。另外一种方向是Full Life Cycle Engineer。比如写后端C++的程序员就不需要掌握Web编程技术，但要能对使用C++开发软件的整个生命周期熟稔于心：当新的功能需求提交出来时能用C++对它进行设计，写完之后能够用相关的工具测试并将服务进行发布，后续还需要支持服务的运维。举个很简单的例子，如果测试、运维的环节被技术管理者忽略，随之而来的问题便是产品质量不可控、Bug一堆、发布成功率低、运维人为事故频发。但对Full Life Cycle Engineer理念的倡导可以有效减少此类问题的发生。

因此，FreeWheel非常倡导Full Life Cycle Engineer，其直接优势在于可以消除上下游间明显的界限。比如一开始设计的时候就会将测试的实施方案、后期发布、运维上的问题一并考虑进去，而不是执行一半之后再去想怎么“填坑”。这是敏捷模式下最为可行的方式：如果整个软件交付过程中还要上下游切换，沟通成本就会很高，整个团队不可能敏捷起来。

3．最快速地定位技术问题出现的根源

研发团队之间的协作非常重要，协作和沟通的效率在很多时候都是解决复杂技术问题的关键。开发过程中，如果我们在上线环节亦或开发测试环境中发现了一个具体的技术问题，不同的研发团队负责人或该领域的资深专家会组成一个临时小团队（War Room），集中调研，分析和研究后认定问题根源并划定应该由哪个团队、哪个工程师具体跟进和解决。解决方案落地且开始执行后，大家还会回过头来进一步验证，确定目前的解决方案是否有其他风险存在。

4．轮岗制的跨地域协作

对FreeWheel而言，最大的挑战之一是跨地域、跨时区的沟通与协作。FreeWheel除了在美国、中国、法国有研发机构以外，在欧、美、亚洲的多个国家也会有自己的办公室。这些国家的团队规模及成熟度较高，但都存在较大的时差。

相比通过电话、电子邮件进行跨时区的交流，我们会尽可能地采用很多其他的方式优化跨时区、跨地域的合作和沟通。比如北京的各模块的研发团队会持续派轮岗人员，去美国等地不同的实验室和不同部门，与产品经理、客服经理在一起紧密地合作一到三个月。这样做的好处之一就是当产品经理面对更多的客户、分析客户需求的时候能得到研发团队第一手的支持，比如从技术角度看业务设计是否合理、能否实现、实现难度大小等。

另外，美国的产品经理会每个季度飞到北京来与这里的同事工作1-2周的时间商议未来3-4个月的研发及项目规划。这类协同工作的目的都是尽可能地减少跨时区、跨地域沟通的难度和障碍。如果团队之间没有很好的沟通，做完以后发现有很多问题，但由于一开始没有识别出来，最后就会演化得愈发严重。