敏捷项目管理课件

1.敏捷项目管理1.1.敏捷软件开发之项目管理1.1.1.软件开发之项目管理项目管理是将知识、技能、工具与技术应用于项目活动，以满足项目的要求。

软件开发项目的项目管理，是为了确保软件开发项目顺利进行的各种管理活动的总和。

PMBOK（Project Management Book of Knowledge）中将项目管理分为9大知识领域①.整合管理②.范围管理③.时间管理④.成本管理⑤.质量管理⑥.人力资源管理⑦.沟通管理⑧.风险管理⑨.采购管理至今为止，项目管理往往从这几个方面制定计划，在实施中，检查计划和实施效果的偏差，监控项目的健康状况。

1.1.2.敏捷软件开发之项目管理敏捷软件开发的项目管理，是指在敏捷软件开发中进行的项目管理活动。

敏捷软件开发，如同第一章所述，是一种积极拥抱变化的开发模式。

敏捷软件开发认可并应对不确定性，换句话说，需要面对风险（根据PMBOK 的定义，风险就是不确定性）。

某种程度上，敏捷开发过程就是风险管理的过程。

敏捷软件开发的各种实践方法（Practice）就是为了应对各种风险而存在。

敏捷软件开发的项目管理，其本质在于- 平衡（Balance）为了提升透明度花费的成本和因为可能发生变更而带来的风险。

敏捷项目管理中，开发流程的概念轻量且抽象。

在日新月异的今天，开发流程本身的灵活性显得非常重要。

不是用一个固定的流程来应对变更，而是根据不同环境不同需要裁剪开发流程。

从这个意义上来说，只定义必不可少的管理内容的、轻量级的开发流程是顺应时代需要的。

如果只在传统的Paradigm下解读和裁剪敏捷开发的流程，就很容易忘记敏捷开发的本来意义，这是造成敏捷开发失败的一个主要原因。

对流程的裁剪，一定要在正确理解敏捷项目管理的意义、不抹杀“敏捷”特性的前提下进行。

1.2.敏捷开发的可交付成果1.2.1.不事先规定可交付成果的细节敏捷软件开发中，品质代表软件与用户需求的匹配程度。

不事先规定可交付成果的细节是为了追求更高品质。

敏捷开发项目管理孙昕IBM Rational资深技术顾问议题• 软件项目管理的演进 • 敏捷软件项目中的一些最佳实践 • RTC敏捷项目管理的最佳载体传统项目管理 - PMI• • • • 5大过程组 9大知识领域 44个管理过程 PMI的关心和焦点:– 计划驱动 – 紧密控制 – 面向业务进行管理软件项目管理的实践我们需要一个完整、详尽的计划。

我们需要一个完整、详尽的计划。

软件开发中能实现么? 软件开发中能实现么 我们需要设计考虑所有的风险和预留的内容。

我们需要设计考虑所有的风险和预留的内容。

