ACP_1_敏捷价值观原则

生生不息，“折腾”不止；Java晋升指北，让天下没有难学的技术；视频教程资源共享，学习不难，坚持不难，坚持学习很难； >>>>

---

一、引论

1.1 课程整体介绍

在学习任何一门体系课程的过程中，都少不了一些准备工作，ACP自然也不例外，所以，第一步，先针对准备工作做一个简单的介绍，其实准备工作很简单，就是介绍一下课程资料 （“6大件”）；

名称	说明
《敏捷实践指南》	PMI-ACP 官方认证发布的实践指南，所有知识体系都是以它作为蓝本； 宝典
《敏捷项目管理》	ACP课程的参考书有很多，有的由专家、实践者撰写的，有的从项目管理领域、技术领域撰写的，整个ACP过程中有14本参考书，种类非常多；而该书： ① 涵盖ACP知识最全面、最体系化 ② 覆盖考试内容、考试点最多 考点
ACP培训讲义	所有课程、课件集锦 文章末，关注小编，免费获取
ACP知识集锦	近5年考试知识点集锦；考点 文章末，关注小编，免费获取
单团队单迭代开发路线 多团队多迭代开发路线	① 一个团队如何实践，全视角展示图 ② 组织规模化拓展，全视角展示图 全局观 文章末，关注小编，免费获取
敏捷生态圈(体系参考)	“敏捷洋葱圈” 敏捷原则 --敏捷价值观 – 敏捷实践 – 组织环境 – 人员能力，包括实践案例

那么，这就是在课程前做的一些准备工作，针对这“6大件”做了详细的解释：
2个教材参考书
2个课程讲义
2个“索引”性质的精华卡片
帮助大家进行知识提炼、知识学习

1.2 从PMP到ACP

思考：从项目管理PMP到敏捷管理ACP，之间有什么关系呢？

先看看这样一幅图，这是一幅“冰山”结构


为什么要看这么一幅图呢，其实每个人一般在学习一门新知识的时候，首先，都会去了解这门知识覆盖了哪些内容，以及自己该使用什么方式去学习它，正如冰山一样，如果我们只是曾经了解过ACP、听说过ACP，那么，极大可能就如冰山一角，只是看到水平面之上的显性部分，大量未知领域处于冰山之下；

所以，我们可以将传统的PMP与ACP相比较，去挖掘冰山之下的“风景”。

冰山之下的“风景


冰山之下的“风景”到底是什么呢？这里我们做一个思考：

1. 自我介绍
   1. 思考一下在职业发展中经历了哪些阶段，又为什么要来学习敏捷呢？（其实这是我们一个逐渐提升的阶段，基于职业发展，基于现做工作的要求，而对自己提出的一个诉求，基于这个诉求，我们需要从项目管理提升到一个敏捷的阶段）
2. 学习目标
   1. 既然要来学习ACP，那么你学习的目标是什么？（通过ACP认证，只有明确的学习目标，才能做真实的、有效的学习计划）
3. PMP vs ACP（重点讨论）

1.3 PMI-ACP 解决的痛点

领域（考试大纲）	说明
敏捷原则和理念	最基本的核心
价值驱动交付	敏捷与传统项目最大的区别在于：聚焦用户，能够产生价值
干系人参与	和敏捷相关的所有利益相关方（团队、外部）
提供团队效能实践	如何让团队更好的发挥效能
适应性计划	传统：一次性预测的未来计划 敏捷：多次适应性计划
问题探测与解决	如果出现问题，与原来的有差异出入，如何拥抱变化，解决问题？
持续改进	在不同的时间盒，针对好的地方、不好的地方，进行完成的回顾，真正做到持续改进

