12 月 20 日，成都上空阴云笼罩，为这个冬季又添了几分寒意，但在华为成都软件开发云创新中心，一群开发者汇聚于此，度过了热闹非凡的一天。
这一天，DevRun·选择不凡——华为云开发者沙龙走进成都，来自成都数字天空、成都软易达、小咖科技、华为云、译讯科技、罗克佳华集团、倍施特科技的技术专家聚焦游戏原型构建、多端小程序开发、DevOps 落地、敏捷开发等众多话题，通过演讲和圆桌对话的方式，分享了各自对当下技术发展与应用的思考，以及提升项目研发效率的实践方法论。
原型构建在游戏开发中的实践
在现场，成都数字天空 RD 组技术经理邓春燕表示，根据数字天空过去的经验，当一个游戏项目还没有进行完整的原型验证和解决技术风险的时候就进行团队扩张，投入到生产阶段。这个游戏的体验问题会大概率跟着时间的推移，雪崩式出现。因此，做好原型可以很大程度地避免技术风险方面的问题。
成都数字天空 RD 组技术经理邓春燕
从原型所解决的不同问题的层面来讲，在游戏开发中原型分成三部分：第一是游戏原型，开发人员会对游戏玩法、游戏规则及创新性进行小范围的验证，先打造一个游戏的小样本；第二个是技术原型，即针对游戏开发中的高风险技术点进行验证；最高的一层就是流程原型，它主要是解决游戏生产阶段的效率问题。游戏的品质、游戏非核心系统以外的其他系统，或者游戏风格、音乐氛围等都在原型考虑范围内。
在技术原型的开发阶段也需要用到迭代的思维。作为技术管理者，需要去设置一些可量化的目标和结果。一方面鼓励技术人员的开发，另一方面保障大家在开发的时候心态不会崩。对于周期长的技术原型，可以再一次进行选择对标的产品，当有了可视化的目标后，大家的信心才会更容易在长周期中保持下去。
邓春燕还分享了作为技术管理者的一些心得：第一，我们应该给技术原型的同学配备给力的队友；第二：零失误对创新公司来说一文不值。因此要保障大家轻松的开发氛围，不要让大家觉得失败是很危险的事情，为公司的生存担忧；第三，启用团队消防员角色和有韧性的工程师进行交流；第四，可以复用在游戏开发过程中积累的技术研究成果。
游戏中 60% 的成本是投入在美术和动画的生产上面的，因此程序员会开发非常多的工具和流程去支持提升美术的生产效率。邓春燕在分享时表示，流程开发需要遵守 KISS 原则，用熟悉的工具、语言、脚本验证可行性之后进行迭代开发，与现有项目管理有一个整合。当我们把产品交付给导演时，导演是一群非常感性的艺术家，他们对于产品迭代的接受度可能没有这么高。因此，这里面一定要非常重视软件的流动性，确保交付给他们的产品非常稳定。
DevOps 演进之路与案例经验分享
DevOps 更快速、更高效和更统一的优点受到慢慢的变多的企业青睐，根据 IDC 预计，DevOps 的软件市场体量将从 2017 年的 29 亿美元，增长到 2022 年的 66 亿美元。作为软件项目开发的关键性要素，DevOps 已深入地影响到了软件世界的整体开发格局。对于许多研发企业而言，开发人员已不再停留在是否对其感兴趣的层面上了，而是真刀真枪地开始去实践 DevOps 相关的技术与方法。
成都软易达 CTO 黄晓东
在现场，成都软易达 CTO 黄晓东表示，很多企业当下面临着几个问题：客户的真实需求变化频繁、开发交付周期拖延以及交付质量难保证，最终导致成本急剧攀升，这也是我们迫切需要落地 DevOps 的原因。
DevOps 能够理解为是以业务敏捷为中心的，加上构造快速发布软件的工具和文化。说到敏捷与 Devops 的关系，敏捷用于指导产品的构建，而 Devops 是在生产中描述如何开发，如何发布管理产品的。即 Devops 是对敏捷理念的具像化，是敏捷思想从开发端到维护端的延伸。
黄晓东介绍转型经验时讲到，选择一个项目作为 DevOps 转型试点，能够使用 UML 方法，分析业务需求，梳理系统用例的流程、规则和约束条件等。并按照 Scrum 框架裁剪相应活动，保留迭代计划会议、每日站会、迭代评审会议，增加专题会议等。他进一步阐述道：“在进行迭代开发之前，我们已对业务需求来做分析，得到总体系统需求，并进行总体系统设计，所以在迭代开发前，系统框架已经搭建完成。迭代开发过程中，是逐渐对系统需求来做细化、设计和功能开发的过程。”
黄晓东表示，使用华为软件开发云作为敏捷迭代的工具，在该平台上能够直接进行需求规划、代码托管和检查等；使用流水线技术、自动化测试等自动化工具和方法加速软件开发各阶段信息流转，从而实现软件的持续集成、持续交付；并能将测试工作注入到整个开发活动中，对开发交付的内容进行持续验证，保障交付的质量。
此外，黄晓东提到，DevOps 刚开始转型时不一定比采用传统模式更快，但可以较大程度降低返工率。“敏捷原则告诉我们要拥抱变化，而不是干掉变化，需求始终存在，只是我们没有发现它，甚至经常臆造出一些‘需求’。在转型之后，我们会发现编写的文档虽然比以前少了，但对于重要而关键的文档要求却更加严格。”
DevOps 的目的是更快速的响应客户变化，快速发布可工作的软件，构建一个逐渐逼近真实目标的软件，同时产品、开发、运维团队之间进行更多的沟通和协作，以便降低返工。企业在落地 DevOps 前，需要仔细考虑转型的价值，根据自身真实的情况，选择实施 DevOps 转型的方法和工具等，DevOps 不只是工具，转型需要更高维度的思考。
小程序时代：如何开发出一款高性能、跨平台的小程序？
自微信小程序诞生以来，历经 2 年多的迭代升级，已有数百万小程序上线，成为继 Web、iOS、Android 之后，第四大主流开发技术。与之相随，小程序的开发生态也在蓬勃发展，从最初的微信原生开发，到 wepy、mpvue、taro、uni-app 等框架依次出现，从刀耕火种演进为现代化开发，生态越来越丰富。选择多了，问题也随之浮现，开发小程序应该用原生还是选择三方框架？
小咖科技前端技术总监陈哲宇（基老板）
小咖科技前端技术总监陈哲宇（基老板）表示，小咖科技有四大 To B 业务体系：代驾，网约车 / 公务用车、城际定制班车 / 顺风车和出租车。考虑到一些 B 端客户存在 App 推广费用高且效果不好、获客渠道单一等问题，因此选择自己研发小程序帮其引流。他表示，之所以不采用第三方框架主要有以下几点原因：
第一，学习 DSL 语法有相应的成本，公司（小咖科技）用的是全 Vue 的技术栈；
第二，第三方框架无法灵活地扩展原生的组建。很多的框架库会帮开发者更多面向比较基础的硬件来封装一些原生的组件。但由于不同企业的业务场景不一样，可能这个框架给开发人员开放的组建不能支撑使用。
第三，兼容多端。第三方框架通常喜欢打“兼容多端”的旗号，但有一个问题是兼容太多会导致上限，开发人员反而要按照兼容性最差的去做产品。
第四，第三方框架的 DIST 文件无法继续开发，它打造出来的东西是编译过的。
第五，第三方框架本身的问题。基老板解释道，我们之前遇到过这样的情况，开发一个东西已经开发一半了，突然框架出现了问题。社区有很多类似的框架，但是用户在社区内提出问题，很少有人能及时回应，这就导致框架出了问题没办法快速解决。此外，还有很多框架为了兼容更多东西过于重。
如今，QQ 小程序、百度小程序、支付宝小程序等众多小程序百花齐放，它们之间虽然语法不一样，但也有共性。基老板表示，比较主流的功能点各个小程序其实都是一样的，除了命名可能会有所不同。
如果是自己开发小程序，需要先了解目标是什么，要达到什么样的效果。基老板提到，“一些组件第三方是没有很好的方法给你提供的，比如地图，因此我们应该在兼容地图的时候扩展原生组件；编译出来的 DIST 文件可以单独进行开发，我不对我的代码进行特殊的编译，我只需要编译成原生的东西，这样在后期，如果我是做一个开发模版的公司，我开发出来的每一个小程序可以单独出售，因为它能够直接进行第二次开发。”此外，基老板表示，在小咖科技有两个团队，一个是迭代团队，一个是效能团队。迭代团队只需要把业务层的代码写好了，不用关心兼容性问题，效能团队只需要维护好框架提供组件和 API。其中用到的思想就是完全分离各端代码和按需加载，
五星级软件工程师的高效秘诀
提升研发效率几乎是一个永恒的话题。在现场，华为云 DevCIoud 西部地区业务总监邱志勇为开发者们分享了五星级软件工程师的高效秘诀。
华为云 DevCIoud 西部地区业务总监邱志勇
邱志勇表示，华为为提升团队和个人的价值的产出做了一个叫 TVI 的项目，经过调研得出影响产出效率的常见问题有以下几点：
1、软件工程师不能聚焦编码，被各种非编码活动影响：团队周边协作与支撑工作占比高，跨团队联动开发等耗时低效；
2、打断问题：员工工作常被突发事务打断（统计数据，平均每小时打断 7 次以上，平均编码持续时间不到 10 分钟）；
3、PL 直接价值贡献少：项目管理 + 团队建设占比高，特性交付占比仅不到 20%；
4、新手写代码，老员工解问题：高职级人员代码产出相对低职级人员没有优势；多数团队新员工编码，老员工主要解决新员工遗留的问题。
对应地，邱志勇提到可以从活力、贡献、管理、能力、协同等维度去切入改进：
第一、调动团队成员积极主动的态度。把每个团队成员的贡献透明化，比如华为在工作中会把每个人交付了多少价值点列出来；其次，建立个人荣誉档案。在一个人的职业生涯中，专业级别在个人荣誉及其后续成长中都很重要；
第二、自我管理。具体可采用静默时间、番茄工作法等进行实践。另外也可采用精益看板和个人看板，在此过程中很容易看到团队的瓶颈点在那个地方；
第三、构建知识网络；
第四、有团队合作。可以建立微战队，形成社区化评审与协同。
传统瀑布模式采取的大批量、强计划、长周期方式，已无法应对市场和客户的真实需求快速变化难以捉摸预测的 VUCA（V：Volatile 动荡，U：Uncertain，Complex 复杂，A：Ambiguous 模糊）时代。目前，很多组织形态为了适应 VUCA 时代而变化，对个体要求更高。
对于如何成为高效个人，邱志勇提到了三点：第一要自主。我做什么我自己决定——人们需要在做什么、何时做、和谁做以及如何做上实现自主；第二，专精。要能够运营并改进所擅长的技能，把想做的事情做得慢慢的变好；第三，目的。即要有自己的工作目的，比如创作不同、认可自己工作的价值、让生活更有意义等。
邱志勇总结道，五星级工程师高效秘诀按照道法术器的说法，首先我们要认识到高效团队及个人是提升研发效率的关键，然后从活力、贡献、管理、能力、协同等纬度进行改进。另外，还要采用静默时间、建立微战队等具体实践方法提升工作效率。最后，可通过工具来提升工作效率，能够用工具的时候尽量用工具。在华为公司有一句说法，有工具的我们用工具，没有工具的我们用流程，实在不行的我们用管理。
敏捷开发，到底是自顶向下还是自底向上？
在业界，“敏捷”一词慢慢的变成了一种软件开发活动的推荐模式。为何需要敏捷？答案很多，每个开发者心中都有一个自己答案，不过关键还在于“变”，也就是我们的需求在变化，且变化很快。
译讯技术负责人杨龙杰
译讯技术负责人杨龙杰表示，从上而下地说敏捷是说思想更是在说如何正确传达信息。无论是企业还是个人都无法改虽然在说变环境，当自然人与法人都在采用先进的生产力，用最高效的方式去满足环境的需求时，其实是在适应环境。很多企业从获得需求到实际产出的过程中，都存在信息闭塞与价值观偏差的问题。敏捷自顶而下就是解决这样的一个问题。
从下而上讲敏捷是讲流程，也更是生产力。之所以能敏捷，基础还在生产力提升。提高生产力后敏捷后的表现为三个方面: 首先是项目管理的自动化，其次是流程变小，以及程序员的基本功提升。项目自动化管理基于对 5 个 W 的认知，流程变小是工具的使用，而基本功就在于反复练习与极限编程。
敏捷是自顶而下还是自底而上，就看先提升沟通还是生产力。当然绝大部分是二者都需要。
如何观察企业是否敏捷，利用指标指导生产？根据杨龙杰的介绍，在译讯，敏捷需要五个方面的观察：
（1）故事点：一个团队在实现某一个故事的时候在时间上会有区别，因此时间不能用于估算工作量。故事点是一个与基准比较而得的量，与基准比较之后进行一个排序。这个排序基本是固定不变的，对于团队而言也是更客观的，它不会因为主观原因进行简化；
（2）价值点：基于可交付的产品才能算出价值点，价值点在项目的每一个阶段都要去推进，在每一次交付后都会变化，一开始就把所有事情的价值点都定下来是非常难的；如同下棋，我们在每一步之后选择价值点最大的地方落子。
（3）优先级：优先级高的不是故事点最大，也不是价值点最高的工作。而是价值点 / 故事点的值最大的工作。
（4）质量：交付只有 0 和 1，质量评估采用 1- 受损故事点 / 总故事点；
（5）利润：利润是所有的核心，一个项目的利润可以计算单位故事点利润，单位价值点价值。可以观察整一个完整的过程哪一环节可以调整。
此外，杨龙杰表示，沟通难度、沟通成本和沟通欲望这几个指标也很重要。沟通难度能够准确的通过一个需求到开发手里需要的时间进行衡量；沟通成本则可以看一个需求到开发手里经历了多少种形式；评判沟通欲望可以参考一下团队聚餐次数，如果大家吃饭都聚不到一起，那么要说价值观相同很难让人信服。
构建软件流水线工厂的实践经验分享
在软件开发过程中，效率和质量、变化和稳定、灵活与成本很难兼顾，往往会顾此失彼。这也让开发人员很难在短时间内生产出非常好的产品。我们期望的一种产品开发方式是标准化和流水线式的开发模式，也就是让软件模块标准化，软件开发流程像生产车间流水线作业一样，所有的软件工程师只需要根据软件设计规格书去模块库选择适当的模块（即原材料），然后编写程序进行拼装、测试、发布即可。无可厚非，这种开发模式，效率是极高的，实施这种模式对一个公司来说很迫切。
罗克佳华集团 CTO 兼副总裁廖强
罗克佳华集团 CTO 兼副总裁廖强表示，在工业或者制造业领域，那些非常严谨的工程面临的问题其实比软件开发还要多，但它们有标准、计算逻辑和规则，它们一直在做的事情是“标准化在。
在完成标准化之后，需要用流水线的方式生产不同工具，也就是做生产机器的机器。对于软件开发来讲，廖强表示，我们的目标是如何做生产代码的代码，让大家少写代码。解决这样的一个问题的核心关键点在于符合标准的组建及其对应的自动化。其中的挑战也往往会集中在三个部分：流程、研发和测试。
在流程方面，关于多环境的配置问题分为几种，比如安全性问题、每个环节上如何标准化执行；研发的标准化有三个方面：标准的建立、标准的自动化、细节。廖强提到，大家在定义接口的时候很容易定义各种各样的接口，缺乏标准化，导致别人用起来很吃力。因此在整个业界，像 OpenAPI 这样的 API 描述规范是一个关键工具，很重要；测试的挑战则来源于两个方面：代码覆盖率 100%、测试串行的效率。
最后关于未来产品的开发方式，廖强提到，当数据结构、定义等所有东西都被自动化后，我们只需定义产品的核心逻辑是什么。在此基础上，是否可以再抽象出一种语言，一种产品经理的语言，当产品经理画完之后这个产品也就出来了。这是未来流水线最核心的方式。
圆桌对话：开发和产品经理高效协同的秘诀
开发团队和产品经理是彼此重要的合作伙伴，也是一个团队，共同来设计和推进一款产品。但是，在实际合作中，开发团队与产品经理如何相互理解并协同工作，不是一件容易的事情。本次圆桌，倍施特科技产品总监刘东升、成都软易达 CTO 黄晓东、成都数字天空 CTO 覃小春、华为云 DevCIoud 西部地区业务总监邱志勇剖析了开发团队与产品经理在实际过程中遇到的“冲突”，并分享了开发和产品经理如何高效协同的经验。
倍施特科技产品总监刘东升
倍施特科技产品总监刘东升表示，站在研发团队的角度看，产品经理做好两个点和两类事能够在某些特定的程度上更好地支撑开发团队开展工作，促进彼此高效协同。首先是两类事：第一、对于做 2B 的行业软件企业，产品经理应尽量按照瀑布流软件开发习惯，输出 Word 版的详细产品需求规格说明书，尽可能穷尽细节。相比脑图或原型，清清楚楚的文字需求更加精准，因为只有想清楚了，才能写成一段话；第二、对于消费互联网的 2C 产品，建议用高效的交付方式，即沟通代替文档，用点对点的高效沟通把需求理解快速统一，配上简单的原型，或者交付的表达就可以。
关于两个点：第一个点就是“把需求想清楚”，无论哪个行业的产品，无论交付文档的粒度粗细，一定要把需求用文字写下来，给自己看，推敲斟酌后对外输出，既是打算口述给开发；第二个点就是验收环节，验收必须是伴随式的，产品经理一定要在平时深入到开发团队中，多和前端、后端、运维聊天，不断地重复你想要什么，请他们展示阶段成果，这样做才能够及时纠偏，不会到最后收到一个离需求千差万别的东西。
成都数字天空 CTO 覃小春
成都数字天空 CTO 覃小春表示，开发人员在和产品经理沟通时要注意把做产品的目标、目的聊清楚了。特别是在成都数字天空做文化这件事情里，会有导演、编剧的角色，他们不懂 IT 相关的东西。有时候他们可能会提出一些方法，但实际上这些方法可能已经过时了，也有一定的可能这些方法并不能处理问题。这时候作为开发者要看他们在追求什么，要看背后的逻辑是什么，然后从自己的专业维度上给出好方法，才能真正处理问题。
成都软易达 CTO 黄晓东表示，产品经理在进行需求调研和分析时，对于干系人讲述的内容，并不一定是客观的，有的甚至是伪需求，因为有时候真正的需求是不方便或不太好描述的，产品经理要能够听到弦外之音。我认为从开发者的角度来看，需要有自主的时间来做编码工作，这时候需要产品经理、项目经理等从制度上予以保障，尽量在规定时间内不要打扰他们。另外，开发人员身处开发“一线”，关注到更多细节，可能会发现一些风险，这时开发人员应及时反馈，这样有助于团队的风险管控。
华为云 DevCIoud 西部地区业务总监邱志勇表示，如果我是一个开发人员，我会走得更靠前一点。第一，弄清楚做这个事情要达到什么目的，也就是价值。华为公司对价值有一个比较明确的定义，即你要为客户解决的是什么样的问题；第二，站在交付团队来说，我会关心这个需求的工作量和技术难度，是否能够按时交付；第三是验收的标准，现在业界强调实例化需求，在项目开始的时候我就要明确有哪些验收标准。
在 2019 年的尾巴上，成都的开发者不仅收获了来自优秀专家们的实践经验分享，也拓展了技术交流的渠道。截止到目前，华为云“DevRun”已经在全国范围内举办了数十场，其聚焦技术创新与解决方案、注重实践与干货分享的特点吸引了众多开发者参加。2020 年，我们还将继续！
2019 年还有哪些精彩等着你？
12 月 28 日，「Atlas Tech Now | 昇腾学院——华为昇腾 AI 技术沙龙」苏州站，将在苏州人工智能产业园举行。届时将有多位华为资深 AI 技术专家，为现场开发者深入解读全栈全场景 AI 计算框架，并通过基于 Atlas 人工智能计算平台与开发工具的实践案例，让开发者快速上手 AI 开发的全流程。
