软件工程与计算II-04-项目启动

本文主要内容来自 SpriCoder的博客，更换了更清晰的图片并对原文的疏漏做了补充和修正。

项目和项目管理

项目的核心是计划：计划包括项目需要的资源、活动，以及在项目中需要产生的中间交付产品。

项目

1. 项目是具有下列特征的一系列活动和任务[Kerzner2009]
   • 具有一个明确的目标；
   • 有限定的开始和结束日期；
   • 有成本限制；
   • 消耗人力和非人力资源；
   • 多工种合作。
2. 项目管理的目标
   • 在限定时间内；
   • 在一定的成本内；
   • 在要求的质量水平上；
   • 高效使用资源；
   • 获得客户认可。
3. 过程组：项目启动、项目计划、项目执行，项目跟踪与控制和项目收尾
4. 活动：计划制定、团队管理、成本控制、质量保障、度量、过程管理、进度跟踪与控制、风险管理、配置管理

团队组织与管理

团队

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

团队的特征

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

团队结构

1. 主程序员团队：决策需要由主程序员进行制定
   • 效率高，如果完成把握大，并且需要时间紧迫，可以优先考虑
   • 一个人的决断容易影响整个团队，如果项目复杂，主程序员会成为瓶颈。
   • 适用于把握性大，时间要求紧的情况
2. 民主团队：没有集中的瓶颈，成员发挥能动性，工作效率降低，冲突解决。敏捷+较有挑战性的项目
3. 开放团队：
   • 为了创新而存在的。黑箱管理，问题在于项目进展没有可视度。
   • 相对于前两个团队的需求明确，团队的需求并不明确
   • 管理者主要负责清除出现的障碍。
   • 开放团队是为了创新而存在

团队建设（高凝聚力的团队被称为胶冻团队） 重要

1. 建立团队章程：建立明确的团队章程，统一团队成员的目标，对团队成员进行一定的约束。经验：有必要指定一定的章程，约束团队成员之间的行为，比如开会请假必须得到其他三人的同意，又如一旦某项决策做出，不同意者不能再后续阶段违反等。

2. 持续成功：设置小里程碑，每隔一段时间让团队体验成功。每次作业的检查结果一定程度上肯定了每个小阶段的工作。

3. 和谐沟通：和谐沟通：建立持续有效的沟通机制，相互尊重，管道畅通，开放透明，坦诚真实。开会频率保持在每周一次左右为宜，在工作量大的时候，需要集体工作，当面沟通，另外吵架可以，但是需要达成一致。

4. 不断总结：不断总结上一阶段的工作成果，运用项目评审等手段，进行反思回顾，指导后续阶段的开发。每个阶段都会有启动会议对上个阶段进行回顾，评审会议对此阶段进行评审。

5. 避免团队杀手：需要对别人的工作全心全意的信任，尽管评审是必要的。产品质量的降低会使得凝聚力下降。

   • 防范式管理。
   • 官僚主义。
   • 地理分散：异地办公
   • 时间分割：可以保证全天候有人在
   • 产品质量的降低。
   • 虚假的最后期限。
   • 小圈子管理

6. 没有人能够成为多个胶冻团队的成员。

某小组的团队章程示例

开会规则：

1. 开会时间由组员协商决定（电话协商），开会地点为 509，一旦决定不允许请假、缺席。否则要求请其他小组成员喝冷饮，并组内批评。
2. 会前各小组成员要对所要讨论的议题有所准备，各小组成员均需发表个人看法，会议结果由表决决定，组长两票，组员各一票。会议期间需要有完整的记录。
3. 开会期间务须认真，不允许干任何于会议内容无关的事情。否则会内批评。

组内联系方式：

• 开会协商：电话、当面协商；
• 会议缺席、迟到：电话联系；
• 文档交流：邮箱、svn；
• 娱乐交流：qq；
• 项目产物交流：svn；

工作时间安排：

• 上午：9:00--11:30；
• 下午：14:00--17:00
• 晚上：19:00--21:00
• 周六、周日的上午跟晚上休息。
• 工作日的晚上如果项目进度较快可以选择性休息，但一周不允许超过两次。
• 如有无故旷课或早退现象需要写检讨并接受小组批评；如果早上迟到需要为大家带冷饮，迟到不允许超过 40 分钟，否则视为旷课。

