知行合一：实现价值驱动的敏捷和精益开发课件

1、2020知行合一： 实现价值驱动的敏捷和精益开发演讲人2025-11-112020知行合一： 实现价值驱动的敏捷和精益开发演讲人202456231目录78对本书的赞誉序一序二序三第一部分 神形兼备的敏捷开发模式第二部分 建立以Scrum为框架的软件开发管理体系第三部分 CMMI框架下的敏捷实施第四部分 新一代精益软件工程456231目录78对本书的赞誉序一序二序三第一部分 神形兼01对本书的赞誉01对本书的赞誉对本书的赞誉对本书的赞誉02序一02序一序一 序一 03序二03序二序二 序二 04序三04序三序三 序三 05第一部分 神形兼备的敏捷开发模式05第一部分 神形兼备的敏捷开发模式1 从

2、“先知后行”到“知行合一”从传统开发模式到敏捷开发模式011.1 重新审视项目成功的标准021.2 重新审视瀑布模式为代表的传统开发方法031.3 复杂软件项目的共性：需求的不确定及技术的不确定041.4 从“先知后行”到“知行合一”05两个团队的故事1 从“先知后行”到“知行合一”从传统开发模式到敏捷开发1 从“先知后行”到“知行合一”从传统开发模式到敏捷开发模式1.1 重新审视项目成功的标准1.1.1 传统的三要素不一定能客观度量项目的成功与否1.1.2 新的项目管理铁三角1.1.3 敏捷让我们实现价值驱动管理1 从“先知后行”到“知行合一”从传统开发模式到敏捷开发1 从“先知后行”到“知

3、行合一”从传统开发模式到敏捷开发模式1.2 重新审视瀑布模式为代表的传统开发方法1.2.1 来自制造业的接力式开发模式1.2.2 瀑布开发模式的不合理之处1 从“先知后行”到“知行合一”从传统开发模式到敏捷开发1 从“先知后行”到“知行合一”从传统开发模式到敏捷开发模式1.3 复杂软件项目的共性：需求的不确定及技术的不确定1.3.1 客户对自己真正需要的产品需要一个认识的过程1.3.2 实现每个客户需求都有代价，但不是每个需求都有价值1.3.3 技术平台的不确定性1.3.4 团队一开始不了解自己的效率1.3.5 传统方法不能高效解决这些不确定性带来的问题1 从“先知后行”到“知行合一”从传统开

4、发模式到敏捷开发1 从“先知后行”到“知行合一”从传统开发模式到敏捷开发模式1.4 从“先知后行”到“知行合一”1.4.1 知行合一是自然的结论1.4.2 敏捷就是在开发中学习、成长、调整和完善1.4.3 敏捷是实现价值驱动管理的好方法1 从“先知后行”到“知行合一”从传统开发模式到敏捷开发2 敏捷开发方法摸着石头过河的智慧2.1 经常被错误解读的敏捷宣言及敏捷原则2.2 敏捷开发架构与Scrum：调整中增量开发2.3 Scrum是一个实现敏捷价值及原则的开发管理架构一个团队的两个故事3 形神兼具实现敏捷的核心价值3.1 形似神不似的Scrum实施2 敏捷开发方法摸着石头过河的智慧2.1 经常

5、被错误解读2 敏捷开发方法摸着石头过河的智慧3.2 使用Scrum的艺术3.3 极限编程是Scrum最好的伙伴3.4 引入Scrum等敏捷方法是一场需要勇气的变革3.5 变革之路：从瀑布模式到敏捷模式的转化两个团队的故事2 敏捷开发方法摸着石头过河的智慧3.2 使用Scrum2 敏捷开发方法摸着石头过河的智慧2.1 经常被错误解读的敏捷宣言及敏捷原则2.1.1 敏捷宣言是价值宣言2.1.2 敏捷的12原则背后的故事2 敏捷开发方法摸着石头过河的智慧2.1 经常被错误解读2 敏捷开发方法摸着石头过河的智慧2.2 敏捷开发架构与Scrum：调整中增量开发2.2.1 敏捷开发架构2.2.2 用一分钟

6、来解释一下Scrum以及Scrum中的3个角色、3个文档和5个会议2.2.3 敏捷框架下看Scrum2.2.4 Scrum和极限编程的结合使用2 敏捷开发方法摸着石头过河的智慧2.2 敏捷开发架构与2 敏捷开发方法摸着石头过河的智慧2.3 Scrum是一个实现敏捷价值及原则的开发管理架构2.3.1 Scrum让敏捷价值的实现变得自然2.3.2 Scrum是敏捷原则的具体体现2 敏捷开发方法摸着石头过河的智慧2.3 Scrum是一2 敏捷开发方法摸着石头过河的智慧3.1 形似神不似的Scrum实施3.1.1 Scrum不能保证解决问题，但能保证暴露问题3.1.2 没有本地化的适配，敏捷过程很难落

