（软件/it）项目管理课程笔记（未完待续……）

课程来源：

中国大学mooc_软件项目管理_北邮

中国大学mooc_IT项目管理_厦大

 

1_基础和概述

1.1_项目与软件项目

1. 项目project：唯一、临时性
   1. 目标明确
   2. 项目活动间有相关性
   3. 周期有限定
   4. 独特性
   5. 成本约束
   6. 不确定
2. 项目集programs
3. 软件项目
4. 项目管理与软件项目管理
   1. 项目管理：理解
   2. 软件管理项目的核心约束：
      1. 确保项目满足范围、进度、成本等约束，提高质量
5. 老师说：不同于其他传统行业的项目管理，没有软件项目经历的人是很难干好软件项目管理的????

1.2_PMBOK与软件项目管理体系

1. project management body of knowledge （项目管理知识体系）
   1. 五大过程组
      1. 启动、计划、执行、控制、收尾
      2. 

 

1. 1. 10个范围/知识域
      1. 整合、范围、进度、成本、质量、人力、沟通、风险、采购
      2. 

 

1. 1. 49个过程
   2. 

 

1.3_敏捷项目管理

1. 敏捷项目管理与传统的区别
   1. 敏捷：自适应的过程（不断调整）
   2. 传统：预测性的过程（按照计划走，达到预期目标）
2. 敏捷宣言
   1. 
3. 敏捷项目领导的3个核心价值观
   1. 价值胜过约束
      1. 价值：可运行的软件
      2. 约束：成本约束等
   2. 团队胜过任务
   3. 适应胜过遵循敏捷原则
   4. 
4. 敏捷原则

• 尽早并持续地交付有价值的软件以满足顾客需求。
• 敏捷流程欢迎需求的变化, 并利用这种变化来提高用户的竞争优势。
• 经常发布可用的软件，发布间隔可以从几周到几个月，能短则短。
• 业务人员和开发人员在项目开发过程中应该每天共同工作。
• 以有进取心的人为项目核心，充分支持信任他们。
• 无论团队内外，面对面的交流始终是最有效的沟通方式
• 可用的软件是衡量项目进展的主要指标
• 敏捷流程应能保持可持续的发展。领导, 团队和用户应该能按照目前步调持续合作下去。
• 只有不断关注技术和设计才能越来越敏捷。
• 保持简明 - 尽可能简化工作量的技艺 - 极为重要。
• 只有能自我管理的团队才能创造优秀的架构, 需求和设计。
• 时时总结如何提高团队效率, 并付诸行动。

1.4 软件项目管理过程

2_软件项目确立

2.1_项目立项

1. 背景：略（客户提出需求）
   1. 并不是所有的需求都可以被实现，只有立项的需求才能被实现
2. 立项：
   1. 明确项目的目标、时间表、项目使用资源和经费，得到项目经理和项目发起人的认可
   2. 目标、时间、费用三要素的认可
3. 项目立项书
4. make or buy
   1. 需要通过计算成本/使用时间等来判断
   2. 如果是buy 则需要招投标

2.2_项目招投标流程

1. 流程
   1. 甲方招标书定义
      1. 邀请人
      2. 合同细节
      3. 需求
      4. 标书模板
   2. 乙方项目分析
      1. 流程（如何实施，如何满足甲方要求）
      2. 
   3. 招标与竞标
   4. 合同签署
2. 招标方式
   1. 公开招标：对于所有
   2. 有限招标：对于一定范围内
   3. 多方洽谈：甲方找几个人谈
   4. 直接谈判：直接找人
3. 案例

2.3_项目章程

1. project charter：确认项目存在的文件，包括对项目的确认，对项目经理的授权和项目目标的概述等
2. 敏捷项目章程
   1. 项目目标
   2. 发布标准
   3. 预期的工作流
3. 项目经理的职责
   1. 开发计划-->组织实施-->项目控制
   2. 敏捷强调：仆人式领导方式
4. 项目经理的能力
   1. 技术项目管理
   2. 领导力
   3. 战略和商务管理

3_生存期模型

3.1生存期模型选择

                四种项目模型：

               

3.2预测型：

1. 从头到尾按顺序来
2. 瀑布模型：需求明确，方案明确，适合短期项目
   1. 
3. V模型：需求明确，方案明确，对系统的性能、安全性要求高
   1. 

3.3迭代型/原型模型：

对原型不断的构造、评估、修改，一直迭代

需求不明确。复杂性高，需求变更频繁

3.4增量型：

1. 每个增量都是一个可交付的成果（最终结果）
2. 每个增量都包括设计、开发、测试、集成
   1. 
   2. 
3. 优点：
   1. 阶段式提交一个可交付的产品
   2. 关键的功能更早出现
   3. 早期预警问题避免缺陷蔓延
   4. 阶段性完成可以降低估计失误

3.5敏捷型：

1. 与传统模型的区别
   1. 敏捷：自适应的过程（不断调整）
   2. 传统：预测性的过程（按照计划走，达到预期目标）
2. 敏捷方法
   1. 

 

scrum

1. 项目需求来自待开发的功能离别
2. 初始需求，要有优先级，
3. 每个迭代按照优先级进行 ，1-4week，提交可交付的成果
4. 成果进行评审、反馈，进行下一个迭代

                         两层的项目规划

                                 远期：产品订单product backlog

                                 近期：冲刺订单sprint backlog

                         迭代开发过程

                                 四个会议进行管理

                                

                                

