一、把事情做对。

敏捷的核心理念追求的就是把事情做对，这样的效率是最高的。中国古代就有南辕北辙的故事，方向错了再怎么努力都是白搭。那什么才是对的事情？这里分成了两派：1、瀑布方式认为一开始提的合同、需求就是对的事情，这在SOR系统中，确实可能存在固定的需求的情况，甚至人为地限定减少变化以加强合规性或稳定性；2、但更普遍的情况是敏捷里认为的那种，“对”的事情都是不断演变和讨论出来的，一开始并不知道什么才是对的事情，只有一个模糊的方向，要找到对的事情那就去寻找，快速试错。这就是SOE系统比较常见的做法。这两派没有绝对的对错，只有找到适合自己的方式才是上策。

二、开发的效率。

不管是瀑布的方式，还是敏捷的方式，都需要快速得到结果。当需求确定以后，占用时间最多的就是开发过程。至于如何节省开发的时间，或者能否真的节省，每个人的看法都不一样，但大家从来没有停止过尝试的脚步，从机器编码到现代的编程语言，到低代码再到AI辅助编码，以及未来的完全AI编码，程序员一直在努力地葛自己的命。

最近在尝试的几个方向：

1、AI辅助编码：试了文心一言和阿里的通义灵码，现在的文心一言稍微比通义灵码好一些，相同之处是都能理解需求，但都存在一本正经胡说八道的现象（甚至会自己杜撰某个比较出名的库的类里的方法，让IDE直接报错）。现在的代码采纳率还非常的低，经常需要回归传统手艺：面向搜索引擎的编码。

2、低代码：只要需求合适，低代码是一个灵丹妙药。但如果强行为了低代码而低代码，会比引入低代码之前还更复杂。比如如果存在大量的CRUD，则可以用模板功能尝试做一个或者直接用现成的低代码平台，但如果CRUD只占很小的一部分，大部分是其他的定制化的业务逻辑，那就很难适用了。（之前的公司里，为了使用某平台的低代码，做了大量的适配，适配代码和时间甚至一度超过了直接开发的规模）。

3、功能模块化、组件化：团队的每个人有意识地积累自己的、团队的通用功能模块，甚至拉出专门的团队来做这些事情，经年累月后将能使团队的开发越来越快。

三、测试的效率：

1、质量左移和内建：这个最左可以左到需求端，需求的质量多少也可以认为是做对的事情，可参考上面的第一点。再右一点是开发阶段，可使用BDD甚至AI来从开发阶段就开始做质量保证，当然单元测试和静态检查是必不可少的活动。

2、测试范围、测试用例、测试报告的编写：现在有AI的帮忙，在理解需求的基础上写验收条件，再通过验收条件生成测试用例都不再是梦。

3、测试执行：自动化测试框架+自动提bug框架（比如selenium+jira+jira的bug管理插件）

四、运维：

1、部署和发布分离。

2、持续部署框架。

五、维护：

轻量级的ITIL，比如JIRA有插件可以配置工单管理系统，跟需求集成打通。

六、整体串起来：DevOps