第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.如果一个团队成员的表现未达到预期，谁应该说出此事：团队。
7.停车场图：用来抓住可能重要的但应该以后再关注的偏离主题的信息
8.完成的定义：事先由团队商定
9.用户故事-》计划扑克-》确定故事点
10.宽带德尔菲，专家再给出估算之前知道还有其他估算者
---------------------------------------------------课后作业1---------------------------------------------------------------
1.看板中的精益生产概念是如何减少瓶颈对工作的影响？通过成为一个及时的调度系统
2.完成一项任务，任务卡放在准备测试目录下
3.MoSCoW技术：M：必须有；S：应该有；C：可能有；W：这次不会有。（用户故事进行优先顺序排列）
4.敏捷故事地图 = 项目计划
5.一个敏捷项目是如何估算的：自上而下
6.敏捷团队应该避免在项目中同时使用两种估算方法
7.开发一个用户故事的理想时间是2-5天
8.一个用户故事包含：角色+目标+商业价值。
9.基于价值的分析的一个技术是：MoSCoW或Kano
10.价值流程图：价值增加和非价值增加
11.敏捷尝试减少WIP
12.解聚将大的用户故事分解为小的更易于处理的小的故事。
13.发布计划，讨论产品愿景
14.计划扑克，出现最高和最低的人时，向团队成员解释自己的观点，达成共识。
15.敏捷团队应当与客户商讨决定是否需要以及用户故事完成的时间
16.用户故事的3个C：卡片，对话，确认
17.敏捷开发的基石是：增量交付。
18.INVEST I：独立；N：可协商；V：有价值的；E：可估算的；S：小故事的；T：可测试的额；
19.产品负责人抱怨功能并没有提供她想要的最佳体验：因为终端体验并不容易测到。
20.价值流程图：WIDETOM (W-等待，I-库存，D-缺陷，E-额外流程，T-运输，O-过度生产，M-动态)
21.优先级的最佳定义：基于价值对产品特征进行相对排序
22.干系人管理：对工作环境的管理和促进，使所有干系人可积极地参与到项目
23.在滚动计划中，一次计划接下来的几次迭代、
24.财务主管通常会定义：时间和预算。
25.通常计划扑克的参展点用户故事是中码或者均码。
26.计划扑克中的每一个用户故事分配的时间是2-3分钟
27.教练和指导的定义是帮助个人或团队提高绩效
28.集中办公与渗透沟通：对问题，想法和信息的流动
29.提高团队激励的一个方法：提供教练指导
30.用户故事不是封闭的：没有清晰的结束点，露营者可导航网页
31.相对级别/优先级的定义：基于团队对优先级定义排序的清单
---------------------------------------------------------------------------课后作业2------------------------------------------------------------
1.动态系统开发方法：DSDM
2.冲刺待办事项：将在冲刺/迭代中开发的产品特征
3.渗透沟通：水晶
4.ATDD，TDD：讨论，提取，开发，示范
5.TDD：1.编写测试；2.核对和确认测试；3.编写产品代码，接着采用测试；4.重构产品代码
6.在价值流程图中，总前置期被认为是浪费
7.精益软件开发中的两种集成类型：概念性的和感知的
8.哪个敏捷框架总有一个产品发布：scrum
9.反思提高研讨会是水晶方法的基石
10.停车场图表是个敏捷文档，用来对用户故事按主题进行分类和管理
----------------------------------------------------------------------------课后作业3-------------------------------------------------------------------
1.敏捷架构中，负责确保包括商业管理和开发者在内的所有干系人有效协作的角色是：项目领导者
2.商业论证包含回报率
3.积极性，不属于社区价值
4.SMART技术：specific，详细的；measurable，可测量的；achievable，可完成的；relevant，相关的；timeboxed：时间定量。
5.如果一个任务可测量，说明：该任务能被团队和客户验证
6.当某一产品准备发布时，发布计划有助于估算
7.通常绘制在风险燃尽图中的是：风险严重程度
8.敏捷是一项平衡灵活性和稳定性的能力
9.敏捷项目的说明性文案：监管合规
10.理想时长用来预测开发人员
11.不是敏捷验证过程的特征：确认产品满足规格和需求
12.在迭代计划和迭代期间估算迭代的任务比较合适
13.在敏捷架构中，项目领导者可以授权团队
14.敏捷三角：价值，质量，约束
15.闪电战计划包含了故事的依存关系和包含使用卡片来计划项目，其中时效性，任何和故事的依存关系被确定和考虑
16.商业论证可以概述项目的预期回报率
17.基于风险的实验是风险管理的一个技能
18.被授权的团队对产品负责，因此更专注交付价值
19.项目的权衡矩阵按照固定的，灵活的，许可的老划分范围成本等
-----------------------------------------------------------------------课后作业4--------------------------------------------------------------------
1.理论上准备交付的特征的含义，与产品负责人合作完成
2.计划扑克和亲和估算都是参与开发用户故事相对工作量
3.时间箱的定义：设定任务实际完成需要的时间的估算值
4.产品路线图的优点：有助于促进组织特征
5.最小可售功能的定义：相对简单和回报价值的功能
6.5个核心风险区：生产率变更，范围渐变，规格故障，內部日程的缺陷，人才流失
7.故事点是开发工作的固定单元
8.海史密斯敏捷企业架构的4个层次：投资管理分层，项目管理分层，迭代管理分层，技术实践分层
9.构想，推测，执行，适应，收尾
-----------------------------------------------------------------课后作业5------------------------------------------------------------------------------
1.最不合适敏捷的合同类型：固定总价合同。
合适敏捷的合同类型：1.初始阶段的一般服务协议和为迭代或用户故事分开设置的固定价合同；2.工料合同；3.不超过固定费用合同；4.奖励性合同
2.估算用户故事的相对规模：故事点，理想时间
3.极限编程一般认为是用户故事的创作者
4.发布计划发生在发布计划期间
5.敏捷反馈技术：样板，模拟，演示，评价，结对编程，单元测试，持续整合，每日站立会议，冲刺计划
6.局部安全性是指：90%可信估计，50%可信估计的差异
7.三角测量法对比两个用户故事来估算开发一个用户故事
8.人物描述详细的，演员通用简明的
9.人物是指开发系统的概念性用户
10.项目缓冲估算：1.平方和的开方 2.关键链项目管理 3.二等分50%估计值
11.用户故事不清晰，高价值的
--------------------------------------------------------------课后作业6-------------------------------------------------------------
1.看板是拉动生产
2.极限编程将新代码集成后，测试代码识别集成缺陷
3.迭代计划发生在每一迭代前
4.用户故事的验收标准写在用户故事卡片背面
5.常用的解决问题的技巧：大声提问
6.基于风险的试验任务：了解搞风险任务的影响力
7.用户故事的包括：书面描述，对话，测试标准
8.敏捷故事地图：项目计划