day48_项目管理学习笔记

• 课程目标
  • 认识项目管理
  • 了解软件项目管理的整个过程
  • 软件工程师在`整个项目过程中要做哪些工作`
  • 提前规划自己的职业生涯，遇到机会立即抓住机会
  • 通过学习本课程学会用 `项目管理的方式去工作`
• 课程安排
  • 第一章：项目与项目管理
  • 第二章：项目启动
  • 第三章：项目规划
  • 第四章：项目实施及控制
  • 第五章：项目结束
  • 第六章：课程学完后的思考

一、项目与项目管理

1.1、项目的定义

项目与日常运作图解：

项目与日常运作的区别：

• 项目是一次性的，日常运作是重复进行的。
• 项目是以目标为导向的，日常运作是通过效率和有效性体现的。
• 项目是通过项目经理及其团队工作完成的，而日常运作是职能式的线性管理。
• 项目存在大量的变更管理，而日常运作则基本保持连贯性的。

项目的特征：

• 有明确的目标性
• 有明确的时限性
• 资源成本的约束性
• 项目的不确定性
• 唯一性(一次性)

项目的定义：

• 日常运作：连续不断、周而复始的活动。
• 项目：是为了创造一个唯一的产品或提供一个唯一的服务而进行的临时性的活动。

1.2、项目管理的定义

项目管理的重要性：

• 据有关统计，全球的项目投资高达十万亿美元，其中在美国有2.5万亿美元，占GDP25%，全球从事项目管理人员大约有11650多万人，其中美国有450多万人。中国未来5年内在信息化建设的投资有上万亿人民币。
• 软件项目越来越复杂（需求、技术、用户关系、后期维护等），很多项目都失败了，导致失败的根本原因：是缺乏有效的项目管理，缺乏合格的软件项目经理。
• 企业成功：在于有效的推行项目管理。

项目管理的通俗理解：

• 假设我们要做一件事情，有一定的约束和目标要求，诸如时间、资金、人力等条件限制，那么如何在这些约束条件下有效地达到我们预想的目标，通过相关的理念、技术方法和工具进行管理的过程就是项目管理。

项目管理的定义：

• 使项目能够按照预定的成本、进度、质量顺利完成并让所有干系人得到满意，而对成本、人员、进度、质量、风险等进行分析和管理的活动。

1.3、项目管理框架

项目管理框架：

• 五大标准化过程组
• 十大知识领域
• 四十七个过程

项目管理的五大标准化过程组：

• 启动阶段 项目的可行性分析、立项、招投标、合同签署。
• 计划阶段 范围定义、进度安排、资源计划、成本估计、质量保证计划、风险计划、实施计划等。
• 实施及控制阶段 项目实施、进度控制、费用控制、质量控制、变更控制等。
• 结束阶段 范围确认、质量验收、费用结算与审计、项目资料验收、项目交接与清算、项目审计与评估、项目总结等。

项目管理的十大知识领域：

项目管理的四十七个过程：

二、项目启动

2.1、初始项目分析

项目类型：

• 合同项目 招投标、合同谈判、合同签署，甲乙双方有合同约束。 参考项目文档“XXXXX合同书”
• 内部项目 确定任务范围和相关各人员进行有效地配合，无合同约束。

初始化项目分析：

• 项目可行性分析 根据市场、技术、人员等各资源分析项目的可行性，对分析结果进行认证讨论。
• 项目范围分析 确定项目的功能模块、边界范围等。
• 项目干系人分析 分析确定项目相关人员，包括：项目发起人、项目开发人员、测试人员、维护人员、客户等。

常用的项目生存期模型：

• 瀑布模型
• 原型模型
• 增量模型

瀑布模型：

• 瀑布模型（Waterfall Model） 是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好“返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段，这也是瀑布模型名称的由来。

瀑布模型的特点：

• 项目需求很明确
• 解决方案也很明确
• 类似的项目如：
  • 库存管理系统
  • 短期项目

原型模型：