不同人员激励因素比较，源自[Boehm1981]

软件质量保障

软件质量

1. 软件工程师也要对软件产品的质量负责。
2. 对软件质量的要求可能是显式的，也可能是隐式的。
3. 人们通常会选用系统的某些质量要素进行量化处理，建立质量特征，这些特征被称为质量属性（Quality Attribute)。
4. 为了根据质量属性描述和评价系统的整体质量，人们从很多质量属性的定义当中选择了一些能够相互配合、相互联系的特征集，它们被称为质量模型。
5. 详见书上的 IEEE 的标准 P54 页

质量模型

1. 因素
2. 功能性
3. 可靠性
4. 易用性：人机交互
5. 效率
6. 可维护性
7. 可移植性

质量保障

评审

典型的评审过程

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

质量度量

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

质量保障有哪些措施（重要）

1. 需求开发——需求评审和需求度量；
2. 体系结构——体系结构评审和集成测试（持续集成）；
3. 详细设计——详细设计评审、设计度量和集成测试（持续集成）；
4. 构造阶段——代码评审、代码度量、测试（测试驱动和持续集成）；
5. 测试阶段——测试、测试度量。

在实践中，软件交付完成后还会要求进行交付计划评审，软件维护阶段还会要求进行回归测试和维护度量。要及时的根据保障计划进行质量验证，质量验证的方法主要有评审、测试和质量度量三种。

软件配置管理

软件配置管理的动机

1. 在软件开发活动中，除了最终产品之外，还会产生很多中间制品，例如需求规格说明、需求分析模型、软件体系结构设计模型、详细设计模型等。这些制品是不同阶段、不同角色、不同软件开发活动进行协同的基础。
2. 在复杂软件系统开发中，产生的制品数量众多，以至于开发者需要维护一个清单才能清楚项目所处的状态，理解已经完成的工作和将要进行的工作。
3. 某个制品发生变化带来的最大挑战是如何确保其使用者能够得到最新的制品，避免开发协同出现问题。

配置管理

1. IEEE 将配置管理定义为[IEEE610.12-1990]："用技术的和管理的指导和监督方法，来标识和说明配置项的功能和物理特征，控制对这些特征的变更，记录和报告变更处理及其实现状态，并验证与规格需求的一致性"。

配置项

1. IEEE 将配置项定义为[IEEE610.12-1990]：“置于软件配置管理之下的软件配置的各种有关项目，包括各类管理文档、评审记录与文档、软件文档、源码及其可执行码、运行所需的系统软件和支持软件以及有关数据等”。

2. 一旦需求发生变更，则需要从评审开始重新操作

基线

1. 基线是指通过了评审和验证，可以作为后续开发工作基础而进入协同工作过程，需要纳入配置管理和执行变更控制的制品称为该配置项的基线。

配置管理活动（重要）

1. 标识配置项版本管理：确定应该被保留的部分，并且给予他们确定标识，包含配置项的特征，包括生产者、基线建立时间、使用者等。
2. 版本管理：极其重要
3. 变更控制：变更请求表单，教材 61 页
4. 配置审计：验证配置项的完整性、正确性、一致性和可追踪性。
5. 状态报告：反映当前的配置状态。
6. 软件发布管理：将配置项发布到开发活动之外，例如发布给客户。

辅助管理工具

在项目实践中，使用配置管理工具对项目进行配置管理，如 SVN。

版本管理示意图

版本控制的问题

lock-modify-unlock solution

copy-modify-merge solution

Android Open Source Project Code and Releases

分支管理常见策略

1. 主分支（Master)
2. 开发分支（Develop)
3. 临时性分支
   • 功能（Feature)
   • 预发布（Release)
   • 修补 bug(Fixbug)

Master	Develop	Feature	Fixbug

Git 分区

查看不同

1. git diff
   • 工作区 vs 暂存区
2. git diff head
   • 工作区 vs 版本库
3. git diff --cached
   • 暂存区 vs 版本库

为啥要暂存区

