项目(Project)是为了创造一个唯一的产品或提供一个唯一的服务而进行的临时性的努力。
项目管理是一系列的伴随着项目的进行而进行的、目的是为了确保项目能够达到期望的结果的一系列管理行为。
甲方招标书定义——乙方项目分析——招标与竞标——合同签署
作坊式——过程控制——敏捷——DevOps
优点：
敏捷方法是一个囊括了各种框架和方法的涵盖性术语。
XP(eXtremeProgramming)极限编程是由KentBeck提出的一套针对业务需求和软件开发实践的规则。
精益（Lean）模式提倡持续不断地改进,减少流程中的浪费。
DevOps是一组过程、方法与系统的统称，用于促进开发、技术运营和质量保障（QA）部门之间的沟通、协作与整合。
需求是指用户对软件的功能和性能的要求。
需求分析是为最终用户所看到的系统建立一个概念模型，是对需求的抽象描述。
需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书。
①确定需求变更控制过程
②建立变更控制委员会(SCCB)
③进行需求变更影响分析
④跟踪所有受需求变更影响的工作产品
⑤建立需求基准版本和需求控制版本文档
⑥维护需求变更的历史记录
⑦跟踪每项需求的状态
⑧衡量需求稳定性
传统方法:1.原型方法2.基于数据流建模3.基于UML建模
敏捷方法
任务分解是项目管理的基础
过程：将一个项目分解为更多的工作细目或者子项目，使项目变得更小、更易管理、更易操作
结果：WBS（WorkBreakdownStructure:任务分解结构）
软件项目规模即工作量例如：软件规划，软件管理，需求，设计，编码，测试，以及后期的维护等任务。
可以分摊到各个具体项目中的成本，例如：培训、房租水电、员工福利、市场费用、管理费、其他等等
从软件程序量的角度定义项目规模
优点：代码是所有软件开发项目都有的"产品"，而且很容易计算代码行数。
缺点：1.对代码行没有公认的可接受的标准定义
2.代码行数量依赖于所用的编程语言和个人的编程风格.
3.在项目早期,需求不稳定、设计不成熟、实现不确定的情况下很难准确地估算代码量.
4.代码行强调编码的工作量,只是项目实现阶段的一部分
FP=UFC*TCF
UFC：未调整功能点计数
TCF：技术复杂度因子
给软件提供面向应用的数据的项（如屏幕、表单、对话框、控件，文件等）；在这个过程中，数据穿越外部边界进入到系统内部。
向用户提供(经过处理的)面向应用的信息，例如，报表和出错信息等。
外部查询是一个输入引出一个即时的简单输出。没有处理过程。
1.计算未调整的角色权值UAW;
2.计算未调整的用例权值UUCW;
3.计算未调整的用例点UUCP;
4.计算技术和环境因子TEF;
5.计算调整的用例点UCP;
6.计算工作量(man－hours)。
估算人员根据以往的完成类似项目所消耗的总成本（或工作量），来推算将要开发的软件的总成本（或工作量）。是一种自上而下的估算形式。
利用任务分解图(WBS),对各个具体工作包进行详细的成本估算,然后将结果累加起来得出项目总成本。
基于任务成本的三种估算值来计算预期成本的方法.
最可能成本（CM）:比较现实的估算成本。
最乐观成本（CO）:最好情况所得到的估算成本。
最悲观成本（CP）:最差情况所得到的估算成本。
由多位专家进行成本估算，一个专家可能会有偏见，最好由多位专家进行估算，取得多个估算值,最后得出综合的估算值。
1.组织者确定专家，这些专家互相不见面
2.组织者发给每位专家一份软件规格说明
3.专家以无记名对该软件给出3个规模的估算值
①最小ai
②最可能的mi
③最大bi
4.组织者计算每位专家的Ei=(ai+4mi+bi)/6
5.最终可以获得一个多数专家共识的软件规模：E=E1+E2+…En/n（n:表示n个专家）
6.如果各个专家的估算差异超出规定的范围（例如：15%），则需重复上述过程
Storypoint（故事点）用来度量实现一个Story需要付出的工作量的相对估算。
1.给任务分配资源成本
2.给任务分配固定资源成本
3.给任务分配固定成本
当一个项目的资源需要固定数量的资金时，可以向任务分配固定资源成本。
进度是对执行的活动和里程碑制定的工作计划日期表
确定为完成项目的各个交付成果所必须进行的诸项具体活动
项目各项活动之间存在一定的关联关系，根据这些关系安排任务之间的顺序
前置活动（任务）→后置活动（任务）
PDM(PrecedenceDiagrammingMethod）
优先图法,节点法(单代号)网络图
ADM(ArrowDiagrammingMethod)
箭线法(双代号)网络图
T=Q/(R*S)
T:活动历时
Q:任务工作量
R:人力数量
S:工作效率（贡献率）
e.g:Q=6人天,R=2人,S=1则：T=3天
Q=6人天,R=2,S=0.5则：T=6天
D:进度(以月单位)
E:工作量(以人月单位)
a:2—4之间
b:1/3左右:依赖于项目的自然属性
Walston-Felix模型：
基本COCOMO:
管理预留是为管理控制的目的而特别留出的项目预算，用来应对项目范围中不可预见的风险。
根据下面专业知识而做出的历时估算
开发速度稳定前-举手表决
开发速度稳定后
传统估算方法:
敏捷估算方法:
作用：
1）解决任务的搭接
2）对任务可以进行合理的拆分
3）缩短项目工期
1.进度压缩单位成本方法线性关系
进度压缩单位成本=（压缩成本-正常成本）/(正常进度-压缩进度)
2.CharlesSymons(1991)方法进度压缩比普通进度短的时候，费用迅速上涨
进度压缩因子=压缩进度/正常进度
压缩进度的工作量=正常工作量/进度压缩因子
改变活动间的逻辑关系，并行开展某些活动.
提前量方法
资源平滑法是在项目编排中进行资源的优化配置，保证资源最优化、最优效。
Releaseplanning-发布计划–远期计划–粗计划.
Iterationplanning-迭代计划–近期计划–细计划
目标函数：
目标结果：f(x)达到最小
SCI:softwareconfigrationitem
受控于软件配置管理的款项
将软件项目中需要进行控制的部分拆分成SCI
建立配置项的对应关系，以便于进行跟踪和版本控制.实现数字化管理
建立配置管理库
开发都在分支上提交，并且可能有多个并行分支，直到快要上线时甚至上线后才合并到主干
所有提交到主干上，提交后自动触发持续集成进行验证和快速反馈
持续交付更倾向使用基于主干的开发模式
1.职能型
2.项目型
3.矩阵型
责任分配矩阵(RAM)
组织分解结构(OBS)
其它,例如文本型
干系人（stakeholder）是能影响项目决策、活动或者结果的个人、群体或者组织，以及会受到或者自认为会受到项目决策、活动或者结果影响的个人、群体或者组织。
1.书面沟通和口头沟通
2.语言沟通和非语言沟通
3.正式沟通和非正式沟通
4.单向沟通和双向沟通
5.网络沟通
沟通计划是确定谁需要信息，需要什么信息，何时需要信息，以及如何将信息分发给他们。
产品负责人(Productowner)
团队促进者(Teamfacilitator)
跨职能团队成员(Crossfunctionalteammember)
ProductOwner（产品负责人）
ScrumMaster（Scrum主管）
开发团队
最有效的敏捷团队往往由三到九个成员组成。(黄金人数5-9人)
理想情况下，敏捷团队应该集中在一个工作场所工作。
团队成员100%为专职成员,协同工作
敏捷鼓励自我管理团队
仆人式领导是通过对团队服务来领导团队的
仆人式领导为团队赋权
旨在使团队尽可能达到最高绩效。
将项目信息发布到公共空间
风险是对潜在的、未来可能发生损害的一种度量，如果风险确实发生了，则会对项目产生有害的或者负面的影响。
软件风险对软件开发过程及软件产品本身可能造成的伤害或损失
已知风险－Knownknown
可预测风险-Knownunknown
不可预测风险-unknownunknown
商业风险、管理风险、人员风险、技术风险、开发环境风险、客户风险、过程风险、产品规模风险等。
风险事件
事件概率
事件影响
风险识别是识别风险事件,系统化地确定对项目计划的威胁，识别已知和可预测的风险。
对风险事件发生概率的评估，对项目风险影响的评估，给出项目风险排序。
针对风险分析的结果，制定一定的行动和策略来对付、减少、以至于消灭风险事件造成的影响
风险控制是在项目执行过程中实施和监控风险计划，同时，不断进行风险识别、风险分析、风险规划的过程。
风险发生的概率（P）
风险对项目的影响（I）
风险值，R=F(P,I)
按风险值排序
定性评估风险概率及后果
风险概率度量：
风险影响度量
1.盈亏平衡分析
2.敏感性分析
3.模拟
4.决策树分析
决策树分析是一种图表分析方法
提供项目所有可供选择的行动方案，行动方案之间的关系，行动方案的后果以及发生的概率
提供选择一个最佳的方案的依据
EMV(损益期望值)是决策树的一种计算值
根据预期结果、发生的概率计算出一种期望的损益
例如：某行动方案成功的概率是50%，收益是10。EMV=10*50%=5
1.回避风险
2.转移风险
3.损失控制
4.自留风险
回避风险是对可能发生的风险尽可能的规避，采取主动放弃或者拒绝使用导致风险的方案
例如：放弃采用新技术
转移风险是为了避免承担风险损失，有意识将损失或与损失有关的财务后果转嫁出去的方法。
例如：分包、开脱责任合同、保险
例如：项目技术培训，预防技术失败损失预防
例如：项目人员储备，抑制人员流失的损失
由项目组织自己承担风险事故所致损失的措施。
损失预防与损失抑制策略
跨职能项目团队(识别风险)
选择迭代内容(选择风险小的)
频繁评审增量产品
持续测试可以及早发现问题
客户参与可以减少需求变更的风险
没有长期计划,识别一些风险比较困难.
没有长期规划，存在变更
范围执行控制是监督项目的范围状态，管理范围基准变更的过程。
防止不合理的范围扩张
把需求列入未完项
不断构建和评审原形系统
通过发布多个版本来明确需求
资源图、进度图、成本图
1）项目甘特图
2）延迟图
4）费用曲线图
5）资源图偏差
量化任务的计划偏差
对计划偏差进行根因分析
①BAC(BudgetAtCompletion)预算总值（估算结果）
③BCWS(Budgetedcostofworkscheduled)计划工作成本
④ACWP(Actualcostofworkperformed)实际工作成本
⑤BCWP(Budgetedcostofworkperformed)已获值(EarnedValue)
进度差异:SV（ScheduleVariance）=BCWP-BCWS
=0：按照计划进度进行
<0：落后于进度
>0：超前于进度
成本差异:CV（CostVariance)=BCWP-ACWP
=0：按照计划预算进行
<0：比预算差
>0：比预算好
进度效能指标SPI(SchedulePerformanceIndex)=BCWP/BCWS
=1：按照计划进度进行
>1：超前于进度
<1：落后于进度
成本效能指标CPI(CostPerformanceIndex)=BCWP/ACWP
=1：按照计划预算进行
>1：低于预算
<1：超出预算
EAC(EstimateAtCompletion)=BAC/CPI预测项目完成成本
成本偏差:VAC=BAC-EAC
未完工指数TCPI=剩余工作/剩余成本=(BAC-BCWP)/(Goal-ACWP)