| |
研发过程与质量的探讨
@同行茶话沙龙 |
| |
俎涛（zutao@uml.net.），2016年12月25。 |
| |
说明：本文中的靶点对标和问题与挑战，由3位专家提供（苗再清，刘莉莉，李庆文） |
| |
|
|
2016年12月24日，平安夜，同行茶话：研发过程与质量沙龙成功举办。来自火龙果软件、京东、58到家，法国电信，航天信息，四维图新，阿里巴巴的7位专家，就共同的话题： |
| |
1. 我们的企业定位
2.当前研发背景
用户的价值观
产品发布周期
产品质量要求
3.研发过程与质量经验谈：
产品组织
流程组织
人员组织
质量保证方法
4.问题与挑战 |
|
| |
|
| |
从各自的视角分享经验，共同探讨、学习。
| 姓名 |
单位 |
| 俎涛 |
火龙果软件工程创始人 |
| 苗再清 |
京东商城质量总监 |
| 王楠 |
阿里巴巴高级专家 |
| 李庆文 |
58到家质量总监 |
| 张健 |
航天信息质量部副部长 |
| 俪小敏 |
法国电信质量经理 |
| 刘莉莉 |
四维图新研发部门过程改进负责人 |
|
| |
|
| |
如下是交流的总结记录 |
| |
靶点的设定 |
| |
俎涛首先发言，提出了本次沙龙的共同靶点： |
| |
|
|
| |
欢迎大家来到同行茶话，一起交流经验、碰撞火花。 |
| |
本次沙龙的主题是《研发过程与质量》。 |
| |
首先给大家介绍一下为什么想组织一个这样的话题。//希望大家能够畅所欲言、展示客观真实的一面，互相学习好的经验，问题解决之道。 |
| |
因为培训和咨询的关系，我们接触过很多企业，大家都希望建立有效的软件工程和质量管理体系。大家的目标相同、问题也接近，例如需求变更、开发效率低、质量难以保证、人力资源和技能不足。很多企业虽然经历多年努力，参考各种软件工程规范（例如先是CMMI，后是敏捷）建立了研发过程和质量体系，但却没有起到预期的作用。在这里，希望能够来自于不同行业的典型代表，向大家展示真实而平凡的一面，启发各自的思考，萃取宝贵的经验。 |
| |
行业很多，在这里仅列举部分体现行业差异如下： |
| |
| 行业 |
特点 |
研发价值观 |
| 互联网，例如：电商、O2O |
面对大众用户，开拓商机 |
用户体验至上，快速响应能力 |
| 汽车电子，航空电子，轨道交通 |
高可靠，安全第一 |
质量第一 |
| 企业信息化，例如：电力、银行、电子政务 |
ＩＴ系统和业务紧密结合 |
企业架构，业务与IT整合。 |
|
| |
软件过程方面，典型的过程参考模型如下： |
| |
| 过程模式 |
特点 |
产生背景 |
| CMMI |
严谨的过程评价、改进与组织。强调好的过程能产生好的产品。 |
企业对IT供应商的软件工程能力进行评价和选择。 |
| SCRUM &敏捷 |
以迭代开发，响应变化，降低复杂度，实现快速交付。 |
互联网行业的快速交付、持续发布。 |
| MBSE(模型驱动系统工程) |
模型驱动的系统需求、设计、开发、测试。实现各个专业的工作紧密衔接和集成。 |
系统工程领域，希望提高系统可靠性。 |
| DevOps |
打通开发和运维，实现二者的闭环迭代，快速响应。 |
互联网微服务，以用户服务视角组织开发和运维。 |
| IPD |
着重市场价值驱动的联合产品开发。 |
用于改造整个企业的市场管理、产品管理、研发管理。 |
|
| |
|
| |
 |
| |
|
| |
MBSE(模型驱动系统工程)：基于模型进行系统分析设计、子系统分析设计、模块分析设计、软件和硬件分析设计，实现严谨的自顶向下的分解，进而通过跟踪实现工程追溯和严谨性。 |
| |
|
| |
|
| |
DevOps：集成开发、发布、运维整个IT生命周期，实现工作闭环，进而提高质量和响应速度。 |
| |
 |
