开发者学堂课程【阿里巴巴研发效能提升实践系列公开课：内建过程质量】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/608/detail/8872
内建过程质量
内容介绍
一、研发效能
二、生产过程中的内建质量
三、内建质量
四、在Aone上设置准入规则
五、总结
本节课继续讲解研发效能提升实践系列的第五讲内建过程质量，也就是说如何在研发过程中保证过程的质量，而达到最终提交的质量。
一、研发效能
1、流动效率（响应力）
2、资源效率（吞吐量）
3、质量
研发效能的提升必须落实到协作、需求、工程、技术等实践中，主要属于团队、项目协作实践
二、生产过程中的内建质量
过程质量或内建质量是源自于生产领域的一种称呼，接下来可以了解到内建质量在生产领域指什么？在产品的开发中需要做什么？
1、以丰田的部分生产系统示意图为例：
图中有车刀或者车床，在旋转其中的一颗螺纹，这是一个自动的生产线。在此过程中，不难发现，工件在不断输入，而成品也在不断输出，如果一切正常，那就是一个很好的全自动化的生产线。
2、丰田提出的两种概念
（1）、自动化（Automation）
自动化图例：
自动化正常时，一切都好；但是当自动化异常发生时
如：车刀在出现裂纹时还是会生产出残次品
在自动化中，当异常发生时,并不能自动感知异常；便会继续产出有问题的产品；当问题产品进入下一环节，比如说装配环节,就会带来进一步的浪费，或者将直接影响整批产品的质量；就算发现问题时，问题也已经存在了许久,如此很难找到根本原因，只能通过回溯查找出原因。
（2）、自动化(auto-no-mation)
理想中的自动化图例：
自动化异常发生时
在丰田中，称之为应该赋予机器人与智能，也就是说当发生异常时，会自动感知异常，比如在此图中，车刀发生裂纹时，机器能自动感知并停止生产，杜绝让有问题产品进入下一环节，工作人员会现场分析根本原因，并纠正。在丰田此种做法称为现时、现地查找法,更能查出根本原因，并彻底解决问题。
这种过程便会称为内建质量：
在每个工件的每一个环节内建质量，而不是依赖于最后的检测环节。
详解：
就是说在每一个工件的每一个环节中内建质量，目的是为了要让每一个工件得到质量的保证，而工件生产的每一个产品都需要得到保证，不管是一个螺纹或者是对产品的精加工，在每一个环节都要保证质量，不要把问题带到下一个环节，也不要依赖检测环节来保证质量。学习的目的是提高研发环境的质量，讲的生产只是比喻。
三、内建质量
1、之前讲的看板，把开发分为各个环节；需求和各个环节不断的流动；此时把以需求为单位保障各环节的质量，（而不是一组需求，比如以一版本为单位来控制需求，）把质量内建到每个需求的各个过程环节中称为内建质量。
2、如何做到
（1）在产品开发过程中会有各类规则：
定制的规则或者是官方的规则，有隐藏或不明确的规则，也有合理或者不合理的、过时的或者新添加的规则，这些规则隐藏在各处，但是有了看板，就有了需求流动过程，这样能有机会去
（2）显示化定义规则：
基于价值流转组织规则和明确定义和显示呈现规则，使得团队用有和使用规则并在实践中持续改进，至此这些规则合理为止。
（3）规则示意图：
看板的各个环节中，可以定义这些规则。比如说选择这一类，为什么要选择这些需求，那就是这个需求的接收标准；比如说就绪这一类的需求，对于开发团队的就绪是开发特定的输入，就需要定义相关的就绪标准；比如说任务的完成，则需要定义代码提交的标准；比如说需求如何才能进入待测试，这是开发的输出标准，也是测试的输入标准，一般称为转测试标准。
（4）举例就绪规则：
就绪是说需求对于开发就绪，可以进入开发过程中，是开发的输入。在 it 行业中，garbage in、garbage out 输入的是垃圾，输出的也是垃圾。作为输入规则，这对于开发尤其重要。
以下便是例子：
①、开发、测试和业务共同澄清需求，定义明确交互过程和验收标准
详解：
需求进入就绪，所期望的是需求能顺畅地向下流动，而不是出现走走停停的问题；在项目管理中，这种现象称为风险。在进入就绪的需求，会应对到业务风险，是指需求不够清晰。
②、已与业务关联方(如有）确认相关计划
详解：
应对的是关联风险，防止第三方不能满足需求。
③、识别大的技术凤险并定义应对方案（应对技术风险）
④、大需求已进行拆分到可以在两周以内完成（应对协作风险）
⑤、诚及三个开发人员以上的需求，指定好协调人，负责进度协调（应对协作风险）
为了后面进入这个行业中的这一类需求能够更加通畅才做出的这些规则，为此需要处理好业务风险、关联风险、技术风险和操作风险，为什么要去定义规则本身？是因为在实施的过程中不断总结出来的，如果有其他发现也可以进行添加，其他规则同样重要，可以举例说明已选择规则和待测试规则；
已选择规则：
①、定义明确的业务场景和解决的用户问题
②、定义要达成的目标及衡量方法
③、与技术团队初步确认技术的可行性
④、定义了明确的优先级
待测试规则：
①、开发对照需求验收标准进行了自测
②、通过了持续集成环境的所有测试
③、己通过Show case演示环节
可以给各个阶级定义规则，但是并不代表定义规则的合理性，还需要在开发过程中不断演进这些规则。
四、在Aone上设置准入规则
1、准入规则设置
2、准入规则可调整，并不是一成不变的
转入规则设置：
一起了解在aone上如何设置规则，其实每一列都可以进行·准入规则的设置，第一步把定义的规则输入到aone的看板中，作为对用户的提示，这是用户对开发者共同承诺的共识。在开发过程中，还可以进行不断地改变，改变规则的反映，之后所取的改进或者对需要进行的改进。规则是可以持续调整的，转入规则有改进的期限，而不是一成不变的标准。
3、定义规则的作用
这种规则应该是团队共同拥有的，如果规则是模糊的，团队中的很多讨论便会陷入主管情绪化；对于有明确规则的团队，讨论就会是客观理性的。
举例：
主观情绪化 |
客观理性 |
“我觉得质量差就是因为他们没有起码的责任心。” |
“我们一起看一下，质量问题究竟是哪个环节的原因，是规则不合理、不清楚还是执行不到位?” |
“凭什么内部改进需求始终不让做啊？” |
“我们需要投入10％左右的人力到技术改造和优化的需求上，未来半年，我们每完成10个业务需求，就开始一个新的技术需求把。” |
从中看出：规则是一个团队执行的标准，是客观理性的一个依据，更重要的一点是，规则是一个改进的基线，如果缺少规则，那问题便会反复，团队这时应该制定相应的规则，有了规则，便会有序的进行；规则本身是一个动态的过程，需要不断地调整和优化。
五、总结
1、以需求为单位保障各环节的质量，把质量内建到每个需求的各个过程环节；
2、明确定义和持续改进各环节的流程规则，按照价值流转和团队协作来组织规则并显式呈现这些规则；
3、明确定义的规则是团队协作和决策的基础，让团队的协作更有依据；
4、明确定义的规则更是持续改进的基线，在执行反馈过程中不断改进团队规则。
