[读书笔记]传统方法VS敏捷
本文地址:http://www.cnblogs.com/raol/archive/2013/04/12/pmp_vs_agile.html
大纲
1.集成管理
2.范围管理
3.时间管理
4.成本管理
5.质量管理
6.人力资源
7.沟通管理
8.风险管理
9.采购管理
1.集成管理
开发项目章程和初步范围陈述
|
传统方法
|
敏捷方法
|
|
从合适的群体或得关于项目目标和论证方面的输入和反馈
|
从合适的群体或得关于项目目标和论证方面的输入和反馈，并将其最为会议的内容
|
|
为获得公司和项目委员会批准而准备一个业务案例以及相关文档
|
如有必要，可以有
|
|
使用公司认可的软件开发方法
|
使用一种敏捷开发方法
|
开发项目管理计划
|
传统方法
|
敏捷方法
|
|
编写正式的文档描述所使用的项目管理过程（如质量管理，沟通管理，风险管理），描述这些过程的实现级别以及如何实现
|
从项目团队选择的敏捷框架开始，准汛期中的指导原则，在每个迭代结束时价差和修正项目管理计划
|
|
编写正式文档和利益相关者沟通方法
|
遵循敏捷原则，让所有的项目信息任何时候都对感兴趣的团体可见，平做出相应的安排
|
|
定义关键管理评审的时间界限
|
管理者和其他例子相关人应该在任何时间对高可见的信息进行评审，迭代结束时也要进行常规评审
|
|
确定正式编写文档来描述变更如何被监视和控制
|
在项目演示和计划会议上识别出变更，并将其记录下产品待完善事项列表中，在评审和回顾会议上识别出过程变更
|
|
确定并编写文档来秒速配置管理如何进行
|
确定配置管理作为团队的工作协议的一部分将如何执行。
|
指导和管理项目的执行、监视和控制
|
传统方法
|
敏捷方法
|
|
直接执行
|
发挥领导作用，培养写作制定决策的环境
|
|
确保执行计划
|
通过遵循所选择的的敏捷方法的基本原则，保证团队对变更的应变能力
|
|
比较实际和计划的差异
|
迭代评审
|
|
采用纠正措施
|
回顾会议
|
|
搜集项目数据和报告项目状态
|
确保有创建高可用的空间和资源，促进演示和评审
|
集成变更控制
|
传统方法
|
敏捷方法
|
|
建立一个变更控制委员会
|
项目团队就是一个变更控制委员会，同时客户是产品变更决策的最终裁决着，团队是过程变更的裁决者
|
|
建立变更请求，并建立文档记录
|
变更请求源自于产品演示的讨论
|
|
确定变更请求的解决方案并建立文档记录
|
产品变更进入PBL并从新排级
|
|
确认方案
|
客户批准已经完成的事项，提醒团队不要忘记过程变更协议
|
|
确定变更影响项目的其他区域，并建立文档
|
每次迭代结束是，重新考察计划并作出必要的变更。
|
2.范围管理
|
范围定义
|
|
|
传统方法
|
敏捷方法
|
|
准备项目范围陈述文档，其中包含下列条目：项目边界目标、产品范围描述......
|
|
|
主要的里程碑和项目交付
|
举行计划会议，准备产品路线图以及举行发布或季度计划会议，确定迭代层次上的里程碑和交付品。
|
|
产品规约和认可标准
|
根据项目团队对“完成定义”和客户定义的接受标准，举行一个迭代计划会议，产生每个特性的细节以及完成这些特性所需要执行的任务。
|
|
假设和约束
|
所有会议都评审和约束
|
任务分解（WBS）
|
传统方法
|
敏捷方法
|
|
创建工作分解结构图
|
举行计划会议，给项目团队分配创建分解结构的职责，将工作分解为更小的工作包，在发布计划中显示高层分解，迭代计划中显示更详细的分解。
|
范围验证
|
传统方法
|
敏捷方法
|
|
用文档记录已经完成的并且被客户接受的交付品和那些没有被接收的交付品以及没有接受的原因
|
用文档记录客户接受的特性可以是正式的也可以是非正式的。
|
|
用文档记录变更请求
|
客户更新待完成事项列表
|
范围控制
面对经常变更的需求-增加迭代周期，减少迭代长度。
|
传统方法
|
敏捷方法
|
|
利用变更系统来管理变更
|
客户管理产品完成事项列表，一旦项目团队交付了需要在一个迭代中完成的工作，范围就应该在迭代期间受到保护
|
|
变更被批准后，更新所有涉及的文档。
|
团队重新审视发布计划，形成路线图，做出必要的变更以便更好的反映团队的进展和客户所请求的变更。
|
3.时间管理
|
战略层的时间进度计划
|
|
|
传统方法
|
敏捷方法
|
|
创建最终的项目进度计划和基线
|
促进协同创建发布计划，产生每一季度的高层计划，其中描述了发布目标，
|
|
酌情更新活动属性，资源，项目计划
|
协助团队根据迭代的执行结果按需要更新发布计划。
|
战略层的进度计划控制
|
传统方法
|
敏捷方法
|
|
基于批准的变更和新基线更新时间进度计划
|
举行评审会议，在会议中团队基于项目执行速度和待完成事项列表的变更来更新发布计划
|
|
计算进度变化和进度性能索引
|
提醒团队应该承担的有关更新迭代待完成列表中的工作，每次迭代结束时更新发布燃尽图
|
|
跟踪和记录请求变更
|
客户更新PBL
|
|
识别和分析推荐的纠正的动作，回到预订的轨道。
|
进行讨论，采取任何纠正性动作（增加迭代，增加团队，减少特性，终止项目）
|
战术层面的会议进入到迭代
|
传统方法
|
敏捷方法
|
|
准备一个任务列表，该列表指出了项目中所有按照时间计划完成的任务。
|
对于每一次迭代，团队将选择的特性分解成任务列表。
|
|
定义任务属性，入负责人，约束假设，工作量
|
定义任务属性，入负责人，约束假设，工作量，迭代计划中定义。
|
|
建立里程碑，安插到项目进度计划中
|
在发布计划中识别主题，每次的增量可作为一个里程碑
|
|
活动的变更加入到变更请求过程
|
发现新的需求，加入PBL，时间盒不会变化
|
|
评估任务时间
|
项目团队在迭代计划期间估计
|
排序
|
传统方法
|
敏捷方法
|
|
定义排序活动，显示在项目的时间进度计划图中
|
为迭代计划做准备，在迭代计划中团队将决定如何处理
|
|
截取对活动列表，星星，变更执行相应的处理
|
根据新的发现有团队维护依赖关系来更新相应的迭代完成事项列表
|
战术层的进度计划控制
|
传统方法
|
敏捷方法
|
|
基于批准的变更重新建立基线，更新时间进度
|
迭代得到了计划，不应许发生变更，不过如果变更使的否定了本次迭代的价值，那么可以决定终止本次迭代。
|
|
计算时间进度的变通方法
|
团队以天数为基础更新迭代列表的剩余工作量，测量自己的速度
|
|
跟踪记录请求的变更
|
客户更新PBL
|
|
识别和分析推荐的纠正的动作，回到预订的轨道。
|
进行讨论，采取任何纠正性动作（增加迭代，增加团队，减少特性，终止项目）
|
4.成本管理
成本评估
|
传统方法
|
敏捷方法
|
|
采用适当的技术在细节和整体上准备成本评估，采用自底向上的方式来实现评估
|
利用自顶向下的技术和发布会以的输出进行成本评估
|
|
采用正式的变更控制过程
|
更新PBI反应新的变化的需求，团队决定发布计划受什么影响。
|
成本预算
|
传统方法
|
敏捷方法
|
|
为整个喜爱那个木准备一个成本基线，根据基线推算出项目的资金
|
团队提供发布计划，根据整个发布计划，通过获取迭代的成本推算出成本基线
|
|
根据变更更新成本计划
|
每次迭代计划之后更新发布计划成本
|
成本控制
|
传统方法
|
敏捷方法
|
|
基于已获批准的变更，新的预测以及诸如EV这样的性能度量结果对成本估算结果和成本基线进行更新
|
利用喜爱那个木团队迭代式学习技术（以及其他技术入AgileEVM），更新发布计划中的成本基线。
|
|
交付给一个正式的变更控制过程。目的是让成本重新复核最初的计划
|
团队每个迭代细化他们的预测，更新发布计划，发布待完成事项列表和成本评估结果。
|
5.质量管理
质量计划
|
传统方法
|
敏捷方法
|
|
同QA进行会晤，决定如何实施质量策略和质量标准
|
询问客户和团队，决定当前的质量策略和标准。
|
|
产生一个正式的文档，阐述了质量管理计划和过程改进计划的大纲
|
产生团队的工作协议和编码测试标准
|
|
注意跟踪项目执行期间产生的一些度量值
|
就那些度量对确定质量水平起作用等问题或得项目团队的一致意见，讨论采用一些有助于管理的度量。
|
质量保证
|
传统方法
|
敏捷方法
|
|
|
将质量人员作为项目的团队成员，鼓励参与产品开发活动
|
|
执行审核
|
执行迭代的演示，评审和回顾
|
|
执行过程分析
|
执行过程分析
|
|
识别请求的变更以及推荐的纠正措施
|
在评审和回顾会议识别推荐的变更，采取相应的措施。
|
质量控制
|
传统方法
|
敏捷方法
|
|
在项目结束前测试代码，查找bug
|
在没一个迭代中都测试和查找bug
|
|
如果人工测试能完成大部分测试工作，那么我们的测试工作就完成了
|
如果人工测试承担了大部分工作是不行的，人工测试将是一个瓶颈，相反我们尽可能多的进行自动化，以便能够维持对质量的控制并加快交付速度。
|
|
参考一些告诉我们测试什么以及测试的预期结果是什么？
|
作为团队的一部分，QA与开发和客户一起工作，理解应该测试什么？测试的预期结果是什么？以及接受标准。
|
|
日志记录缺陷
|
发现bug告诉开发人员，并验收重现过程，没有修复的bug放入，待完成列表
|
|
使用不同的工具（《PMBOK Guide》介绍了“7中基本质量工具”）监视产品质量
|
使用通过测试和客户认可的手段
|
|
使用不同的工具监视过程的质量，包括采用审核
|
通过使用燃尽图，度量值，和根源分析等作为主要手段监视过程的质量。每个迭代结束时评审和回顾会议上对监视情况进行评审。
|
6.人力资源
规划
|
传统方法
|
敏捷方法
|
|
基于详细的项目计划和进度表，确定所需要的技能以及成员参与该项目的时间表
|
创建一个完备的跨功能团队，基于发布计划，确定团队中还不具备的专家以及每个成员的时间表
|
|
结果记录在正式的概述员工管理计划文件中
|
记录在非正式的文档中
|
组件项目团队
|
传统方法
|
敏捷方法
|
|
根据与昂管理计划寻找团队成员，并酌情更改文档
|
建立一个跨功能的团队，让团队所有成员自己应该平等地承担交付该产品的责任
|
|
与团队进行沟通，给出项目期间需要他们的日期或者百分比。
|
沟通找到完全致力于项目的团队成员
|
|
通过虚拟团队节省开支
|
团队在同一位置节省开支，提高生产力。
|
发展项目团队
|
掌握一些软技能，比如：同理心，倾听，解决问题，促进
|
掌握一些软技能，比如：同理心，倾听，解决问题，促进
|
|
处于同一位置是个好方案，
|
处于同一位置是个首选方案
|
|
提供一些可以建立信任和确定良好工作关系的团队建设活动
|
建立信任和确定良好工作关系的团队建设是敏捷框架的一部分
|
|
未定义团队价值观和设定明确的期望为团队制定一些基本原则
|
为了定义团队价值观和设定明确的期望，有团队定义基本原则和约定
|
|
承认和奖励有意义的行为
|
提供一个充满活力的团队环境，为员工提供各种发展机会，鞋机新技能，经历任务中的变化，发展和演示，勇敢面对挑战和成功的喜悦
|
|
通过评估来评价团队的绩效
|
采用回顾来评价团队的绩效，并且决定改进的方法
|
管理项目团队
|
传统方法
|
敏捷方法
|
|
观察团队的工作，通过谈话保持相对了解
|
与团队坐在一起进行指导，帮助成员专注于与目标并对过程进行必要的修改，定期和团队成员进行一对一的交流以便共享反馈和解决问题
|
|
为团队成员进行绩效
|
避免个人绩效
|
|
采取一些预防和纠正措施，比如进行交叉培训或者额外的培训，人事变动，纪律处分以及奖励
|
采用迭代评审和回顾使用团队的收集，评估和实现提高的建议
|
7.沟通管理
沟通规划
|
传统方法
|
敏捷方法
|
|
决定重要的信息，这些信息是何时，怎么样，以及谁会进行关于项目的沟通
|
决定重要的信息，这些信息是何时，怎么样，以及谁会进行关于项目的沟通
|
|
准备一个沟通计划文档
|
决定作为一个团队在整个计划会议中（立项，发布计划，迭代，每日立会）不断的沟通（通过wiki，workshop等）以及接下来更加正式的沟通
|
项目发布
|
传统方法
|
敏捷方法
|
|
设计和监测交流方式
|
注重面对面的交流
|
|
定义信息整合和信息检索系统
|
整个团队非常容易的整合和检索系统
|
|
设计信息发布方式
|
保持发布信息的简洁性
|
|
通过总结教训来传达信息
|
迭代回顾作为内部交流
|
利益相关者管理
|
传统方法
|
敏捷方法
|
|
制定在项目中使用的沟通方式
|
尽量使用面对面的甲流，不能交流时使用其它方式
|
|
使用问题日志把问题和解决方法传达给利益相关者
|
障碍显示在任务白板上，由管理者解决，并通过计划与会议进行交流
|
|
就已经确定的更改可以将项目带回预订的轨道
|
与团队客户更新他们的发布计划
|
|
更新项目计划在内的文档
|
需要时做出或更新文档
|
8.风险管理
风险管理规划
|
传统方法
|
敏捷方法
|
|
与管理者开会，决定风险管理的方法
|
确定适当的风险管理方法
|
|
得到一些风险管理流程文件
|
可以有
|
风险识别
|
传统方法
|
敏捷方法
|
|
使用清单文件审查，信息收集，假设分析，图表等方法识别风险
|
信息收集，假设分析，图表等方法识别风险
|
|
有限的会议上
|
每一次整个团队都参与的会议上
|
|
风险触发器上正式记录
|
非正式
|
风险分析
|
传统方法
|
敏捷方法
|
|
定性和定量分析
|
定性分析
|
|
使用概率和影响分析优先处理风险
|
使用概率和影响分析优先处理风险
|
|
对造成的风险积极应对和观察
|
对造成的风险积极应对和观察
|
|
记录风险登记册中
|
非正式记录
|
风险监测和控制
|
传统方法
|
敏捷方法
|
|
非正式的风险管理评审会议进行风险评估
|
规划和回顾会上进行风险评估
|
|
风险评估作为一项正式的评审
|
回顾会上进行风险评审
|
|
分差分析和趋势分析
|
在评审会议上对燃尽图和数据进行分析
|
|
技术性测定
|
评审会议中进行速度分析
|
|
状态会议
|
任务版，燃尽图和每日立会
|
规划
|
传统方法
|
敏捷方法
|
|
根据WBS，项目范围说明书和项目管理计划来制定采购管理计划
|
当涉及可能的采购活动时要求团队提供输入产品路线图和发布计划做帮助
|
|
确定合同类型
|
考虑诸如目标成本的合同
|
|
创建工作说明书
|
根据团队的投入创建合同工作说明书
|
|
确定自制还是购买
|
要求团队研究实现方案和做出决定
|
合同规划
|
传统方法
|
敏捷方法
|
|
创建采购文件
常见评估标准用来选择最好的卖方
|
与团队会晤写上征求建议书中使用做好的措辞
团队制定和审查潜在供应商候选人的评估标准
|
要求卖方回应
|
传统方法
|
敏捷方法
|
|
组织投标人会议
|
组织会议，强调你对敏捷的饿期望，准备对这些人进行敏捷方法的培训
|
|
建立合同买卖
|
去除没有能力的卖家
|
|
为合格的卖家创建采购文件包
|
为合格的卖家创建采购文件包，然后评审卡是否符合敏捷开发方法的需求
|
|
从卖方收到建议
|
收到卖方的回应，然后让那些感兴趣的团队再次进行评审
|
选择卖家
|
传统方法
|
敏捷方法
|
|
使用诸如加权和帅选的方法来确定合格的卖家
|
包括一些量化的敏捷需求和期望的条款
|
|
选择卖家并且洽谈合同
|
使谈判尽可能的写上，留出相应的时间久敏捷知识进行培训，包括一些敏捷就参与和交付的期望文件
|
|
建立一个合同管理计划
|
确定合同管理活动的迭代
|
合同管理
|
传统方法
|
敏捷方法
|
|
确定如何最好的管理合同（绩效评估审计付款变更）
|
参与团队对合同期望的制定工作，通过敏捷假话和相关职责和承包商变得熟悉起来，通过每日例会和评审会议让开发商帮助减少进度，成本和技术
|
合同结束
|
传统方法
|
敏捷方法
|
|
结束合同，更新卖方记录
|
通过确认用户接收交付的产品来结束合同，更新卖方记录主要包括工程结果或他们作为一部分参加迭代回顾
|
