敏捷基础之质量内建
质量内建：产品一旦被发布之后就有了好坏之分，通过某些检验方式已经无法提高或保证它的质量，所以质量检验必须内置在产品或服务构建的过程中，而不能在它发布之后。
总而言之，质量内建必须是在产品或服务构建的过程中的， 而不是发布之后的。
非质量内建的一些质量维护措施
监控报警
通过监控项目的日志， 数据库， 运行系统的运行情况，当发生错误（错误日志），cpu或内存 负载过高，发生了数据库慢查询 等等， 通过监控系统发出报警， 显示对应的报表。 开发再根据对应的时间点， 事后进行处理修复完善。
代码回顾，日常的优秀代码show
有些公司会在代码发布后， 或者是 固定一段时间，让开发人员把自己认为好的代码， 认为不好的代码， 进行回顾讨论，期望能通过讨论提高开发人员的代码能力， 间接提高项目质量。
测试人员测试
测试人员测试 不属于质量内建。 一般测试发生于产品构建之后， 测试人员再进行对应的功能的测试。测试出结果， 开发修复，修复完再测试， 可以说无限循环。
质量内建措施
上面这些居然都不是质量内建， 那么质量内建要怎么做呢？
单元测试
单元测试，单元测试是开发人员自我保证代码质量最好的方式， 假设你是一名开发人员， 开发了一个功能， 只是简单的进行调用测试，然后就丢给测试人员。测试完再修复bug， 有bug就继续修复，一直持续。 假设你现在是这个状态， 你应该想到为什么总是很多漏洞，怎样才能交付给测试人员一个质量比较有保证的版本，而不是依靠测试人员测试，返工修复。
做IT行业的都知道单元测试， 每个人都知道说有单元测试会保证质量，但是很多团队就是无法实施下去，“单元测试” 在他们看来就是一项耗时间，维护困难，没有太大意义的上级要求做的麻烦事情。 然而并不是， 在业界对单元测试已经发展了很久， 为了解决 单元测试 的一系列困难， 整个单元测试 框架 也不断的进化， 更加简单， 更加快速， 更加容易维护。睁眼看世界，多看看行业的变化。
代码扫描
使用代码扫描工具（Sonar， checkMark）进行代码扫描，在开发过程中， 分析有问题的代码， 并立即修复， 无须等到测试才发现。
Git Hook集成
通过对git hook(husky)集成单元测试， 代码扫描工具， 在push到远程代码仓库之前，进行对应的代码检测，单元测试，单元测试覆盖率到达标准， 确保提交到远程的代码质量， 不达标，不予提交。
Pull Request 代码Review
对每一个所做的修改， 都使用pull request进行管理， 可以参照Git工作流，每个pull request都全团队进行代码review， 建议在每日早会之后， 开发人员进行代码昨天提交的pr的代码review。
总结
以上就是 敏捷中质量内建的一些方式，也是业界比较常见的做法， 可以再发散一下， 是否有其他方式，可以在产品 开发或构建 过程中，提高产品质量。 希望大家可以能够更好的实施敏捷！