如何提高软件开发团队的效率？

质量和效率是对矛盾，短期效率和长期效率是对矛盾。最极端的高效率，就是一个人独自做所有事。如果是团队，就必须考虑合作效率，所以流程非常重要，因为流程是合作的契约。一般来说，无论多小的团队，基本的方案和代

如何提高软件开发团队的效率？质量和效率是对矛盾，短期效率和长期效率是对矛盾。

最极端的高效率，就是一个人独自做所有事。

如果是团队，就必须考虑合作效率，所以流程非常重要，因为流程是合作的契约。

一般来说，无论多小的团队，基本的方案和代码评审必须要有，这两个点是保证合作能长期有效的方法。

评审除了能让其他人帮你把关在，还能向其他人同步你做的东西，是业务和知识共享的一种方式。

如果你的团队没有方案评审，没有代码评审这两个基本流程的话，短期看效率高，但是长期看，系统会越来越难以维护，长期开发效率会下降，而且后期逆转起来要花百倍的精力。

要想提高软件系统的长期开发效率，保持软件的基本质量稳定是唯一途径。

段英伟：统御至诚 统御项目管理工具产品市场负责人

一般团队都存在这样的问题。有效的、合适的管理是提升团队工作效率的办法。在较大的团队更需要通过规章制度这样正式的组织管理来实现团队成员间的沟通与协调。小的团队个人建议推荐更多的使用非正式组织管理的方式进行沟通协调。多通过一下会议、研讨的方式来进行管理会更加有效。同时还可以将团队成员比较弱的带一下。

如果在项目化管理的过程中引入项目管理的方法和相关的软件我想效果会更好。在这里我推荐一下我们公司的项目管理系统统御项目管理软件。（长期提供免费版）

统御软件 （oKit）| 项目管理软件，项目管理咨询，项目需求管理工具，集成研发管理平台 --管理咨询与实施工具 一站式项目管理解决方案

最简单的是你先了解团队中每个人的技术特点与性格特点，根据他们各自的特点做合适的事就是整个团队的正能量。这就是手段

要提高效率有很多方法，但得先具体分析问题

1. 是否人员能力水平不一致？可以考虑招聘强者、提昇团队学习分享氛围、加强员工能力传承
2. 敏捷开发现在确实比较火，我们的书跟课程都有详细讲解如何实际上我们如何在网易应用
1. 敏捷思维如何帮助大家利用站会等手段，帮助大家快速同步信息
2. 切短迭代时间、固定时间盒，帮助产品持续交付价值。每个版本要做的需求少了，自然各环节的时间也简短，更快应对变化

可以看看我们课程：

互联网项目管理-微专业 - 网易云课堂

把所有的信息公开给所有人。

每天早上站立会议。

项目经理每天下班前轮流确认大家的当天工作成果。

所有的重要沟通都要书面确认。

有问题。尽量集中在早上会议的时候讲。如果问题严重，另外开会讲。

关键是，这些事情每天都要准时或者及时做。形成习惯。

Scrum模式。
两周一次计划会，一次review会，各半天，用来计划这两周做什么以及做的怎么样。计划会同时要求全员分析任务，尽量分解任务到最小单位，例如一天可完成，但不安排人员，除非别人都不会。
每日例会，总结每人在做的任务状态，并让完成当前手头任务的人挑选可以做又想做的任务。
初期大家会很痛苦，只有大牛能头头是道的说，瞎说也没人能反驳，任务分解也是他们定，但是因为任务是全员自由挑选完成，并不是大牛从头干到尾，经过多轮迭代后，大牛说的对不对大家都有数了，再经过多轮迭代大家基本上对每一块都熟悉了。这时候就是大牛走人，进来个没经验的人，也很快被带节奏。

千万别用传统模式，大牛一走或者根本是伪大牛，大家一起死。

蚂蚁金服国际事业群技术风险部研究员南门，聊聊Code Velocity，希望能在团队效率问题方面，为你带来一些启发。

