软件开发流程

规范制定目的

• 探索更加合理化的软件开发流程
• 明确参与人员的职责和任务
• 有效地推进软件开发的规范化、流程化

对于稍微大一点的互联网产品都要有精心部署和安排才行，否则项目进行的将会一塌糊涂。

1、需求分析

概念

指对要解决的问题进行详细的分析，弄清楚问题的要求，包括需要输入什么数据，要得到什么结果，最后应输出什么

要点

1. 为实现产品目标，进行产品调研，竞品分析
2. 功能需求、性能需求、 可靠性和可用性需求、出错处理需求、将来可能提出的要求
3. 开会讨论，输出需求文档

2、软件评审

概念

软件评审并不是在软件开发完毕后进行评审，而是在软件开发的各个阶段都要进行评审。因为在软件开发的各个阶段都可能产生错误，如果这些错误不及时发现并纠正，会不断地扩大，最后可能导致我们开发结果不可控。

评审内容

• A 计划的评审

　　主要是关注的核心在于估计是否准确；人员安排是否合理；以上两个方面如果合理，项目的进度就不会出很大的问题。 　　

• B 需求的评审

　　主要关注需求来源、需求的准确性、需求的完整性，避免产生二义性；最好让测试人员和客户参加，以便让各角色达成共识。 　　

• C 总体设计的评审

　　在总体设计评审中，最好将已经评审通过的需求文档从配置管理库中提出，对照总体设计是否和需求一致；另外，技术领域专家参加评审还要关注于设计的合理性、可实现性以及完整性。 　　

• D 代码评审

　 由项目组内进行代码审核，主要关注代码的格式、整体逻辑、变量的命名、程序注释等表面的属性；至于运行质量应当放在单元测试中解决。 　　

• E 管理性的评审

　 管理性的评审一般放在里程碑、项目结束后进行。准备的资料包括前期工作的总结，是否按照计划执行、出现的问题的数目、解决了多少、未解决的问题、是否对后期有影响等

评审目标

• 发现任何形式表现的软件功能、逻辑或实现方面的错误；
• 通过评审验证软件的需求；
• 保证软件按预先定义的标准表示；

评审过程

• 召开评审会议：一般应有公司评审委员会组织，会前每个参加者做好准备。
• 会议结束后必需有结果性东西：接受该产品，不需做修改；由于错误严重，拒绝接受；暂时接受该产品。
• 评审报告与记录；所提出的问题都要进行记录，在评审会结束前产生一个评审问题表，另外必须完成评审简要报告。

时间控制

为了提高效率，每次评审会议只评审一个工作产品，并且时间最长不能超过2个小时。所以要求，在评审准备时候各位评委事先作好准备。

3、详细设计

输出

1. 软件原型图
2. 设计图
3. 交互图
4. 软件的基本结构和流程等
5. 软件的使用教程

4、编码

1. 开发规范定义
2. 环境和约定等等

5、测试

1. 测试流程规范
2. 每日测试
3. 测试报告

6、维护和迭代

1. 按此流程来处理

7、实际操作

1. 需求、设计、开发结束阶段都需要进行评审

2. 每周一下午开软件团队的会议，（ < 2h ）

   • 评审
   • 总结上一周做的工作
   • 本周的计划
   • 提出自己的问题和想法
3. 各阶段输出相关的文档
4. 使用 teambition 来管理开发流程

Teambition

任务主要通过产品、文档、设计、开发、测试负责人委派，个人建立任务为辅。
通过负责人进行任务委派，以便观察任务进展，做出适当调整。

Teambition 任务分组

产品
文档
设计
开发
测试

任务分组以工作内容任务划分，而不是原本的项目划分。

长期项目（笔戈博客），建立项目版块，长期使用和维护。
短期项目（笔戈招聘或合作项目），建立项目版块，项目完成后，进行归档。

360 云盘

产品原型，产品文档
设计稿，设计素材

360云盘 文件划分与 Teambition 类似，以项目划分主文件夹，工作内容划分子文件夹。比如：

笔戈博客
|——产品
|——开发
|——设计
产品、设计、开发相应负责人需进行文件命名规范与整理

Github Page

代码拥有相应的开发文档
脱离代码的文档，通过 Github Page 发布（如：code style）

版本号

产品、设计、开发文档需注明相应版本号。
版本号命名：主版本号.子版本号.修正版本号

1.项目初版时,版本号为 1.0.0
2.当项目在进行了局部修改或 bug 修正时，主版本号和子版本号都不变，修正版本号加 1（例子:1.0.1）；
3.当项目在原有的基础上增加了部分功能时，主版本号不变,子版本号加 1，修正版本号复位为 0（例子：1.1.0）；
4.当项目在进行了重大修改或局部修正累积较多,而导致项目整体发生全局变化时,主版本号加 1，子版本号、修正版本号复位为 0（例子：2.0.0）；