作者 | 九歌 网易智企服务端开发
敏捷开发的一个重要目标是建立持续价值交付的能力。这种能力最终必须服务于业务的创新，促进业务的成功。
面临的问题
在互联网行业，业务的发展通常日新月异，并且伴随着不断的试错。这对研发团队的效率和灵活性有着非常高的要求，在传统的迭代模式中面临很多问题，如：
- 需求相互耦合，上线交叉感染。一个版本上线出现问题时，由于上线的内容很多，定位问题就会变得更困难，不能确定是哪个需求的变更引起的问题。
- 临时调整需求，牵一发而动全身。大家应该都碰到过版本上线前一天了，产品说有个很重要的需求必须得加急上，不上不行。这种临时的需求调整，对版本的交付影响是很大的。
- 因为一个不重要的需求，延期整个版本的上线。上线当天，可能发现有一个不是很重要的需求有问题，整个版本都必须等这个问题解决，有时候直接回导致版本的延期，或者产生很多临时方案。
- 整个团队上线发布到凌晨。由于一个版本交付的内容太多了，准备工作很长，影响的范围也很大，通常会安排在晚上做发布，而发布过程中只要遇到一两个问题，通常发布就会搞到凌晨甚至后半夜。
- 有checklist依然不能避免遗漏。同样也是当版本越大，内容越多时，就越容易遗漏。
- 不同价值的需求，相互影响。一个版本中通常会包含各种优先级的需求，而不同优先级的需求同时开发交付，就一定会存在相互影响的问题。
- 产研团队交付效率上不去。所有问题最后都导致了交付效率上不去，交付质量上不去。
相信大家也有碰到过和我们类似的这些问题。这其中有很多问题，都是可以通过敏捷交付来解决。
敏捷VS迭代
那什么是敏捷呢？关于敏捷模式和迭代模式的理论知识，相信大家都已经有些了解，这里就不细说其中的理论知识了。
迭代模式中每个迭代的需求、时间、资源是确定的，三个因素相互制约。最大的优势在于可预测性，流程简单，有固定的时间点。但同时带来的问题是缺乏灵活性，进入版本后，调整需求或时间的代价会非常大，并且版本越大时带来的风险和不确定性越大。大多数研发团队采用的都是迭代模型。敏捷模式中需求变成了变量，在固定时间和资源的情况下，灵活调整需求，从而获得最大交付价值。
如图所示，迭代模式中整个团队按步骤一步步执行，最终全量交付。而在敏捷模式中，在固定的时间内（迭代周期）将一个版本拆分为一个个可以独立交付上线的需求，优先交付高优先级（高价值）的需求，并由一个个独立的小团队负责交付。最大的优势是非常灵活，可以根据实际情况随时调整需求，同时由于交付单元限定在最小范围内，使得上线发布的影响范围最小，风险可控，也可以提高交付质量。目标是在尽可能短的时间内交付尽可能高的价值。
先试点再推广
进行敏捷交付的转型前，我们进行了很多调研和沟通工作，学习公司内部外部已经实现敏捷交付的团队的经验。然后制定了初步的方案，并在小范围内进行试点，试点过程中不断调整方案，调试工具，当试点方案执行顺利以后再推广到整个团队。互客刚开始的时候，就是选择其中一些比较小的简单的需求来进行试点的。在转型的过程中，我们总结出四个重要的要素：系统、规范、工具、组织。
需要准备什么
系统架构
首先想要进行敏捷交付，需要有能适应敏捷模型的研发环境，包括系统的合理拆分、边界清晰的业务、可以进行独立开发测试的环境隔离能力。要有平滑发布的能力，任何时间发布任何服务不应该因为发布动作本身引起问题。还需要有完善的监控可以实时反馈系统的异常，特别在实践初期总会有意外情况，研发应该能第一时间获知系统发生异常。如果研发环境本身还是非常耦合，牵一发而动全身的情况，需求的负责人都不知道影响范围在哪里。那就很去难实现敏捷的交付方式。如果没有准确的异常监控能力，会有很大的风险。因此合理的架构是敏捷的基础。
流程规范
然后是流程规范。从需求拆分、时间规划、代码分支管理、技术方案评审、测试报告、发布审核、自动化回归。团队中的每个人必须严格按照流程进行，因为越灵活的方案，背后意味着更多的不可控。所以在转型初期，严格执行流程是非常必要的。
敏捷交付的前提是需求必须是合理拆分的，而我们对合理的定义就是，可以独立交付上线的称为一个需求。如果两个需求之间是相互耦合的，少了其中一个，另一个需求都不能独立交付。那么这样的需求就是不合理的，应该合并为一个需求。
这个是互客某一个版本的需求列表，以及分工，时间规划等等。可以看到大部分是正常需求，黄色部分是比较大的不跟版本的需求，红色和划线的是延期或取消的需求。需求的交付变成了一个灵活的过程。
这个是我们的需求分支管理，非常简单，每个需求开始时从线上分支拉一个独立的需求分支，当需求环境提测通过后，合并到灰度分支，灰度验证后，再合并到线上分支发布上线。其中比较重要的是一定要经常从master合最新代码到自己的feature分支。
实施工具
工具是流程的承载，没有合适的工具是很难把流程执行起来的。网易内部的ovemrind效能平台可以很好的支持我们的流程，配合协作文档，测试用例管理平台和测试自动化平台，基本上可以比较好的支持整个流程了。下面的截图是某一天下午的发布单，可以看到一下午就有多次发布。
团队组织
最后我们需要根据敏捷交付的逻辑去适当的调整团队的组织形式，原先的团队组织形式，边界在于职能，所有的需求在不同的职能间流转，最后由版本负责人负责交付上线。这种模式下，各职能团队的人只能接触到自己工作范围内的东西，所以对需求的理解程度高低不等，当产生需求变更时，也更容易产生抵触情绪，当出现调整或返工时也会付出很大的代价。
右边是为了适应敏捷交付调整的组织形式，每个需求都会有一个临时的虚拟小组来负责，需求只在这个小组内部流转，最后由需求负责人交付上线。在这种模式下，团队组织的边界不再是职能，而在于需求。虚拟小组的成员需要关心一个需求的全生命周期，能更好的理解需求。当有需求变更时，影响范围也相对小得多。并且通常会在方案设计过程中研发和产品一起讨论调整需求。
不管是环境、流程还是工具，最后一定都是需要人去执行的，也就是团队中的每个成员。因此团队成员的思维转变是敏捷转型中的重点，在工作进行前，首先应该在团队内进行足够的沟通，让每个人理解转型的价值和意义，让每个人都愿意为之努力。当团队达成一致的目标时，离成功就已经不远了。
得到了什么
这是互客过去几个版本的需求吞吐量，缺陷密度，不管质量还是吞吐量都是有比较明显的提升的。
当然，我觉得更重要的是，我们得到了持续快速的交付价值的能力，得到了沟通顺畅，相互信任的团队。另外从我个人做需求感觉来说，在敏捷模式下，我对需求的理解会更好，工作会变的更聚焦，会自然而然的关注需求从评审到上线的整个过程，会及时的关注自己的需求的情况等等。比如有一个客户的成单就是因为我们上了一个数据看板的需求，需求的价值会直观的反馈到了这个需求的负责团队，这可以让产研统一目标，相互促进，产生良性循环。
经验总结
在网易互客实践敏捷交付的过程中我们踩了许多坑，并总结了一些经验，希望可以帮助大家少走一点点弯路。
- 不要过分追求模式，我们的目标是质量和效率，而不是模式
- 沟通，充分的沟通，要达成理解一致
- 转型初期流程要严格执行
- 需求一定要有负责人
- 需求交付尽量不要合并操作，容易相互影响出错
- 对质量负责的不是QA，是每个需求的小组
- 系统可观测性很重要，研发团队需要掌握系统的实时状态
最后期望所有的研发团队都能让有限的资源产生最大的价值。
