不确定性一直都是系统建设的大敌。在工业革命引领的自动化生产线时代，一切生产都要以确定性的规格尺寸为前提。一辆汽车，哪怕是车长减少了10厘米，整条生产线都需要重新加以改造，更遑论加多一个座椅或加多一对负重轮。为什么？传统的工业生产是以明确的工业设计为前提，通过各种确定尺寸的零件、相应的模具和固化的加工单元组成相应的生产组织结构，所以我们称它为刚性自动化生产线。
软件工程也是一样的道理。传统的软件开发模式是一帮软件极客搞出来的，被称为"瀑布法"或者是V model。核心走的就是刚性自动化生产线的思路。业务用户首先要提出明确、无歧义、有时效性的业务需求，系统分析人员根据业务需求设计系统功能组件和系统整合策略，细化成为软件架构设计、系统整合方案并进行分模块开发。模块开发完毕后从单元测试、集成测试、系统测试直到用户接受度测试一级级往上扩展。
传统的软件系统开发方式路线清晰，管控容易，但最大的前提就是需要业务需求清晰稳定。一旦需求发生变更，尤其是核心需求和关键功能\流程的调整，往往会给开发和架构带来灾难性的影响。就好像根据确定车型的生产流水线已经搭建起来了，产品经理说，麻烦把车加长10厘米。生产总监一定会两手一摊说，给我三个月改造生产线吧。
一般情况下，程序员对产品经理动了杀心就是在传统软件开发方式+重大需求变更时发生的。
另外，传统的系统开发路线的确清晰，但从设计到开发再到上线往往要经过漫长的等待。最要命的是，在等待期间需求不能随意修改，术语叫做"需求冻结"或者是"需求窗口关闭"。但是在互联网世界里客户的要求是不可能被冻结的，所以…用传统的软件开发方式玩互联网，产品经理是会"仆街"的。
为了在瞬息万变的互联网行业里活命，一些脑子机灵对软件开发熟悉的产品经理捣鼓出了和传统软件开发流程完全不同的开发方式-敏捷开发(Agile Development)。
敏捷开发嘛，顾名思义，最大的特点就是快。那它是怎么实现快速开发的呢？核心思想就是快速迭代，不断优化，永远在改进，永远在发布新版的路上。
从图中我们可以看到，敏捷开发的起点往往是并不非常清晰的业务需求。但随着开发的进行和原型开发过程中与业务用户的交互，核心的功能点逐渐清晰并形成测试用例。在完成最基本的核心功能后，系统就可以内部上线并供业务人员使用，让业务人员吃"第一批的新鲜狗粮"(就是指刚出炉的自己的新鲜产品)。
业务人员在试用后认为基本达到业务目的，就可以小范围开闸交给友好用户使用。如果业务人员认为不够成熟，那就会返工重新修改调整。我们看到的互联网app经常是1-2周就有一个新版本发布，往往就是采用这种"短平快"周期的敏捷开发模式，术语一般称为"持续交付"。
所以有人形象地做了个比喻：从河岸这一侧的A点到河岸那一侧的B点，传统开发就是设计桥梁，建造桥墩，铺设桥板，按部就班；敏捷开发就是先用弓箭射一根线到对岸，然后线带细绳，细绳带粗绳，粗绳带钢缆，逐步把通行能力从蚂蚁、老鼠，猫最后提升到人甚至汽车。
正是看到了这样的优势，除了互联网行业之外，一些传统的企业级应用开发厂商也逐步开始玩转敏捷开发了，比如亚信科技。
2018年，亚信科技推出了自己的敏捷开发平台——AIDO，这是一个很有意思的产品。为什么说这个产品很有意思呢，因为它包含了绝大部分敏捷开发的要素，但又具有一般的敏捷开发不具有的优势。
在敏捷开发体系中，测试是一个非常重要的环节。之所以重要，一方面是测试环节在敏捷开发体系中会非常前置，甚至在业务需求整理过程中就开始形成测试案例和测试场景/要素的定义。
另一方面，由于测试贯穿整个敏捷开发流程，所以大量的测试工作是以系统自动化的方式进行，而不是像以前一样以手工方式完成。亚信科技的敏捷开发平台里嵌入了一个自测云，里面构建了分层自动化测试的框架。第一层是是静态的代码检查，通过预设的测试规则检查代码中相对明显的错误；第二层是单元的自动化测试，确保每个单元模块满足业务需求中各个应用场景的功能需要；第三层是接口的自动化测试，通过和人工智能引擎支撑的测试训练模型的建立，帮助开发/测试人员从几十万上百万行代码中自动查找软件的bug甚至各种极端条件下的系统反馈。这种自动化、智能且高效的测试方式在以前是不可想象的，能够帮助企业软件系统从开发质量、效能提升和缺陷预测这三个方面快速提高。
另一个重要的核心功能就是DevOps的支持。DevOps一般称为"开发运维一体化"。在以前，砍死产品经理的通常是开发工程师。但你知道开发工程师自己通常被谁砍死吗？你猜对了，一般砍死开发工程师的都是运维工程师，而且下手更狠。为什么呢？因为开发工程师经常会给运维工程师留下各种伤天害理的运维难题。在产品管理系统中，有开发工程师把产品参数写死在程序包里，甚至还有野鸡开发工程师把服务器名称甚至IP地址写死在程序里。一旦换个网卡，系统就再也连不上了，你说这样的开发工程师不砍死留着干啥？
为了最大程度减少开发过程中对运维的各种坑害行为，最好的办法就是"让挖坑的人自己填坑"，让开发工程师同时完成系统运维的工作。
DevOps就是要求开发工程师同时兼备运维工程师的角色。在系统开发过程中，同步考虑运维面临的各种挑战，以同时兼顾开发和运维的需求，减少两者之间的冲突。当然，这样的身兼二职对开发工程师提出了更高的挑战，但以此方式完成的软件系统将大大降低运维的难度，并为未来的自动化运维创造条件。亚信科技的AIDO架构包含了完整的开发——测试——运维——监控一体化集成功能，能够帮助技术人员从多角度应对业务功能实现过程中开发到运营的各种挑战。
难能可贵的是，亚信科技的AIDO还包含了双模的支撑方式：既支持传统的瀑布型开发方式，也支持敏捷的快速迭代方式，甚至还可以支持一个大的软件系统中不同组件采用不同的开发方式完成。数据库作为传统软件系统中业务逻辑层的核心，AIDO还可以支持和数据库的集成，数据库和原代码版本的集成，这是亚信科技新型开发平台中最大的特点之一。
作为中国少有的大型企业级应用软件系统的开发商，亚信已经完成了从企业软件系统开发向互联网软件系统开发的转型。我相信，亚信科技的AIDO系统的广泛使用将大大减少产品经理的伤亡率，并进一步提升我国企业软件系统开发和运维的水平。
|( 京ICP备09078825号 )
发表于 2018-8-2 13:19:41
收藏
