没有合适的资源?快使用搜索试试~ 我知道了~
首页ACP备考必备知识点.pdf
资源详情
资源评论
资源推荐

敏捷 ACP 知识点总结
敏捷章程
敏捷项目也存在项目章程的说法,这个更多的是美国项目管理协会 PMI 需要和传统 PMP 对应
的产物。敏捷章程中不仅仅要对项目经理授权,也会加入针对团队的授权,并明确的团队的
权利和义务等内容。项目章程是重要的管理文件,需要所有干系人的参与。专家建议章程的
内容应不超过一页,又要包括关键信息,所以创建项目章程是非常具有挑战性的。最重要的 3 个关
键信息是前景、任务和成功标准。前景回答为什么做这个项目(Why),任务是项目达到预期前景所
要做的什么内容(What),成功标准是管理的指标,定义项目如何是成功完成(How/Criteria)。
商业论证
商业论证开发是敏捷项目管理中重要的起步点。商业论证是对项目的
构想,目标
,达到
目标的
策略
,
重大事件,所需投资和预期回收
所作的简明概要文件。商业论证向客户阐明
该项目
为什么
和
怎么样
会带来价值。
精益看板
看板在精益生产过程中起到了一个及时的库存控制调度系统。产品流程只有在收到命令
信号时才执行。用这种方式谨慎控制库存确保了没有机器生产多余或者无序的产品。而机
器只有在当时有能力执行生产时才发出命令信号。因此,库存(或者 WIP)不会成为瓶颈,
这是因为库存的命令信号是高度控制的并且是基于流程速度和绝对的需求的。软件开发的
看板、限制品和团队速率的概念如出一辙。
敏捷估算
敏捷项目的工作量估算一般采取宏观方法,即
自上而下估算
。通常是一种
相对估算
的行
为,即待完成用户故事的工作量通常可以用
理想日
或
故事点
等两种方法来表示。敏捷开发
团队应约定在实际项目中一次只试用一种估算方法,故事点或者理想日,因为这两种方法使
用不同的测量单位,
同时使用会造成混乱
。另外,
开发一个用户故事的理想持续时长是
2-
5
天(任务是 4 小时到两天)
,如果估计一个用户故事的开发时长过长,需要把此用户故
事拆分成较小的用户故事后再进行重新估算。另外,常用的敏捷估算方法为
宽频德尔菲和
计划扑克
,它们都是相对估算的方法。如果以大码、中码和小码等相对估计的话,估算参
照点一般设为
中码或者均码
。
价值分析
用户故事是基于能够给客户带来的价值进行优先排序的。价值通常由投资回报(效
益)、团队知识增长和风险减少等来综合决定。通过
价值分析的方法
致力建立由客户定义
的价值与待开发产品特性之间的关系,具体可以使用的方法有

MoSCoW、Kano、相对权重和价值流程图等。价值,成本和风险是优先处理用户故事时考虑的
重点因素。
敏捷团队必须时常处理产品待办事项里的产品特性优先级问题。从发布计划到迭代计划,
敏捷团队必须优先处理产品的用户故事/特性来确保高质量和高价值的特性优先得以开发,
以此帮助带来乐观和较早的投资收益。
敏捷团队往往在相对价值和风险方面优先处理需求或用户故事/特性;价值由客户决定(即
客户-价值优先级)。
处理产品优先级的常用方法是:MoSCow 和 Kano、相对权重。MoSCoW 方法将产品特性分为
“必需含有”,“应该含有”,“可以含有”和“会含有”四类。
MoSCoW 技术是通常用来对用户故事进行优先排序和创造用户故事地图。
MoSCoW 指的是 M-must have 必须有;S-should have 应该有;C-could have 可能有;W-won't
have this time 这次不会有。 必须有的是对开发很重要的产品特征,一般占全部工作的 40%。
应该有的是对开发不是很重要但有重要商业价值的产品特征,一般占全部工作的 20%。可能有的
是能增加一些商业价值的产品特征,一般占全部工作的 20%。不会有的基本没有商业价值的产品
特征,一般占全部工作的 20%。在迭代开发过程中如果想临时更改待开发的用户故事,一般选择
更换不会有或可能有的工作。
而 Kano 方法将特性分为“必须含有(开端)”,“不满足因素”,“满足因素”和“愉
悦因素”。
“必需含有”是指必需含有的特性。
“不满足因素”是指反过来影响感知价值而应该移除的特性。
“满足因素”是指此类因素越多客户越满意,能够正相关地增加感知价值的特性,但并不
是必需的。
“愉悦因素”是指能指数型地增加感知价值来满足客户的特性。
依据风险来优先处理特性,可运用风险-价值指标。
风险-价值指标含 4 个象限,横轴表示价值,竖轴表示风险。用户故事被分配到其中一个分
类/象限:低价值,低风险;低价值,高风险;高价值,低风险;高价值,高风险。
成本-价值指标同样可用这种方式形成。
敏捷中所有的优先化都是“相对的”,也就是说一个用户故事只是相对优先于其他用户故
事,而非在固定规模上得到优先处理。
在 Kano 分析中,功能被区分成必要的功能、线性功能和兴奋点。这一工作是通过向潜在
的用户文后面两个问题来完成的:如果有这个功能他们会觉得如何以你如果没有这个功能
他们又会觉得如何。
相对权重方法提供了一种是用一个值来对实现这个功能所带来的收益、不实现它所带来的
惩罚和实现它的成本进行评估的方法,这个值就代表了这个功能的优先级。
价值流程图

