软件开发模型(2)

下放权利

重视反馈回路， 通过反馈来不断改进系统

质量管理

提供持续改善

Culture文化

持续尝试和学习的文化，以及对于事故处理的学习态度

Lean（精益软件开发模型）2003年

DevOps模型2013年

“最简可行产品”——用最快、最简明的方式建立一个可用的产品原型，这个原型要表达出你产品最终想要的效果，然后通过迭代来完善细节。

建立可视化的工作流追踪，提升工作完成效率

尽早测试，多去尝试一些新的方案，听取反馈与其他团队或成员，用户多沟通，不断改善产品

全局优化

运维研发沟通

Prometheus Grafana

业务

ThreeWays 模型

Kanban模型2004年

降低迭代周期更快的发布产品

系统性思考整个工作流

运行维护

容量规划

透明，目标清晰

Measurement监测

可建立快速通道处理紧急任务

设置流转规则，不能盲目迁移

知识分享

持续学习

Automation自动化

快速发布

Lean模型2003年

可见性，提供持续反馈

使用不同颜色便利贴体现紧急程度

开发

根据需要建立不同的列

企业与技术氛围

监测服务质量

Ansible/Chef/Puppet

Sharing共享

CI/CD

减少浪费

迭代增强模型（增量模型）1975年

不必要的功能和代码软件开发过程的延迟不明确的需求繁文缛节低效的内部沟通

识别存在的问题，并持续改进

提升开发人员自主选择的权利，从底部持续优化

CAMS模型

采用的敏捷方式，Scrum或Kanban

限制每个流程最大的处理工作量

Infrastructure As Code

Scrum开发1995年

融合运维和开发团队，继承其他敏捷开发的方式，没有具体的实现，只是提供一种软件开发管理的方式。

降低部门之间沟通成本，消除隔阂，DevOps趋势发展

贯穿每一个环节，而不只是测试阶段

瀑布模型1970年

螺旋模型1986年

建立从需求到用户的整个链路，优化处理流程

用户