7、地生根3.1.3 不要因为错误的原因引入Scrum，要明确引入敏捷的目的2 敏捷开发方法摸着石头过河的智慧3.1 形似神不似的S2 敏捷开发方法摸着石头过河的智慧3.2 使用Scrum的艺术3.2.1 Scrum中的自我管理及实现方式3.2.2 管理者从监控型到服务型的转变3.2.3 追求问题的解决而不是最佳解决方案3.2.4 对工程人员能力提升及自律的要求3.2.5 Scrum实践的互补，完整的Scrum才最有价值2 敏捷开发方法摸着石头过河的智慧3.2 使用Scrum2 敏捷开发方法摸着石头过河的智慧3.3 极限编程是Scrum最好的伙伴3.3.1 技术债务：Scrum的杀手3.3.2 极

8、限编程的4个核心价值3.3.3 极限编程的原则3.3.4 极限编程的4个核心工程活动3.3.5 极限编程的12条实践3.3.6 极限编程+Scrum：1+122 敏捷开发方法摸着石头过河的智慧3.3 极限编程是Sc2 敏捷开发方法摸着石头过河的智慧3.4 引入Scrum等敏捷方法是一场需要勇气的变革3.4.1 精益组织与敏捷团队3.4.2 管理者的勇气：做有远见的智慧型领导者3.4.3 工程人员的勇气：合奏与独奏3.4.4 过程改进人员的勇气：找到你的定位2 敏捷开发方法摸着石头过河的智慧3.4 引入Scrum2 敏捷开发方法摸着石头过河的智慧3.5 变革之路：从瀑布模式到敏捷模式的转化3.5

9、.1 瀑布模式到敏捷模式中人和组织的转化3.5.2 瀑布模式到敏捷模式中企业文化及习惯的转化3.5.3 瀑布模式到敏捷模式的转化过程2 敏捷开发方法摸着石头过河的智慧3.5 变革之路：从瀑06第二部分 建立以Scrum为框架的软件开发管理体系06第二部分 建立以Scrum为框架的软件开发管理体系4 布好自己的局确定Scrum中的角色、文档和活动4.2 建立自己的敏捷过程4.4 敏捷过程对文档的要求4.6 敏捷工具4.1 敏捷转型的布局规划4.3 确定Scrum的角色4.5 建立一个成熟的Scrum过程4 布好自己的局确定Scrum中的角色、文档和活动4.24 布好自己的局确定Scrum中的角色

10、、文档和活动两个敏捷角色的故事5.4 Scrum中的风险管理5.3 建立、维护你的敏捷岛5 迭代管理亦有道执行Scrum项目管理5.1 应对变化的敏捷计划：波浪式的版本规划5.2 Scrum迭代中的管理：频繁反馈，及时调整4 布好自己的局确定Scrum中的角色、文档和活动两个敏4 布好自己的局确定Scrum中的角色、文档和活动两个团队的故事4 布好自己的局确定Scrum中的角色、文档和活动两个团4 布好自己的局确定Scrum中的角色、文档和活动4.2 建立自己的敏捷过程4.2.1 建立一个端到端的敏捷过程4.2.2 进入Scrum迭代的准备过程4.2.3 敏捷迭代过程及验证过程4.2.4 敏捷

11、的改进过程4.2.5 选择敏捷实践4 布好自己的局确定Scrum中的角色、文档和活动4.24 布好自己的局确定Scrum中的角色、文档和活动4.3 确定Scrum的角色4.3.1 猪和鸡合作创业的对话4.3.2 选择Scrum产品经理4.3.3 选择Scrum过程经理4.3.4 选择Scrum团队成员4.3.5 架构师在Scrum团队中的定位4.3.6 Scrum of Scrum （大敏捷项目的管理）的安排4.3.7 Scrum中的共享团队资源4 布好自己的局确定Scrum中的角色、文档和活动4.34 布好自己的局确定Scrum中的角色、文档和活动4.4 敏捷过程对文档的要求4.4.1 文档