价值流程图是敏捷采用的精益生产分析技能,用于对形成客户产品或服务的原料和信(即
价值)的流动进行分析。可以基于流程图来分析价值增加和非价值增加的具体内容。价值
流程图是一项协作性地流程分析技能,一支功能多样的团队绘制一个流程来识别浪费发生
的地方并且确认可完善的地方。它是流程分析技能的一个例子。和价值流程图类似,流程
图也用于绘制一个流程来识别瓶颈(即流程会减缓和产生库存的地方)。执行价值流程图
大致包括 5 个步骤:
1)确认产品、客户和范围(即流程的始末)。
2)确认流程步骤,延时和信息需求。估算流程步骤的持续时长和
前置期持续时长(lead
time
durations)
。前置期是指在发生前一项流程或者事件需等待的时长。
3)分析价值流程图来确认浪费存在的地方(比如前置期)和流程可完善的地方(
流程时间
通常认为是价值增加时间,但是应尽量减少整个流程的时间,由此来缩短向客户交付价值
流的时间
)。
4)通过分析,总结出一份展示价值流应努力达到的前景或者目标的
未来价值流程图
。
5)通过流程完善活动或者其他方法来达到目标的一些工作。
在价值流程图中,能辨别出过程中存在的浪费是很重要的。
WIDETOM
可以用于记录不同种
类的浪费,价值流程图是敏捷采用的精益生产分析技能。一张价值流程图可能用于分析信
息或者材料的流动,从它们的源地到重点,以此来识别浪费区域。识别出的区域成为流程
可完善的地方。
浪费的形式非常多,可用 WIDETOM 来记忆。
W-waiting 等待
I-inventory 库存
D-defects 缺陷
E-extra processing 额外流程
T-transportation 运输
O-over-production 过度生产
M-motion 动态。
教练和指导
团队内的教练和指导有助于新生的敏捷团队及经验丰富的敏捷团队。教练和指导是帮助个人或
团队提高绩效和实现实际目标的一种方式。因为敏捷拥有一个持续改善的价值,教练和指导不
单是为新生的或未成熟的团队服务,同时由于指导有助于达到高水平的绩效,所以也服务有经
验的团队。对敏捷团队教练和指导的尺度是可变化的。一些新生的团队会一直需要指导,而其
他的团队可能只在特殊的挑战环境下需要指导。有一名指导人员在冲刺/迭代计阶段共同帮助团
队,然后再迭代阶段帮助指导个别的团队成员,这样的情况是很常见的。
站立会议
一个健全的站立会议的重点特征包括:
同辈压力——因为团队靠大家,所以同辈的期望可带动进步;
密切的配合——团队应当理解对专注的必要性并独立工作;
专注——团队应当理解每日站立会议中简洁的必要性,由此团队才有效益;
每日承诺——团队应当理解对每人每日承诺的价值所在,并兑现这些承诺;
辨别障碍——团队应当集体意识到每个人的困难,由此团队可集体尝试解决。
团队激励
不仅在敏捷中,富有动力的团队对任何项目都至关重要。富有动力的团队运作更流畅,生
产效率高,表现超越期望值。