什么是代码速度（Code Velocity）？
Code Velocity的定义是：一段代码变更，从git里的commit time，到在生产环境里运行，中间经过了多少时间。换句话说，代码从写完开始，多快能到达生产环境。
举个例子，C公司的一个团队，他们今天的code velocity一般在是2-4周左右：
他们的一个典型的迭代周期是4周?1?：第一周系分测分，第二、三周coding、testing、修bug，第三周末或第四周初合并回master、部署集成测试环境、跑回归、上预发、上生产环境。在这样的迭代节奏和“分支开发、主干发布” ?2? 的模式里，从commit time到进生产环境，平均是2周左右。
他们还有一些比较长周期的项目。例如，有几个项目是四月中上旬拉的分支，一直到五月下旬才合回master，六月初发布上线。从四月上旬到五月下旬，这几个项目分支里的代码没有合回master过。这几个项目的code velocity就比较长，平均是4周左右。
为什么要度量和提高Code Velocity？
Code velocity体现的是一个研发团队快速响应业务需求的能力。
以上文C公司这个团队今天的快速响应、交付的能力水平，在两周一次发布窗口的节奏里，大部分时候可能已经够了，但一旦遇到各种意外，就捉襟见肘了，例如：临时封网，需求变更，项目因故延期等。
快速响应、快速交付的能力要有一定的“储备”，这就好像足球运动员要有体能储备：要想赢下加时赛，就要有踢两个加时赛的体能。研发团队要能在两周一次发布窗口的节奏里游刃有余，就要有一周一发甚至一周两发的能力。况且，可以预见在不远的将来，两周一次的发布窗口也嫌太久了，业务压力会倒逼一周一发成为常态。那时候，这个团队就要有“天天发”的能力，才能游刃有余。
研发团队的code velocity和他们拿到的业务结果之间的关系，就像饭店上菜时间长短和生意火不火之间的关系一样，两者是相关的，但不是强因果关系：
有些饭店上菜挺快的，但生意不火。不能就因此说“上菜时间长短”不重要。
有些饭店，上菜很慢，但生意也还是很火。也不能因此就说“上菜时间长短”不重要。
一家饭店要火，还要看地段、装潢、菜单、原料、厨子、服务员、宣传等。
除了快速响应业务需求以外，提高code velocity还能帮助开发和测试同学降低项目并发、减少上下文切换、提高幸福感。在两周一次发布窗口的节奏下，很多时候研发同学把一个需求写完、测完，要等其他需求，等集成环境测试，再回来搞一波，然后到了生产环境发布再回来搞一波。事情是不连续的，开发测试其实是被打断的。Code velocity提高了以后，开发测试有连续性，写完了测完了的代码就发走了，研发同学也不用身上同时背着一串项目了。

