工程管理与工作流

1 统一开发环境/ 协作工具

你知道开发环境指的是什么吗? 

开发环境:

工程运行环境、开发工具/ 编辑器 、开发依赖环境、 配置文件 

软件环境:

“仿真预演”环境 Staging 

生产环境前最终验证、 这一环境尽可能的仿真了真实的生产环境 、另一个关键是用于性能测试,特别是加载时间 

开发环境 Development 

往往创建在开发者的设备上 、软件环境软件在这个环境下开发 、一个沙盒环境 

生产环境 Production 

也被称为线上环境 、向生产环境部署是最为敏感的步骤 、生产环境出现问题会导致严重的后果工程运行环境 

测试环境 Testing 

允许人类测试者采用自动化或非自动方式进行测试 、如果测试失败,测试环境会将这部分 并通知对应开发者 

你所了解的协作工具有哪些? 

你们之前开发环境都选用过哪些呢? 

为什么要对它们进行统一呢? 

2、工程管理与工作流

在软件项目管理中我们关心什么 

需要关注钱的问题吗? 

需要关注时间吗? 

还需要关注什么呢? 

关心:

在预算之内 、在计划时间之内 、工程质量良好 

W5HH 计划 

这个功能为什么要被开发? 

将要做什么,什么时候完成? 

谁负责来实现? 

他们的机构组织位于何处? 

从技术和管理上这个功能可以怎么被完成? 

有哪些资源应该被需要到?

Umbrella activities :

测量 & 数据矩阵 

预估

风险

排期

追踪与控制 

做好工作的拆解:

将任务拆解为多个部分 :

产品、过程、组织 、自上而下的拆解 、考虑全局的分析与组织 、确保没有遗漏 、考虑现实性 

做好排期 :

问:一个项目是怎么会延期了一年的呢? 

答:每次遇到问题延迟一天就足以导致这个结果

工作流是什么? 

我们做开发是怎么做的呢? 

需要按哪些步骤进行? 

每个步骤之间关系是什么? 

项目级的工作流 :需求 、评审 、设计 、开发、审计与测试 、部署与监控 

有了工作流之后

开发切忌偷工减料 

工作流是提升效率的,而不是降低效率的 

在执行前要有约定好的惩罚性、奖励性措施 

3、需求来自哪里

探索性项目需求 、针对性项目(用户需求不明确 )、针对性项目(用户需求明确)

工程管理与工作流_第1张图片

 工程管理与工作流_第2张图片

4、Git 

我们面对的问题:

多个人需要共同参与一个软件开发
一个软件可能有多个要支持的版本
一个软件可能会用多种不同的运行环境

版本的基准:

根据质量管理所需确定的阶段性规格说明,这个说明应是被正式评审认可的。 

之后的开发过程都应该要遵循“基准”的要求进行。 

对于基准的修改是要极为慎重的,要通过严格的变更流程。 

例子: 

Baseline A :所有接口应被完备的定义,各方法的内容为空。 

Baseline B :所有的数据访问方法应该被实现并测试。 

Baseline C:GUI 被完成

基准的命名:

基准的命名有一个非常常用的三点命名法。
A.B.C(如9.3.1)
A:从用户(消费者)角度看到的发布出的标记数(Release)
B:从开发者角度看到的关键的版本(Version)号
C:从开发者角度关注的修改版本(Revision)号

术语定义:发布(Release)     版本(Version)     修改(Revision)
版本(Version):最初发布或再发布的“代码及其附属品”的组合,它应该是可被完整编译或被认定为完整可用的。不同的版本表现出不同的功能特性。
修改(Revision):对于一个版本的修改,只做了代码设计的错误修正,对于已经“附属品”中文档所描述的功能特性没有任何改动。
发布(Release):被批准的面向用户进行分发的版本。

本地Gt仓库的三个分区:

01     工作目录(修改/没修过的文件)working directory
02     暂存区(暂存的文件)staging area
03     Gt仓库(提交的文件)repo

基本的Git使用:

配置一个Gt仓库:
Git init创建Git仓库,让当前目录处于Gt管理之下
Git clone将一个已经存在的Git仓库克隆到本地
Git config对Gt的基本配置进行设置(如邮箱、姓名)

工程管理与工作流_第3张图片

工程管理与工作流_第4张图片 

 

创建仓库
01在当前目录下创建   git init
在指定的目录创建
02git init<指定的目录路径>
03创建一个bare git仓库   git init --bare myrepo.git

工程管理与工作流_第5张图片

工程管理与工作流_第6张图片 

工程管理与工作流_第7张图片 

工程管理与工作流_第8张图片 

工程管理与工作流_第9张图片 

 工程管理与工作流_第10张图片

工程管理与工作流_第11张图片 

工程管理与工作流_第12张图片 

工程管理与工作流_第13张图片 

Git 的多人协作 / 远程仓库:
 工程管理与工作流_第14张图片

分支

01查看现有分支  git branch  创建分支
02  git branch<分支名>
03  切换分支   g it checkout<分支名>    创建并切换到分支
04  git c   checkout-b<分支名>    删除分支
05 git branch-d<分支名> 

合并的默认行为

只执行g it merge时,如果可以fast-forward,则fast-forward,否则进行non fast-forward merge。
在non fast-forward merge过程中,会尝试合并修改
如果发生不能自动合并的冲突,则需要手动解决冲突。

工程管理与工作流_第15张图片

工程管理与工作流_第16张图片 

工程管理与工作流_第17张图片 

 

 Gitlab 工具

任务管理与计划:

在 Group 中建立 Milestone 

在Group / Repo 拆分任务,建立 Issue 关联 Milestone、设置 Deadline,并评估完成时间 在开发过程中关注任务计划 

工程管理与工作流_第18张图片

工程管理与工作流_第19张图片 

Issue的使用

01Group中的ssue:不具体到某一个部分的开发
02 Repository中的Issue:具体到某一个部分的开发
03无论是哪个部分的Is$ue都应该是可以被完成、关闭的 

工程管理与工作流_第20张图片

工程管理与工作流_第21张图片 

工程管理与工作流_第22张图片 

工程管理与工作流_第23张图片 

工程管理与工作流_第24张图片 

工程管理与工作流_第25张图片 

3、代码提交与测试、审计

 写完代码提交有什么要求
01一个分支关联一个1ssue,一次提交只做一件事情
02提交的内容应该与分支目的相关
03提交信息首字母要大写、要关联到Issue

持续集成与Code Review
01发起Merge Request后测试会自动跑
02在自动化检测通过后,我们可以进行人工Review
03人工Review后可以批准修改,之后可以由对MR发起人或项目负责人完成合并

 

你可能感兴趣的:(入学前实训课,需求分析,github,git,规格说明书,团队开发,敏捷流程)