前言:

软件开发本身就是一个持续改善的过程;一个从无知到智慧的过程。

在软件开发的世界里,没有标准答案。

在软件开发的世界里,没有任何一个人能为软件开发制定所谓的 “统一标准”、“统一规范”; 例如: 没有任何一个人, 能规定微服务的架构只能这样设计, 不能那样设计。

在软件开发的世界里,我们真正需要的是 “持续改善”;有效、有智慧的持续改善。

 

本文:

  • CMMi 是期望团队能在达到 CMMi-2,CMMi-3 时,建立起软件开发流程的规范。并期望团队在达到CMMi-4 时,能找出先前在 CMMi-2,CMMi-3 所建立的流程上的瓶颈、风险,而能在达到 CMMi-5 时,“持续改善” 软件开发的流程。
  • 敏捷开发期望团队能借由最直接的人与人之间的交互与最高效的自动化的工具,而能在最短的时间内反映出产品开发上的瓶颈、风险。

所以,不论是 CMMi 或著是敏捷开发,都在指引着我们如何在软件开发的过程中,能做好 “持续改善”。

为何 CMMi,敏捷要这么做?

因为,软件开发的过程,本身就是一个 “学习的过程”:

  • 学习着如何能更加贴近用户的想法、行为?
  • 学习着如何能对用户产生更多正面的影响?
  • 学习着如何能在更正确的时间,交付更有价值的产品?

既然软件开发是一个学习的过程,所以,什么样的流程,什么样的工程实践,什么样的自动化工具最适合团队,也同样是要经由一段 “学习的过程”;持续改善;才能有所结论的。

这道理大家都明白,但,为何总是做得似乎不大好?

不论是在 CMMi,还是在敏捷开发,我们都还是习惯用 “标准答案” 去界定我们的软件开发做得好不好?做得对不对?而所谓的持续改善,也只是肤浅的将不符合标准答案的部分,“修改” 为符合标准答案。

真正的问题到底出在那?

除了软件开发在度量上缺乏 “持续改善” 的思维、作法、数据以外,另一个的问题就是⋯

  • 我们缺乏一个可视化、轻量级的工具;可以使得我们在发现软件开发问题的同时, 就能持续改善软件架构的决策、工程的实践、开发的框架、自动化的工具。

Cloud-Native 元素卡就是要借由轻量级、可视化的 卡片来解决这个问题;使得团队永远可随时将不适用的软件架构决策卡片、工程实践卡片、开发框架卡片、自动化工具卡片给移出,给舍弃,同时也能随时加入适合的各类型卡片。

 

[图一: Cloud-Native 微服务板]

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

团队中的各不同角色; 产品经理、架构师、开发人员、测试人员; 在 “Cloud-Native 微服务板 (请参考图一)” 前协作:

  • 在 Cloud-Native 微服务板上的 Cloud-Native 元素卡的指引下, 团队对价值特性与外部用户、产品的交互场景、功能达成共识; 请参考图二。
  • 在 Cloud-Native 微服务板上的 Cloud-Native 元素卡的指引下, 团队对微服务的粒度达成共识; 请参考图二。
  • 在Cloud-Native 微服务板上的 Cloud-Native 元素卡的指引下, 团队对微服务的 Restful 接口、事件达成共识; 请参考图二。

 

[图二: Cloud-Native 元素卡]

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  • Cloud-Native 微服务板上的 Cloud-Native元素卡的指引下, 团队对微服务的软件架构方案、开发的框架达成共识; 请参考图三。
[图三: Cloud-Native 元素卡]

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

开发人员便以 Restful, gRPC 开发著第一个版本的微服务, 并将微服务先部署到蓝线上。请参考图四。

[图四: 蓝线部署、绿线发布]

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

当第一个版本的微服务被部署到蓝线上后, 团队便想针对以下的问题进行持续改善:

  • 微服务间的高藕合
  • 不易处里异步事件流
  • 不易传送、合并有业务关连性的数据集

所以, 团队决定将 KAFKA 引入到第一个版本的微服务架构中, 并新增了 KAFKA Cloud-Native 元素卡; 以 “持续改善” 团队 Cloud-Native 微服务的软件架构的决策、工程的实践、开发的框架、自动化的工具。

[图五: 团队新增了 KAFKA Cloud-Native 元素卡]

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

结论:

Cloud-Native 元素卡使得团队中的各个不同的角色; 产品经理、架构师、开发人员、测试人员; 能在 Cloud-Native 微服务板前高效的协作, 大幅的缩减了团队在 Cloud-Native 微服务设计上所需花费的时间。而使得开发人员能更快速的将微服务部署到蓝线上, 进而使得团队能在更短的时间内, 就能发现已开发完成的微服务在粒度、软件架构决策、开发框架、自动化工具上所存在的风险或缺陷。

团队更可以从所发现到的风险或缺陷中, 设计新的 Cloud-Native 元素卡或淘汰不适宜的 Cloud-Native 元素卡; 以持续改善团队 Cloud-Native 微服务的软件架构的决策、工程的实践、开发的框架、自动化的工具。

软件开发的本质就是 “持续改善”;我们也正在逐步的打造一个 “软件开发持续改善的生态系统”。

 

请参考:

Cloud-Native 元素卡: 高效的搞定 Cloud-Native 微服务的持续交付 

Cloud-Native 微服务设计元素卡 

Cloud-Native 微服务开发元素卡 

Cloud-Native 微服务架构元素卡

 

 

 

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据