为什么Code Velocity快不起来?
仔细想想，一段代码从git commit到生产环境，这个过程中时间大部分是花在等待上的：等着和其他代码一起发布上线。之所以会要把很多代码合到一起，每两周发一次，是出于cost vs. benefit的权衡：
每次常规发布，不管payload（即发布的代码量）有多大，有些固定工作是逃不掉的：
首先，由于采取了“分支开发、主干发布”的模式，代码要从各个项目分支和迭代分支合并回master，要解决冲突，确保合并时没有漏代码。
然后，要对master里的代码跑一次全量的回归：准备环境、部署代码和配置、执行回归测试用例、分析结果。这个过程做一遍，短则半天一天，长则两三天甚至更长。如果发现问题，需要修bug，这个过程还要再重复。
与此同时，有些团队还要写发布计划，详细列出发布的步骤：要改哪些配置，各个系统的发布顺序是什么，回滚的步骤是什么，等等。发布计；划写好了还要评审。
最后，要走一遍发布流程：先上预发，上去以后QA要做预发验证；上生产环境，按照发布计划一步步做，蓝绿切流的过程中要让各个系统的owner确认OK，再继续蓝绿切流。整个发布过程需要很多人的协同。
在某些项目中，把代码拆成小块分多次发布会增加开发的难度和工作量。
例如，X系统的API增加了一个新参数，要求Y系统在调用这个API的时候必须要传这个参数。如果两个系统上的代码变更一起发（而且是蓝绿发布），就比较简单。但如果把这个工作拆解成小块，开发工作就变复杂了：X的API新增的这个参数必须先做成optional的，等Y那边的代码改好发上线了以后，再把X的这个新参数改成required。
另外，在有些实际项目中，实际情况比上面举的这个例子更复杂，并不是那么容易一眼就能看出来怎么拆解的。
如何提高Code Velocity？
要提高code velocity，就要对上面提到的这些原因对症下药，提升四个关键能力：
能频繁地把代码合回master
非常强大的跑回归的能力
一键部署乃至无人值守发布的能力
把大项目拆成小项目做的能力
提高code velocity，要实现质的飞跃，第一个能力“能频繁的把代码合回master”是关键抓手。把这个能力建设好了，提升code velocity的四个关键能力中的三个就具备了，因为“能频繁地把代码合回master”有三个前置条件：
实行了代码门禁
有非常强大的跑回归的能力（即上面四个关键能力的第二个）
把大项目拆成小项目做的能力（即上面四个关键能力的第四个）
代码门禁（Gated Checkin）
代码门禁能够确保每一个进入主分支?3?的commit都达到了一定的质量标准，例如：编译必须通过，单元测试和接口测试必须通过，新代码的覆盖率不能低于某个水平，静态代码扫描必须通过，等等。其实今天很多公司已经有post-checkin的CI在跑这些检查项了。代码门禁看似平淡无奇，无非就是把这些检查项从post-checkin挪到了pre-checkin。但别小看这一挪，它的效果，不亚于把“当月业绩决定本月提成”改成“当月业绩决定下月提成”的效果。
代码门禁是很典型的“测试左移”的做法，和我们对质量的基本规律的认知也是一致的：问题发现得越早，修复起来代价越小。实施了代码门禁后，能确保主分支常年处于良好状态。代码门禁实施起来也很容易，很多开源和商用的CI/CD平台都支持，例如GitLab+Jenkins。
只要做得好，代码门禁是不会降低工程师的日常效率的。“做得好”的标准是：
执行时间：一般能接受的是10-20分钟，95%的情况下不应超过30分钟，否则体感就不好了。
False negative率：也就是说，代码门禁如果失败，有多少比例是因为代码（包括测试用例代码）本身的确有问题，有多少是因为代码门禁的infrastructure的问题（比如，底层机器的资源和稳定性）。一般来说，要把false negative率控制在5%以下。False negative率如果达到20%-30%（也就是说，五次失败里面就有一次失败是跟提交的代码变更无关的），团队里面就会开始怨声载道了。
非常强大的跑回归的能力
有了强大的回归能力，就能在代码频繁的合并回master的情况下，仍然保持master分支处于可发布状态或者接近可发布的状态，有了强大的回归能力，我们甚至可以把一小部分的回归放到代码门禁里面去跑，那将会进一步有助于保持master分支处于可发布状态。
回归能力的强大体现在以下几方面：
无人值守：准备环境、部署代码和配置、执行测试、拿回结果，整个过程都必须没有任何人的参与。
频次：跑回归不嫌多，最理想的是每次CI都跑回归，那样发现问题更早、定位问题更精确。
覆盖率：主要是业务覆盖率???。
稳定性：很高的通过率，很低的噪音率，结果非常repeatable。
执行时间：也许6小时和4小时看上去没有什么大差别，其实是有本质区别的。如果回归跑一遍要6小时，那么“改代码-跑回归-看结果”这个过程一天只能干两轮；但如果回归一遍只要4小时，那么这个过程一天就能干三轮。如果能再缩短到2小时，一天就能干六七轮。
这几方面的回归能力相互之间是相辅相成的，能够形成正循环，产生“飞轮效应”：
回归的运行，只有真正做到了无人值守，才有可能长期高频次运行。
高频次的运行，可以充分暴露各种稳定性问题，提高回归的稳定性。
缩短执行时间，一方面可以缩短“反馈弧”，加速各种稳定性问题的修复，另一方面可以提高测试环境的“周转率”，在不增加硬件成本的前提下实现更高频次的回归。
提高了稳定性，可以缩短用于分析回归结果的时间。如果一个有5,000个用例的回归用例集只有90%的通过率，那每次跑完回归有500个失败的用例需要分析
? ??。但如果通过率有99%，那就只有50个用例需要分析了。
强大的回归能力的背后需要的支撑能力是：
优质的测试环境：要在预算允许的范围内，确保测试环境的稳定和资源充沛，这样才能支撑起回归的稳定性和高频次执行。
配置代码化（configuration-as-code）的能力。今天常见的web-based centralized配置变更管理模式不足以支持高频词、高并发的回归运行模式。实现了配置代码化，才能实现快速的环境部署，以及在不同的环境之间用不同的配置跑回归。配置代码化并不是简单地把配置写在config文件里面，和代码一起打包发布。配置代码化是对这种config文件做法的否定之否定：配置可以在git里面修改；配置也可以在配置管理系统里面直接修改，变更会回沉到git里面。部署的时候，部署工具会把git里面的配置值以增量的方式推到配置管理系统里面。
把大项目拆成小项目做的能力
如前所述，把代码拆成小块分多次发布，的确是会增加开发的工作量的。有不少开发同学不理解为什么要这样做。增加了这些工作量，能让我们的研发模式更加敏捷。这个代价是值得付出的，这些额外的时间是值得花的。
大项目拆成小项目做的一些常见套路包括：
分两部走：先向下兼容，再去掉兼容性。这就是前文举的那个例子：X系统的API增加了一个新参数，要求Y系统在调用这个API的时候必须要传这个参数。拆成小项目的拆解方法是：首先，X的API新增的这个参数做成optional的，把X发布上线。然后等Y那边的代码改好发上线了以后，再把X的这个新参数改成required，再发布一次X。或者，也可以用一个feature flag来控制这个新参数是否required。
Feature flag：有了feature flag，新功能的代码写了一半也没关系，可以把feature flag关掉，就算代码发上线了也不会被执行到。有时候，有些新功能所需要的代码变更是改动在老代码里面的。这样的代码变更无法用feature flag来屏蔽。但这也没关系，因为我们有强大的回归能力，能尽我们所能确信这些的代码变更至少不会break老功能、不会在发上线后造成故障。Anyway, 哪怕不是为了把大项目拆成小项目，feature flag也是需要的。Feature flag、白名单等都是很常见的continuous delivery手段。
Capability probing：很多新功能涉及整条链路上各个系统的改造。现在往往上游系统的发布依赖于下游系统的发布。解耦这种依赖关系的一种方法是让每个系统都通过一个统一的API接口来暴露自己当前的能力。这样，上游系统可以判断下游系统当前是否支持某个新功能所需要的能力Foo（例如，某种支付渠道），根据结果走不同的code path。
按域独立发布也是一种很成熟的拆分的方法。按域独立发布，实现域和域之间的解耦，能减少每次发布的系统的数量，降低发布风险，增加发布的灵活度。
大项目拆成小项目，还需要有比较强的需求拆分的能力：能够把一个全链路级别的需求文档拆分成域级别、系统级别的需求，这样每个域、每个系统可以“分而治之”。

