-
Notifications
You must be signed in to change notification settings - Fork 22
笔戈软件开发流程
- 探索更加合理化的软件开发流程
- 明确参与人员的职责和任务
- 有效地推进软件开发的规范化、流程化
对于稍微大一点的互联网产品都要有精心部署和安排才行，否则项目进行的将会一塌糊涂。
指对要解决的问题进行详细的分析，弄清楚问题的要求，包括需要输入什么数据，要得到什么结果，最后应输出什么
- 为实现产品目标，进行产品调研，竞品分析
- 功能需求、性能需求、 可靠性和可用性需求、出错处理需求、将来可能提出的要求
- **开会讨论，输出需求文档 **
软件评审并不是在软件开发完毕后进行评审，而是在软件开发的各个阶段都要进行评审。因为在软件开发的各个阶段都可能产生错误，如果这些错误不及时发现并纠正，会不断地扩大，最后可能导致我们开发结果不可控。
- A 计划的评审 主要是关注的核心在于估计是否准确；人员安排是否合理；以上两个方面如果合理，项目的进度就不会出很大的问题。
- B 需求的评审 主要关注需求来源、需求的准确性、需求的完整性，避免产生二义性；最好让测试人员和客户参加，以便让各角色达成共识。
- C 总体设计的评审 在总体设计评审中，最好将已经评审通过的需求文档从配置管理库中提出，对照总体设计是否和需求一致；另外，技术领域专家参加评审还要关注于设计的合理性、可实现性以及完整性。
- D 代码评审 由项目组内进行代码审核，主要关注代码的格式、整体逻辑、变量的命名、程序注释等表面的属性；至于运行质量应当放在单元测试中解决。
- E 管理性的评审 管理性的评审一般放在里程碑、项目结束后进行。准备的资料包括前期工作的总结，是否按照计划执行、出现的问题的数目、解决了多少、未解决的问题、是否对后期有影响等
- 发现任何形式表现的软件功能、逻辑或实现方面的错误；
- 通过评审验证软件的需求；
- 保证软件按预先定义的标准表示；
- 召开评审会议：一般应有公司评审委员会组织，会前每个参加者做好准备。
- 会议结束后必需有结果性东西：接受该产品，不需做修改；由于错误严重，拒绝接受；暂时接受该产品。
- 评审报告与记录；所提出的问题都要进行记录，在评审会结束前产生一个评审问题表，另外必须完成评审简要报告。
为了提高效率，每次评审会议只评审一个工作产品，并且时间最长不能超过2个小时。所以要求，在评审准备时候各位评委事先作好准备。
###输出
- 软件原型图
- 设计图
- 交互图
- 软件的基本结构和流程等
- 软件的使用教程
- 开发规范定义
- 环境和约定等等
- 测试流程规范
- 每日测试
- 测试报告
- 按此流程来处理
-
需求、设计、开发结束阶段都需要进行评审
-
每周一下午开软件团队的会议，（ < 2h ）
- 评审
- 总结上一周做的工作
- 本周的计划
- 提出自己的问题和想法
-
各阶段输出相关的文档
-
使用 teambition 来管理开发流程
任务主要通过产品、文档、设计、开发、测试负责人委派，个人建立任务为辅。
通过负责人进行任务委派，以便观察任务进展，做出适当调整。
Teambition 任务分组
产品
文档
设计
开发
测试
任务分组以工作内容任务划分，而不是原本的项目划分。
长期项目（笔戈博客），建立项目版块，长期使用和维护。
短期项目（笔戈招聘或合作项目），建立项目版块，项目完成后，进行归档。
产品原型，产品文档
设计稿，设计素材
360云盘 文件划分与 Teambition 类似，以项目划分主文件夹，工作内容划分子文件夹。比如：
笔戈博客
|——产品
|——开发
|——设计
产品、设计、开发相应负责人需进行文件命名规范与整理
代码拥有相应的开发文档
脱离代码的文档，通过 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）；