一、观点
- 计划不是用来限制变化的，而是用来适应变化的。
计划本身也是“管理单元”，计划对变化的适应能力来源于计划本身“粒度”的缩小。 - 软件研发是一个复杂过程
不要试图用复杂方法处理复杂过程，尝试将复杂过程简化成简单过程，再用简单方法处理简单过程。
这里让我想起了建造者模式，核心都是分解复杂过程，然后通过简单过程，组建完整的复杂流程。
- 管理属性和工程属性的衔接点，就是版本管理
版本管理就是让研发中的任何人都可以用一种简单的语言描述我们在做什么，做了什么，还有多少要做。 - 众多行业中谁最需要敏捷和DevOps?强烈依赖IT的非IT行业
金融行业的业务人员从来不觉得自己是干IT的；金融企业的IT人员从来不觉得自己是干金融的。 - 敏捷提供创新的大脑，DevOps提供创新的肌肉
- 研发效能提升的2大法宝
- 管理粒度
管理角度的优化永远是在通过控制“管理单元”的粒度来完成的。所谓的“管理单元”可能是团队，需求，任务，测试，交付物等任何研发中的被管理对象。 - 提升效能
无论是敏捷，精益或者持续交付，其最终目的都是为了提升效能。所谓“效能”，就是持续适应市场变化调整自身价值输出方式和速度的能力。 - 工程解耦
技术角度的优化永远是在通过解除“工程对象”之间的耦合实现的。所谓“工程对象”可能是系统、工具、代码、模块、服务、平台、云或者任何在研发过程中存在或者交付的“技术对象”。
- 忘记敏捷和DevOps，记住“效能”
所谓“效能”：就是持续适应市场变化，调整自身价值输出方式和速度的能力。 - 信号卡、看板
信号卡最早来源自精艺制造，最早出现在丰田生成系统（Toyota Production System,TPS）。目标：1、最高质量；2、最低成本；3、最小前置时间 。
精益制造体系通过看板形成“拉动系统”，带来控制库存，加速流通，灵活响应和促进改善等好处，最终让用户价值顺畅高质量地流动。
制造企业的的工人做的工作是“制造”，软件开发中的工作者做的工作是“创造”。
二、工具
1、docker
2、容器编排系统
支持部署到不同的环境（公有云、私有云、独立数据中心、虚拟机和实体机）
四大编排平台：
- Apache Mesos & Marathon (DC/OS)
- Google Kubernetes(k8s)
- Docker swarm(Docker datacenter)
- Microsoft Azure Service Fabric
3、CI/CD 流水线
CI/CD 流水线，其中 CI 代表持续集成（Continuous Integration），CD 代表持续交付（Continuous Delivery）和持续部署（Continuous Deployment）。
参考文档：《如何从零开始搭建 CI/CD 流水线》
4、Git代码管理
特性分支管理方法。
声明：本文内容是整理的学习笔记，内容来源徐磊老师的现场授课。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/68886.html