Code Velocity和质量、线上稳定性的关系
从上面的分析可以看出来，提高code velocity并不是以牺牲质量为代价的。上面这些提高code velocity的手段，并没有cut corner，并没有降低质量标准，并没有比今天少执行任何测试。即便是频繁的把代码合回master，即便是把大项目拆成小项目做，该运行的各种验证和测试还是继续运行。而且，为了要提高code velocity，实行了代码门禁，建设了强大的跑回归的能力，反而是对质量有提高作用的。
提高code velocity也并不会降低线上稳定性。把大项目拆成小项目做、更加频繁的发布小块代码，能够降低单次发布的风险；发布中如果出了问题，因为payload小，排查和回滚也更方便。另外，在投入资源提高code velocity的同时，我们不会降低对故障发现能力、止血能力、应急能力、监控核对等能力的投入。提高code velocity不会导致线上技术风险防控体系变弱。
将来
如果一个团队的“能频繁的把代码合回master”的能力做得足够好了，就可以完全抛弃项目分支和迭代分支，每一个commit都直接checkin进master，而且master分支每天都有若干个可以发布的版本???，每个版本都可以用一个不同的release分支来保存。这就是所谓的“主干开发、分支发布”（Trunk-based Development）模式了。
到那时候，就有做到“天天发”的能力了。那时候，代码从commit到上线可能平均只需要两三天时间。那时候，因为有了“天天发”的能力，甚至连紧急发布都不怎么需要了。
如果你希望加入蚂蚁金服国际事业群，可以随时与我们直接联系。Java开发、测试开发、SRE工程师和工具开发等岗位虚位以待，有兴趣的童鞋可发简历至：
intl_hire_account@service.alipay.com
【注】
1.一般会有两个为期四周的迭代并行，每个迭代有自己的目标发布窗口。发布窗口一般是每两周一次。
2.“分支开发、主干发布”的开发模式来自于A successful Git branching model。但这种模式在实践中是有不少问题的（参见A succesful Git branching model considered harmful）。更好的模式是“主干开发、分支发布”（aka. Trunk-based Development)
3.主分支可以是master，也可以是项目分支或者迭代分支。
4.单元测试和接口测试看代码覆盖率，回归测试看业务覆盖率。这在行业内的一部分开发和测试之间已经形成共识了。
5.当然，我们可以用技术的手段使得分析500个失败的用例变得更容易。但这并不应该成为我们不去提高通过率的理由。
6.版本：对于“大库模式”(monolithic repo)来说就是一个commit，对于“小库模式”来说就是每个repo的一个commit构成的一个“截面”。

