ACP-证书备考

2021.10.07

第一章*

1.敏捷的四个价值观
-个体和互动
-客户合作
-可用的软件
-应对变更

2.敏捷的十二个原则（从四个价值观演化）
-最高目标：尽快持续交付有价值的软件
-欢迎需求变更
-经常交付可用软件（几周到几月，越短越好）
-实施过程，开发和业务必须通力合作
-善于激励项目人员
-最有效的沟通：面对面
-衡量进度的首要标准：可用的软件
-倡议可持续的开发
-对技术的精益求精和对设计的不断完善以提高敏捷性
-简洁，即尽可能减少不必要的工作
-最佳的架构、需求和设计出自于自组织团队
-定期反省怎样才能更有效，并相应调整团队的行为。

3.敏捷方法
3.1Lean精益 -最大限度减少不能给客户创造价值的工作（精+益）
精益生产-以满足客户需求为目标，力求降低成本，提高产品质量，不断创新的资源节约型的生产方法
（七大原则：
a. 消除浪费（不产生价值的工作都是浪费）
b.内建质量（过程产生质量）
c.创建知识
d.推迟决策（需求不清不给出项目时间）
c.快速交付
e.对人尊重（一线人员最了解实际情况）
f.整体优化

3.2看板（日本丰田最先采用库存管理，just in time)
核心属性
-工作流可视化
-限制在制品
-管理流程
-明确过程政策
-实践反馈循环
-提高协作性

输入-分析（进行中/完成）-实现（进行中/完成）-测试（进行中）-发布或完成

3.3动态开发方法
-基本原则
协作：活动用户必须参与；
持续和明细沟通：必须授权DSDM团队进行决策
迭代开发：必须频繁交付产品
专注于业务需求：判断产品是否可接受的一个基本标准是符合业务目的
增量式构建：准确的业务解决方法需要采用循环和增量开发
开发期间的任何更改都是可逆的
整个生命周期集成测试
-关键词：以业务为中心，用户参与，迭代，快速交付，团队协作和沟通

3.4 FDD 功能驱动开发

1.开发整个模型->2.构建功能列表 ->3.以及功能规划 -> 4.依据功能设计->5. 以及功能构建

** 4.生命周期** （不是说敏捷下的生命周期，包括瀑布）
取决于交付频率和变更程度
-预测型
瀑布，详细的计划，了解要交付什么和怎么交付）-强调部门划分，有效有顺序的工作，不在项目结束前交付商业价值
-迭代型RUP
连续的原型或概念验证来改进成果或产品（为了学习优化，而不是为了交付速度）
-增量型
少量可频繁交付

二者的区别
迭代通过重复的循环活动来开发-反复求精
增量通过渐进增加产品的功能。-逐块构建

迭代-原型不断改进，就是一开始我想要的是四轮车，后面确认小轿车，然后…确认是奔驰，仅限于资源和时间固定，而且很快
增量-交付的就是对的最终想要的，就像想买的是一辆奔驰，一开始给我四个轮子，然后车身，然后…最后得到的就是我想要的奔驰

-敏捷型/适应型（也叫变更驱动）
目的在于应对大量变更，包括了迭代和增量的概念，不同在于迭代很快，需要的时间和资源都是固定的。而敏捷开发，迭代的时间盒一样但是资源其实是不一样的？
基于流程和基于迭代的敏捷是不同的
迭代时间盒相同，流程中，各个功能的开发所需的时间各不相同。

-混合

2021.10.08
5.敏捷实践
5.1 Scrum

• 价值观
  Focus专注
  Openness开放
  Respect尊重
  Courage勇气
  Commitment 承诺

- 流程（待完善）
从Product backlog 到Sprint backlog
Sprint planning:4hours(PO介绍）+4hours (sprint 安排）-一个月为Sprint的最大值

发布规划会议

Sprint plan

• （可以是一个或者两个，一个按照一周sprint 为1个小时，也就是total 两周一迭代的话就是4小时）
• 产出
  A.Sprint 目标
  B.Sprint backlog
  C.团队
  D.Demo演示时间
  E.Scrum meeting timing and location

Sprint review
1小时每周，2小时/2周sprint
Sprint retro
45分钟每周，1.5小时/2周sprint
Daily scrum
15分钟

• 用户故事
  都要经过3C
  1.Card 用户卡片-测试员与PO访谈出初步US
  2.Conversation-发布规划阶段，写用户细节和高阶验收标准、完善验收条件和用例
  3.Confirm- 和PO确认后才能进入开发。

INVEST原则

• Independent
• Negotiable
• Valuable
• Estimable
• Small(小到可以在一个迭代中完成）
• Testable可测试的

用户故事地图
是针对某一用户故事选定一个具体的业务目标，按照主流程和分支流程梳理角色达到目标所经历的每个业务节点，并通过地图的形式展现。

Sprint团队的velocity是通过计算每个Sprint完成的故事点来计算出来的。

20211009
6.极限编程
最大的特点应该是测试驱动开发TADD （test acceptance driven development),即不需要实现设计，而是先写测试程序。
-四角色PTCC
Programmer
Tester
Customer
Coach
-四原则FSCC
Feedback
Communicate
Simple
Courage

-CRC card
是索引卡的集合，面向对象的工程设计方式

类名
信息｜获得信息的描述
详细描述和CEC设计的注意事项

-重构
XP是Refractor merciless，前提是自动化测试

2021.10.11

鱼缸窗口：团队分布的各个工作地点之间建立长期视频会议链接，创建一个鱼缸窗口。每天工作，人们打开链接，结束时关闭。增加彼此间的互动，减少身处不同地点工作固有的协作落后的问题。

错题：

2021.10.13

燃起图：随着迭代（时间）变化完成故事点
燃尽图：随着迭代（时间）变化剩余故事点
根据二者建立下一次迭代能力衡量指标。

交付周期和周期时间：后者更短

第六章 项目敏捷性的组织考虑因素

1.采购和合同
基于敏捷，合同签署技术包括：
-多层结构
-强调价值交付
-固定时间和资源
-累计时间和资源
-提前取消合同
-总价增量
-动态范围方案
-支持全方面供应商（多个供应商交付独立的功能）
-团队扩充

2021.10.14
敏捷适用性筛选模型

2021.10.18

1.用户故事地图&影响地图

2.敏捷/精益/看板共性

敏捷是方法，手段，实践，技术和框架，一般情况下是默认指方法。

2021.10.20
错题综合

要注意敏捷也存在计划，而计划的种类包括：
产品愿景-产品路线图（主要是发布计划，囊括高层次的主题和高级别功能）-版本计划（明确版本需要几个迭代完成，明确需要完成的用户故事，和阐述了特性的描述-迭代计划（细层次的计划分解）

评审会议，项目状态主要显示：ROI和NPV
因为PO关注的是交付的价值，而上述二者是用来衡量价值的工具。

累计流量图：可预测项目完成时间和发现可能存在问题的工具，因为它可以确定循环实践，借助利特尔法则作为预测和分析队列情况的工具。
曲线表示开发过程中的阶段（队列-分析-开发-测试-完成）

2021.10.23
1.sprint backlog owned by team while produce backlog owned by PO.
2.时间：2四四二二
2周迭代对应：
4小时发布计划
4小时迭代计划
2小时评审
2小时回复

2021.10.26
塔克曼阶梯模型