| |
|
| |
敏捷与Scrum：一种敏捷过程框架，由ProductOwner、ScrumMaster、开发、测试组成的敏捷团队，基于ProductBacklog制定发布计划，并分解到迭代计划，实现迭代性开发和验证。 |
| |
 |
| |
|
| |
IPD（集成产品开发过程）：是覆盖整个企业层面的一套产品开发管理的思想、模式和方法，本质上是一种产品经营管理的模式。综合考虑投资、市场、产品、技术、人员、成本等各种因素，建立跨部门联合开发团队，实现市场驱动的产品开发和交付。 |
| |
 |
| |
|
| |
那么，那个过程好呢，这需要从用户、老板、工作人员3个视角进行综合评价，只有3个视角都觉得符合自己的期望，才是能够被执行和不断改进的。三个视角关注的内容如下图： |
| |
 |
| |
|
| |
 用户关注最终的产品是否有用、好用。 |
| |
老板关注研发产品的流程是否高效率、低成本。 |
| |
工程师关注研发产品的工作是否简单可行。 |
| |
可见三者的利益因为站在不同的利益角度，并不是简单的一致，而是存在某些差异性。 |
| |
|
| |
那么，什么是好的过程呢？ |
| |
应该是三者皆大欢喜、而且能够协调三者之间的关系，最后实现利益一致。 |
| |
|
| |
那么如何组织过程呢： |
| |
|
应该首先从用户角度划分产品，这是顶级过程，关注的是价值； 各个产品之间的关系一般是并行过程，例如 微软的产品office和window，各个产品之间的关系一般是商业工作流关系——价值组合关系，并不是研发过程关系。 |
|
| |
|
然后，从管理者的角度，分解产品研发过程为各个worker的工作，实现从用户请求到最终交付的快速响应，高效率，低成本。 |
|
| |
|
最后从worker角度，考虑当前可行的人员能力，分解为工作任务。因为一个人同时只能执行一个工作任务，所以组织任务的时候要考虑多人多任务的协调关系。 |
|
| |
|
| |
而过程的执行最重要的基础就是人，再好的过程，如果没有人愿意执行，也会流于形式。不好的过程，大家都乐意执行，也会碰撞出高效的火花。
说到人，一般会涉及到企业文化、团队士气和个人情感，这些说起来似乎有点虚，花虚无为实际的行动则需要大智慧。 |
| |
|
| |
 |