如何提高一个研发团队的“代码速度”？-博客-云栖社区-阿里云

更多技术干货敬请关注云栖社区知乎机构号：阿里云云栖社区 - 知乎

提升效率最简单的方法就是找到拖慢进度的人，让他做最简单的工作，防止效率过低。

当然还有一些特殊的方法，例如让男成员女装（

多给钱就行了，效率自然就上来了。你想让马儿跑得快，还想马儿吃的少，这是不可能的。兰博基是不可能9.9元包邮的，就算你去拼多多搜，他们也不会这么卖的。你钱没到位，效率自然上不去。同样的岗位，同样的工作，同行拿着10k，他只拿3k，换做你，你会有效率吗？此时此刻不是反省自己为什么别人能拿10k，而自己却只能拿3k，而是应该反省同样的工作为什么别人的公司能给10k，而我的公司才给我3k。而这个信息差，正是为什么公司禁止谈论薪酬的原因，因为公司不想让你知道我在亏待你。

蚂蚁金服国际事业群技术风险部研究员南门，聊聊Code Velocity，希望能在团队效率问题方面，为你带来一些启发。
什么是代码速度（Code Velocity）？
Code Velocity的定义是：一段代码变更，从git里的commit time，到在生产环境里运行，中间经过了多少时间。换句话说，代码从写完开始，多快能到达生产环境。
举个例子，C公司的一个团队，他们今天的code velocity一般在是2-4周左右：
他们的一个典型的迭代周期是4周?1?：第一周系分测分，第二、三周coding、testing、修bug，第三周末或第四周初合并回master、部署集成测试环境、跑回归、上预发、上生产环境。在这样的迭代节奏和“分支开发、主干发布” ?2? 的模式里，从commit time到进生产环境，平均是2周左右。
他们还有一些比较长周期的项目。例如，有几个项目是四月中上旬拉的分支，一直到五月下旬才合回master，六月初发布上线。从四月上旬到五月下旬，这几个项目分支里的代码没有合回master过。这几个项目的code velocity就比较长，平均是4周左右。
为什么要度量和提高Code Velocity？
Code velocity体现的是一个研发团队快速响应业务需求的能力。
以上文C公司这个团队今天的快速响应、交付的能力水平，在两周一次发布窗口的节奏里，大部分时候可能已经够了，但一旦遇到各种意外，就捉襟见肘了，例如：临时封网，需求变更，项目因故延期等。
快速响应、快速交付的能力要有一定的“储备”，这就好像足球运动员要有体能储备：要想赢下加时赛，就要有踢两个加时赛的体能。研发团队要能在两周一次发布窗口的节奏里游刃有余，就要有一周一发甚至一周两发的能力。况且，可以预见在不远的将来，两周一次的发布窗口也嫌太久了，业务压力会倒逼一周一发成为常态。那时候，这个团队就要有“天天发”的能力，才能游刃有余。
研发团队的code velocity和他们拿到的业务结果之间的关系，就像饭店上菜时间长短和生意火不火之间的关系一样，两者是相关的，但不是强因果关系：
有些饭店上菜挺快的，但生意不火。不能就因此说“上菜时间长短”不重要。
有些饭店，上菜很慢，但生意也还是很火。也不能因此就说“上菜时间长短”不重要。
一家饭店要火，还要看地段、装潢、菜单、原料、厨子、服务员、宣传等。
除了快速响应业务需求以外，提高code velocity还能帮助开发和测试同学降低项目并发、减少上下文切换、提高幸福感。在两周一次发布窗口的节奏下，很多时候研发同学把一个需求写完、测完，要等其他需求，等集成环境测试，再回来搞一波，然后到了生产环境发布再回来搞一波。事情是不连续的，开发测试其实是被打断的。Code velocity提高了以后，开发测试有连续性，写完了测完了的代码就发走了，研发同学也不用身上同时背着一串项目了。