痛点	说明
团队的目标、任务不明确	愿景、使命 （我们愿景、使命即是我们为之奋斗的目标）
团队的工作协议不明确	价值观、原则和工作协议 （公司推行的价值观/原则，团队间的规范，即是我们的一起配合共事的协议）
团队的工作环境不明确	？
需求不明确	帮助发起人和相关方指定产品愿景。 考虑使用实例化需求、用户故事地图、影响地图来构件产品路线图。 让团队和产品负责人，一起来明确需求的期望和价值。 逐步将路线图分解为具有更少具体需求的代办事项列表 （我们需要交付的是价值需求，是否有价值，从是否对齐目标去衡量）
工作的分配和进展不明确	帮助团队认识到要自我管理工作。 考虑用看板面板查看工作流程。 考虑利用每日站会，根据看板查看工作进展。
由于产品代办事项列表不够完善，导致工作延误/超时	产品负责人和团队一起研讨故事。 为故事创建一个准备就绪的定义。 考虑分拆故事以使用更小的故事。
产品代办事项列表杂乱无序	按价值排序，并考虑延迟成本按持续时间（CD3）和其他价值模型划分
估算不准确	通过 分解故事 来让故事变小。 让整个团队使用相对估算进行估算。 考虑通过敏捷建模或刺探来理解故事。 （将故事拆解的足够细粒度，让整个团队去估算，而不是由个人主观估算）
错误的开始，前功尽弃	让产品负责人成为团队不可分割的一分子
用户体验不佳	开发团队的用户体验设计实践 应在早期就让用户经常参与。（ShowCase + 验收）
相关方要求无法满足	仆人式领导与这个相关方（可能是产品负责人）一起工作
产品复杂性过高	无论是软件项目还是非软件项目，都要常常 鼓励团队思考 ： “最简单的有效方法是什么？”，并应用“简洁，即尽最大可能减少不必要的工作，这是一门艺术”的敏捷原则。 这样做将有助于降低复杂性
意想不到或不可预见的延误	让团队更频繁地检查，使用看板面板检查工作流和在制品限制，了解需求对团队或产品的影响。 也可以在障碍板上跟踪障碍和障碍消除情况。
前期工作过多导致返工	不要做过多前期工作，而要考虑让团队通过刺探来学习。 另外，在项目开始时衡量在制品（WIP），看看哪些部分团队并不需要设计，只需要交付价值。 缩短迭代，并创建一个稳健的完成的定义。
工作未完成	团队确定故事 完成的定义（DOD），包括验收标准在内。 另外，还要为项目补充发布标准
技术债务（代码质量降低）	重构、敏捷建模、普适测试、自动化代码质量分析、完成的定义
团队合作过程进展缓慢或没有改善	在每次回顾中，选择的改进项目不要超过三个。 让仆人式领导帮助团队学习怎么整合这些待改进型。
仓促/等待，不均匀的工作流程	计划要对应团队的能力，而不是超出能力所及。 要求人员停止多任务，为一个团队专注工作。 请团队利用结对、群集或群体开发等方式，平衡整个团队的能力。
孤立的团队，而不是跨职能团队	让项目成员作为跨职能团队的自我组织。 使用仆人式领导技巧帮助管理人员理解为什么敏捷需要跨职能团队。
团队面临障碍	仆人式领导能够帮助消除这些障碍。 如果团队不知道他们都有哪些预选/可选方案，就要考虑聘请教练。 有时，团队或仆人式领导无法消除障碍，团队就需要上报故事。
缺陷	考虑对特定环境有效的技术实践。 它们可能是：结对工作、产品集体负责制、普适测试（测试驱动方法和自动化测试方法）以及稳健的完成的定义。

二、敏捷理念导入

2.1 敏捷导入

思考：什么是敏捷？


一种标准？
一种策略？
一种方法论？
一种过程？
一种模型？
… …

2.2 敏捷思维

在做敏捷的过程中，首先要想到该如何去执行敏捷，如何要做成一个怎样的产品，如何执行这个过程，从而选择适当的区域、选择适当的敏捷方法；

2.3 敏捷执行

思考：什么样的过程，是敏捷执行的过程？


针对于，非常明确的、变化比较小的、需求比较稳定的工作，通常来讲，我们执行的过程叫做预定义的过程；
那么对于，没有特定稳定的、需求变化比较频繁的、外部的影响、外部的调整比较多的，这种过程叫做实验性过程

预定义的过程	实验性的过程（敏捷）
命令和控制（采取命令和控制的方式）	边前进边学习（一开始无法预测执行的思路是怎样的，只能在工作的过程中，实时调整）
计划（有一个最初的计划，按照计划向前推进和执行，若产生与计划冲突的部分，我们需要采取“变更”的控制，有时还要采取“纠偏”的措施）	预计到变化会出现
强制性地按计划执行	拥抱变化（态度从讨厌变化、厌恶变化，变成拥抱变化，积极主动地欣然接受变化）
“变更”的控制	检查和适应（当变化出现的时候，先检查当前的状态，根据当前的状态做成相应的调整）

思考：什么样的工作，可以采取预定义的过程？
比较稳定，一开始比较有全盘的、正确的计划，然后按部就班一步一步执行
在过程运行的根本机制相当简单易懂的情况下，典型的做法就是采用预定义的建模方式


思考：什么样的工作，可以采取实验性的过程？
一开始没有明确的需求，而且会经常发生变化，受外部环境因素影响比较大
如果过程复杂程度超出预定义方式的能力范围，则应采用实验性的建模方式

2.4 敏捷简史

2.5 敏捷宣言（上）- 敏捷软件开发宣言

2.6 敏捷宣言（下）- 敏捷12原则

2.7 敏捷实践概述 - 业界可选的敏捷方法

2.8 敏捷洋葱圈小结

三、其他