项目开发和管理流程
软件开发流程
作为一名软件开发工程师,我们需要了解软件开发过程中的流程,以及软件开发过程中涉及到的岗位角色,各自的分工、职责,并了解软件开发中涉及到的三种软件环境。本文档重点在于总结软件开发周期中各个环节的标准化流程:
- 需求分析
- 产品设计
- 开发
- 测试
- 发布|部署|运维
角色分工
岗位/角色 | 职责/分工 |
---|---|
项目经理 | 对整个项目负责,任务分配,把控进度 |
产品经理 | 进行需求调研,输出需求调研文档、产品原型、需求文档 |
UI 设计师 | 根据产品原型输出界面效果图 |
架构师 | 项目整体架构设计、技术选型等 |
开发工程师 | 功能代码实现 |
测试工程师 | 编写测试用例,输出测试报告 |
运维工程师 | 软件环境搭建,项目上线 |
上述我们讲解的角色分工,是在一个项目组中比较标准的角色分工,但是在实际的项目中,有一些项目组由于人员配置紧张,可能并没有专门的架构师或测试人员,这个时候可能需要由项目经理或者程序员兼任。
筹备和需求分析
任务项 | 输入 | 输出 | 相关要求 | 责任人 | 协同 | 执行项 |
---|---|---|---|---|---|---|
需求清单确认 | 合同或标书 | 需求清单 | 由项目经理根据合同或标书,协调产品经理进行需求清单的撰写输出,通过邮件下发给技术经理进行需求清单的确认。 | 项目经理 | 产品&开发 | 必选 |
开发团队 | 开发人员清单 | 由技术经理评估开发人员数量与部门负责人商定开发人员清单,并输出给项目经理。由项目经理开通工时系统和禅道等权限。 在多团队合作的项目中,由项目经理明确技术经理的管理边界、合作模式、消息同步方式等 | 技术经理 | 必选 | ||
技术选型 | 技术要求 | 概要设计说明书 技术选型 | 技术经理和产品经理通过技术选型会议,制定研发框架平台、统一研发平台版本等,并输出概要设计说明书 - 技术选型文档。 | 技术经理 | 产品 | 可选 |
代码仓&文档库建立 | 代码仓地址 | 由技术经理建立相关 git 仓库,并分配团队和人员权限,并下发 git 分支合并相关要求。 建立文档库,形式不限可以为 Git、语雀,腾讯文档、致得等,同时维护包括但不限于 vpn、产品使用情况、运维 Sql 脚本等内容 | 技术经理 | 必选 | ||
服务器申请 | 服务器要求 | 服务器清单 | 由项目经理发起申请相关服务器资源,技术经理提供技术支持,给予服务器数量、部署环境、网络拓扑等资料由测试部门操作相关资源,并将相关开发环境测试环境搭建完成。 | 测试部门 | 项目经理&技术经理 | 必选 |
项目环境
在软件开发中,会涉及到三套环境,分别是: 开发环境、测试环境、生产环境。 接下来分别介绍一下这三套环境的作用和特点。
开发环境(development)
软件开发人员在开发阶段使用的环境,就是开发环境,一般外部用户无法访问。
比如,我们在开发中使用的 MySQL 数据库和其他的一些常用软件,我们可以安装在本地, 也可以安装在一台专门的服务器中, 这些应用软件仅仅在软件开发过程中使用, 项目测试、上线时,我们不会使用这套环境了,这个环境就是开发环境。
测试环境(testing)
当软件开发工程师,将项目的功能模块开发完毕,并且单元测试通过后,就需要将项目部署到测试服务器上,让测试人员对项目进行测试。那这台测试服务器就是专门给测试人员使用的环境, 也就是测试环境,用于项目测试,一般外部用户无法访问。
生产环境(production)
当项目开发完毕,并且由测试人员测试通过之后,就可以上线项目,将项目部署到线上环境,并正式对外提供服务,这个线上环境也称之为生产环境。
准生产环境
对于有的公司来说,项目功能开发好,并测试通过以后,并不是直接就上生产环境。
为了保证我们开发的项目在上线之后能够完全满足要求,就需要把项目部署在真实的环境中,测试一下是否完全符合要求,这时候就诞生了准生产环境,你可以把他当做生产环境的克隆体,准生产环境的服务器配置,安装的应用软件(JDK、Tomcat、数据库、中间件 ...)的版本都一样,这种环境也称为 "仿真环境"。
但由于项目的性质和类型不同,有的项目可能不需要这个环境。而且准生产环境的搭建成本比较高,因此一些大厂会采用灰度发布的方式。
例如某个接口 100w qps,共有 10 台机器提供服务,该接口测试通过后,进行发布时,有 6 台提供旧的服务,有 4 台提供最新的服务,然后流量分发,将适量的流量打到 4 台新的机器上,然后查看效果,如果没问题,机器逐次替换。
产品设计
任务项 | 输入 | 输出 | 相关要求 |
---|---|---|---|
需求澄清 | 需求功能清单 | 需求规格说明书 | |
功能清单输出 | 功能清单 | ||
原型图设计 | 需求文档 | 原型图、UI | |
需求评审 | 需求分析 | 需求任务录入禅道 | |
需求排期 | 产品需求 | 开发计划表人力估算表 | |
开发规范澄清 | 后端开发代码规范前端统一开发规范 | ||
性能要求澄清 | 性能要求文档 | 由技术经理组织会议进行开发性能要求的澄清,除非特别说明一般接口性能要求规范 123 原则:新增修改 1 秒,大屏 2 秒,后台批量查询 3 秒。 | |
数据结构设计 | 需求文档 | 数据结构文档 SQL、ER 图 | |
业务架构设计 | 需求文档 | 业务流程图、组件图、流程要素 | |
技术评审 | 设计文档 | 技术评审文档 | |
接口设计 | 原型图 | 接口文档或 Mock 地址 |
开发
任务项 | 输入 | 输出 |
---|---|---|
需求转开发任务 | 需求文档 | 禅道开发任务 |
数据库/流水线搭建 | 数据结构文档 SQL | 数据库连接串、流水线地址 |
功能开发 | 开发任务 | 功能代码 |
UI 规范及原型匹配检查 | UI 图、原型图 | UI 检查结果 |
冒烟测试用例 | 冒烟测试用例 | |
开发自测/单元测试 | 冒烟测试用例 | 自测 |
代码合入 | 质量扫描报告 | 合入审核 |
文档编纂 | 需求规格说明书 | 设计文档 |
测试
任务项 | 输入 | 输出 | 相关要求 | 责任人 | 协同 | 执行项 |
---|---|---|---|---|---|---|
代码提测 | 质量扫描报告 代码评审会议记录 | 代码提测邮件 | 技术经理与测试沟通后将有质量扫描报告和代码评审记录相关需求的代码由 release 分支合并至 test 分支,提供功能清单及相关开发人员,同时发送提测邮件给测试。发送提测邮件后,由测试确认是否合并到 test 分支,测试确认后,再行合并,技术经理对本次合并负责,如果合并出现任何问题,由合并人负责修复 | 技术经理 | 测试 | 必选 |
功能测试 | 测试用例 | 功能测试报告 | 测试 | 必选 | ||
性能测试 | 性能要求文档 | 性能测试报告 | 测试 | 可选 | ||
bug 修复回归 | bug 单 | bug 单及回归报告 | 测试将代码相关 bug 提交至禅道,由测试根据功能清单中的开发责任人指派到相关开发人员,由开发修复相关问题,同时在禅道上说明问题出现原因,问题解决方案。以及预防相关问题出现的预防措施(可选)。如果找不到相关开发,由技术经理指派人员。 Bug 修复时限为每周五,原则上 bug 不过周。每周五统计开发个人 bug 数,每月中、月末统计项目 bug 总数,做好预警和清零工作。 | 开发 | 测试 | 必选 |
上线
任务项 | 输出 |
---|---|
上线准备 | 上线软件包、脚本 SQL、配置项 |
配合统计结果输出 | |
演示汇报保障 | |
版本留档 |
运行维护
任务项 | 输入 | 输出 |
---|---|---|
转运维文档输出 | 运维文档 | |
线上问题 | bug 单、禅道任务 | 代码整改方案 |