Update README.md

README.md

-# BXERP
+# BXERP dev by BX研发体系(BX R&D Hierarchy)
+## 1. 简介
+　　BX研发体系是一套关于博昕研发团队如何开展各项开发活动的体系。这套体系，可以让研发团队具备强大的生产力。这种生产力表现在高质量交付的过程和结果。
+## 2. 业务视角
+　　如果你们需要将既有的生态系统演化到更易维护的状态，或者根据现有业务体系构建一个新的生态系统，像下图的博销宝产品线/生态系统一样，你们可以选择我们。
+
+![博销宝(ProSales Box)产品线图片](https://codechina.csdn.net/weixin_44071138/bxerp/-/raw/master/Doc/img/ProSalesBox_Product_Line.png "博销宝产品线/生态系统")  
+　　博销宝产品线，完完全全基于可复用的BX研发体系。
+
+　　BX研发体系是指，博昕团队为构建企业及品牌数字化运营系统的基础软件框架（服务器后端自研框架、App框架、自动化测试框架、自动化部署框架、桌面研发体系）、开发流程尤其是持续交付流程、常见敏捷开发工具集、最佳实践形成的质量控制体系等的合集。它不仅能支持零售行业系统定制化开发的快速和高质量交付、持续交付，同样亦适用于其它行业和不同领域的业务系统构建。
+
+　　BX研发体系，脱胎于业内先进的敏捷开发理论，保持了敏捷开发的核心要素，又创造性地用研发团队代替测试团队进行测试活动，去掉了测试团队，认为“只有编码者才知道如何测试”，极端重视单元测试用例、集成测试用例的设计和实现，极端重视自动化测试以降低研发成本提高迭代速度和质量，尤其是每一次迭代的成本，在成本控制和质量控制上达到完美的制衡关系。我们相信，用研发团队代替测试团队的工作，将成为敏捷开发方法论发展的趋势。
+
+　　只依靠先进的软件框架来持续交付软件系统，缺乏有效的软件质量控制流程和体系，是没有生命力的，也是不可持续发展的。这是业内软件工业界长期存在的问题。但我们认为，软件系统就像一个生命，需要不断生长和进化。支持它健康成长的，必然不能只是依靠先进的软件框架。BX研发体系就是这样的一个既有肉体也有灵魂的可以令商业生态系统健康成长的体系。
+
+## 3. 技术视角
+### 3.1 综述
+　　我们将软件产品看成一个有生命的个体，具有可持续发展的强烈需求。
+
+　　一般企业在追求进度和可持续发展上，若是在可持续发展上失衡的话，就会导致团队陷入“多Bug-加班-低效工作-多Bug”死循环的痛苦中，无论是在开发期还是维护期。解决这些痛苦的问题，是引入必要的自动化测试、文档、开发人员代替测试人员测试等等。
+### 3.2 阶段及其要点
+　　一般企业认为追求进度和可持续发展是互相矛盾、互相冲突的。如果追求可持续发展，就会拖慢进度。实质不然。
+
+　　举个简单的例子来说明。做个创建订单的功能，只算开发期里后端的行为，一般来说后端编写代码后，需要手动测试很多遍（可能达50次），观察页面显示是否正确。而自动化测试，用机器代替人去运行测试，可以减少次数至少一半且由机器而不是人眼判断结果是否正确。其额外开销主要是实现自动化测试代码和脚本的时间。而这些时间，较于多余的手动测试以及在后面的维护期里的手动测试，根本不算什么。
+
+　　因此，使用正确的方法推进软件工程，可以大大节省开发的资源并且所有人都不会觉得痛苦。在维护期，可能只需要少于1/3的人力就能持续维护系统。为什么呢？因为大量的自动化测试，可以让研发人员轻松地解决新出现的Bug，可以轻松地开发新功能同时保证旧的功能没有矛盾。保证旧的功能没有矛盾，就是由当初编写的大量自动化测试确保的。
+
+　　**我们认为以下阶段对于保持进度和可持续发展的双重追求具有重要意义。**
+
+| **阶段** | **主要活动** | **软件产出** | **服务器要求** | **作用** |
+|--------|----------|---------|------------|------------|
+| 立项   | 主要论证市场需求和政策需求，即产品研发的原因。  | 《立项书》      |           |
+| 需求分析1/2 | BA（商业洞察者）制作需求规格说明书。  | 《需求规格说明书》      |           | 商业角度看需求         |
+| 需求分析2/2 | RD（研发团队）将业务转化为BA和RD都可以理解的文档。   | 《功能需求说明书》     |          | RD内部对需求达成一致的理解         |
+| 设计        | RD将《功能需求说明书》细化成《概要设计说明书》甚至《详细设计说明书》，使得RD在开发、修改bug、迭代新功能时有据可依。如果没有这些文档，后面的沟通费时费力。在产品的维护期，一旦有问题出现，几乎无法轻松解决。故一般来说，缺乏本阶段的文档，产品没有很强的生命力，难以可持续发展。维护成本巨大，所有人都很头痛。   | 《概要设计说明书》、《详细设计说明书》、《测试用例设计文档》      |     | RD内部对需求达成一致的理解    |
+| 编码和测试  | 如之前所言，编码期，会进行手动测试和编写自动化测试。敏捷开发拥抱需求变化，所以在需求变化发生后，有些功能会回到设计阶段甚至需求阶段进行讨论。   | 代码、测试用例设计文档、测试脚本      | 1人1台开发机器    |     |
+| DEV         | 开发测试阶段。测试单项功能、手动单元测试，每天运行全部自动化测试并发送问题报告，版本更新非常频繁。   | 兼有运行测试、运行产品的服务器      | 1台服务器    | 确保单项功能没有问题    |
+| SIT         | 集成测试阶段。测试N项功能同时运行有没有问题。在DEV阶段开发得到稳定的版本后，再部署到本阶段的服务器。   | 运行产品的集成测试服务器      | 1台服务器    | 确保集成测试没有问题    |
+| UAT         | 用户验收阶段。用户验收功能是否正确。   | 运行产品的用户验收服务器      | 1台服务器    | 确保用户满意    |
+| Prod        | 生产环境阶段。用户使用。   | 运行产品的线上服务器，即生产环境      | 1台服务器或以上    | 产出用户价值    |
+| 维护期      | 功能迭代。   |       |     |     |
+
+### 3.3 团队组织原则：轻松地做好事情
+　　做好事情是所有企业的要求，但轻松地做好和痛苦地做好是非常不同的。不断地追求轻松地做好事情，可以让自己能量节省下来，使得后面的事情也可以轻松地做好。如果是痛苦地做事，不断地重复痛苦，只会形成恶性循环。在博昕研发团队中，我们很好地践行了这一个原则。团队成员几乎每天都是精神抖擞地工作，效率特高。
+
+