| |
下面期待各位能够救如下4个方面分享真实故事： |
| |
产品组织 |
| |
流程组织 |
| |
人员组织 |
| |
工具使用 |
| |
质量保证方法 |
| |
|
| |
|
| |
靶点对标 |
| |
|
| |
分别由三位专家，分别介绍了各自企业的过程与质量情况，如下是把三位专家的共同靶点的对标 |
| |
|
| |
| |
苗再清（京东质量总监） |
刘莉莉（四维图新过程改进负责人） |
李庆文（58到家质量总监） |
| 企业定位 |
作为一家什么企业 |
京东：中国最大的自营电商 |
四维图新：图商解决方案提供商 |
58到家，上门oto， |
| 为什么用户 |
全世界各行各业的个人及企事业单位、社团等 |
车厂，互联网，行业用户 |
生活大众 |
| 提供什么产品 |
提供物美价廉的保真商口。真品，正品是京东的核心竞争力之一。 |
离线地图，在线地图服务，动态交通信息服务，车联网整体解决方案 |
提供生活服务； |
| |
| 产品组织 |
产品如何划分 |
京东的产品是按业务线划分，主要分零售，交易，仓储，物流，支付，结算，广告，金融等 八大产品线 |
按地图上的要素划分产品：基础地图、高精度地图、专题地图（桩家） 按客户规格划分产平：例如欧美系车厂MIFG、本地车厂NavEx、日系车厂AIF |
3+1； 3个自营业务，1个平台业务 |
| 由谁负责管控 |
每个产品有一个团队负责人，在京东叫做PO（不是敏捷中的PO），由PO负责这个产品的升级和维护。如果这个产品启动了一个项目
，则PMO会安排一个PM进行项目管量 |
公司有专门的产品企划部门 |
业务之间各自为战 |
| 产品发布周期如何定义 |
没有明确的产品发布周期定议，在京东产品的发布非常频繁，基本上每次上线都作为一次产品发布。 |
根据产品质量和更新频度划分： 日：重要情报快速更新（POI-关键地图点位+高速道路） 月：基础地图数据更新
季：高精度&高质量地图数据部分更新 |
客户端大版本每月一次（含所有业务线），涉及 常规需求scrum，每周四 运营需求随时上线（例如
节日活动）。 |
| |
| 过程组织 |
过程参考模型 |
过程参考模型是CMMI，PMBOK及敏捷。 |
汽车行业软件研发过程规范ASPICE [注2] 质量规范TS16949（地图生产为主）[注3] |
研发过程分为三类：
1.常规业务开发过程：采用SCRUM每周迭代，每月版本发布。
2.运营类开发过程：根据需要，快速处理请求，响应速度第一。
3.技术类：根据具体技术的需要，制定开发过程。
|
| 过程如何建立 |
过程的建立在研发部有一个总的框架，更具体的过程由各个研发团队自已建立。 |
体系对标&差距分析-过程梳理-过程建立 采用自上而下和 自下而上2个角度。 |
业务优先，研发效率其次 |
| 执行如何落地 |
落地方面各个研发团队有很大的自主性，因此现在各个团队的落地情况参 差不齐，主要看各个团队PO的意识水平 |
过程落实到具体部门／组织 定期审核 |
试点，评估，推广 |
| 过程如何改进 |
研发质量部会在关键点上推动一些研发部级的改进，更具体的改进由各个产品团队自主进行 |
内部问题
度量指标
改进意见 |
不停迭代打磨 |
| |
| 人员 |
人员协作关系原则 |
京东的研发工作主要分两大类，一是项目类，一是维护类，项目类的协作由PM负责，而日常级护类工作的协作由研发人员或者研发团队的PO负责。
组织结构按照业务单元划分为da部门，大部门下面再分为业务和IT2个部门，为了统一的业务目标努力。符合最终价值利益。 |
敢于暴露问题、大家共同协商、各司其职不推诿 |
业务优先，按照业务划分工作。 各司其责，
快速补位：根据业务发展和需要快速调整人员。 |
| 人员能力如何评价 |
人力资源部每年度有人才盘点，360度评价，每个人在人才九宫格中有相应的位置。 |
岗位职级评审（参考了腾讯的岗位序列+职级） |
PM: 需求收益偏差，需要对业务效果负责。 RD: 缺陷密度，lpd（参考值） QA: 测试方法，漏测率 |
| 人员如何培养 |
在人才培养方面主要由京东大学负责，各个研发团队也有自已的培养流程。HR与京东大学配合，对于不同职级的人员有不同的课程，有必修课和选修课。最近几年又开展了京东一二三年级的人才培养计划。另外京东大学制作了数以万计的教学视频，京东员工可以自已进行e-learning |
新星培养计划。 在职大讲堂，内部分享和外聘专家结合。 采用导师制师傅带徒弟。 |
培+练 |
| 工具 |
公司统一推行研发支持工具，例如配置管理、持续集成、测试工具。但是是否使用由团队自己决定。团队会根据需要自己搭建工具，未必一定用推荐的。
系统上线很频繁，1年几千次，影响面大，绝对要求使用同一工具审批、自动化上线。 |
公司统一推行一些工具，是否使用由团队根据自己情况决定。 |
工具自动化并不强调，更针对当前快速发展，强调业务快速支持，达到当前预期。 |
| 质量 |
质量价值观是什么 |
在质量方面，京东CTO一直强调的是没有质量一切等于零，每个人做好自已的事情，强调自我管理 |
从不认为制造的缺陷是不可避免的，从不认为缺陷的代价是微不足道的，从不认为代价的清偿是金钱可度的。
|
业务效果是生命，IT研发质量是生命线。在保证生命的基础上强调生命线。 |
| 产品质量如何保障 |
1、各个二级部门都有独立的测试团队 2、具有专门的自动化测试平台 3、统一的静态代码扫描工具
4、评审 |
对产品质量、项目进度等各种工程数据建立监察体系。 软件检测手段（统计差分、验证） |
从产出需求开始，给出监控项 |
| 过程质量如何保障 |
过程质量的保障手段有 1）公司每年都有SOX404[注1]内审和外审，这个对于各个过程都有明确的要求和产出物
2）研发团队自主保证本地过程 3）质量管理部统一对质量关键过程进行推进 |
过程度量指标 评审 |
结果反推 |
| |
|
| |
|
| |
问题与挑战 |
| |
|
| |
苗再清（京东质量总监) |
| |
| 问题 |
解决思路 |
| 面对频繁快速发布的现实，如何保证质量 |
1、利用大量的工具辅助质量保证
2、化繁为简，将复杂的质量保证体系进行简化，执行最有效的活动 |
| 在一个5000人以上的研发团队中，如何进行质量保证工作？ |
1、聚焦，每个时期只抓一两个关键质量保证过程，甚至将主要力量投入到几个研发团队上
2、树立标杆团队，并进行大力宣传
3、通过质量周报，发布横向对比数据，促进研发团队的改进
4、借助SOX404审计的力量 |
| 如何让研发团队认同质量部的工作 |
1、去掉所有形式化的东西，一切以实效为出发点；
2、与研发团队讨论，聚焦研发团队感兴趣的过程 |
|
| |
|
| |
刘莉莉（四维图新研发部门过程改进负责人） |
| |
| 问题 |
解决思路 |
| 多部门协作效率低 |
跨部门的项目合作制度落地
借力项目管理软件 |
| 质量体系与敏捷开发的冲突 |
系统化、自动化 |
| 过程度量指标难以量化 |
？？ //zutao：整个一直想做，目前是难点，正在梳理。 |
|
| |
|
| |
李庆文（58到家质量总监） |
| |
| 问题 |
解决思路 |
| 58同城系统演化 |
系统模型不同，很多情况还在沿用相同的过程 – 区别建模，逐步优化； |
| 业务速度和产品质量的权衡 |
创业阶段公司，不快即死 - 项目分级制 |
| 技术项目资源问题 |
？？//zutao：尽量提高工作效率，努力工作：） |
|
| |
|
| |
参谋建议 |
| |
|
| |
王楠，介绍了当前阿里云OS的质量管控方法，尤其是测试平台和测试自动化对于提高质量和效率的好处，并建议了人员激励方面的一些方法和建议。
俪小敏，介绍了法国电信跨过团队的协同工作方式，敏捷开发过程中遇到的问题和解决方法。 |
| |
|
| |
过程与质量的共识 |
| |
|
| |
什么是适合自己的过程？ |
| |
| |
大家觉得不同的企业，因为行业背景不同，面临的问题优先级不同，企业发展状况不同。对产品和过程的要求也就不同，所以研发过程和质量管控体系都应该围绕自己的研发特点建立。另外，应该充分考虑具体工作的可操作性，让工程师能够快速展开，乐于接受，分享力量。而不是高高在上，单向要求。这样的互相促进，才能够是规范和实际工作对接，管理和工作双赢，实现共同的产品价值目标。 |
|
| |
过程应该关注什么层次？企业如何参考？ |
| |
| |
敏捷关注开发团队，MBSE关注复杂系统分解开发过程，CMMI关注研发整体组织，IPD关注整个企业的产品运营。其实这些过程都是从不同专家角度提出的针对不同层面的问题解决方法，关注的角度和颗粒度不同，同时还存在互相交错的关系，所以参考的时候，应该首先定位当前遇到的问题的层次，然后再看看参考的过程框架是否合适，这样才能够恰当的认识问题和解决方法，有的放矢。避免盲目引入，自相矛盾，认为增加新的混乱。而实际上，企业的研发的问题，从来不是研发自身的问题，一定是跟市场、产品、技术、人员互相联动产生的问题，所以应该具有企业级别框架，也要具有操作级别的细节。因为各个企业具有很大的文化和产品、技术差异，所以真正有效地过程体系无疑需要自己广泛参考、透彻理解、不断尝试、研究，最后才能消化吸收为自己的有效工作与管理体系。 |
|
| |
最基本、最重要的还是人！ |
| |
| |
?无论是什么样的工程规范，最后落地的都是人，对于人的能力调度，需要3个方面：
1、充分调动人的工作责任感和积极性，是最重要的。有了这个基础，很多都不是事了，怎么调动人的积极性呢，还是要回归文化和利益。民主的文化，虽有些杂乱，但是积极性高。利益吗，需要决策层有足够的魄力，给出方向，然后可以具体化为分红、项目结果激励，采用能够打动人心的激励方式。
2、同时也需要强有力的领导，能够敢于引入、推行一些好的工程方法、工具，带动大家上进，而不是只是民主的散沙。
3、还需要建立淘汰机制，不断竞争才能进化，对落后者要敢于淘汰，让自然选择不断优化组织。 |
|
| |
关于工具： |
| |
| |
对于大型团队，工具非常重要，好的工程理念和方法的推广，不可能就只是靠培训和帮带，更需要简化为可行的工具，工作规则自动化、高效化。好的工具让大众从理念到行为，都有一个稳定的载体。但是工具如何选择，一定是基于工程的目标，对产品和业务的支持需要，当前人员现状结合的。 |
|
| |
|
| |
工程建议 |
| |
|
| |
当前的过程和质量问题，最终的目标是提高效率、降低成本。 |
| |
而这对于一个新的项目，其实都是很难的，因为大家的能力差别并不大，再好的过程，效果也有限。而且其实很多过程都很难严格遵循，因为新项目的问题是千奇百怪的，例如：资金不到位怎么办，大拿突然离职了怎么办，突然出现了一个强有力的竞争对手怎么办？很多看起来和工程关系不大，却又致命的影响，很难说用什么过程方法解决。解决的方法可能也是五花八门的，能见效的就好。
而企业研发更多成本是消耗到新产品项目的第一个版本的后续版本开发。例如windows研发已经20多年了。如何在一期生存的基础上，针对后续二期、三期的研发，找出规律、建立针对性过程，才是提高效率的重点。而过程无外乎当前大家公认的几大类，虽然有行业变体，但是差别不大，例如CMMI
在各个行业的演变，敏捷在各个领域的演变。 |
| |
而参考一下其他行业，例如机械制造、建筑、家具，效率的提升的关键是产品规范化、零件标准化、差异服务化。 |
| |
|
产品规范化，就是把大众各种各样的需要，规范为几个产品版本，减少产品版本数量，满足尽可能多的用户，这其实是一个产品设计的问题。 |
|
| |
|
零件标准化，就是把组装成各种产品的零件根据用户灵活化需要，拆分为可以独立变更的单元，变更可以采用替换或者参数调整，这样就能够快速响应需求变更。而零件标准化，必须解决零件的一些公共服务问题，例如运行环境管理、调度、访问接口，这就需要有平台支撑。技术平台和零件之间是密不可分的关系，缺一不可，这类似于机械领域装配框架和零件的关系。 |
|
| |
|
差异服务化：产品规范花了后，总是有对某些个性需求的损失，这其实也是当前产品之间的一个关键竞争，谁能在规范的基础上实现个性化，就能够赢得更多用户。这就需要在产品的个性需要和标准零件之间建立服务机制，可以快速用标准零件实现产品个性化。常见的服务方式可以是：零件选择、零件更新、参数配置，
而这些对于IT来说，也需要提高效率，采用自动化手段进行，这可以进一步引入到当前热点DevOps体系框架。 |
|
| |
|
| |
其实，如上3个方面，很多企业也注意到了，但是我们发现还是停留在方法论、或者技术工具上的偏多，反而是最重要的部分：产品内容、零件内容方面，进行整体梳理的少。 |
| |
|
| |
例如很少见到有企业梳理出来整体的产品目录、产品规范，公共组件（零件）仓库。 |
| |
为什么这样的，觉得需要4个方面的支持， |
| |
|
一个就是应该建立针对产品规范和零件的应用开发过程理论框架，而这个现在基本没有，大部分都是谈如何做一个新产品、新项目，一说到维护类的，也就是需求变更、缺陷处理流程，级别太低。这就需要软件开发过程要特别关注一种基于资产的研发过程，需要建立一个明确的、可行的过程指南。 |
|
| |
|
第二就是需要有人去梳理产品规范和公共组建仓库。这个说起来容易，做起来其实很难，因为很少有人能够具备这个整体视角，例如产品规范谁去梳理，按道理是产品经理，可实际上很多产品经理根本对产品就缺乏整体的、持续的了解。那就换为架构师，很多架构师又是重技术、轻业务，而产品的核心无疑是业务。那么谁来理呢？
应该结合产品经理和架构师，为这个事情专门成立一个委员会或者小组，作为工程和研发管理的基础，不断定期整理，这是非常值得的。 |
|
| |
|
第三就是需要有人去梳公共组件仓库。这个无疑是架构师整理出来目录，并为组件仓库建立公共空间，以鼓励、开放和自由的态度广泛接受开发人员提供的组件，并建立组件共享查找和激励机制，让好的组件被更多人认识、使用，提高效率。 |
|
| |
|
建立一个能够集成管理人员、产品、工作、能力、问题的工程管理框架，并提供工具支持，很多时候，不是不会管理，而是管理的成本太高，尤其是分为各个领域的时候，会造成不断加深各个专业，整体管理效率低，丧失整体目标。而其实以上这些都是围绕一个终极目标，那就是实现企业的核心价值。所以如果放在一起管理，反而是简单而有效。
|
|
| |
|
| |
下面就介绍一下 基于产品规范和平台和组件的开发过程路线图，如下图所示， |
| |
|
| |
 |