为什么Code Velocity快不起来?
仔细想想，一段代码从git commit到生产环境，这个过程中时间大部分是花在等待上的：等着和其他代码一起发布上线。之所以会要把很多代码合到一起，每两周发一次，是出于cost vs. benefit的权衡：
每次常规发布，不管payload（即发布的代码量）有多大，有些固定工作是逃不掉的：
首先，由于采取了“分支开发、主干发布”的模式，代码要从各个项目分支和迭代分支合并回master，要解决冲突，确保合并时没有漏代码。
然后，要对master里的代码跑一次全量的回归：准备环境、部署代码和配置、执行回归测试用例、分析结果。这个过程做一遍，短则半天一天，长则两三天甚至更长。如果发现问题，需要修bug，这个过程还要再重复。
与此同时，有些团队还要写发布计划，详细列出发布的步骤：要改哪些配置，各个系统的发布顺序是什么，回滚的步骤是什么，等等。发布计；划写好了还要评审。
最后，要走一遍发布流程：先上预发，上去以后QA要做预发验证；上生产环境，按照发布计划一步步做，蓝绿切流的过程中要让各个系统的owner确认OK，再继续蓝绿切流。整个发布过程需要很多人的协同。
在某些项目中，把代码拆成小块分多次发布会增加开发的难度和工作量。
例如，X系统的API增加了一个新参数，要求Y系统在调用这个API的时候必须要传这个参数。如果两个系统上的代码变更一起发（而且是蓝绿发布），就比较简单。但如果把这个工作拆解成小块，开发工作就变复杂了：X的API新增的这个参数必须先做成optional的，等Y那边的代码改好发上线了以后，再把X的这个新参数改成required。
另外，在有些实际项目中，实际情况比上面举的这个例子更复杂，并不是那么容易一眼就能看出来怎么拆解的。
如何提高Code Velocity？
要提高code velocity，就要对上面提到的这些原因对症下药，提升四个关键能力：
能频繁地把代码合回master
非常强大的跑回归的能力
一键部署乃至无人值守发布的能力
把大项目拆成小项目做的能力
提高code velocity，要实现质的飞跃，第一个能力“能频繁的把代码合回master”是关键抓手。把这个能力建设好了，提升code velocity的四个关键能力中的三个就具备了，因为“能频繁地把代码合回master”有三个前置条件：
实行了代码门禁
有非常强大的跑回归的能力（即上面四个关键能力的第二个）
把大项目拆成小项目做的能力（即上面四个关键能力的第四个）
代码门禁（Gated Checkin）
代码门禁能够确保每一个进入主分支?3?的commit都达到了一定的质量标准，例如：编译必须通过，单元测试和接口测试必须通过，新代码的覆盖率不能低于某个水平，静态代码扫描必须通过，等等。其实今天很多公司已经有post-checkin的CI在跑这些检查项了。代码门禁看似平淡无奇，无非就是把这些检查项从post-checkin挪到了pre-checkin。但别小看这一挪，它的效果，不亚于把“当月业绩决定本月提成”改成“当月业绩决定下月提成”的效果。
代码门禁是很典型的“测试左移”的做法，和我们对质量的基本规律的认知也是一致的：问题发现得越早，修复起来代价越小。实施了代码门禁后，能确保主分支常年处于良好状态。代码门禁实施起来也很容易，很多开源和商用的CI/CD平台都支持，例如GitLab+Jenkins。
只要做得好，代码门禁是不会降低工程师的日常效率的。“做得好”的标准是：
执行时间：一般能接受的是10-20分钟，95%的情况下不应超过30分钟，否则体感就不好了。
False negative率：也就是说，代码门禁如果失败，有多少比例是因为代码（包括测试用例代码）本身的确有问题，有多少是因为代码门禁的infrastructure的问题（比如，底层机器的资源和稳定性）。一般来说，要把false negative率控制在5%以下。False negative率如果达到20%-30%（也就是说，五次失败里面就有一次失败是跟提交的代码变更无关的），团队里面就会开始怨声载道了。
非常强大的跑回归的能力
有了强大的回归能力，就能在代码频繁的合并回master的情况下，仍然保持master分支处于可发布状态或者接近可发布的状态，有了强大的回归能力，我们甚至可以把一小部分的回归放到代码门禁里面去跑，那将会进一步有助于保持master分支处于可发布状态。
回归能力的强大体现在以下几方面：
无人值守：准备环境、部署代码和配置、执行测试、拿回结果，整个过程都必须没有任何人的参与。
频次：跑回归不嫌多，最理想的是每次CI都跑回归，那样发现问题更早、定位问题更精确。
覆盖率：主要是业务覆盖率???。
稳定性：很高的通过率，很低的噪音率，结果非常repeatable。
执行时间：也许6小时和4小时看上去没有什么大差别，其实是有本质区别的。如果回归跑一遍要6小时，那么“改代码-跑回归-看结果”这个过程一天只能干两轮；但如果回归一遍只要4小时，那么这个过程一天就能干三轮。如果能再缩短到2小时，一天就能干六七轮。
这几方面的回归能力相互之间是相辅相成的，能够形成正循环，产生“飞轮效应”：
回归的运行，只有真正做到了无人值守，才有可能长期高频次运行。
高频次的运行，可以充分暴露各种稳定性问题，提高回归的稳定性。
缩短执行时间，一方面可以缩短“反馈弧”，加速各种稳定性问题的修复，另一方面可以提高测试环境的“周转率”，在不增加硬件成本的前提下实现更高频次的回归。
提高了稳定性，可以缩短用于分析回归结果的时间。如果一个有5,000个用例的回归用例集只有90%的通过率，那每次跑完回归有500个失败的用例需要分析
? ??。但如果通过率有99%，那就只有50个用例需要分析了。
强大的回归能力的背后需要的支撑能力是：
优质的测试环境：要在预算允许的范围内，确保测试环境的稳定和资源充沛，这样才能支撑起回归的稳定性和高频次执行。
配置代码化（configuration-as-code）的能力。今天常见的web-based centralized配置变更管理模式不足以支持高频词、高并发的回归运行模式。实现了配置代码化，才能实现快速的环境部署，以及在不同的环境之间用不同的配置跑回归。配置代码化并不是简单地把配置写在config文件里面，和代码一起打包发布。配置代码化是对这种config文件做法的否定之否定：配置可以在git里面修改；配置也可以在配置管理系统里面直接修改，变更会回沉到git里面。部署的时候，部署工具会把git里面的配置值以增量的方式推到配置管理系统里面。
把大项目拆成小项目做的能力
如前所述，把代码拆成小块分多次发布，的确是会增加开发的工作量的。有不少开发同学不理解为什么要这样做。增加了这些工作量，能让我们的研发模式更加敏捷。这个代价是值得付出的，这些额外的时间是值得花的。
大项目拆成小项目做的一些常见套路包括：
分两部走：先向下兼容，再去掉兼容性。这就是前文举的那个例子：X系统的API增加了一个新参数，要求Y系统在调用这个API的时候必须要传这个参数。拆成小项目的拆解方法是：首先，X的API新增的这个参数做成optional的，把X发布上线。然后等Y那边的代码改好发上线了以后，再把X的这个新参数改成required，再发布一次X。或者，也可以用一个feature flag来控制这个新参数是否required。
Feature flag：有了feature flag，新功能的代码写了一半也没关系，可以把feature flag关掉，就算代码发上线了也不会被执行到。有时候，有些新功能所需要的代码变更是改动在老代码里面的。这样的代码变更无法用feature flag来屏蔽。但这也没关系，因为我们有强大的回归能力，能尽我们所能确信这些的代码变更至少不会break老功能、不会在发上线后造成故障。Anyway, 哪怕不是为了把大项目拆成小项目，feature flag也是需要的。Feature flag、白名单等都是很常见的continuous delivery手段。
Capability probing：很多新功能涉及整条链路上各个系统的改造。现在往往上游系统的发布依赖于下游系统的发布。解耦这种依赖关系的一种方法是让每个系统都通过一个统一的API接口来暴露自己当前的能力。这样，上游系统可以判断下游系统当前是否支持某个新功能所需要的能力Foo（例如，某种支付渠道），根据结果走不同的code path。
按域独立发布也是一种很成熟的拆分的方法。按域独立发布，实现域和域之间的解耦，能减少每次发布的系统的数量，降低发布风险，增加发布的灵活度。
大项目拆成小项目，还需要有比较强的需求拆分的能力：能够把一个全链路级别的需求文档拆分成域级别、系统级别的需求，这样每个域、每个系统可以“分而治之”。