软件项目能否预先考虑到所有的风险? 软件项目能否预先考虑到所有的风险软件项目中难以预知所有的内容和风险，这不是传统行业！！！ 软件项目中难以预知所有的内容和风险，这不是传统行业！！！软件开发工作，是一个逐步认知和明晰的活动 拥抱变化 - 软件开发中的变化，是实际存在和必然的涉众期望域的 不确定性初始状态初始计划敏捷项目管理Scott, 我们今天的软件项目管理更应侧重 这些内容:– 弹性的项目管理方式 – 通过初始计划开展工作 – 项目的资源管理和控制 Vision Roadmap Releases IterationsDaily Scrums敏捷项目管理和传统项目管理比较• 传统项目管理关注与整个系统的构建，从整体角度考虑– 项目计划的建立、项目计划的执行 – 项目的风险根据项目计划考虑• 敏捷项目管理更关注与交付的价值– 高质量的交付物是最重要的 – 系统不是一次构建而成，而是迭代演进的 – 基于完整的场景构建计划、并按优先级执行 您是想获取一些更有价值的交付产品呢， 您是想获取一些更有价值的交付产品呢，还是 只想完成进度表!! 只想完成进度表敏捷项目管理 VS 传统项目管理Agile!!!! PMBOK!!!!鱼和熊掌可以兼得The Business议题• 软件项目管理的演进 • 敏捷软件项目中的一些最佳实践 • RTC敏捷项目管理的最佳载体敏捷项目管理方法：Scrum敏捷核心 迭代开发 2级项目规划 整体团队 持续集成 测试驱动开发敏捷项目的核心-迭代• 大部分公司还在使用瀑布模型敏捷核心 迭代开发 2级项目规划 整体团队 持续集成 测试驱动开发需求 分析 开发 测试 Crash! 发布12迭代式开发:本质改变 - 你多久运行你的项目一 次？• 变长的、复杂的项目周期为短的、简单的 长的、复杂的 短的、 长的 短的 简单的迭代周期– 团队在快速迭代的重复过程中，快速得到反馈/获取经验 – 团队每执行一次迭代，信心都得到提升 – 信心提升，效率和速度也相应提高了重复=自信=速度迭代和两级规划：通过反馈来不断调整方向计划完成敏捷核心 迭代开发 2级项目规划 级项目规划 整体团队 持续集成 测试驱动开发成功区域计划路径起点实际路径随着认识的不断加深， 随着认识的不断加深，通 过反馈来不断调整方向实际完成符合需求开发的启发式过程要求14为什么要进行两级项目规划项目的特点：逐步完善 – 决定了计划的渐进明细 不断的获取干系人反馈，修订范围 符合启发式的需求开发过程要求 计划和变化的有效平衡 复杂的事情简单化15根据真正的需要修改工作安排高优先级对于每个迭代首先实现高优 先的工作工作任务的优先级应该被定义 并清楚地描述动态增加新的工作项 根据需要，经常重新调整 工作项的优先级对于低优先级的内容可以 等待清晰后明确低优先级有些时候需要删除工作项工作项列表16核心敏捷最佳实践：“整体团队”敏捷核心 迭代开发 2级项目规划 整体团队 持续集成 测试驱动开发Scrum团队一般有6～8个人 拥有多种技能的、跨职能协作的团队 关注向干系人交付价值 整体团队：自指导、自组织、可持续的速度文化变革： 人本管理从麦格 雷戈的X理论向Y理论的转变17敏捷最佳实践：“整体团队”的自指导团队共享远景 和目标团队承诺拥有共同目标 分担责任，彼此承诺 共同目标、分担责任 彼此承诺致力于目标实现 共同目标 分担责任， 团队拥有足够的授权和资源 授权和资源，解决问题，找到自己的成功之路 团队 授权和资源做自己喜欢的事情 有效的沟通和信息的透明 适当的团队建设敏捷最佳实践：“整体团队”的可持续速度敏捷过程推行可持续的开发– 保持团队在一个可持续的生产力水平上工作文化变革： 关注可持续发展19有效的持续集成敏捷核心 迭代开发 2级项目规划 整体团队 持续集成 测试驱动开发持续集成（CI）是一种实践，能够让团队在持续地构建的基础上，不断收到 反馈并进行改进，不必等到开发周期后期才寻找和修复缺陷。

（ACP）敏捷项⽬管理第1章为什么需要敏捷第2章敏捷和敏捷项⽬管理定义第3章敏捷项⽬管理价值和原则1.我们的最⾼⽬标是，通过尽早持续交付有价值的软件来满⾜客户的需求2.欢迎对需求提出变更，即使在项⽬开发后期也不例外。

