项目概要评审

 

理由

为什么需要编写技术方案和进行技术评审

1. 加强对需求理解，减少错误几率。通过编写文档，可以再自己复盘一下需求流程，并且对开发过程有个大概的模拟，可以初步判断任务的难点和可能出错点。
2. 变更详细。通过文档记录，可以对需要变更那些文件，有个具体的记录，方便后期维护。
3. 可以将需求资料集中。因为有文档记录，开发期间可以方便查阅相关内容，如果以后其他人有基于这个需求的迭代也可以先查看这个文档。

那些需求可以不用

1. 逻辑跨度不超过两个页面的非主流程任务
2. 纯UI更新，没有需要新增/更改组件或没有新增逻辑。
3. 开发时间小于1天的非主流程任务

方式

按照项目、迭代版本进行路径存放，用主任务的名称进行文件命名

 

内容

1. 背景（为什么要做这个需求）
2. 目标（对这个需求的目标是什么，主要是技术类的需求，业务的可以不写）
3. 资料（开发流程需要的各种资料）
4. 方案
   1. 流程简述

例如

1. 可以是流程图，类图，时序图各种
2. 也可以是单纯的文本描述
3. 还可以是伪码
4. 形式不重要关键是要能把流程理顺，自己能说清楚，别人能理解就行

2. 变更内容

例如

1. 需要新增那些类
2. 那些已有类需要新增那些逻辑/UI
3. 旧逻辑/UI的更改
4. 那些类需要新增入口或参数
5. 尽量还是能写的详细一点，方便后续自己查看

3. 需要后台提供的接口

5. 风险（根据方案可能会存在的难点）
   1. 技术类风险

例如

1. 某些UI需要自定义功能
2. 某个功能业务逻辑较重

2. 协同类风险

例如

1. 需求变更了
2. 设计图完了
3. 接口没那么快开发
4. 其他人阻塞了你

6. 需要协调的地方

例如

1. 后台接口文档时间
2. 依赖其他人的服务 

7. 备注（可能有需要更改的地方和你觉得的一些问题）

 

模板

技术文档

参考

电子签(CA认证)需求技术方案

流程

1. 需求评审结束后编写技术文档（见技术文档格式）
2. 组内相关开发人员参加
3. 开发者根据文档，进行技术方案讲解
4. 参与人员对存在的疑问提问，开发者解答
5. 将遇到的问题或更改，同步到文档

时间

评审开始节点

原则上是在需求评审结束后，估时开始前；如果手里任务紧，则在开发前必须完成评审

评审时长

建议不超过30分钟

存在问题

如果一个需求很大，该如何编写技术文档？

注意

1. 如果文档有变更需要周知

 

 

-------------------------------

 

技术文档模板

背景

目标

资料

方案

流程简述

内容变更

后台提供的接口

备注

风险

技术类

协同类

需要协调的地方

-------------------------------