1. 增加灵活性
   • 修改了 4 个文件，在不放弃任何修改的情况下，其中一个文件不想提交，如何操作？（没 add ： git add 已经 add： git reset --soft )
   • 修改到一半的文件，突然间不需要或者放弃修改了，怎么恢复未修改前文件？ (git checkout)
   • 代码写一半，被打断去做其他功能开发，未完成代码保存？(git stash)
   • 代码写一半，发现忘记切换分支了？(git stash & git checkout)
   • 代码需要回滚了？(git reset)

变更控制

变更要求表单

管理实践

经济为本

1. 人员的成本：这是最重要的一部分投入。现在的软件从业人员的工资不断上涨，工资占整个软件成本的比例更是呈上升趋势。 除了开发人员外，还要计算项目管理人员和其他相应支持人员的费用（不是全职的，按时间乘比例计算）。
2. 工具的购买：包括计算机及其周围配套设备等硬件，也包括开发工具、办公套件等软件。
3. 培训的费用：开发人员接受培训，获得开发项目所需技能的费用。
4. 差旅费：拜访客户，参加会议等的费用。
5. 维护的费用：定时的数据备份、系统监控、系统维修和升级等引起的费用。
6. 生产停顿的损失：因为项目调试引起正常工作业务停顿的损失。
7. 市场和服务的费用：推广软件产品所要的广告费用、参加展览会的费用等。
8. 机会成本：因为投资该项目，而不能投资别的项目或者放银行收取利息的机会成本。
9. 节约商业活动成本：只要是和无新软件系统时候比较，将节省的时间和原材料折算成量化的数字。例如，开发了新的库存管理系统后，加快了流通并减少了库存浪费。
10. 创新商机增加销售：指由于使用新软件带来的盈利，可能是软件产品本身的销售，也可能是软件项目带来的营业成长。
11. 提高品牌含金量： 提高质量和客户满意度，可以带来品牌含金量的提高。这比较虚一点，但也可以像企业的无形资产一样估算。

总结

1. 为技术而技术是条死胡同
2. 以经济原则指导软件项目的决策过程
3. 按照产品规律来营销软件产品
4. 以收益为依据规划设计产品

分工协作

建议的团队

1. 首席程序员
2. 副手
3. 行政助理
4. 编辑
5. 秘书两名
6. 程序管理员
7. 工具专家
8. 测试员
9. 语言专家

三架马车

1. 产品经理：关于产品需求
2. 项目经理：实施过程中的管理
   • 配置管理、合理、管理、控制
3. 技术经理：保证可以克服技术难题

项目管理的角色

1. 非正式的角色
2. 明确定义的角色（PM)
   • 领导整个团队以了解项目工作（计划，进度安排以及收集需求）
   • 带领项目进行设计和开发工作（沟通、决策以及中期策略）
   • 以及驱动完成整个项目（领导力、风险管理以及终局策略）

目标驱动

1. 确保原因的合理性

目标的 SMART 原则

1. specific 明确的
2. measurable 可度量的
3. achievable 可实现的
4. reasonable 有理由的
5. time 时间

常来常往

观念

1. 相互尊重
2. 管道流畅
3. 开放透明
4. 坦诚真实

有张有弛

方法

1. 启动大会
2. 发布聚会
3. 休假
4. 技术培训
5. 人员培训和被培训
6. 换个项目

不断总结

1. 关键是“不断”

给管理新手的建议

1. 压力和分心
2. 不要将流程与目标相混淆
3. 适度参与
4. 利用好自己的观点
5. 创造独特的价值
6. 你所知道的比你想象的要多。
7. 让人喜欢是好事，但不用刻意讨好。
8. 人们并不介意自己被管理。
9. 如果你想唤起别人对某件事的热情，自己先表现出热情。
10. 需要坦白的时候就直言不讳。
11. 你需要不停地进步。

项目实践

1. 为实践项目组建你的团队：
   • 选择技能互补的成员组成团队，明确分工；
   • 根据成员特点，选择团队结构；（建议使用民主团队）
   • 建立团队章程；
   • 明确团队的交流沟通手段。
   • 需要保留开发过程，用来确保可查
2. 配置管理
   • 所有产物都通过 Gitlab 来管理
   • 建立 Group
   • 文档采用 MD 文件
3. 项目结构：

ERPnju
├── src
│   ├── main
│   │   ├── java
│   │   └── resources
│   └── test
│       ├── java
│       └── resources
└── doc
    ├── md
    └── img

项目开发管理工具

CI/CD