敏捷过程要善于利⽤需求变更，帮助客户获得竞争优势3.要经常交付可⽤的软件，周期从⼏周到⼏个⽉不等，且越短越好4.项⽬实施过程中，业务⼈员与开发⼈员必须始终通⼒合作5.要善于激励项⽬⼈员，给予他们需要的环境和⽀持，并相信他们能够完成任务6.团队内部和各个团队之间，最有效的沟通⽅法⾯对⾯的沟通7.可⽤的软件是衡量进度的⾸要衡量标准8.敏捷过程提倡可持续的开发9.对技术的精益求精以及对设计的不断完善将提⾼敏捷性10.简洁，尽最⼤可能减少不必要的⼯作11.最佳的架构，需求和设计将出⾃⾃组织团队12.团队要定期反省怎样做才能更有效第4章⽣命周期选择第5章敏捷实施-创建敏捷环境仆⼈式领导敏捷团队第6章敏捷实施-在敏捷环境中交付常见敏捷实践：1.回顾：让团队学习，改进，调整其过程2.待办事项列表编制3.待办事项列表的细化4.每⽇站会：不超过15分钟，5.展⽰/评审：⽤户故事，产品负责⼈，每两周⾄少⼀次，6.规划基于迭代的敏捷7.帮助团队交付价值的执⾏实践：持续集成，在不同层⾯测试，验收测试驱动开发，测试驱动开发/⾏为驱动开发，刺探8.迭代和增量如何帮助交付⼯作产品第7章敏捷项⽬管理过程框架第8章关于项⽬敏捷性的组织考虑因素第9章敏捷各流派框架介绍第10章敏捷术语解析-------------------------------------------------------第1章-----------------------------------------------------------------1.Scrum中的迭代计划会议应该不长于8⼩时2.现值（PV）和净现值（NPV），PV不考虑成本，NPV考虑成本3.项⽬章程同样适⽤于传统项⽬和敏捷项⽬4.⼲系⼈是任何对项⽬感兴趣的⼈5.⼒场分析法是寻找推动和阻碍变化的因素并给因素分配编号以了解两边⼒量和总和6.史诗故事是⼀个⼤型故事，称为⼀种能⼒7.测试驱动开发，软件应该按照如何会被接受的前提⽽编写8.相对规模估计，是估算某件事相⽐其他事情需要更多或更少⼯作量的⼀种实践9.近似估计，利⽤衬衫尺⼨，咖啡杯尺⼨或其它尺⼨使团队能和⼯作量联系起来-------------------------------------------------------第2章-----------------------------------------------------------------1.线框图，团队可以不写代码⼆迅速创建它们2.时间盒，只有在规定时间内通过验收的功能包含在时间盒内3.持续集成的意思是所有代码变化要每天提交和测试4.最⼩可售功能，⼀个能增加客户价值的⼩单元5.⼀个迭代等同于⼀个冲刺6.挣值管理在迭代级别被获取和⽤于沟通7.极限编程项⽬中的⾓⾊：教练，客户，程序员，测试员，跟踪员8.价值流程映射法，通过观察⼀系列过程并在整个系统中对其跟踪以便深⼊理解和分析每个过程产出的价值9.累计流程图,显⽰的是任务的⼯作流，⽽不是过程的⼯作流10.精益追求最⼤化未开展的⼯作-------------------------------------------------------第3章-----------------------------------------------------------------1.速度表⽰团队在⼀个迭代周期可以完成的故事点；循环时间表⽰⼀个功能点从开始到完成所花费的时间；燃烧率表⽰每次迭代的团队成本；2.⽇本的管理术语，持续改善（细微的变化），看板（信号）3.测试驱动开发：测试，编码，重构，交付4.⼀次探测是在遇到前进⽅向的问题时⽤⼀个⼩的实验来决定如何⾏动5.可⽤的软件是衡量进度的主要指标6.敏捷任务是全员完成7.冲刺评审或者回顾会议⼀般是半天（4⼩时）8.持续改善在敏捷宣⾔中没有-------------------------------------------------------第4章-----------------------------------------------------------------1.每⽇站会会议的主要⽬的是让团队协调⼯作和交流问题2.围绕被激励起来的个体来构建项⽬3.表明⼀个常见根源问题的通常被称为⽓味4.修剪产品树是⼀种⽤于需求收集的创新游戏5.PMO接受敏捷在不同项⽬中的实施⽅式不同-------------------------------------------------------第5章-----------------------------------------------------------------1.敏捷宣⾔创⽴于2001年2.极端⼈物有助于引出正常⼈物可能丢失的需求3.要不断交付可能的软件，周期从⼏周到⼏个⽉不等4.任务，不⼀定增加价值但是需要完成5.渗透式沟通指团队成员⽆意中听到并接受的所处环境中沟通的信息6.如果⼀个团队成员的表现未达到预期，谁应该说出此事：团队。