[课业] 10 | 软工 | 项目启动

项目和项目管理

项目

项目是具有以下特征的一系列活动和任务

1. 具有一个明确的目标
2. 有限定的开始和结束日期
3. 有成本限制
4. 消耗人力和非人力资源
5. 多工种合作

注：solution往往不坏就可以

项目管理的目标

项目管理的目标是做到以下方面

1. 在限定时间内
2. 在一定的成本内
3. 在要求的质量水平上
4. 高效使用资源
5. 获得客户认可

过程组与活动

过程组
       项目启动，项目计划，项目执行，项目跟踪和项目收尾
活动
       计划制定，团队管理，成本控制，质量保障，度量，过程管理，进度跟踪与控制，风险管理，配置管理

团队组织与管理

团队

1. 一个协作良好的团队很重要
2. 有效团队组织和管理；软件开发就是以人为主的活动，人力资源是项目最大资产
3. 很多实践者认为比生产高质量产品更大的成功是在生产过程中建立一个凝聚的团队

团队的特征

1. 团队的定义：为了一致目的、绩效标准、方法而共担责任并且技能互补的少数人
2. 团队里：
   成员要具备共同目标
   成员要共担责任
   成员要技能互补
   内部要一个明确的目标

团队结构

主程序员团队

一个主程序员，他要做大量工作、决策；其他人负责完成主程序员布置的任务

民主团队

开放团队

常用于很强调创意的项目；明确人员和任务的项目一般不适用

团队建设

建立团队章程

团队章程实例

不同人员的激励因素

避免团队杀手

要避免的团队杀手有

1. 防范式管理
2. 官僚主义
3. 地理分散
4. 时间分散
5. 产品质量的降低
6. 虚假的最后期限
7. 小圈子控制

软件质量保障

软件质量

概述

1. 软件工程师也要对软件产品的质量负责
2. 软件质量要求可以是显式也可以是隐式
3. 质量属性：对系统的某些质量进行量化处理，建立的质量特质
4. 质量模型：根据质量属性描述评价系统的整体质量，从很多质量属性的定义中选择的一些能够相互配合、相互联系的特征集

质量模型

1. 因素：
   功能性，可靠性，易用性，效率，可维护性，可移植性
2. 各因素的视角和标准
   

质量保障(QA)

软件开发过程与质量保障过程的流程对应

有的公司是每个项目单独配置QA团队，有的公司是一整个公司配置一个QA团队
开发过程会有一次次milestone，QA过程活动对应在这些milestone的前后

评审

1. 在计划阶段(Planning)，制定审查计划，决定审查会议次数，安排每次审查会议时间、地点
2. 在总体部署阶段(Overview)，向所有参与审查会议人员描述待审查材料等内容，审查的目标以及一些假设，并分发文档
3. 在准备阶段(Preparation)，审查人员各自独立执行检查任务；在审查的过程当中，他们可能会被要求使用检查清单、场景等检查方式；检查中发现的问题也会被记录下来，以准备开会讨论或者提交给收集人员
4. 在审查会议阶段(Inspection Meeting)，通过会议讨论，识别、确认、分类发现的错误
5. 在返工阶段(Rework)，修改发现的缺陷
6. 在跟踪阶段(Follow-up)，要确认所有发现的问题都得到解决，所有错误都得到修正

评审过程

质量度量

1. 度量产生自统计控制(Statistical Control)思想，“你不能控制自己无法度量东西”
2. 测度(Measure)就是为了描述产品而提供的定量指标（如代码行数）
3. 进行测度的活动被称为测量(Measurement)
4. 度量(Metric)是软件产品在特定属性上的量化测度程度（如基于所有对象的代码行数测度可以建立平均代码行数、最大代码行数、最小代码行数）

软件配置管理

软件配置管理的动机

5. 开发过程中会有中间制品（如需求规格说明、需求分析模型、软件体系结构设计模型、详细设计模型等）；这些制品是不同阶段、不同角色、不同软件开发活动进行协同的基础
6. 产生制品数量多时，需要维护一个清单才能清楚项目所处的状态
7. 某个制品发生变化带来的最大挑战是如何确保其使用者能够得到最新的制品，避免开发协同出现问题

配置管理

用技术的和管理的指导和监督方法，来标识和说明配置项的功能和物理特征，控制对这些特征的变更，记录和报变更处理及其实现状态，并验证与规格需求的一致性

配置项

置于软件配置管理之下的软件配置的各种有关项目，包括各类管理文档、评审记录与文档、软件文档、源码及其可执行码、运行所需的系统软件和支持软件以及有关数据等

配置管理活动

标识配置项
版本管理
变更控制
配置审计
状态报告
软件发布管理

版本管理

示意图

Git

版本控制问题

需求设计时改来改去就会有不同版本 解决办法1
锁住行为，一个人锁住，其他人就拿不到、不可修改
解决方法2
可以一起修改，然后merge，由一个人写进库；不是最终版本的人再pull一遍

分支管理常见策略

主分(Master)
开发分支(Develop)
临时性分支：功能(Feature)、预发布(Release)、修补bug(Fixbug)

Git的一些

git是一个协议
本地三个分区：工作区，暂存区，版本库
远程还有一个版本库

Git的分区

查看不同

git diff：工作区vs暂存区
git diff head：工作区vs版本库
git diff --cached：暂存区vs版本库
注：为啥需要暂存区

暂存区可以增加灵活性

变更控制

1. 提请者提请变更
2. 接受者接受请求
3. 评估者做变更评估（即评估变更的各种影响）
4. 变更控制委员会决定是否变更
5. 若拒绝，就完；若接受，交给相应变更人员执行，验证者验证
6. 会生成变更请求表单
   

管理实践

经济为本

1. 软件项目的投入：人员成本，工具购买，培训费用（开发人员获得开发项目所需技能），差旅费，维护费用，生产停顿的损失（因为项目调试），市场和服务费用，机会成本（因为投资该项目而不能投资别的项目或放银行收利息的机会成本）
2. 软件项目的产出：节约商业活动成本，创新商机增加销售，提高品牌含金量
3. 境界为本
   为技术而技术是条死胡同
   以经济原则指导软件项目决策过程
   按照产品规律来营销软件产品
   以收益为依据规划设计产品

分工协作

1. 建议的团队：首席程序员，副手，行政助理，编辑，秘书两名，程序管理员，工具专家，测试员，语言专家
2. 三驾马车：产品经理，项目经理，技术经理
3. 项目管理的角色
   非正式的角色
   明确定义的角色
       领导整个团队以了解项目工作（计划，进度安排以及收集需求）
       带领项目进行设计和开发工作（沟通，决策以及中期策略）
       驱动完成整个项目（领导力，风险管理，终局策略）

目标驱动

目标的原则：SMART原则

1. specific
2. measurable
3. achievable
4. reasonable
5. time

常来常往

相互尊重，管道流畅（保证有渠道），开放透明，坦诚真实

有张有弛

破冰会，发布聚会，休假，技术培训，人员培训和被培训，换个项目

不断总结

关键是不断

项目实践

1. 搞定团队
   选择技能互补的成员组成团队，明确分工（功能：产品经理；代码：技术经理；文档：文档编写；过程：技术经理）
   根据成员特点，选择团队结构（建议民主团队）
   建立团队章程
   明确团队的交流沟通手段
2. 配置管理
   gitlab管理
   建立group
   文档采用md文件
3. 项目结构
   项目结构图示
   
4. 项目开发管理工具
   
5. CI/CD
   
   
   
   
   
    
    
   
   

___Fin___