知道创宇总监姚昌林：敏捷开发-如何打破研发交付过程中的“墙”
接力技术，链接价值
-----------------------------------------------------
链接3000+技术总监/CTO, 每天早上推送技术干货文章
全文：6519字28图
阅读时间：14分钟
姚昌林
读完需要
速读仅需 3 分钟
我今天给大家分享的是：敏捷协作——如何应对研发交付过程当中的墙，我的分享更多的是我自己的经历和实践，我也算是一个实践派吧。
我来自知道创宇，当前主要是负责研发项目的交付实施，以及新产品的孵化，同时我是研发过程改进的一个实践者。对于实施交付而言，我的工作以及我们部门的工作有对内的，也有对外的，所以比较复杂。也是正因为这样的一个前提，所以会有这样一个主题。
曾经有一个有篇文章，他把玩王者荣耀和跟团队能力的一个协作能力打造结合到了一起，说完王者荣耀玩的好的，那么他的团队协作能力一定很强。在我们玩王者荣耀的过程是怎么的？
一开始我们来自五湖四海，全国各地，相互不认识的人一秒级秒级组建团队，快速汇聚到一起，能够相互尊重，同时在游戏过程当中齐心协力，目标高度的一致。在游戏里面每个角色，他的技能和擅长点都不一样，我们在选择的时候也是取长补短，在游戏的过程当中还能相互补足，而且能够互相支持和帮助。
在游戏胜利之前，谁也不会去想我到底应不应该去抢人头,或者说其他的，先以结果服从大局为重，在快要死了的时候，都还会说撑住我们能行，不到最后一刻绝不服输。
对于这样这样的一个例子，好像说的很有道理。
那么对于在我们的真正的交付过程当中的话，现实情况是什么样子？
刚才说我们在交付过程当中有对外的，也有对内的，在整个企业的内部，任何的人也可能是我们的协作方，也可能是我们的需求方，同时我们还可能跟着他们一起去向外部的客户进行需求交付，我们的人员可能来自于各自的团队，快速的通过项目组的方式快速组建，组建完了之后，我们希望通过流程的方式，然后让大家形成统一的共识，并且快速的去实现对于用户价值的一个交付。
这中间会有一些我们所熟知的一些方法和思想，比如说我们持续集成、DevOps、敏捷持续交付等等，但是这样他真正能够解决问题吗？以及我们在这个过程当中真的会就是一帆风顺吗？从我趟坑的经验来说，这是答案肯定是否定的！
在整个过程当中，因为我们的组织不一样，不一定所有人都有全局观，而且对于各个组织和部门来讲，他们的考核目标，他们的职责以及他们的所在的地域都有可能不一样，同时对于交付而言是比较苦的。古人说人生有三苦，撑船打铁做交付。
所以对于很多的研发而言，如果持久做这种业务交付，他的内心是不太愿意的。因为重复，而且在处在整个研发生态链的最后端。这个时候我们该怎么办呢？
比较简单的方法就是不做交付了，换个部门继续做，但这个时候老板会跳出来告诉你，你一定要撑住。所以这个时候没办法，我们只能想怎么样去解决这个问题。
以前有一个朋友跟我提了一个建议说“你看这个人员留不住，对吧？留不住那怎么办？我们是不是可以招一些普通一点的人，他们没有那么多的想法抱负，让他们来做这个交付如何？”我当时没有回应，但是内心万马奔腾。如果这样的话，我干嘛还继续做它呢？对吧？
从组织能力杨三角的一个理论说，他说一个企业的一个组织能力，它有三大支柱，分别是员工能力，员工思维和员工的治理。
员工能力和思维，大家都能理解。员工治理是说对于组织的一个流程和资源，是否能够支持和帮助到员工去完成所需要完成的任务。
那么对于员工而言，就我刚刚说的，如果按照对于能力而言，我们要求更低，如果说敏捷是我们的一个组织能力，那我相信这个组织能力是很难只通过流程或者其他的一些方法去得到提升的。
所以在创宇我们是实现了很多的一些方法和实践。很多时候我们可能是内部自己去做。
首先对于员工能力而言，我们要的不是普通的人，相反我们需要全栈。其实对全栈而言，有这几种定义，第一种是我们在开发的过程当中，比如说我能做前端也能做后端，然后既能做架构，也能去当客服。
这是一个全干的能力，但是一个真正的全栈，我的理解是：
1、必须要有就最基础的解决问题的能力。
2、同时它需要有超强的学习能力，以对于交付的一些项目来说，它的变化会很多，他需要成超强的学习能力，快速应对变化。
3、同时良好的沟通能力，能够在交付的不同的交互过程当中，和不同的人员进行沟通和协作，起到桥梁的作用。
4、技能迁移的能力，比如说像现在我们的前端，有太多的技术栈和框架要学，学习完这些东西基本上不可能。但是我们对于方法和思想来说，其实它是一致的，我们需要有这样的一些知识、技能迁移的能力。
5、全局思维能力
同时为了让员工更愿意去做这些事情，我们必须给他一些新的东西，新的idear，新的思路，让他勇于去创新。我们在交付的过程当中，其实交付而言，它有天然的优势，可以接触到不同的业务，不同的需求，不同的用户。那么在接触的过程当中，我们有很多的机会可以基于技术去孵化。
比如说我们知道创宇是做安全的，今年区块链很流行，我们有个同事想了解，想去看一下，了解钱包怎么样。然后把市面上所有的这个硬件钱包看了个遍，结果发现这些都不安全，一大堆的漏洞。
然后，基于此公司让我们能不能做一个极致安全的钱包，所以我们自己也做了钱包，然后现在对于这个钱包而言，那些市面上流行的钱包厂商都来找我们，说这个如何能够帮他们解决这个安全漏洞问题，能不能帮我做下审计？
这些都是一个创新的模式，但是对于创新而言，我们有一个叫cs3.0的原则，也叫实用主义。
前几年，我们在每天中午下班之后，我们会组队打cs，公司有搭建这个cs服务器，基于打cs玩的多了，然后我们就总结出来一套理论叫cs3.0，就是我能不做的就不做，能省着做的我绝对不多做，能用第三方的，我干嘛要自己去重复造轮子。
S是只要能用Script脚本语言编写的，我就一定不会去用一个重型的框架去实现这样的一个需求，只有在其极端情况下面，比如说影响到性能效率，这个时候我们用C去重写就行了。
这样的实用主义其实是对于一个mvp的一个快速验证的一个过程。那么对于这样的一个鼓励创新的模式，让员工愿意去做，同时基于他做的事情能够有更多的一些驱动能力。
在知道创宇，比如刚才说的钱包，其实我们做安全的经常会接触到很多平常人接触不到的一些事情，比如说黑产灰产，对吧？那些都是钱更集中的地方。
所以对于公司的一个核心价值观，我们必须要有所为而有所不为，这个不管是对做交付而言，还是说做产品研究，都必须要有的。同时在孵化产品的过程当中，其实就是少即是多。
以钱包为例，在市面上的其他钱包，他们做的很多的功能、特性。但是对于我们而言，我觉得只需要做安全就足够了。以苹果为例，如果说苹果手机它也做双卡双待，同时待机30天，可以想想苹果会是什么样子，以及我们现在看到的它是什么样子，它的售价。它在行业当中的一个对比，大概的一个竞争力是如何。
解决了员工的能力和意愿的一个问题。从员工治理上面，我们以前用Scrum的一个开发模式，主要的一个期望是跟敏捷一样，就是尽早的交付价值，以及希望通过Scrum模式快速响应需求的变化，然后在真实的一个过程当中，真实一个结果是什么呢？
就是开发环节的Scrum，它不会让我们真正感受到价值的交付以及用户的反馈。因为在开发之前，我们就是需求和需求的来源，需求的一个市场调研等等，这些东西缺失了，那研发你仅仅只能去做执行。然后在那个开发完成之后，你的部署实施验证反馈，这些环节如果脱节的话，你没有办法去持续改进。
比如在开发流程有Scrum流程里面也有一些问题，比如因为我们的绩效激励也跟这个相关，那么在拆分任务以及评估估点的时候，这样大家会基于一些干扰因素，要么就是过于激进，要么就是过于保守，以这样的一个情况所做出来的东西，我们在数据衡量上面，它就缺失了一个真正我们希望他达到的一个价值和目标。
同时我们sprint 两周，但是在sprint整个过程当中，经常会有一些新增的紧急时、紧急、特别紧急，必须马上在半个小时之内解决的一些问题插进来。但是不在这个sprint里面，这个时候对于scrum而言有其他的一些影响，影响是什么呢？
影响的是你这个任务没办法插进来，以及就算插进来了，在scrum的里面原本的任务会延期，导致每个sprint我们都不能完成，然后程序员的成就感就会越来越低，然后无限循环，最后大家对这个scrum就没有了意义。
后来我们了解到了精益，这个原本用于生产制造的一个流程，我们把它搬到我们的研发过程当中，精益和敏捷他们都讲究尽早的交付价值，尽早的交付价值之后快速验证，并且拥抱变化。但是对于精英而言，它可能更多的是除了满足敏捷所要求的这些东西之外，他还专注于如何去减少在交付过程当中减少与客户价值交付无关的浪费。
我们采用的是精益看板的一个方法。把整个软件开发、开发交付，从需求到交付整个链条，所有涉及到的环节，所需要的环节全部放到一个物理看板上面。
然后从需求从左边第一列进来之后，它是一个用户的一个需求，需求澄清之后变成就绪，就绪的话是拆分之后的一个story，然后在story实现过程当中，我们会以设定甬道，根据团队的能力，我们有不同数量的一些甬道，同时对于一些公共的技术，我们可以我们设定一个专门的技术甬道。然后对于临时紧急增加的一些需求进来，我们在最上面可以加这种加急的紧急甬道，在每个story在实现过程当中，它又会拆分成不同的任务，比如说前端、后端、web、moble之类的。当某一个story所有的任务都完成之后，那么这个story也会被拖动到下一个环节。
同时在整个看板中，我们会用不同的颜色标签来定义不同类型任务，他有不同定义，有些是任务，有些是story，有问题有bug。
在看板的方法当中，我们有几个实践有，第一个是从端到端，需求从进来到需求交付，它不只是开发环节，不管我们团队里面的人员在哪边，他都能够看到当前这个需求价值是否交付，以及交付的反馈如何，同时在这个过程当中体现了团队的一个协作，在实现过程当中，如果说需要团队协作的，大家在这个看板上面能够直观的看得到。
同时也有需求的分解合并之类的一些动作在里面，但是这些所有的都是基于看板，大家自发的，不再是我们需要单独主会，或者说单独去评审一下，或者是陷入到这个重复的沟通当中。
精益看板它的时间，每一列的一个流动过程，流动从上一列到下一列，它会有一个显示的一个规则，在这个看板当中，我们的需求从待澄清到就绪，这个拖动需要产品经理、研发、测试一起来参与，一起来评定，开发完成到验证它开发必须要完成自动测试，这是整个基于规则的一个定义。
同时我们根据团队的人数数量，每个甬道会有最大的一个限制，超过这个限制的话，我们就不让他再新增新的任务进来，那这样的话我们关注的是什么呢？关注的是与其我一个人同时兼任着很多个任务，或者说很多个需求，但是每一个需求都没有完，都没有真正交付，那还不如直接交付其中一个，尽快把它拖到下一个环节。
所以在这个看板当中，如果说某一列它的变迁会很多，那这个时候其实我们能够看得到它是一个阻碍项，那这个时候整个团队的人需要看的就是如何去把这个阻碍项消灭掉。
然后我们晨会的时候也会按照这种方式，比如说每个不同职能的人员，他会关注自己的那一列的任务，以及他前一列的任务，他需要不是研发完了之后，交给测试给测试说，测试你赶紧去给我测试什么的，而是我们测试他主动的去拉动，拉动新的待认证的需求。
然后研发从就绪也是一样的，如果说就绪的太多了，然后研发story里面没有，那其实也是一个阻塞。
因为我们的团队有些时候会跨地域，我们在Java的这种电子看板上面也做了同样的一个事情，他的不好的一点。
对于精益看板而言，我到现在还没有发现一个在电子看板上面能够真正做好的一个实践，所以最好的还是在物理看板上面，但在电子看板上面的话，我们能够跨地域的去协同，然后方便我们去做统计。如果每个地域的团队可以将电子看板再还原，比如打印还原到这个物理看板上面去。
然后还有一个实践是对于管理层面的。
前面的看板是我们项目组成员，直接在这个环节当中按照规则去执行。那对于我们的有很多的问题项，这些问题项解决完之后，我们会把它就是分类，按照原因、影响的周期进行分类，然后我们的缺陷也按照这种方式去分类，这样的话我们能够发现影响进度，我们整个看板阻塞的一些流程上面的问题，或者我们协作上面的问题。
而这些问题可以反馈出，比如说我们制定的规则可能需要调整，那整个团队就根据反馈的一些问题进行讨论优化。然后最终是基于反馈能够持续改进。
然后对于效率而言也是同样的。在做scrum的时候，这些统计其实没有意义了，但是在这个精益看板的时候，我们其实不在乎每一个sprint到底是按时完成了，或者说是没有按时完成，我们关注的只是说你需求交付的一个速度。
所以累计流图我们可以看出我们的交付速率，同时经过长时间的一个积累，我们可以得出某一个团队他在完成这些需求当中的服务水平协议，就说你完成80%的需求大概周期是多长，因为完成百分之百的，其实这个是很难有，所以我们是取得一个比较正常合理的一个值“二八原则”，那么基于这个效率的反馈，同样也是能够方便团队的协作，去持续优化和改进。
同时这个也作为我们的激励和考核的一些目标。但是考核的话，它应该是针对于组织，也就是针对于整个团队的，而不是针对个人的，如果针对个人的话，可能又会陷入另外一个坑里面去了。
所以对于精益看板的话，我们能够更清晰全面的反映从需求到交付，端到端的一个完整过程，同时瓶颈和问题也能够在看板上面得到一个及时的体现，团队在每天晨会的时候，所有的问题都可以在看板上看到。团队里面的每个成员，就算在没有管理的情况下，他能够自驱的去协作和作出决定。
同时在交付的时候，我们经常会做一些重复的工作，那这些重复的工作我们怎么办？
我们需要工具化的一些思考，就是经常去思考一下，我们是否有重复高频低效的一些环节，那么我们是否可以通过这个做一些工具，将我们可复用性比较高的实用性比较高的做成工具，然后通过工具来对我们的协作赋能，通过工具来提升我们的协作效率。
所以在这个过程当中，我们可以沉淀一些开发框架，比如像数据平台，还有我们的这种对于流程协作的一些工具，同时也可以做一些这种基础的研发平台出来。
其次就是在组织架构的一个设定上面，我们现在的交付，仍然是处于最后端，但是我们在交付里面同样分的比较细，有业务也有平台。
对于这两个而言，职能矩阵就是按照职能去拆分它的优势，更好的能够去进行资源统筹和人员的一个备份，同时对于我们技术创新而言，它的领域生根能力会更强。再比如我们在做这种安全研究方面，可能就是按照这种方式去做。
然后对于业务举证它更能够快速的去全职能的目标打通，同时能够建立利益共同体。就是针对我们之前在协作过程当中提到的，可能每个部门的出发点可能都不太一样，我只是来帮你去协作的、打杂的，我做完之后，后面是你来维护，其实我只关心当前的，对于未来的可能考虑的比较少，如果通过业务矩阵的管理模式的话，那能够更最大化的去发挥它的一个价值。
所以总结一下的话，其实真正要解决这个沟通当中的一些墙和我们交付过程当中研发过程当中的这些墙的问题，其实是最终是需要打造企业的一个组织能力，如果敏捷是一个组织能力的话，我们打造的就是敏捷的组织能力。
那么对于员工的能力、思维和治理每一个环节都很重要，但是在这个过程当中，持续改进，就是跟精益看板一样持续改进，对于现在我们的团队也是在持续改进的过程当中，也会遇到一些问题。
但是，首先从员工的能力上来讲，我们需要精兵强将，同时员工思维上面我们希望它能够自我自我驱动，就是减少管理的一些成本，或者说必须要被动的去接受一些事情。
要从员工治理上面的话，比如精益看板也好，还是说我们的激励考核都能够公开透明的这种信息沟通，然后激励是基于我们激励能够更加公平或合理的一种透明化的一些机制，不是按照纯的一个职能部门。
同时在鼓励创新上面，我们基于能够提供这种试错或失措的一些机会的，我觉得这样这样子的话，对于整个沟通或者整个协作的过程当中，跨部门的一些问题，以及员工内心上面的问题都能去解决一大部分。
可点击下方“阅读原文”查看演讲视频