前言:
软件开发本身就是一个持续改善的过程;一个从无知到智慧的过程。
在软件开发的世界里,没有标准答案。
在软件开发的世界里,没有任何一个人能为软件开发制定所谓的 “统一标准”、“统一规范”; 例如: 没有任何一个人, 能规定微服务的架构只能这样设计, 不能那样设计。
在软件开发的世界里,我们真正需要的是 “持续改善”;有效、有智慧的持续改善。
本文:
所以,不论是 CMMi 或著是敏捷开发,都是在指引着我们如何在软件开发的过程中,能做好 “持续改善”。
为何 CMMi, 敏捷要这么做?
因为,软件开发的过程,本身就是一个 “学习的过程”:
既然软件开发是一个学习的过程,所以,什么样的流程,什么样的工程实践,什么样的自动化工具最适合团队,也同样是要经由一段 “学习的过程”;持续改善;才能有所结论的。
这道理大家都明白,但,为何总是做得似乎不大好?
不论是在 CMMi, 还是在敏捷开发,我们都还是习惯用 “标准答案” 去界定我们的软件开发做得好不好?做得对不对?而所谓的持续改善,也只是肤浅的将不符合标准答案的部分,“修改” 为符合标准答案。
真正的问题到底出在那?
除了软件开发在度量上缺乏 “持续改善” 的思维、作法、数据以外,另外的一个问题就是⋯
Cloud-Native 元素卡就是要借由轻量级、可视化的 “卡片” 来解决这个问题;使得团队永远可随时将不适用的软件架构决策卡片、工程实践卡片、开发框架卡片、自动化工具卡片给移出,给舍弃,同时也能随时加入适合的各类型卡片。
团队中的各不同角色; 产品经理、架构师、开发人员、测试人员; 在 “Cloud-Native微服务板 (请参考图一)” 前协作:
当第一个版本的微服务被部署到蓝线上后, 团队便想针对以下的问题进行 "持续改善":
所以, 团队决定将 KAFKA 引入到第一个版本的微服务架构中, 并新增了 KAFKA Cloud-Native 元素卡; 以 “持续改善” 团队 Cloud-Native 微服务的软件架构的决策、工程的实践、开发的框架、自动化的工具。
结论:
Cloud-Native 元素卡使得团队中的各个不同的角色; 产品经理、架构师、开发人员、测试人员; 能在 Cloud-Native 微服务板前高效的协作, 大幅的缩减了团队在 Cloud-Native 微服务设计上所需花费的时间。而使得开发人员能更快速的将微服务部署到蓝线上, 进而使得团队能在更短的时间内, 就能发现已开发完成的微服务在粒度、软件架构决策、开发框架、自动化工具上所存在的风险或缺陷。
团队更可以从所发现到的风险或缺陷中, 设计新的 Cloud-Native 元素卡或淘汰不适宜的 Cloud-Native 元素卡; 以持续改善团队 Cloud-Native 微服务的软件架构的决策、工程的实践、开发的框架、自动化的工具。
软件开发的本质就是 “持续改善”;我们也正在逐步的打造一个 “软件开发持续改善的生态系统”。
附注:
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。