12、的价值及应用4.4.2 敏捷文档制作指南4.4.3 敏捷过程的需求文档4.4.4 敏捷环境下的工程文档4.4.5 必要的维护文档4.4.6 敏捷（Scrum）的管理文档4 布好自己的局确定Scrum中的角色、文档和活动4.44 布好自己的局确定Scrum中的角色、文档和活动4.5 建立一个成熟的Scrum过程4.5.1 什么是成熟的敏捷过程4.5.2 保证敏捷过程的执行力4.5.3 保证敏捷过程的改进力4 布好自己的局确定Scrum中的角色、文档和活动4.54 布好自己的局确定Scrum中的角色、文档和活动5.1 应对变化的敏捷计划：波浪式的版本规划5.1.1 掌握你的团队速率5.1.2 允许

13、项目需求范围有一定的灵活性5.1.3 遵循“最小有市场价值”原则制订产品版本计划5.1.4 制订第一个版本计划4 布好自己的局确定Scrum中的角色、文档和活动5.14 布好自己的局确定Scrum中的角色、文档和活动5.2 Scrum迭代中的管理：频繁反馈，及时调整5.2.1 细化版本需求列表中的用户故事：准备好下一轮迭代的工作5.2.2 计划下一轮迭代5.2.3 开好每日站立会议5.2.4 展示团队的迭代成果：开好迭代评审会议5.2.5 不断完善Scrum过程：开好迭代回顾会议4 布好自己的局确定Scrum中的角色、文档和活动5.24 布好自己的局确定Scrum中的角色、文档和活动5.3 建

14、立、维护你的敏捷岛5.3.1 迭代任务状态板块5.3.2 其他信息板块5.3.3 白板是最有效的沟通方式4 布好自己的局确定Scrum中的角色、文档和活动5.34 布好自己的局确定Scrum中的角色、文档和活动5.4 Scrum中的风险管理5.4.1 软件项目的5大风险来源5.4.2 把握你的进度风险5.4.3 把握好需求使之自然完善而不是遍地蔓生5.4.4 建立一个T字型能力团队缓解团队不稳定风险5.4.5 建立维护好产品规格5.4.6 克服低效率风险的几个法宝4 布好自己的局确定Scrum中的角色、文档和活动5.46 把握好敏捷的度敏捷工程及质量控制实践6.1 再议技术债务6.2 敏捷中的

15、需求开发及管理6.3 敏捷中的设计和开发6.4 敏捷中的测试6.5 健康迭代比速度更重要两个团队的故事6 把握好敏捷的度敏捷工程及质量控制实践6.1 再议技术6 把握好敏捷的度敏捷工程及质量控制实践6.1 再议技术债务6.1.1 技术债务的来源6.1.2 管理技术债务6.1.3 减少技术债务的实践6.1.4 减少技术债务的具体步骤6.1.5 技术债务的度量6 把握好敏捷的度敏捷工程及质量控制实践6.1 再议技术6 把握好敏捷的度敏捷工程及质量控制实践6.2 敏捷中的需求开发及管理6.2.1 敏捷四级产品计划6.2.2 用户类型的识别过程6.2.3 建立维护典型用户档案6.2.4 从用例到用户故

16、事6.2.5 贯穿整个开发过程中的需求澄清：串讲及反串讲6 把握好敏捷的度敏捷工程及质量控制实践6.2 敏捷中的6 把握好敏捷的度敏捷工程及质量控制实践6.3 敏捷中的设计和开发6.3.1 简明设计原则6.3.2 设计决策的时机6.3.3 再议程序开发中的代码重构6.3.4 敏捷中的评审6 把握好敏捷的度敏捷工程及质量控制实践6.3 敏捷中的6 把握好敏捷的度敏捷工程及质量控制实践6.4 敏捷中的测试6.4.1 测试驱动开发的价值及方法6.4.2 持续集成：提高开发效率的重要保证6.4.3 敏捷测试策略及方法6.4.4 让发现的缺陷的价值最大化6 把握好敏捷的度敏捷工程及质量控制实践6.4 敏

17、捷中的07第三部分 CMMI框架下的敏捷实施07第三部分 CMMI框架下的敏捷实施第三部分 CMMI框架下的敏捷实施7 盲人摸象关于敏捷和CMMI的错误偏见DE7.1 来自两个阵营的偏见7.2 CMMI的核心和价值7.3 CMMI+敏捷：解决软件开发问题之匙7.4 来自敏捷宣言起草者及CMMI作者的最新声音敏捷和CMMI的故事ABC第三部分 CMMI框架下的敏捷实施7 盲人摸象关于敏捷和8 建立敏捷的保护网CMMI架构下的敏捷实施18.1 从使用角度看CMMI28.2 完善Scrum实现CMMI项目管理的要求38.3 用敏捷实践实现CMMI工程活动的要求48.4 用敏捷手段实现CMMI支持活动

