敏捷ACP冲刺
2021-07-05 20:25:04 0 举报AI智能生成
敏捷ACP考试冲刺笔记
作者其他创作
大纲/内容
一、敏捷文化
四大宣言
个体和交互胜过过程和工具
1、团队聚焦个体参与和互动，频繁交互协作，例如：每日展会
2、对外交互：PO、客户；了解具体需求
3、个体：人。项目由人执行、范围由人确定、困难由人解决、成功标准由人制定
4、左项是价值，右项是工具
可工作软件胜过详尽的文档
1、有价值、高质量的软件为首要目标
2、可工作软件是客户最期望的的交付物
3、只有软件的完成度才能反映项目的进展
4、右项价值：文档是用来支持开发的；有人需要/维护的文档才是有价值的
5、考试会出现的文档：项目章程、团队工作协议/团队章程。其他的慎选
客户合作胜过合同谈判
1、合作可以获取最真实的业务逻辑（需求）
2、共同定义完成标准、共同创造价值
3、知识型项目是动态的，客户真实需求时常变化（拥抱变更）
4、右项价值：合同确定合作关系；敏捷合同具有应对变化的灵活性，通常是工料合同/成本合同（提倡灵活和包容）
响应变化胜过遵循汁划
1、不存在完美的计划
2、变化的目的是为了适应实际的需求
3、知识型项目在初期具有高不确定性和风险
4、右项价值：敏捷有5层计划，具有滚动性规划的特点；敏捷的计划具有灵活性。
十二原则
1.我们的最高目标是通过尽早和持续地交付有价值的软件来满足客户。
2.即使在项目开发的后期，仍欢迎对需求提出变更。敏捷过程通过拥抱变化，帮助客户创造竞争优势。
3.要不断交付可用的软件，周期从几周到几个月不等，且越短越好。（迭代内任务不变，双轨制。）
解题关键
1.产品负责人(PO)是组织内最理解客户需求的代表
2.由客户或PO决定价值优先级;产品待办列表(PB表)的排序和事项(userstory)的去留由客户/PO决定。
3.短的迭代周期可以显著提升客户对产品增量的验收概率（小步快跑）。
4.在项目过程中，业务人员与开发人员要每天在一起工作。
5.要善于激励项目人员，给他们所需要的环境和支持，并相信他们能够完成任务。
6.团队内部和各个团队之间，最有效的沟通方法是面对面的沟通。
解题关键
1.与关键利益相关方形成定期、频繁的信息反馈回路，即使当事人不愿意，也要试图说服他/她;
2.允许和鼓励团队成员尝试新事物，尝试后再作评估;
3.尽量满足成员学习其他技能的愿望和兴趣，以激发成员的内驱力;
4.渗透式沟通（共享办公区）是解决不愿意发表意见的良策;
5.面对沟通不畅的问题，集中办公比信息发射源、虚拟工具等更管用。
7.可工作的软件是衡量进度的首要指标。
8.敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久、稳定的进展速度。
9.对技术卓越和好的设计的持续关注有助于增强敏捷性。
解题关键
1.没有完成的用户故事，不能计入团队速度中去;
2.管理层不了解敏捷的表现:在速度恒定的情况下要求提升速度;将两个团队的速度直接进行比较;
3.要重视技术债务，要将技术债务作为PB表的一部分，必须进行处理;
10.尽量做到简洁，尽最大可能减少不必要的工作。这是一门艺术。
11.最佳的架构、需求和设计出自自组织团队。
12.团队要定期回顾和反省如何能够做到更有效，并相应地调整团队的行为。
解题关键
1.团队是一个整体，一方有困难或质量有问题，团队一起解决;
2.敏捷是人本主义管理学，任何监工式、命令式、强迫式的管理方式都是错误答案
3.自组织团队的最高境界是自我管理、自我决策;
4.邀请额外资源来解决问题基本上是错误答案;
5.要麻烦团队成员的职能经理的基本是错误答案;
6.团队规模、团队风格、团队所用的工具由团队成员自己决定（授权于自组织团队)
对应关系
可工作的软件
最高目标
周期短
衡量进度
质量管理
好的设计
回顾反省
简洁艺术
个体
激励
可持续
自组织
交互
面对面
客户合作
业务人员
响应变化
拥抱变更
二、价值驱动交付
价值驱动交付
交付价值，是敏捷方法的核心组成部分。这种概念已经融入了敏捷的核心，包括敏捷宣言和敏捷原则。
敏捷的主题就是最大化价值交付
业务价值带来收益，也有相关的风险，因此需要综合考虑功能性需求和风险
风险等于反价值
风险一旦发生会潜在地削弱、移除和降低项目价值。风险会降低价值，因此为了最大化价值，必须最小化风险。
让相关方尽早参与
项目发起人、业务代表或者客户作为关键相关方，对移除项目障碍和推动项目成功至关重要。
规划价值
项目章程:
敏捷项目的愿景以及高层级描述,属于必需的文档。可以包含项目愿景说明书。
项目章程的5W1H:
为了实现某个目标(Why)，项目由谁(Who)在什么时间(When)、什么地点(Where)、通过什么样的方式(How)以完成什么内容(What)。
章程的3个关键因素:
愿景:项目发起的原因以及要实现的目标价值;
任务:项目的内容;
成功标准:可测量的、可视化的项目成功标准;
项目的愿景例子:电梯测试说明书(30秒原则)、产品盒子
价值流程图：
价值流图可以用于分析信息或者材料的流动，从初始到结束，用来识别浪费环节，以改进流程，提升价值。
价值流图通常由团队共同制作，团队可以一起定义和查看整个流程，识别非增值活动。
客户价值优先级：
敏捷项目通过对优先级列表(PB、SB)的工作项排序来实现价值最大化。
简单模式：最简单的模式，在工作项标上P1、P2、P3等
MOSCOW：工作项被分成Must-have、Should-have、Could-have和Won't-have四大类。
虚拟货币(100点法)：发给相关方等量的虚拟货币(100点)，要求他们将这些虚拟货币(点数)分配给系统的工作项，此排序最有效率。
需求优先级：属于数学方法，每个特性的益处、坏处、成本和风险按1-9打分，然后逐个代入一个加权基准中计算其相对优先级。
卡诺分析：
将工作项按客户的喜好分成四个类别:惊喜、满意、不满意、无关紧要。
唯一一个将客户的期望和优先级排序相联系的排序工具，可用于相关方管理。
相对优先级排序：
让业务人员直接按照优先级顺序列出所有产品特性。
此方法避免了对需求优先级的过多分析，最为简单、快速。
单一优先级列表(PB表的五大内容)：
将功能性需求、非功能需求、缺陷处理、技术债务、风险处理等都放在同一个优先级工作项列表中进行处理。
优点:透明、容易控制、更为高效。
非功能需求：
可靠性、安全性、合规性、测试工作
技术债务：
混乱的代码、不统一的编码风格、没有参数化的函数、没有重构的算法
敏捷合同：
敏捷合同尝试固定资源和时间，通过调整功能来达到更高优先级和更高质量的产品。
敏捷合同需要客户的信任;对不信任或不参与的客户，敏捷合同可能很难执行或者根本不适合。
七个软件浪费：
燃尽图和燃起图：
燃尽图：
燃起图：
燃尽图能反映一个迭代内(范围固定)的进度并预测达成迭代目标的可能性。
燃起图不仅能展示已完成的点数，还能看出整个范围的变化，可用于迭代、版本甚至是整个项目。
燃起图可以判断剩余点数还需要几个迭代，而燃尽图不能。
累计流量图：
循环时间(图中周期时间):任务从队列被取出到完成的时间长短。
累计流量图的三大作用:
1.发现项目瓶颈;
2.监控任务的循环时间;
3.预测项目完成日期。
三、相关方与团队
识别相关方
相关方的分类
相关方是指影响项目或受项目影响的全部人员、群体或组织。
人物
用细节描述详细阐述用户信息，提供客户的背景，从年龄、收入、喜好、厌恶或其他细节分析用户的需求。
快速识别项目相关方及其兴趣点的工具。
用人物来识别相关方需注意：
1.提供一个用户的原型描述；
2.立足于现实；
3.有形的和可操作的；
4.聚焦。
解题关键:
识别用户需求和预估用户满意度的最佳工具是“人物”，相当于角色扮演和换位思考。
极端人物的方法可以防止一些场景的用户故事被遗漏。
线框图
在软件研发中，线框图描绘不同的屏幕以及屏幕间的流动关系；
属于低保真度的原型，可快速低成本得获得相关方的反馈。
原型的一种，原型是指低成本/低风险，向客户展示设计概念的方法，旨在开发前获得客户反馈。
用户故事
定义:大小适中的，可以被理解的商业功能模块。
敏捷团队通过用户故事待办事项(PB表的一种形式)进行商业需求优无级的排序。
用户故事的三要素
例：作为<旅客>，我想要<注册成为XX旅店会员>，以便<使用网上预订房间的服务>。
用户故事的3C原则：
Card：故事写在物理卡片上，卡片是载体，非需求本身；目的是为了方便面对面的交流和移动操作。
Conversation：故事的诸多细节需要和用户协商确定；体现了“个体和交互胜过流程和工具”；同时也与INVEST特性中的“可协商”属性相匹配。
Confirmation：故事包含验收标准,以确保被正确实现；验收标准必须在开发前确定；验收标准可以随着与PO的交流而不断改变，一旦被选入迭代就不再改变；
用户故事的INVEST特性
lndependent(独立的)：每个用户故事都是独立的；避免相互依赖；避免让故事的工作量和难度与实现次序相关
Negotiable(可协商的)：团队和PO一起协商和权衡用户故事；可协商性可以挖掘客户的真实需求
Valuable(有价值的)：用户故事必须是有价值的，否则无法对其商业价值进行优先级排序
Estimable(可估算的)：可以对用户故事进行估算，从而更好地制定迭代计划
Small(小的)：用户故事要小到可以在一个迭代中完成，工作量通常是2~5天；不提倡小于2天
Testable(可测试的)：对应3C原则中的Confirmation，在编写用户故事时就应识别故事的验收标准
用户故事难以估算的原因：
解题关键：
1.碰到史诗级用户故事，唯一手段是分解；
2.刺探可用于无法确定用户故事的确切估算。
相关方分析
故事地图
一种细化的产品路线图
客户价值优先级排序的工具
解释哪些会纳入第一个版本、第二个版本或者子版本
鼓励相关方用不同的方式参与
通过可视化的展示引发相关方的关注
管理相关方参与
管理相关方参与是指在整个项目中，与相关方进行沟通和协作，解决过程中出现的问题，促进相关方合理参与到项目中的相关活动。
提升来自相关方的支持
把相关方的抵制降到最低√显著提高项目成功的概率
解题关键:可在计划会、评审会积极管理相关方的期望
信息发射源：
用高可视化的图表/图形向相关方传递项目的信息
确保相关方及时知悉项目当前状态
速度
团队在每个迭代中完成的故事所对应的点数之和；
利用前几次迭代所完成的故事来评估团队后续的工作能力；
团队速度在经历几次迭代之后会逐渐稳定。
完成的定义
在测量速度前，一定要跟相关方就故事的“完成"达到共识；
“完成"可以是:已设计、已编码、已测试、已部署......
题:团队在第一个迭代中完成了故事A和B，故事C完成了50%，那么团队的速度是多少?
解题关键：
1.迭代完不成所计划的用户故事怎么办?结束后把未完成的用户故事放回PB表中，让PO进行重新排序。
2.迭代提前完成了计划的用户故事怎么办?继续从PB表顶部抽取用户故事继续做,直至迭代时间用完
授权
授权团队进行自主管理，是敏捷方法论的基石；
考试中，“由团队自己决定"基本都是正确选项；
谈判
团队和客户在功能和成本之间进行权衡；
敏捷项目谈判不是"零和博弈”，而是倡导双赢
冲突解决
冲突是不可避免的
建设性的冲突有利于项目，但SM需确保冲突不升级
负面冲突要尽量杜绝
理解团队绩效
团队激励
每个人的需求都不同（内驱力)
在不破坏项目目标的前提下尽量满足个人愿望
考试中，“直接支持成员个人意向”基本都是正确选项
由项目成果导致的奖励应为团队共有
组建高效团队
团队
一些技能互补(一定程度上)、有着共同目标和愿景、共同承担责任的人；
规模:敏捷团队通常是5～9人;
技能互补:敏捷提倡“T”型人才(考试中称为通才)，而非“I"型人才；
共同的愿景:为了同一个项目目标而努力
自组织团队
团队从“命令和控制"的管理中解救出来
各成员可以用其知识决定如何最好地完成工作
需要成员之间相互信任、分享以及尊重
如何领导自组织团队:
(1)设立一个基本规则
(2)提供一个排好序的用户故事列表
(3)授权并信任团队选择适当的工作方式
(4)帮助团队提升估算、解决问题以及决策的能力
(5)知人善任，挖掘成员潜力并给予激励
(6)服务型领导（保护、保持、保障、保姆)
(7)团队对项目的成果具有集体所有权
打造高绩效团队
每日站会
站会的三个问题可以帮助团队对任务目标达成一致
有助于团队通过频繁沟通而实现自组织
教练技术
整体层面:在四大仪式上对团队进行引领
个体层面:在日常工作中对个体进行引导
作战室(集中办公)
利:渗透式沟通，无意的信息共享提升沟通效率
弊:缺乏私有空间
潜规则知识
没有书面说明的、成员间自觉形成的默契和不言而喻的规则
分布式工具(虚拟协作工具)
团队内网、虚拟看板、视频/电话会议
需考虑语言、文化、时区等差异
头脑风暴
一种用来产生和收集需求的多种创意的技术，又称“集思广益”
不包含投票或排序
特点:面对面、无恐惧、快速、不求最后结果
要点:
1.确保中立和舒适的会议环境
2.有经验的引导者来当主持
3.提前告知成员会议目标、议程及基本规则
4.成员应来自多领域、多样化
5.删除任何阻碍思想产生的评论
四、适应性计划
敏捷计划的层次
第一层：愿景
项目章程
5W1H（教材第97页）
制定章程的过程可以帮助获取相关方对项目的支持
剩余的四层计划
第二层：产品路线图
特性优先级排序、归类；
粗略时间框架确定
勾画出产品多个版本的演变过程，属于粗粒度计划
关注中长期目标，而非细节
第三层：版本计划（发布计划）
用户故事估算；估算团队速度；确定用户故事优先级
初步确定发布日期(考试中，发布周期是可以调整的)
一般在每次迭代结束/开始时更新版本计划
故事地图
产品路线图和版本计划的有机结合
第四层：迭代计划
聚焦于实现本次迭代的用户故事以及任务的下发
一个版本由多个迭代组成
每个迭代的周期是固定不变的
迭代目标应由团队和客户/PO一起讨论得到(自组织团队)
根据团队速度以及迭代目标，成员领取用户故事/任务
重要考点：后期发现的缺陷及本次迭代未解决的缺陷作为需求加入到PB表中(不包括排序)
第五层：每日计划
每日站会第2个问题：“今天我打算做什么”
反馈环仅为1天，及时根据当前情况进行调整和反馈
时间盒
固定的一段时间，相对比较短
例：一个迭代是2周、一个站会是15分钟、一个迭代计划会是2小时
目的：保证工作的连续性，时间盒内的工作不被打断，减少因任务切换而带来的效率浪费
时间盒内工作未完成，应马上停止，并将遗留工作纳入Backlog中
时间盒内工作已完成但还有时间，应从Backlog中继续领取任务
帮助成员克服帕金森定律
时间盒的结束点为检查点
项目具有频繁的检查点，有利于及时评估和反馈，从而应对不稳定的环境/需求
解题关键：迭代长度和所有会议的时间长短都需要遵循时间盒规则
渐进明细
也称“滚动式规划”
随着项目进行中细节的涌现，逐渐明确计划和估算
敏捷的五层计划体现了项目的渐进明细性
最小可售功能（MMF）
功能包足够完整到可以为用户或者市场提供价值
重要考点：可以提供商业价值(注意与“最小可行产品"区分)
例：微信的第一个版本仅提供了语音发送功能
有利于抢占早期市场
基于价值的分析
指根据产品的商业价值而采取行动
定义愿景：产品盒子/电梯测试说明书
特性分解+特性排序
迭代循环：在迭代开发中识别额外的价值需求
敏捷计划的估算
宽带德尔菲
一种团队共同参与的估算方法
匿名提交估算结果，同时出牌，经过多轮迭代
每一轮开始之前对上一轮的估算结果进行讨论
估算结果收敛并达到退出标准即可停止
有效避免以下心理学效应
计划扑克
一种以菲波那契数列为基础的估算扑克
通常与宽带德尔菲联用
用于估算用户故事的点数
具体操作步骤：
1.每位成员领一副牌
2.PO作为主持人讲解一个用户故事
3.每位成员同时出牌，彼此可看到出牌结果
4.估算过高/过低的成员辩护自己的结果
5.重新估算，直到结果收敛为止
亲和估算
粗略估算PB表中待办事项的方法
常用于项目早期
估算精度不如计划扑克和宽带德尔菲
利用若干个尺码大小对事项/故事进行估算
故事点
一种用于估算用户故事工作量的单位
故事点的重要考点:
达成共识：不同的人对同一故事的点数估算应该是一致/相近的
不可对比：不同团队之间的速度、故事点是不可进行直接对比的
解聚前后：大故事被拆分前后,故事点的总和是不一定相等的
规模相对：一个点数为4的故事对应的工作量是点数为1的故事的4倍
理想时长
团队在不被打扰的情况下完成故事的理想时间作为估算单位
例：人天、人月
缺点：不太符合实际情况，估算之后往往要加缓冲时长
优点:
1.简化估算
2.易于向外部人员解释
3.开始估算时容易起步
4.容易估算开发速度
五、敏捷实践
概述
敏捷的全流程视角
精益
精益的价值观
持续改进工具：反思会、根本原因分析、价值流图、7种浪费等等
精益敏捷领导力：应用并教练精益思想(聚焦价值、消除浪费)，基于长远发展目标进行决策
精益软件开发
消除浪费：消除软件开发中的七种浪费
延迟决策：获取尽量多的信息，减少返工风险，应在“最后责任时刻”做决定
看板
看板的两大作用：流程可视化；识别障碍和瓶颈；
WIP(Work in Progress)，在制品，指已经开始但还未完成的工作，在精益中被视为一种浪费。
过多的WIP所产生的问题包括:
1.团队在多个任务之间来回切换，降低工作效率；
2.WIP隐藏了过程中的瓶颈，包括减缓工作流和掩盖工作效率；
3.WIP在获得验收前都有可能发生变更，存在返工的风险；
而过少的WIP又会导致团队成员过于空闲，浪费人力资源;
敏捷提倡限制WIP，可识别过程瓶颈，并最大化生产率。
利特尔法则(Little's Law)：生产周期与WIP的数量成正比。
利特尔法则指出有效缩短生产周期的两个方向：提高产能；限制WIP
极限编程（XP）
极限编程(XP)是一种轻量级的软件开发方法，侧重于从技术角度实现敏捷开发。
极限编程的基础和价值观包含:沟通、简洁、反馈、勇气和尊重。
沟通：团队成员需知悉其他成员都在干什么，每日站会是关键
简洁：减少复杂程度、多余的功能,消除浪费；“最简洁的就是最可行的”
反馈：早期的错误是有益的,可以尽早获得信息以进行改进
勇气：有勇气将自己的工作公开，并有信心做重要的改动，结对编程是关键
尊重：团队是一个整体，对代码有共有权，因此要会尊重别人工作的不同
12个技术实践
计划游戏：包含发布计划和迭代计划两大活动;开发团队对用户故事的难度和规模进行预估
小版本：XP提倡频繁的小版本测试，可以更为快速地将工作的软件部署给自标客户
用户测试：完成用户测试是完成的定义的一部分;客户需描述一个或多个测试来展现交付的软件是可以使用的;
代码共有权：所有程序员共同负责软件中的任意模块或技术，可以减少某个程序员离职所带来的不良影响
编码标准：与代码共有权联用;整个团队按照统一标准编写代码使得整个系统的代码看起来好像是一个人编写
可持续的速度：XP认为最高的生产率水准是团队可以达到持续的开发速度。避免长期加班可以避免技术债务，长期看来是很有价值的
比喻：生动形象的比喻可以更好地让相关方理解和解释软件系统是如何工作的
持续集成：每天一次/多次将新代码集成到系统中共同运行，可以尽早暴露问题和发现错误，有利于持续改进
测试驱动开发：先编写测试用例再开发功能代码；有利于测试前移，在测试的保护下重构代码，消除重复设计，优化设计结构
重构：在不改变软件现有功能的基础上，优化程序的设计模式和架构，使其更为合理
简洁设计：可工作的最简化系统相对于复杂的架构在未来更具灵活性；相对于庞大而复杂的编码，简洁设计可降低风险
结对编程：可以实现一边编写代码一边实时审查，可以尽早发现编码错误,还能促进知识共享
其它实践
动态系统开发DSDM
DSDM项目尝试固定资源和时间(成本的主要花费部分)，通过调整功能来达到在这些约束下产生更高优先级和更高质量的产品。
水晶
水晶的原则:
频繁交付：不断地增量交付
反思改进：经常思考改进及新方法
渗透式沟通：项目信息的无意识共享
个人安全：在无恐惧环境中分享信息
专注：平静地专注于项目工作
容易接触专家用户：尽快获得反馈
技术环境：自动测试、配置管理及频繁集成
SCRUM
SCRUM与其他实践的实施率
三大支柱
透明
建立信任和安全感；信息的可视化和透明化；对每个术语理解一致；对每个决策达成共识；
检验
监控迭代进展；识别项目偏差；测试内建于开发；及时发现问题；
适应
持续改进的基础；依据检验结果；调整团队行为；调整项目目标；
迭代
谁参加：TEAM和SM，PO不参加
何时：每次迭代计划会之后
何地：开发现场
输入：迭代待办列表
输出：潜在的可交付产品增量（PSI)
原则：
迭代开发是有节奏的小步快跑,但建立在坚实的质量基础上；
迭代过程中，迭代目标不变，质量目标不变；
及时暴露问题、及时消除风险、及时反馈；
三大角色
PO：产品负责人(关注产品的价值)
组织内最能理解客户需求和价值的代表人物。
主要职责:
指导价值方向，持有产品愿景，管理Product Backlog(产品待办事项)，排列PB的优先级顺序，决定产品发布，负责产品的投资回报率
参与的工作:
需求梳理会
迭代计划会（可调整故事优先级)评审会
回顾会
每日站会（可不参加）
版本发布计划及验收团队的迭代增量
SM：敏捷项目经理(关注团队的自组织)
主要职责:
监控整个项目，促进团队自组织，激励团队，为团队提供所需的环境和支持，排除项目障碍。
参与的工作:
需求梳理会
迭代计划会
评审会
回顾会
每日站会
服务型领导
保护
保护团队不受不属于本项目工作的影响和中断，确保注意力不被转移
保障
保障团队的项目工作顺利进行，移除障碍，以让团队专注于交付价值
保持
保持团队项目工作始终不脱离项目愿景；保持团队的速度，进行可持续开发
保姆
激励团队，为团队的高效运行提供必要的资源，如工具、食物、福利、培训等
TEAM：开发团队(关注产品增量)
主要职责:
全程参与项目，在每个迭代中创建潜在的可交付产品增量(PSI)，最终交付有价值的可工作软件
参与的工作:
需求梳理会
迭代计划会
迭代（设计、编码、集成、测试)
每日站会
评审会
回顾会
敏捷项目团队=PO+SM+TEAM
自组织敏捷项目团队的特点：遇到问题作为一个整体一起解决(信任+安全)，而不是相互指责或追究。
五大事件
需求梳理会（可选）
对于需求较为简单的项目，需求梳理可以是首次迭代计划会的前半部分
参与人:PO+SM+TEAM+相关方
何时:PO获得客户需求、场景之后
目的:
1．将客户的原始需求(Feature)分解为用户故事(User Story)
2.对用户故事进行初步优先排序
3．对用户故事进行初步估算(亲和估算)
重要输出:
经过初步排序的产品待办事项(PB)
PB表的特点:
A.由PO排序后的
B.随时都可变(与SB不一样)
需求的层级
故事是分层的，就像计划可以分层次一样
项目的分层规则确定好之后应坚持使用
需求的分层不等同于瀑布型项目中的WBS
Sprint（迭代）计划会
参与人:SM+TEAM，PO可选
何时:产品代办事项(PB表)明确之后
目的:
1．把用户故事(User Story)分解成具体的任务(Task)
2．对任务进行具体估算(宽带delphi和计划扑克)
重要输出:
经过排序的迭代待办事项(SB表)
SB表的特点:
A.开发团队根据预估速度选择迭代的任务(Task)
B.优先选择在PB表中优先级高的任务
C.在迭代的过程中一般不会变化
D.一般包含2～3个迭代的任务
每日站会
参与人:SM+TEAM，(PO/供应商/其他相关方)
何时:迭代过程中的每一天
何地:看板旁
目的:
1.成员之间的沟通和协调
2.每个成员分享实际进度，带来同行压力
3.制定每日计划
内容:（三大问题)
1．昨天我做了什么?
2.今天我打算做什么?
3.我遇到了什么障碍?
重要考点:
站会不讨论具体问题的解决方案，而是写到看板上并指派责任人；
解决方案的讨论可以在站会后另开一个会；
Sprint（迭代）评审会
参与人:PO(验收)，SM+TEAM，客户(可选)，相关方
何时:每次迭代后，回顾会前
何地:会议室/实验室
目的:
1.TEAM向PO或客户展示本次迭代的成果并获得反馈
2.尽早获得反馈，降低“不能满足需求”的风险
内容:
演示并反馈，客户的新需求会导致PB表的修改
重要考点:
不要因为需求未完成而延长迭代周期；
若需求未完成，可以（1）提出发布周期的变更（2）减小范围；
Sprint（迭代）回顾会
参与人:SM+TEAM+PO，相关方
何时:评审会后，迭代最后一个环节
何地:会议室
目的:
总结经验教训，改进下一个迭代
内容:
1.有哪些是做得好的?
2.有哪些是做得不好的?
3.下一个迭代我们要尝试哪些改进举措?
三大工件
产品待办事项(Product Backlog表)
作用:对客户价值优先级进行排序，产品可能需完成的需求列表
何时:需求梳理会的输出，在整个项目过程中都可变(动态性)；
内容：
功能性需求：产品功能、需求、性能、增强项
其他需求：非功能需求、技术债务、缺陷修复、风险处理
思考：
谁能向PB表添加事项? 谁都可以
谁有权决定PB表的事项优先级? 只有PO可以
迭代待办事项(Sprint Backlog表)
作用:指导迭代的工作优先级
何时:迭代计划会的输出，迭代过程中不发生改变
内容:
PB表的子集,从PB表的最优先事项中选择；
把用户故事分解为任务(Task)；
用户故事的选择应符合团队速度的估算；
用燃尽图、燃起图或累计流量图等监控迭代的进展。
产品增量
作用:每个迭代产生潜在的可交付增量(PSI)，以交付价值
何时:每个迭代的输出
内容:
团队完成的所有产品PB表条目的集合，包括当前Sprint和以往所有的Sprint；
需满足验收条件；
重要考点:
产品增量需经过PO或客户验收才能转换为交付的价值；
敏捷项目团队都需要对每一次迭代增量的完成定义(DOD)在迭代之前达成清晰的理解和共识；
Potentially Shippable ≠ Shippable（潜在的可交付的≠可交付的）
敏捷中的变更控制流程:
1．根据客户需求编写或改写用户故事；
2．将上述用户故事加入产品待办列表(PB表)；
3．由产品负责人对PB表重新排序;
4．团队在下一次迭代规划会中选取PB表的前几个用户故事作为下一次迭代的开发任务;
5．进入下一轮迭代;
6．迭代完成，开评审会，由客户/产品负责人对迭代的成果验收；
7．开回顾总结会总结迭代的经验教训；
SCRUM OF SCRUMS
当团队规模大到一定程度时，可以分成多个SCRUM团队而不是一个大型SCRUM团队来管理，其中一个团队包含3～9名成员。
六、回顾与持续改进
发现问题
问题的处理流程
解题关键：无论是技术问题还是管理流程问题，“根本原因分析”基本是正确答案
每日站会
发现问题的重要机制
第三个问题：“我遇到了什么障碍”
站会明确问题的三要素：What?Who?When?
站会不讨论具体解决方案
循环时间
限制WIP
缩短循环时间
故障泄漏
故障是哪个环节被发现的?是哪个环节所引发的?
尽早发现故障，避免交给客户才发现故障
质量标准
用客户验收衡量产品质量(避免镀金)
每个迭代应解决90%已发现故障
开发和业务人员应对验收标准达成共识
控制图
用于判断一个过程是否稳定，发现问题的重要工具，横坐标是时间。
解题关键；
（1）某数据点超出控制界限即为失控；
（2）连续7点在中心均值上方或下方即为失控。
解决问题
持续集成
团队及时将变更的代码集成到应用程序中
每天可进行多次
及时获悉代码合入的错误
尽快修复错误而不是拖延到发布
快速回退版本
风险探测(Spike)
风险发生前先快速验证风险的应对方案
如果所有方案被验证无效，则进入“快速失败"模式
频繁的确认与验证
提升产品质量的最重要措施，敏捷项目质量管理的核心理念
结对编程：实时审查及时发现错误并反馈
自动化测试：消除手动测试的低效率和人为错误
解题关键:
避免缺陷的三大手段：DOD，持续集成，频繁测试；
安排额外时间或单独的迭代来处理缺陷都是错误答案
测试驱动开发(TDD)
TDD倡导的理念是开发之前编写测试代码，因为开发人员在实际开发功能之前要清楚该功能如何被测试。
测试驱动开发的三个流程
测试
明确测试标准，编写测试代码，运行测试用例直至全部通过测试。
编码
按照测试用例和标准编写功能代码，伴随频繁测试。
重构
在不改变代码功能的基础上，通过消除冗余等行为对代码进行改良。
分析原因
头脑风暴
用来产生和收集产品需求和创意的技术。包括安静书写、循环发言和自由讨论三个步骤
名义小组
通常与头脑风暴联合使用,利用投票选出最有用的创意或者想法。
五问法
源于丰田的精益思想，团队成员对问题连续问五次“为什么”，目的是帮助找到问题的深层次原因。
鱼骨图
问题陈述放在鱼骨的头部，用来追溯问题来源。
解题关键：推导问题的根本原因、可能原因。
理解持续改进
学习模型
阿吉里斯的双环学习模型
持续改进的核心前提是建立一个行之有效的学习模型。
学习：学是效仿，习是实践、运用。而实践不是蛮干，需要反思。
戴明环（PDCA环）
戴明环是一个典型的双环学习模型。
回顾
回顾的类型
回顾通常是迭代之后的一个经验教训总结会，团队聚在一起检查并改进其方法和团队绩效。
回顾通常包含以下改进类型。
改进生产力
减少返工，获得更多富有成效的工作
改进能力
回顾使团队的稀缺知识量增加，可以执行与知识相关的任务
改进质量
通过发现导致缺陷的原因来改进产品质量
改进技能
聚焦于发现流程效率的提高，改进团队的工作技能
预设会议基调
目的：营造讨论问题的和谐气氛，让参与者积极发言。
主旨：让成员用正确的情绪提供信息和想法。参与者或许由于害怕冲突而不敢提出问题，所以不愿评价同事/管理者。重要的解决途径是匿名。
活动：例如签到、ESVP等。
签到
每个人用一两个关键词概括主要想法。
ESVP
此活动中参与者匿名汇报他作为下列某种身份的选择。
Explorers(探索者):渴望新主意和灵感，想学到新的东西
Shoppers(采购着):收集信息，并高兴地把有用的信息带回去
Vacationers(度假者):对回顾会不感兴趣，参加会议是为了躲避无聊的日常工作
Prisoners(囚徒):自身不愿参加回顾会，是被强迫来参加会议的
三大步骤
预设基调后的三大活动包括：收集数据、激发灵感、决定做什么。
注：对回顾会上的三大主题都应重复使用上面三个步骤，形成有效的双环学习模型。
收集数据
时间盒
三五成型
颜色标记
寻找优势
满意度直方图
团队雷达
分析原因
头脑风暴
名义小组
五问法
鱼骨图
采取行动
简单主题
SMART目标
回顾收尾
回顾的最后一个步骤是总结收尾，团队成员彼此表达感谢，作为团队沟通协作的一个良好机会。
+/Δ
“+”代表下一个迭代继续做的事情；
“Δ”代表下一个迭代需要改进的事情。
帮助/障碍/设想
哪些是有帮助的?
哪些是有阻碍的?
构想任何可以改进的建议。
欣赏
相互感谢其他成员的帮助，是团队建设的一种手段。增强团队感情和相互协作。
过程定制
过程定制指的是要依据不同的项目、不同的环境及不同的团队来选择合适的敏捷实践及流程，也称为敏捷的多样化。
考试中，“由敏捷团队决定具体方法"基本都是正确答案。
过程定制应遵循“系统思考"和"流程分析两大原则”
系统思考
在实施敏捷流程之前，需多了解项目的环境(如组织架构、文化、市场等)和系统(如技术手段、风险种类等)。
流程分析
分析敏捷方法的流程，以减少流程带来的浪费，提升流程运转效率，如价值流程图等。
0 条评论
下一页
