技术领导力实战笔记_68_第54讲_|_打造高速运转的迭代机器：现代研发流程体系打造（一）
你好，我是f二CTO兼知晓云负责人何世友。
今天想跟大家分享的话题是打造高速运转的迭代机器。
现代移动互联网对研发流程提出的新问题。
移动互联网时代的产品研发基本上是两个特性，分别对应老板和用户的要求，一、迭代速度再快一点，一分钟上线一个特性。
二、交付质量更高，一点半个bug也不能有，而且没有上限。
而速度和质量是一个肉眼可见的相悖的存在，速度快了，自然要牺牲质量质量高了，自然要牺牲速度。
但在移动互联网公司的意识形态里再相悖，那也是把大象塞进冰箱的问题。
因此，也就对研发流程提出了新的挑战。
本文试图就该问题分享我的经验所得，正式解决前我们尾随机的采访，几位围观群众问如何搞定，更快迭代开发工程师说，给我精确可实现的需求。
我一人能干三人的活儿，运维工程师说，给我更多一点机器干活，我让机器随时随地跑。
构建测试部署。
其他各种师说，大家高效沟通，快速复盘、地毯式推荐，问，如何产出更高质量？项目经理说，迭代中各种工序完整涵盖各职责，其他各种师说沟通全面，无疏漏。
运维工程师说，更多一点机器背锅。
所有人说，产品研发、测试构建部署各环节紧密关联，随时可回溯，随时可加入新人。
项目规模或大或小，周期或长或短，都是由一个又一个版本迭代构筑起来的当我们在谈研发流程时，实际上在谈的就是这不断重复的迭代过程。
因此，打造研发流程，就是要打造一台高速运转的迭代机器，打造迭代机器。
工业时代的崛起运转在工厂车间，永不停歇的传送带是成功的基石。
这条传送带贯穿了整个环节，配合精确的时间控制，最终形成产出效率最大化的流水线。
纵观整个产品迭代周期，我们需要立即着手的恰恰就是找到这一条传送带。
那什么是研发流程里面的传送带呢？先来总览迭代过程。
我在文中放了一张图，一个标准的互联网产品的一次迭代，大概长这个样子，大家可以点开文稿查看。
这个过程中参与角色有，一PO项目负责人，二PN产品经理、项目经理，三designer设计师。
四developer泛指各种研发岗位、开发者、架构师、运维等。
五teter测试工程师各个节的交付物有，一、story一段需求描述。
二、product document产品文档原型。
三、task任务由各岗位在项目管理平台创建并维护。
四、design设计稿、交互稿、切图素材。
五、test case测试用例由测试工程师编写并发起评审。
六、tech design document技术设计文档由开发者在开始编码前编写。
七、cute comment,一次代码提交。
八、CI build持续集成系统自动化，构建九、test run,一次测试。
十、deployment一次部署，各环节与环节之间的转场动作有，一、review审核讨论、修改。
二、acceptance验收。
需要注意的是，这里的角色交付物并非限定因素，各团队可以根据自身因素和项目规模应用不同的角色设定和交付物设定，大可不必纠结，可以看到一次可短至一天内完成的迭代，涉及到五种角色十种交付物，同时每个角色之间、交付物之间都会有各种审批和验收的动作填充一眼看上去复杂到爆炸。
而我们作为技术管理者，需要将这些角色和交付物和动作管理起来，这是打造研发流程的基础。
现代化的项目管理工具要做管理，必然离不开管理工具项目管理工具。
在近十年里得到了很多厂商的青睐，纷纷投注研发力量。
于是我们如今可以用上red、 mine、 java、 traellow、 tower、 teambition、 wordtile、禅道等各种工具。
其中，受travel的影响，近些年的项目管理工具多，实现的是简洁的看板管理方法，成品往往具有简单好用的特征。
老牌的java则同时支持scrum看板管理方法。
Scrum看板均是敏捷，开发流程的实现并不存在特别大的区别，各团队可以根据自身的喜好选择，这并不是重点。
但如果项目管理工具还只是让项目中的各角色在上边手工创建更新任务卡片，那一定会成为项目推荐中的阻碍。
现代项目管理工具一定要将交付物管理串联起来，管理工具的目的是为了维护任务状态，而任务状态事实上是实际任务完成与否的反应。
也就是说，管理工具需要具备从交付物所在平台获取动作事件，将其转换成任务的流转并完成任务状态更新的功能。
比如说工程师的任务是写代码，但他做了一次代码提交，就意味着这个任务完成了。
如果还需要他手动去任务管理平台更新，任务状态就比较多余。
因此，任务管理平台需要具备从代码仓库获取代码提交事件的能力，并自动更新对应的任务状态。
可以说，项目管理工具就是上文提到的研发流程里的传送带。
这条传送带承载了任务的流转，更需要承载一个任务。
所有交付物的关联。
一个任务包含产品原型、文档设计稿、技术设计、文档代码、测试用例测试结果、CI构建部署等诸多交付物。
把这一切串起来，可以解决什么问题呢？回溯可回溯的迭代，得益于不断提速的迭代流程。
互联网项目的代码腐化速度早就从年提升到月一个正常迭代的互联网产品。
即便立项时的架构设计，文档写的再细致出色，每次迭代时的代码写的再易读，注释清晰三个月。
后来一个新人一定搞不懂为什么代码会写成这个鬼样子，为什么呢？因为无法追溯代码的每一次更改，都是在响应当次迭代的产品变更。
虽然每一次产品变更都可以通过产品原型的更迭得到留存，但因此导致的代码更改乃至架构微调，却无法产生对应关系。
那通过任务管理平台来关联产品变更和代码变更呢。
这样每一个产品变化导致的代码变化，以及当次的测试构建部署结果都是串起来的当需要回顾事故现场时，可以将这些关键交付拿起来看，应该可以解决所有问题了吧。
还不够不断迭代的技术架构设计，虽然可以通过这些元素的串联，还原当时的迭代详情，但依然可能出现搞不懂代码为什么写成这个鬼样子的困惑。
因为已有元素的提供，可以搞清楚代码变更的罪魁祸首，但无法还原现场。
在此需要的是完善的不断迭代的技术架构设计文档。
举个例子，电商业务产品想增加送礼功能，用户a下了一个订单，付完款，用户b填写收货地址，产品变更简单增加一个用户b更新地址的流程就可以。
但对应的代码变更则大了去了。
这一个礼品功能的增加可能直接导致订单架构的变化。
这时候，如果没有技术架构设计文档的补充，对当时的需求进行分析和架构变更设计进行记录，产出的代码一定是不好理解的。
现代的软件工程构建，再也不是一座桥梁的构建模式。
蓝图画好了就打死不改代码可以不断迭代。
同样的蓝图，也就是技术架构设计也应该不断迭代。
而设计文档就是技术架构设计的迭代。
交付物在整个迭代过程中至关重要，至此，迭代过程可以做到完全可追溯，这对保证项目质量起到非常大的作用。
一个新人刚加入项目，不管是从代码提交记录，还是从设计文档的修改记录，还是从每一次构建部署的记录，都可以追溯到关键节点。
如此一来，项目的生长轨迹再也不用依靠老同事的口耳相传得以维系，其腐化速度也能得以缓解。
一个快速迭代成长的项目就需要这样的基础。
在这个基础之上，如何快速推进须知参与项目的不仅有人类角色，还有各种交付所在的系统、在线文档协作平台、代码仓库测试用例管理平台、CI构建平台、自动化部署平台等。
这些角色机器之间也需要沟通，沟通，不仅是人和人迭代中的沟通，一般有这么几种需求。
一、角色之间的沟通讨论，约定解决冲突。
二组群内的沟通头脑风暴计划宣布等三就某一话题进行多人沟通。
沟通工具要满足的条件之一就是所有沟通结果可留体用于未来追溯。
因此呢，重要的信息邮件依然是最佳选择。
通常在项目启动、验收等关键时刻，邮件确认是最合适不过的。
平日的沟通交流则以效率优先，大多是发生在即时聊天工具上的微信，提供了非常便捷的讨论组功能。
外部联络时非常高效，可以瞬间圈起公司内外相关人士进行畅聊。
但日常工作中，很多时候会有临时的话题，需要进行多人沟通，沟通完就散。
举个例子，code review群组里，CI构建系统发了一条最新的测试失败消息，相关的开发者需要就这一个失败进行讨论，直接在code review群里讨论吧。
消息一多就冲垮了，有噪音，拉一个新的群组吧，又太费劲了。
这种情况下，select提供的threat功能就派上用场。
此外，研发流程里参与的角色一半以上都是机器系统。
此外，沟通工具优先要满足的其实是如何让机器和人对上话，这就是现代沟通工具的特征。
在同一个沟通工具里，人类角色可以像和其他人类角色沟通一样，和机器沟通，如接收机器的通知，像机器发送指令等，用机器打造迭代机器项目管理平台。
这条传送带让一次迭代里的各个角色任务可以快速进行流转，并从流程上充分利用时间，减少损耗。
一个需求力度划分越细，就越可以做到精确可控。
然而，一次需求从代码到上线，这中间的过程是漫长的。
编码到静态检查，到单元测试、到测试、到代码审查到构建到部署、到运维，我们要做的就是尽可能的自动化，让机器包揽所有能干的活。
这样一来，迭代过程不仅可以无误差运转，甚至连运维的工作都可以更加高效。
上面提到的过程中，除了编码和代码审查，这两个是必须要人类参与的步骤。
其他环节机器均可以胜任。
可能有人会问，研发团队写这一套自动化流程得花多大成本？是不是和研发产品缘木求鱼了？答案是磨刀不误砍柴工。
至于成本嘛，感谢开源社区和相关服务提供商，几乎都是现成的，可以花合理价钱买到的篇幅有限。
这里呢我就不展开了。
下一篇文章我将跟大家简单说说各环节的现有解决方案及选型，敬请期待。
研发流程是一个团队打造产品的过程。
这里边有一个最基本的性质，就是生长不断的生长，而产品快、速度、高质量的生长，离不开高速运转的迭代机器。
本文就迭代机器的打造，给出了我自己的经验与答案，存在疏漏在所难免。
欢迎大家在评论区提问讨论。