18、的要求58.5 敏捷环境下实现CMMI过程管理的要求68.6 敏捷环境下实现CMMI高成熟度的要求8 建立敏捷的保护网CMMI架构下的敏捷实施18.1 从8 建立敏捷的保护网CMMI架构下的敏捷实施8.7 敏捷环境下的CMMI评估应关注的两个问题敏捷环境下的两个CMMI实施和评估故事8 建立敏捷的保护网CMMI架构下的敏捷实施8.7 敏捷8 建立敏捷的保护网CMMI架构下的敏捷实施8.1 从使用角度看CMMI8.1.1 一个产品开发最佳实践的集合8.1.2 CMMI的4条主线8.1.3 正确解读CMMI评估8.1.4 CMMI对工作产品（文档）的要求8 建立敏捷的保护网CMMI架构下的敏捷实施

19、8.1 从使8 建立敏捷的保护网CMMI架构下的敏捷实施8.2 完善Scrum实现CMMI项目管理的要求8.2.1 需求管理和“Scrum+极限编程”8.2.2 项目计划和“Scrum+极限编程”8.2.3 项目监督与控制和“Scrum+极限编程”8.2.4 供方协议管理和“Scrum+极限编程”8.2.5 集成项目管理和“Scrum+极限编程”8.2.6 风险管理和“Scrum+极限编程”8 建立敏捷的保护网CMMI架构下的敏捷实施8.2 完善8 建立敏捷的保护网CMMI架构下的敏捷实施8.3 用敏捷实践实现CMMI工程活动的要求8.3.1 需求开发和“Scrum+极限编程”8.3.2 技术

20、解决方案和“Scrum+极限编程”8.3.3 产品集成和“Scrum+极限编程”8.3.4 验证和“Scrum+极限编程”8.3.5 确认和“Scrum+极限编程”8 建立敏捷的保护网CMMI架构下的敏捷实施8.3 用敏8 建立敏捷的保护网CMMI架构下的敏捷实施8.4 用敏捷手段实现CMMI支持活动的要求8.4.1 敏捷环境下的过程与产品质量保证8.4.2 敏捷环境下的配置管理8.4.3 敏捷环境下的度量与分析8.4.4 敏捷环境下的决策分析与解决8 建立敏捷的保护网CMMI架构下的敏捷实施8.4 用敏8 建立敏捷的保护网CMMI架构下的敏捷实施8.5 敏捷环境下实现CMMI过程管理的要求8

21、.5.1 敏捷环境下的组织级过程关注8.5.2 敏捷环境下的组织级过程定义8.5.3 Scrum环境下的组织级培训8 建立敏捷的保护网CMMI架构下的敏捷实施8.5 敏捷8 建立敏捷的保护网CMMI架构下的敏捷实施8.6 敏捷环境下实现CMMI高成熟度的要求8.6.1 敏捷下的量化管理：QPPO、基线及模型（OPP和QPM）8.6.2 敏捷环境下过程优化管理：CAR和OPM8 建立敏捷的保护网CMMI架构下的敏捷实施8.6 敏捷8 建立敏捷的保护网CMMI架构下的敏捷实施8.7 敏捷环境下的CMMI评估应关注的两个问题8.7.1 实施选择还是模型要求8.7.2 理解模型的目的8 建立敏捷的保护

22、网CMMI架构下的敏捷实施8.7 敏捷08第四部分 新一代精益软件工程08第四部分 新一代精益软件工程9 敏捷不是解决软件开发问题的银弹9.1 再议软件过程的特殊性9.2 敏捷的局限及挑战9.3 有效软件开发借鉴之源及应具备的特点9 敏捷不是解决软件开发问题的银弹9.1 再议软件过程的特殊9 敏捷不是解决软件开发问题的银弹9.1 再议软件过程的特殊性9.1.1 软件过程公理9.1.2 软件过程体系应追求的价值9 敏捷不是解决软件开发问题的银弹9.1 再议软件过程的特殊9 敏捷不是解决软件开发问题的银弹9.2 敏捷的局限及挑战9.2.1 如何尽早获取有价值的用户反馈9.2.2 如何设计软件架构支持快速迭代开发9.2.3 缺乏具体有效方法实现敏捷原则9.2.4 忽略了