| |
|
| |
|
首先从产品外在角度，整理出来产品的规范，包括各个产品都分为哪些版本，每个版本有哪些功能。 |
|
| |
|
然后从产品内在角度，整理出来平台和组件，平台一般是面向技术的平台，例如 web、window、 Android多个技术平台。组件包括技术平台之上的公共组件和私有组件。 |
|
| |
|
建立产品规范和平台+组件的配置表。 |
|
| |
|
| |
在此基础上，如果来了一个新的版本应用开发需求，可以基于以前的产品规范或者版本，基于老版本描述新的版本的变更需求，在此基础上，分配变更需求到各个平台+组件的开发需求。组件的开发需求也是基于复用的思路，采用组件变更的方式进行描述。因为基于复用进行需求分析、组件设计和开发，这样就可以充分利用历史资产，最大化的提高效率和保证质量。如下图所示： |
| |
|
| |
 |
| |
|
| |
目前火龙果正在致力于这方面的方法的梳理（结合各个企业的问题和经验），基本已经成型；并在研发一个主持全面管理的研发管理工具（目标是简化管理：人员、产品、工作、能力、问题）。 |
| |
|
| |
 |
| |
|
| |
火龙果研发管理工具整体方案示意图
研发管理工具iWork界面图示 |
| |
|
| |
后记 |
| |
此次是火龙果软件工程第一次组织专家，就同一话题进行对靶讨论。大家结识了同行朋友，在轻松的茶话气氛中，各抒己见，互相启发。期待这能够在快速多变而浮躁的当下，为每一位参加者带来值得回味的美好时光，让新结识的朋友，互相多一份参考、多一句提醒
：） |
| |
标注： |
| |
1．SOX404为Sarbanes-Oxley法案的404条款：内部控制的管理评估。法案明确了管理层对与财务报表及与其相关的内部控制制度的有效性的责任，并要求管理层对此发表书面声明。旨在通过加大控制力度来加重上市公司决策人的责任。美国政府已强制性地要求所有公开交易公司必须于2005年底满足本部分的要求，与财务报告一起提供内部控制的年度管理报告
(CEO和CFO必须签署书面声明)，这之中包括：a、记录控制设计效力测试的结果， 对公司建立和维持足够的财务报告内部控制负有责任b、披露任何主要缺陷c、获取外部审计公司审核以证明相关报告。参考资料：SOX404条款—管理层实务指南(中文版) |
| |
|
| |
2. 汽车行业软件研发过程规范ASPICE（?Automotive SPICE是一个评估和改进系统及软件开发过程的标准，是由欧洲主要汽车制造商共同制定的面向汽车行业的流程评估模型。该模型参考了CMMI），参考资料：Automotive
SPICE 3.0与2.5比较 |
| |
|
| |
3. TS16949（国际标准化组织（ISO）于2002年3月公布的一项行业性的质量体系要求，是在ISO9001:2000质量标准体系基础上为汽车行业定制生产件与相关服务件的质量管理体系） |
| |
|