Code Velocity和质量、线上稳定性的关系
从上面的分析可以看出来，提高code velocity并不是以牺牲质量为代价的。上面这些提高code velocity的手段，并没有cut corner，并没有降低质量标准，并没有比今天少执行任何测试。即便是频繁的把代码合回master，即便是把大项目拆成小项目做，该运行的各种验证和测试还是继续运行。而且，为了要提高code velocity，实行了代码门禁，建设了强大的跑回归的能力，反而是对质量有提高作用的。
提高code velocity也并不会降低线上稳定性。把大项目拆成小项目做、更加频繁的发布小块代码，能够降低单次发布的风险；发布中如果出了问题，因为payload小，排查和回滚也更方便。另外，在投入资源提高code velocity的同时，我们不会降低对故障发现能力、止血能力、应急能力、监控核对等能力的投入。提高code velocity不会导致线上技术风险防控体系变弱。
将来
如果一个团队的“能频繁的把代码合回master”的能力做得足够好了，就可以完全抛弃项目分支和迭代分支，每一个commit都直接checkin进master，而且master分支每天都有若干个可以发布的版本???，每个版本都可以用一个不同的release分支来保存。这就是所谓的“主干开发、分支发布”（Trunk-based Development）模式了。
到那时候，就有做到“天天发”的能力了。那时候，代码从commit到上线可能平均只需要两三天时间。那时候，因为有了“天天发”的能力，甚至连紧急发布都不怎么需要了。
如果你希望加入蚂蚁金服国际事业群，可以随时与我们直接联系。Java开发、测试开发、SRE工程师和工具开发等岗位虚位以待，有兴趣的童鞋可发简历至：
intl_hire_account@service.alipay.com
【注】
1.一般会有两个为期四周的迭代并行，每个迭代有自己的目标发布窗口。发布窗口一般是每两周一次。
2.“分支开发、主干发布”的开发模式来自于A successful Git branching model。但这种模式在实践中是有不少问题的（参见A succesful Git branching model considered harmful）。更好的模式是“主干开发、分支发布”（aka. Trunk-based Development)
3.主分支可以是master，也可以是项目分支或者迭代分支。
4.单元测试和接口测试看代码覆盖率，回归测试看业务覆盖率。这在行业内的一部分开发和测试之间已经形成共识了。
5.当然，我们可以用技术的手段使得分析500个失败的用例变得更容易。但这并不应该成为我们不去提高通过率的理由。
6.版本：对于“大库模式”(monolithic repo)来说就是一个commit，对于“小库模式”来说就是每个repo的一个commit构成的一个“截面”。

如何提高一个研发团队的“代码速度”？-博客-云栖社区-阿里云

更多技术干货敬请关注云栖小二知乎号：云栖小二 - 知乎

四五个人的团队比较适合用敏捷中的scrum模式。

首先说一下scrum的角色：scrum master（敏捷教练） product owner（产品负责人） dev team（开发团队）

scrum master主要是为了保证团队执行scrum准确性，一般会外聘顾问（也可以由团队内比较有经验的资深工程师担任）；product owner 一般由产品经理或客户担任，主要是确定产品各项需求；dev team属于泛称一般包括前端、服务端、设计师等；

标准的Scrum运行流程是，Product Owner基于Vision，创建多个Product Backblog，即为达成Vision所要完成的各种功能需求，然后Product Backblog会被拆分成一个个Sprint，真正的Scrum是在一个个Sprint周期之内，不断地完善产品。

详细可参考文章 Worktile 首席架构师详解：如何让敏捷更好地落地？

Worktile提供最好用的scrum落地工具：

需求、缺陷管理：

迭代规划：

注册Worktile体验超好用的scrum工具，提高你团队的开发效率~