可提高动力的简单步骤包括:
1)共度黄金时间,团队成员可在个人层面上了解他人以此营造社区氛围,
2)提供反馈,指导和训练,赞扬和感谢团队成员的出色工作,同时为技能和能力提升提供
指导和训练,
3)授权,授权团队成员作关键决策,在此期间,建立信任并显示领导对团队能力的信任。
增量交付
敏捷开发的基石是“增量交付”。增量交付是指为及时反馈和接纳,频繁向客户交付连续改
善的工作产品。为演示和反馈,往往在每一个冲刺或迭代的末期交付产品。这项反馈技能,
可使客户评价产品并提出新的需求。在敏捷流程中,接受变动/更新/改善的需求,以确保客
户得到有价值和质量的产品。一个冲刺或迭代往往持续 2-4 周,最后,渐进地交付一个新
的并改善的产品。
团队在迭代内完成交付成果,集成到以往的迭代成果中,形成增量式的交付
每次交付的用户故事必须符合验收条件
每次交付的增量成果必须处于可用状态,而不管 PO 是否决定发布这个用户故事
FDD 特征驱动开发
特征驱动开发(FDD)使用一个规范性的模型,当中计划,管理并从个别软件特征方面跟踪
软件开发流程。FDD 使用两周或者更短时长的短迭代来开发一定的特征。 FDD 的五个步骤
是:
1.开发整体模型;
2.建立特征清单;
3.依特征做规划;
4.依特征做设计;
5.依特征进行建立。
TDD 测试驱动开发
TDD 测试驱动开发过程具有 4 个基本步骤:
1)编写测试
2)核对和确认测试
3)编写产品代码,接着采用测试
4)重构产品代码。
其中一个例子可为,用户必须记录产品的生存期值。一项完善的测试需要确保用户数据输入是一
个正数,而不是不同类型的输入,比如一个字母(即编写测试)。编程人员需要验证当输入字母
而不是一个数字时,程序会出现异常(即核对和确认测试)。接着编程人员编写的代码,需要用
户记录产品的生存期值(即编写产品代码)。然后编程人员会运行产品代码并且输入正确和错误
的产品生存期值(即采用测试)。如果产品代码运行成功,那么编程人员会重构产品代码,以完
善产品的设计。遵循这 4 个步骤,迭代保证编程人员探讨一项软件程序首先可能会如何失败,并
且建立可全面测试的产品代码。这样有助于编出高质量的代码。
验收测试驱动开发(ATDD)
验收测试驱动开发(ATDD)与测试驱动开发(TDD)类似,在于它同样需要编程人员在产品
代码前编写出测试。验收测试驱动开发的测试旨在验证预期软件中的特性/行为。验收测试
驱动开发的迭代的 4 个步骤可简记为 4 个 Ds:1)Discuss 讨论:敏捷团队和客户或者商
业干系人详细讨论用户故事,包含用户故事应和不应有的预期行为。

2)Distill 提取:开发团队研习讨论中的条目并提取成可验证和确认这些行为的测试。提
取流程中,整个团队应充分认识“完成”对用户故事的意义,这正是验收标准所在。
3)Develop 开发:提取后,团队开发测试代码和产品代码以产生产品特性。
4)Demo 示范:产品特性开发后,团队向客户或商业干系人展示以获得反馈。
迭代计划三部曲
在迭代计划中,团队根据三部曲去设计迭代待办事项:
1.团队分解大的或复杂用户故事为多元的、小的故事
2.团队把每个用户故事分解为开发任务
3.团队估计任务功力或周期,通常用理想时间。
渗透沟通
关于水晶开发方法一个首要原则就是渗透沟通。
渗透沟通是沟通的一种,信息在互相搭配工作的团队成员之间无意识地进行共享。
敏捷架构
常见的敏捷架构/方法论包括:
scrum,
XP 极限编程,
精益软件开发,
水晶,
特性驱动开发(FDD),
动态系统开发方法(DSDM),
敏捷统一过程(AUP)。
Scrum
Scrum 作为一种框架,促进复杂产品迅速且高效的开发,促进对变动的需求的适应
和促进工作产品的增量交付。
Scrum 开发包括 3 个主要阶段:游戏前,游戏中,游戏后(赛前、赛中、赛后)。
Scrum 着重的是产品和冲刺待办事项的使用,迭代开发的使用(称为“冲刺”),
每日站立会议(称为“Scrum”),冲刺查看和反思(称为“示范”),以及信息
发射源的使用,例如任务板和燃尽图。
极限编程
极限编程(XP)是一项以编程人员为中心的敏捷架构,注重小而迅速的发布。 XP 极
限编程强调以下原则:结对编程;可持续速度;不断自动测试;有效沟通
简单性;反馈;勇气;代码集体所有;持续集成(CI);激励工作;共享工作空间;现场
客户代表;使用隐喻说明概念
XP 极限编程用语中“
caves
和
common
”指的是,为团队成员创造的两个分区。
公共范围是一个公共的空间,在此常有渗透沟通和协作。
洞穴区域是一个私人的交易预留空间,需要一个孤立且安静的环境。
为了维护公共领域,每一名团队成员应当工作于一个且是同一个的项目上。
一项 XP 极限编程项目通常每天至少一次集成代码。
持续集成
剩余22页未读,继续阅读















安全验证
文档复制为VIP权益,开通VIP直接复制

评论0