XP（extreme programming）极限编程

                         最佳实践

                                

                                 entire team practices

                                         whole team 团队意识：客户、程序员、分析员、经理。。。是平等的

                                         planning game 两个计划：发布计划、迭代计划

                                         small release 小版本：如果有可能每天都要发布小版本

                                         customer test 每个需求都有验收测试

                                 development team practices

                                         collective ownership 每个人都能读所有代码

                                         coding standard 编程标准

                                         sustaninable pace每周保证40h工作时间，统一效率

                                         metaphor 以讲故事的角度形象的描述需求

                                         continuous integration 频繁整合系统以发布一个新的可用系统

                                 developmentor practices

                                         simple design用最简单的办法实现小需求，后续不断地重整优化

                                         pair programming 结对编程，两个程序员在同一台机器上编写

                                         test-driven development 测试驱动开发，每次代码都应该运行一遍所有测试

                                         refactoring 重构，不断改进

 lean精益

                         不断改进（删除），减少流程浪费

  持续交付（CI/CD）

                        

                         持续集成

                                 将个人代码持续向集体部分交付

                         持续部署

                                 集成的代码持续向可运行的环境交付，测试

                         持续交付

                                 尽早向客户交付，以便发现生产环境中的问题

 DevOps：

                         development和operations组合，开发和运维紧密合作

 

4_软件需求管理

4.1需求管理过程（5个过程）

                需求确认：需求获取->需求分析->需求规格编写->需求验证

                         需求获取：问卷、讨论会、展示，最有效的是面对面的沟通）

                         需求分析：

                         需求规格编写：需求规格说明书

                需求变更

                         管理

                         核心是制定一个需求变更控制系统

                         需求变更控制流程

 4.2传统需求管理过程

                原型方法

                         通过不断的评价原型，完成需求的建模

                         工具：axture

                基于数据流方法-结构化建模

                        

                         数据流图DFD

                         数据字典DD

                         系统流程图

                基于UML方法-面向对象建模

                        

                        

                        

        4.3敏捷需求管理过程

               

               

                需求分析user story(对应UML的用例图)

                        

                        

                MoSCoW

                         优先级排序

                         Must have

                         should have

                         could have

                         want have

 

5_软件项目的任务分解/范围界定

        5.1任务分解的基本概念

                工作分解结构（WBS: work break down structure）

                         是对项目由粗到细的分解过程

                         面向交付成果

                         组织并定义了整个项目的范围

                工作包（work packages）

                         WBS的最低层次的可交付成果

                         工作包应当由唯一的主体负责

                         WBS字典：对工作包进行详细的解释

        5.2任务分解方法

                类比

                模板

                自上而下(最常规，由一般到特殊)

                自下而上

                WBS分解建议

                         最底层是可控和可管理的，但是不能过细

                         每个工作包必须有一个提交物

                         定义任务完成的标准

                         有利于责任分配

                         分解到40h以内，敏捷项目分解到小时

        5.3敏捷任务分解

                epic比较大、模糊的需求

                epic可以分解

                        

                acceptance criteria：epic分解完之后应该给出用户接受标准

                例子

 

6_软件项目成本计划

        6.1传统估算方法

                成本相关概念

                         软件项目规模：

                                 工作量

                                         例如：软件规划、项目管理、需求分析、系统设计、编码、测试、维护……

                                 规模单位

                         软件项目成本

                                 完成软件规模相应付出的代价

                                 待开发项目所需资金

                                 人的劳动的消耗所需要的代价是软件产品的主要成本

                                 货币单位

                         软件规模与成本的关系：

                                

                         成本估算的结果

                                 直接成本

                                 间接成本

                代码行估算法

                         特点

                                 与具体的编程语言有关

                                 分解足够详细

                                 有一定的经验数据

                         优点

                         缺点

                功能点估算方法

                         特点

                         albrecht

                                 简介

                                 公式

                                 UFC

                                         外部输入EI(external input)：例如输入的账号密码

                                         外部输出EO(external output)：例如教务系统显示的成绩

                                         外部查询EQ(external inquiiry)：就是查询啊

                                                 外部接口文件EIF'S(external interface files)

                                                 内部逻辑文件ILF'S（internal logical files)

                                 计数规则

                                         事务组件进行定级

                                                

                                                

                         其他方法

                用例点估算法

                         用例点的确定：通过用例图确定角色、用例、相应的复杂度

                         估算流程：通过用例视图确定角色、用例、相应的复杂级别，然后确定用例权值和角色权值，相加后得到未调整的用例点再计算技术复杂因子。。。

                                

                         步骤：

                                 UAW

                         解释：略

                类比/自上而下估算法

                         介绍

                         使用情况

                         相似项目

                                 先要计算相似度

                                 而实际中常常是主观判断

                自下而上估算法

                         定义

                         评价

                三点估算法

                         三种估算值

                         两种计算方法

                参数估算法

                         定义：参考的模型不定

                         walston-felix模型

                                 原理

                                 例子

                         COCOMO (constructive cost model)

                                 介绍

                                 原理

                                 COCOMO 81

                                        

                专家估算法

                         定义

                         算法

        6.2敏捷估算方法

                思路

               

               

                常用的

                过程

        6.3成本预算