项目管理

项目管理的内容: 配置管理, 评审, 变更; 三个内容都是不可缺少的.属于公共的流程.

配置管理:

       类似于 "图书管理员". 但是配置管理是通过平台来操作的.

       配置管理所使用的"工具": SVN, GIT

       配置管理所管理的"内容": (程序, 需求文档, 测试用例)的版本; 项目中所有的代码; 项目中用到的所有工具; 所有数据;

       这些内容都叫做项目管理的 "配置项".

       图书管理员管理的是图书, 给图书进行编号, 给图书编上标签, 放到相应的书架上,

       而配置管理员则会把项目中所有的程序, 需求文档, 测试用例, 代码, 工具, 数据等全部管理起来, 放到SVN和GIT上, 给这些配置项也会进行编号命名, 编上标签, 放到SVN或者GIT上进行管理

       GIT上的默认分支是master. SVN建立分支是打个tag, 即就是给它起个名字.

       分支: 即就是管理不同的项目上的功能点. 分支起到的作用就是版本管理. 即就是保存每个版本的代码, 给每个版本都建立一个分支. 下个版本是在上个版本的基础上完成的, 即就是下个版本能够覆盖上个版本的功能.

        举个例子:产品上线出现bug, 需要进行回滚, 而此刻再调试本版本的代码已经来不及了, 并且容易出错. 因此将上个版本的代码拿出来进行调试即可. 即一旦出现问题就可以回滚回去, 这样的话能够降低成本.

        配置管理的流程: 编写配置计划--配置管理

评审:

        评审的内容: 针对项目里 " 核心文档, 测试用例, 设计文档, 需求文档, 代码, 计划类的文档 " 进行评审.

        对于研发里的代码评审, 一般称为 "代码走查, 代码审查, CODERIVWER"

        文档检查和代码检查用的方法不一样.

       评审类别: 分为 "正式评审" 和 "非正式评审".

              正式评审需要召开会议, 提前发会议通知, 邀请项目组中所有成员(研发测试人员等)到会议室进行开会

              非正式评审不需要开会, 只需一个人或多个人将代码检查一遍

       评审的流程: 提交申请--会议讨论--后期跟踪

       评审的目的: 找bug, 验证文档和代码的正确性

变更:

       变更和配置管理息息相关

       举个例子, 第一分支有10个功能, 第二分支有20个功能, 在第三分支中要把第二分支的20个功能里面多余的5个功能去掉. 去掉哪5个功能, 去掉的原因, 在需求变更文档里面都会详细地说明.(1) 变更的原因.(2) 变更会带来的风险.(3)再反复确定是否需要进行变更.

       虽然用户是上帝, 但是如果用户提出的变更需求不合理, 是不能随意变更的. 不然会引起一系列的bug以及不可预估的风险.变更是拥有一套完整的流程的.

       变更的流程: 申请变更--评估变更--实施变更--验证变更--发布上线

       代码变更之后, 新版本还是需要在配置管理库进行管理, 因此变更和配置管理是息息相关的.一旦变更, 就需要进行配置管理.