• 原型模型即样品模型，先借用已有系统作为原型模型，通过“样品”不断改进（迭代），使得最后的产品就是用户所需要的。
• 原型模型采用逐步求精的方法完善原型，使得原型能够“快速”开发，避免了像瀑布模型一样在冗长的开发过程中难以对用户的反馈作出快速的响应。
• 常用的原型工具：Axure

原型模型的特点：

• 在项目开始前，项目的需求不明确
• 需要减少项目需求的不确定性
• 类似的项目如：
  • 第一次开发的产品，验证可行性

增量模型：

• 增量模型融合了瀑布模型的基本成分（重复应用）和原型实现的迭代特征，该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的“增量”。
• 当使用增量模型时，第1个增量往往是核心的产品，即：第1个增量实现了基本的需求，但很多补充的特征还没有发布。客户对每一个增量的使用和评估都作为下一个增量发布的新特征和功能，这个过程在每一个增量发布后不断重复，直到产生了最终的完善产品。

增量模型的特点：

• 项目开始，明确了需求的一部分，但是需求可能会发生变化
• 对于市场和用户把握不是很准，需要逐步了解
• 对于有庞大和复杂功能的系统进行功能改进，就需要一步一步实施的

2.2、生存期模型

选择生存期模型

• 评审、分析项目的特性
• 选择适合项目的生存期模型

项目经理的角色

• 项目组织的领导者
• 项目组织的管理者
• 项目组织的决策者
• 项目组织的分析者
• 项目组织的计划者
• 项目组织的控制者
• 项目组织的组织者
• 项目组织的评价者
• 项目组织的协调者

项目经理的责任

• 项目计划
• 组织实施
• 项目控制

2.3、项目立项

项目立项-项目章程

• 确认项目存在的文件，包括对项目的确认、对项目经理的授权和项目目标的概述等。
• 将项目启动阶段的工作内容形成统一的立项文档，文档没有统一的格式根据公司实际管理水平制定。
  • 参考资料：项目章程

项目立项—立项申请报告

• 明确项目的目标、时间、项目使用的资源和经费，而且得到执行该项目的项目经理和项目发起人的认可。
  • 参考资料：项目立项申请报告

招开项目立项会

• 通常由公司PMO(项目管理办公室)组织立项会，对项目的调研、范围、项目经理等进行确定授权、评审、最后要有评审报告。
  • 参考资料：立项评审报告

三、项目规划

• 范围计划
• 进度计划
• 成本计划
• 质量计划
• 人力资源计划
• 沟通计划
• 风险计划

3.1、范围计划

WBS任务分解：

• 工作分解结构（Work Breakdown Structure，简称WBS）就是把一个项目按一定的原则分解，项目分解成任务，任务再分解成一项项工作，再把一项项工作分配到每个人的日常活动中，直到分解不下去为止。
  • 即：项目 --> 任务 --> 工作 --> 日常活动
• 工作分解结构以可交付成果为导向对项目要素进行的分组，它归纳和定义了项目的整个工作范围，每下降一层代表对项目工作的更详细定义。
• WBS总是处于计划过程的中心，也是制定进度计划、资源需求、成本预算、风险管理计划和采购计划等的重要基础。

工作包：

• WBS的最低层次的项目可交付成果称为工作包(Work Package)，具有以下特点：
  • 工作包可以分配给另一位项目经理进行计划和执行。
  • 工作包可以通过子项目的方式进一步分解为子项目的WBS。
  • 工作包可以在制定项目进度计划时，进一步分解为活动。
  • 工作包可以由惟一的一个部门或承包商负责。用于在组织之外分包时，称为委托包(Commitment Package)。
• 工作包的定义应考虑80小时法则(80-HourRule)或两周法则(Two Week Rule)。
• 即：任何工作包的完成时间应当不超过80小时。在每个80小时或少于80小时结束时，只报告该工作包是否完成。通过这种定期检查的方法，可以控制项目的变化。

任务分解原则：

• 1、将主体目标逐步细化分解，最底层的日常活动可直接分派到个人去完成；
• 2、每个任务原则上要求分解到不能再细分为止；
• 3、日常活动要对应到人、时间和资金投入。

