Worktile带你学敏捷：网易DevOps平台的敏捷之旅
概述：本文来自网易敏捷教练于旭东的分享： 网易DevOps平台从0到1的敏捷之旅 。
分享主要从 产品管理、团队组织、过程管理、工程实践 四方面讲述了网易DevOps的产品研发过程。他们在敏捷实施过程中遇到了什么问题，又是如何解决的呢？让我们一起来看。
开篇
8月15日，在Worktile主办的Tech Talks上海站活动中，网易敏捷教练于旭东作为主讲嘉宾之一，讲述了网易DevOps平台从0到1的敏捷之旅，我们做了一些编辑整理，希望大家一起分享。
以下内容基于现场演讲速记稿整理，经讲师审阅后发布。
“产品的研发周期，一般分成两部分，一部分叫 产品的探索 ，一部分叫 产品的交付 。探索是更多关注客户需求，交付关注的是采用什么方法组建什么团队，采用什么样的工程实践才能交付产品满足客户需求。以网易DevOps平台的从0到1产品研发过程为例， 这次分享将会从产品管理、团队组织、过程管理、工程实践这四方面展开。”
“首先说一下背景，我们的产品是一个内部toB产品的，刚开始组建的时候是10个开发，包括7个后端开发，3个前端开发，前后端是分离的。团队不了解敏捷，Scrum和 LeSS。”
产品管理
1.Output VS Outcome VS Impact
假如Woktile平台是我们的output，我们应该关心的不只是这个平台可以输出什么样的功能，更多是能不能帮助客户解决问题，能否对客户产生一些影响。以此为出发点，用最小的产出达成最大的结果和影响，也就是用最小的代价实现最大的价值。
2.Lean Startup
“如何衡量我们产品的影响呢，以前传统的开发过程中，我们有了idea，然后找人把产品做出来，上线后收集一些客户反馈和数据，了解产品的哪些模块需要调整。当然也有一些产品，会赶紧上一个东西，然后就没有然后了，不关心到底这个产品的结果和影响怎么样，只关心产品有没有真正上线。
在精益的过程中，我们首先会关注如何衡量产品的结果和影响，也就是数据，然后考虑如何在产品里获取这些数据，再之后才是真正去构建这个产品。从精益创业的角度是希望把这样的循环能够加快，并且用最小的代价去加快验证产品是否符合预期。很多公司都有这样的想法：‘我们是很棒的，我们可以解决客户很多问题’。到市场上之后呢？也许客户其实并不买账。我们的产品要对客户产生什么影响，如何衡量这个产品是成功的，如何可以快速的验证产品，这是最为重要的。即使失败也要快一点！”
3.产品OKR
“那如何定义我们的产品目标呢？OKR，即目标管理工作法。产品需要有一个远景目标，但真正开始第一步的时候需要找到一个可以切入的目标。‘提高测试环境运行效率’——这是我们产品的一个切入目标，它是定性的，关键结果是达成目标的需要达成的内容，它是定量的。关键结果要关注资源效率和时间效率，这是我们产品最重要的目标。在产品最开始立项的时候，我们就确定需要解决的问题要达到的结果。”
4.影响地图
“有一个目标之后，就要考虑另外一个问题，产品需要做哪些内容，来实现既定目标。这时可以运用影响地图。
Why -为什么我们做这个产品？
Who -谁可以促成目标的达成或者妨碍目标的达成？
How -什么样的行为会对这个结果有影响？
What -最后我们产品需要交付什么样的内容，去触发相关人行为的变化，从而帮助我们实现我们的目标。”
5.产品Backlog
“再回到精益创业的循环里面，我们希望用最小的代价达成目标。这个过程中，我们需要影响地图上找到一个最短的路径。用敏捷的方式形成一个产品的backlog，有些东西是非常关注的就优先级高一点，有一些在当前阶段不太关注就优先级低一点，我们还经常会根据客户的反馈做一些变化和调整。以前的需求强调的是系统需要做一个什么样的东西，使用用户故事的方式描述需求，更关注的是客户到底需要什么东西，虽然只是小小的改变，但是经常会触发大家的一些思考。形式看起来没有变，但是思维的转变是非常重要的。”
团队组织
“我们有一个产品的目标，基于这样的产品目标我们知道做哪些事情，但关键是怎么落地呢？你要怎么样组织这样的团队，用最小的代价更快的达成呢。”
组件团队和特性团队
“组件团队是关注在某一个组件，客户的需求可能会涉及到多个团队的多个组件。特性团队，是一个长期跨职能跨组件可以端到端交付客户需求的团队。跨功能就是我们会有开发、测试等不同的技能在同一个团队里。跨组件是说原来我们团队是负责某一个领域的某一块，现在我们希望这个团队能够负责客户端到端，可能会涉及到多个组件的修改。”
组件团队和特性团队做一个对比：
多团队开发
“如果项目涉及到多个团队的开发，我们要问一下团队的进度大概怎么样。A团队说我们好了，B团队说我还没有弄好。这样就会导致等到B完成之后才能做集成，集成的时候又发现一堆问题，方案和需求也许会发生一些变化。
特别是平台研发，没有对应到某个业务线，业务线就更关注自己的绩效是怎么样的，需要的时候就会抢平台的资源，其他人也会抢，而对于整个公司来说，这件事的优先级是不是最高呢？”
临时性低效项目团队
“我见过非常牛的项目经理跟非常厉害的团队合作，在项目时间之内就把这个事情搞定。大部分情况，对一个临时组建的项目团队来说，我需要熟悉你的情况，你也需要熟悉我的工作模式，这个需要磨合，才能有强大的战斗力。”
一直变大的团队
“在某一个时间之内某个项目很紧急，要发展肯定要加人，导致团队的组织越来越大。从外面来看，虽然人增加了，但是交付的价值好像没有那么大。在一些互联网企业，可能三或六个月要重构一下，把领域合并拆分一下。”
过程管理
“有了产品和需求我们也知道如何组织团队，这些人到底该怎么样合作把产品交付呢？这涉及到过程管理，比如 Scrum框架 。”
“最开始我们只给团队一个约束，每两周要交付一些可工作的产品能够给客户带来价值。第一周的周一做迭代计划，分两部分，product owner做哪些东西和看哪些可以做完。然后会在第二周的周五会做迭代验收和回顾。这里不是每一个迭代只交付一次，而是在这个迭代过程是持续的提交这些东西，只要做完了就上线。”
“这是我们工作过程中用到的敏捷实践，实际做的过程中类似于看板的方式，持续不断的把这些优先级高的用户需求做出来。因为我们涉及到比较多的团队，有三个比较小的团队，这些团队如何组织在一起，我们在用了一个LeSS的框架，适应多团队如何协调来开发一个产品的东西。”
工程实践
“有产品，有需求，有组织，我们也知道如何配合，最后就是采用什么样的工程实践来实现产品。”
单体to微服务
“最开始我们是一个单体的结构，随着团队的不断成长，业务的不断丰富，会发现很多冲突和依赖会降低我们的效率。接着做了第二件事，我们先把它模块化，再后面就把它拆成了微服务的架构。”
测试阶段to测试活动
“最开始会把测试阶段变成测试活动，也就是说，每一个开发都要去做测试，而不是说只有测试的同学去做测试，不是说只有提测之后才有测试，这是一个变化。现在我们会把测试再往前拉，采用接收测试驱动开发的模式，让测试更早的介入，更早的发挥测试的技能，进行需求的测试。”
总结
1. 产品价值
“定期要把产品的结果给大家review一下，持续不断的跟团队和产品及相关利益相关者去沟通我们现在的情况。后面每做一个功能都会去定一个类似这样的指标，等到三个月之后看这个指标有没有达到，如果没有达到的话，就要去看一下原因，然后决定是否继续下去。”
2. 变化
“原来的延期交付变成持续快速交付产品，那么客户的信任度会加深，过程也更透明，因为可以持续得到反馈。”
3. 关键点
“持续尽早的交付可工作产品，最重要的是要有持续的改进，所有的东西不是一个人设计出来推给团队的，在这个过程中需要持续不断的做一些改进和尝试。”
“一句话总结， 守—破—离 。最开始大家如果没有把握的时候，最好是守，去follow去实践，熟悉了之后，有哪些东西阻碍你的时候你可以稍微破一下。当你真正的掌握了这个东西以后，也许可以抛开所谓的招式等等，也就是所谓的无招胜有招。
最后有一个免责声明：其实没有所谓的最佳实践，这里面谈到的工作方式和方法可能是适合我们团队当前个产品当前这样的状况，但是并不代表适合所有的场景、所有的产品。只有说在尝试去找到一种合适的自己场景的实践。不去试怎么知道呢？”
Tips：为了帮大家更好地理解敏捷，我们后续将推出 《Worktile带你学敏捷》 系列文章，从不同角度剖析敏捷到底什么？如何实施敏捷开发？敏捷开发有什么价值等等，敬请期待。
