信息化系统-自研开发流程

第八章实施篇——核心系统实施方法论8.2 自研开发流程8.2.1 自研开发的理论定位自研开发是企业信息化建设中“掌握核心、自主可控”的战略选择其理论任务是通过系统化的开发流程、自动化的工程实践和严格的质量保障高效、高质量地交付满足业务需求的软件产品。与采购成熟软件不同自研开发需要企业具备完整的软件工程能力从需求到设计、从开发到测试、从部署到运维形成闭环。很多企业选择自研是因为业务独特行业特殊需求市场无成熟产品核心能力软件是企业的核心竞争力需要自主掌控长期演进业务变化快需要快速迭代响应成本考量长期来看自研比采购定制更经济但自研也面临巨大挑战周期长、成本高、技术风险大、团队要求高。本章将系统阐述如何系统化地开展自研开发降低风险、提升效率。自研开发的核心价值价值维度描述对项目的意义完全匹配软件完全按照业务需求定制流程不改体验最优自主可控代码、数据、知识产权归企业不受制于人可随时演进快速迭代业务变化时可快速响应敏捷灵活适应变化能力沉淀培养企业自有技术能力长期竞争力8.2.2 敏捷开发实践敏捷开发的理论价值敏捷开发是应对需求不确定性的有效方法论其核心思想是“小步快跑、快速反馈、持续交付”通过短周期迭代让业务方尽早看到成果及时调整方向避免“闭门造车”。传统瀑布式开发要求需求一次性完整、清晰这在快速变化的业务环境中几乎不可能实现。敏捷开发正是解决这一问题的良方。敏捷开发的核心原则敏捷宣言原则传统做法敏捷做法个体和互动重于流程和工具严格按流程走团队沟通优先可工作的软件重于详尽的文档文档驱动软件驱动客户合作重于合同谈判按合同交付持续合作响应变化重于遵循计划拒绝变化拥抱变化Scrum框架详解Scrum是最流行的敏捷开发框架适用于5-9人的小型团队。Scrum核心角色角色职责人选产品负责人PO管理需求清单Product Backlog排序优先级验收成果业务方代表Scrum Master保障流程顺畅移除障碍辅导团队技术负责人/项目经理开发团队负责具体开发、测试、交付开发、测试人员Scrum核心工件工件描述内容Product Backlog需求清单按优先级排序用户故事、需求描述、优先级、估算Sprint Backlog当前冲刺要完成的任务从Product Backlog选取拆解为任务Increment当前冲刺完成的可用软件可交付的功能增量Scrum核心活动text┌─────────────────────────────────────────────────────────────┐ │ Sprint Planning冲刺计划会 │ │ • 每个Sprint开始2-4小时 │ │ • 确定本次Sprint要完成的需求 │ │ • 拆解为可执行的任务 │ ├─────────────────────────────────────────────────────────────┤ │ Daily Scrum每日站会 │ │ • 每天15分钟 │ │ • 三问昨天做了什么今天要做什么有什么阻碍 │ ├─────────────────────────────────────────────────────────────┤ │ Sprint Review冲刺评审会 │ │ • 每个Sprint结束1-2小时 │ │ • 演示完成的成果收集反馈 │ ├─────────────────────────────────────────────────────────────┤ │ Sprint Retrospective冲刺回顾会 │ │ • 每个Sprint结束30-60分钟 │ │ • 团队复盘做得好做得不好改进什么 │ └─────────────────────────────────────────────────────────────┘Kanban方法Kanban适用于需求不确定、需要持续交付的团队核心是“可视化工作流、限制在制品数量”。Kanban核心实践实践描述可视化工作流看板列待办 → 进行中 → 测试中 → 已完成限制在制品WIP每列限制同时进行的任务数量如“进行中”最多3个度量交付时间关注任务从开始到完成的时间持续改进定期复盘优化流程看板示例text┌──────────┬──────────┬──────────┬──────────┐ │ 待办 │ 进行中 │ 测试中 │ 已完成 │ │ (WIP:∞) │ (WIP:3) │ (WIP:2) │ │ ├──────────┼──────────┼──────────┼──────────┤ │ 需求A │ 需求B │ 需求D │ 需求F │ │ 需求C │ 需求E │ │ 需求G │ │ 需求H │ │ │ │ └──────────┴──────────┴──────────┴──────────┘Scrum vs Kanban如何选择维度ScrumKanban节奏固定周期冲刺1-4周持续流动无固定周期角色PO、SM、团队无固定角色变更Sprint内不能加需求可随时加需求度量速度Velocity交付时间、吞吐量适用场景需求相对稳定需求变化频繁、紧急任务多中小企业建议从Scrum开始先建立节奏成熟后可混合使用Scrum框架 Kanban看板。敏捷开发实践要点用户故事编写markdown# 用户故事格式 作为一个 [角色] 我想要 [功能] 以便 [价值] # 示例 作为一个 销售员 我想要 在手机上录入客户信息 以便 外出拜访时也能快速记录客户资料 # 验收条件 - [ ] 支持录入客户姓名、电话、公司 - [ ] 支持拍照上传名片自动识别 - [ ] 提交后自动同步到CRM需求优先级排序优先级含义处理方式P0必须有没有这个功能系统无法上线当前Sprint必须做P1应该有非常重要但暂时没有也可以优先纳入下一SprintP2可以有有了更好但可以等看资源情况决定P3暂缓未来考虑记录需求池以后再议Sprint长度选择团队成熟度Sprint长度理由新团队2周节奏感强快速反馈成熟团队1周或3周1周更灵活3周适合复杂功能运维为主连续流Kanban不设固定Sprint8.2.3 DevOps体系建设DevOps的理论价值DevOps是开发Development和运维Operations的融合其核心思想是通过自动化工具链和协作文化打通从代码提交到生产上线的各个环节实现“持续集成、持续交付、持续部署”。传统开发模式中开发写完代码交给测试测试测完交给运维各管一段效率低下问题难追溯。DevOps正是解决这一问题的答案。DevOps的核心价值价值维度描述量化收益加速交付从代码提交到上线的时间大幅缩短从周级到小时级质量提升自动化测试减少人工失误bug率降低30%以上快速反馈问题早发现、早修复修复成本降低90%责任共担开发参与运维运维参与开发团队协作提升CI/CD流水线CI/CD持续集成/持续部署是DevOps的核心实践。text┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ 代码提交 │───▶│ 自动构建 │───▶│ 自动测试 │───▶│ 自动部署 │───▶│ 自动发布 │ └──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘ ↑ ↓ ↓ ↓ ↓ Git触发 编译打包 单元测试 部署到测试 部署到生产 代码检查 集成测试 环境 可选CI/CD流水线各阶段阶段活动工具产出代码提交开发者提交代码到GitGit代码变更持续集成CI自动编译、自动测试、代码扫描Jenkins/GitLab CI构建产物持续交付CD自动部署到测试环境自动冒烟测试Jenkins/GitLab CI可交付版本持续部署CD自动部署到生产环境可选Jenkins/GitLab CI上线版本CI/CD工具链环节工具推荐功能推荐指数代码仓库GitLab、GitHub、Gitee版本控制、代码托管★★★★★CI/CD平台GitLab CI、Jenkins、GitHub Actions自动构建、自动测试、自动部署★★★★★构建工具Maven、Gradle、npm编译、打包★★★★★代码扫描SonarQube代码质量、安全漏洞★★★★制品管理Nexus、JFrog构建产物存储★★★★容器化Docker应用打包★★★★★容器编排Kubernetes容器管理、弹性伸缩★★★★CI/CD流水线配置示例GitLab CIyaml# .gitlab-ci.yml stages: - build - test - deploy variables: MAVEN_OPTS: -Dmaven.repo.local$CI_PROJECT_DIR/.m2/repository # 构建阶段 build-job: stage: build script: - echo 编译代码... - mvn clean package -DskipTests artifacts: paths: - target/*.jar only: - main - develop # 测试阶段 test-job: stage: test script: - echo 运行单元测试... - mvn test - echo 运行代码质量扫描... - mvn sonar:sonar only: - main - develop # 部署到开发环境 deploy-dev: stage: deploy script: - echo 部署到开发环境... - scp target/*.jar dev-server:/app/ environment: name: development only: - develop # 部署到生产环境手动触发 deploy-prod: stage: deploy script: - echo 部署到生产环境... - ansible-playbook deploy.yml environment: name: production only: - main when: manualDevOps实践要点1. 持续集成CI每次代码提交都触发自动构建和测试构建失败立即通知提交者测试覆盖率不低于80%2. 持续交付CD自动部署到测试环境自动运行冒烟测试测试通过后可手动部署到生产3. 基础设施即代码IaC环境配置用代码管理Ansible、Terraform应用部署用容器化Docker环境可复现消除“环境问题”4. 监控与告警应用日志集中收集ELK关键指标监控Prometheus Grafana异常自动告警8.2.4 质量保障测试策略测试是质量保障的核心需要分层设计形成“测试金字塔”。text▲ │ UI测试端到端 │ • 模拟用户操作 5%│ • 工具Selenium、Cypress │ │ 集成测试 20%│ • 验证模块间交互 │ • 工具Postman、JMeter │ │ 单元测试 75%│ • 验证单个函数/方法 │ • 工具JUnit、Mockito ▼单元测试单元测试是测试金字塔的底座占比最大执行最快。测试对象测试内容工具覆盖率目标工具类公共方法JUnit/TestNG100%业务类核心逻辑JUnit Mockito80%数据访问SQL、ORMH2、TestContainers70%单元测试示例Java JUnitjavaclass CalculatorTest { private Calculator calculator; BeforeEach void setUp() { calculator new Calculator(); } Test void testAdd() { int result calculator.add(2, 3); assertEquals(5, result); } Test void testDivideByZero() { assertThrows(IllegalArgumentException.class, () - { calculator.divide(10, 0); }); } }集成测试集成测试验证多个模块间的协作。测试类型测试内容工具执行时机API测试接口契约、参数校验Postman、RestAssuredCI阶段数据库测试SQL正确性、事务TestContainersCI阶段消息队列测试消息发送/消费嵌入式MQCI阶段微服务测试服务间调用WireMockCI阶段端到端E2E测试端到端测试模拟用户真实操作验证完整业务流程。测试类型测试内容工具执行频率冒烟测试核心流程Selenium、Cypress每次部署回归测试全流程Selenium、Cypress每周/每版本性能测试并发、响应时间JMeter、Gatling每月/大版本端到端测试示例Cypressjavascriptdescribe(用户登录流程, () { it(用户输入正确账号密码登录成功, () { cy.visit(/login) cy.get([data-cyusername]).type(testexample.com) cy.get([data-cypassword]).type(password123) cy.get([data-cysubmit]).click() cy.url().should(include, /dashboard) cy.contains(欢迎回来测试用户) }) })自动化测试自动化测试是持续集成的核心应逐步构建自动化测试体系。自动化测试演进路径阶段目标内容第一阶段核心单元测试工具类、核心业务类第二阶段API自动化核心接口第三阶段冒烟自动化核心业务流程第四阶段全回归自动化所有P0/P1用例第五阶段性能自动化关键场景压测测试自动化覆盖率目标测试类型覆盖率目标说明单元测试80%核心逻辑全覆盖API测试100%所有对外接口冒烟测试100%核心流程回归测试70%P0/P1用例8.2.5 常见问题与避坑指南问题1敏捷变成“无流程”表现号称用敏捷实际是“没计划、没文档、没规范”变成无序开发。对策敏捷不是“无流程”而是“轻流程”。Scrum的四大活动必须坚持计划会、站会、评审会、回顾会。问题2DevOps变成“开发运维”表现把开发人员和运维人员放一起就叫DevOps工具链还是割裂的。对策DevOps的核心是自动化流水线不是人员合并。先建CI/CD再建协作文化。问题3测试自动化率低表现写了自动化测试但跑不起来跑起来了但没人看结果。对策测试自动化要融入CI失败必须阻断发布。测试覆盖率作为质量门禁。问题4代码质量差表现代码没有规范没有审查没有扫描技术债越积越多。对策建立代码规范强制代码审查集成SonarQube自动扫描。问题5忽视非功能测试表现只测功能不测性能、安全、兼容性。对策性能测试、安全测试、兼容性测试纳入测试体系大版本必须执行。8.2.6 本章小结自研开发是企业信息化建设中“掌握核心、自主可控”的战略选择其核心价值在于通过系统化的敏捷开发流程、自动化的DevOps工程实践和严格的质量保障体系高效、高质量地交付满足业务需求的软件产品。敏捷开发以Scrum框架为核心通过Sprint规划、每日站会、评审会、回顾会形成开发节奏。用户故事描述需求优先级排序控制范围Sprint长度根据团队成熟度选择。DevOps体系打通从代码到上线的自动化流水线。CI/CD是核心实践每次代码提交触发自动构建、自动测试、自动部署。GitLab CI是中小企业推荐的一体化工具。质量保障采用测试金字塔策略单元测试占75%快、多集成测试占20%端到端测试占5%。自动化测试逐步演进测试覆盖率作为质量门禁。常见问题提醒我们要避免敏捷变成“无流程”、DevOps变成“人员合并”、测试自动化率低、代码质量差、忽视非功能测试等问题。