任务分解方法：

• 1、采用树状结构进行分解；
• 2、以团队为中心，自上而下与自下而上的充分沟通，一对一个别交流与讨论，分解单项工作。

3.2、进度计划

制定MPP

• 使用MPP工具制定进度计划
• 参考资料：软件项目计划.mpp

四、项目实施及控制

团队管理的要点：

• 合理的人员结构
• 明确的职责及工作分工
• 适度的激励政策
• 集体责任感和荣誉感的培养和加强
• 共同提高的指导思想

编码的基本原则：

• 严格按照系统设计说明书完成软件的编码工作。
• 执行制定的软件编码规范。
• 提炼公用代码，加强公共模块的开发，提高开发效率。
• 注重软件阶段性成果及文档资料的管理工作，加强版本控制。

编码规范：

• 标示符的命名规范
  • （1）符号的名字应尽量能反映它所代表的类型、含义、功能、调用特点等。
  • （2）应有一定的实际意义，使非本程序编写的同行能够见名知意。这有助于加强对程序功能的理解，增加程序的可读性。
• 注释规范
  • （1）序言性注释 　　类、方法名之前，对定义、输入、输出、参数、功能、调用形式等整体说明。
  • （2）功能性注释 　　方法内部实现过程的段落性注释。描述其语句说明、程序段或变量完成的功能及意义。
• 程序的书写格式
  • （1）在程序的编写中应学会使用使用空行和缩进，以增强程序代码的段落性和可读性。
  • （2）循环、分支嵌套层次不要太深。
• 公共代码的抽取及开发
  • 软件开发过程中往往存在大量的公共代码，在进行任务分解的时候要善于抽取出较多的公共代码，并安排技术能力较强、开发经验丰富的软件工程师承担公共模块的开发任务，降低软件开发中的重复劳动，提高软件编码的工作效率及软件质量。
• 代码质量管理
  • 正确理解设计说明书
  • 强制要求所有开发人员的代码符合编码规范
  • 定期和不定期的代码走查(code walkthrough)
  • 编码规范模板
• 软件测试V模型

• 单元测试
  • 单元测试是针对软件设计的功能方法，进行正确性检验的测试工作。其目的在于发现`各模块`内部可能存在的各种差错。
  • 单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。
• 集成测试
  • 将所有模块按照设计要求组装成为系统。这时需要考虑的问题是：
    • 模块接口的数据是否会丢失
    • 模块之间的功能是否产生不利的影响
    • 模块组合起来能否达到预期要求
    • 全局数据结构是否有问题
• 系统测试
  • 是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起，进行信息系统的各种组装测试和确认测试，系统测试是针对整个产品系统进行的测试。对象不仅仅包括需测试的软件，还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。
• 验收测试
  • 验收测试是以用户为主的测试。软件开发人员和QA（质量保证）人员也应参加。
  • 由用户参加设计测试用例，使用生产中的实际数据进行测试。
  • 在测试过程中，除了考虑软件的功能和性能外，还应对软件的可移植性、兼容性、可维护性、错误的恢复功能等进行确认。

五、项目结束

制定结束要做的工作

• 制定结束计划
• 完成收尾工作
• 项目结束评审
• 项目总结
  • 总结成功的经验和失败的教训
  • 软件项目历程文件
  • 将项目中的有用信息进行总结分类，放入信息库，它是软件项目记录的资料
  • 它对将来的项目是有用的，并从中提取一般教训

六、课程学完后的思考

• 职业规划
• 实际工作中如何运用本课程
• 职业人生的几点建议

软件开发职业路线：

• 技术路线：
  • 程序员 --> 高级程序员 --> 系统分析员(系统设计) --> `系统架构师` --> 技术主管（CTO）
• 业务路线：
  • 程序员 --> 高级程序员 --> 系统分析员(需求分析) --> `项目经理` --> 产品经理

实际工作中如何运用本课程：

职业人生的几点建议：

只要你感兴趣，这就是你的天赋，确定目标，全力以赴，一定成功！