导图社区 敏捷实践指南课堂笔记
本思维导图全面整合《敏捷实践指南》(Agile Practice Guide)的核心理念与实用方法,结合PMP与ACP考试重点,系统梳理敏捷项目管理的关键知识模块,帮助学习者深入理解敏捷思维的本质、掌握典型实践框架,并具备在项目和组织层面推动敏捷转型的能力。内容涵盖“敏捷价值观的来源”“敏捷方法概览”“实施敏捷的三个关键步骤”“Scrum项目实践”“一种典型的敏捷实践框架”以及“组织层面如何实施敏捷”等核心主题,结构清晰、逻辑严谨,适用于项目管理人员、备考PMP/ACP考生、企业敏捷教练及希望提升团队协作效率的从业者。 导图首先追溯敏捷价值观的基本来源,深入解析《敏捷宣言》(Agile Manifesto)提出的四大核心价值观与十二项原则,强调“个体和互动高于流程和工具”“工作的软件高于详尽的文档”“客户合作高于合同谈判”“响应变化高于遵循计划”的根本理念,阐明敏捷以人为核心、拥抱变化、持续交付价值的本质特征。 在敏捷方法概览部分,导图对比Scrum、Kanban、XP(极限编程)、Lean(精益)、Crystal、FDD等主流敏捷方法的适用场景与核心实践,帮助学习者根据项目特点选择合
编辑于2025-10-01 22:12:28本思维导图全面整合《敏捷实践指南》(Agile Practice Guide)的核心理念与实用方法,结合PMP与ACP考试重点,系统梳理敏捷项目管理的关键知识模块,帮助学习者深入理解敏捷思维的本质、掌握典型实践框架,并具备在项目和组织层面推动敏捷转型的能力。内容涵盖“敏捷价值观的来源”“敏捷方法概览”“实施敏捷的三个关键步骤”“Scrum项目实践”“一种典型的敏捷实践框架”以及“组织层面如何实施敏捷”等核心主题,结构清晰、逻辑严谨,适用于项目管理人员、备考PMP/ACP考生、企业敏捷教练及希望提升团队协作效率的从业者。 导图首先追溯敏捷价值观的基本来源,深入解析《敏捷宣言》(Agile Manifesto)提出的四大核心价值观与十二项原则,强调“个体和互动高于流程和工具”“工作的软件高于详尽的文档”“客户合作高于合同谈判”“响应变化高于遵循计划”的根本理念,阐明敏捷以人为核心、拥抱变化、持续交付价值的本质特征。 在敏捷方法概览部分,导图对比Scrum、Kanban、XP(极限编程)、Lean(精益)、Crystal、FDD等主流敏捷方法的适用场景与核心实践,帮助学习者根据项目特点选择合
整车质量保证体系全生命周期管理思维导图是一套面向汽车行业质量管理者、整车厂工程师、项目管理人员及海外出口业务负责人的系统性工具,以脑图形式完整覆盖从项目立项、工程验证、生产启动到量产交付、售后质量改进的全过程。该模板将质量保证分解为关键过程、控制要素与落地措施三大层次,并为各价值链环节设定量化KPI及具体达成手段,同时专项涵盖出口海外整车与KD(散件组装)零部件的质量控制要点,帮助车企构建闭环、可追溯、持续进化的质量保证体系。 在项目立项与工程验证阶段,模板明确质量先期策划(APQP)的关键节点:项目质量目标设定(如新车投产初期千台故障率≤XX)、设计评审与失效模式分析(DFMEA)、工程样车验证(DV/PV测试通过率)。控制要素包括设计规范、试验标准、供应商早期介入。落地措施为跨职能质量门评审(Quality Gate),每阶段设置退出标准并强制验收。量化KPI包括设计问题关闭率、试验完成率等。 在生产启动阶段,模板聚焦过程验证与产能爬坡质量。关键过程包括生产件批准程序(PPAP)、过程失效模式分析(PFMEA)、控制计划(CP)、测量系统分析(MSA)及过程能力研究(Cpk)。控制
社区模板帮助中心,点此进入>>
本思维导图全面整合《敏捷实践指南》(Agile Practice Guide)的核心理念与实用方法,结合PMP与ACP考试重点,系统梳理敏捷项目管理的关键知识模块,帮助学习者深入理解敏捷思维的本质、掌握典型实践框架,并具备在项目和组织层面推动敏捷转型的能力。内容涵盖“敏捷价值观的来源”“敏捷方法概览”“实施敏捷的三个关键步骤”“Scrum项目实践”“一种典型的敏捷实践框架”以及“组织层面如何实施敏捷”等核心主题,结构清晰、逻辑严谨,适用于项目管理人员、备考PMP/ACP考生、企业敏捷教练及希望提升团队协作效率的从业者。 导图首先追溯敏捷价值观的基本来源,深入解析《敏捷宣言》(Agile Manifesto)提出的四大核心价值观与十二项原则,强调“个体和互动高于流程和工具”“工作的软件高于详尽的文档”“客户合作高于合同谈判”“响应变化高于遵循计划”的根本理念,阐明敏捷以人为核心、拥抱变化、持续交付价值的本质特征。 在敏捷方法概览部分,导图对比Scrum、Kanban、XP(极限编程)、Lean(精益)、Crystal、FDD等主流敏捷方法的适用场景与核心实践,帮助学习者根据项目特点选择合
整车质量保证体系全生命周期管理思维导图是一套面向汽车行业质量管理者、整车厂工程师、项目管理人员及海外出口业务负责人的系统性工具,以脑图形式完整覆盖从项目立项、工程验证、生产启动到量产交付、售后质量改进的全过程。该模板将质量保证分解为关键过程、控制要素与落地措施三大层次,并为各价值链环节设定量化KPI及具体达成手段,同时专项涵盖出口海外整车与KD(散件组装)零部件的质量控制要点,帮助车企构建闭环、可追溯、持续进化的质量保证体系。 在项目立项与工程验证阶段,模板明确质量先期策划(APQP)的关键节点:项目质量目标设定(如新车投产初期千台故障率≤XX)、设计评审与失效模式分析(DFMEA)、工程样车验证(DV/PV测试通过率)。控制要素包括设计规范、试验标准、供应商早期介入。落地措施为跨职能质量门评审(Quality Gate),每阶段设置退出标准并强制验收。量化KPI包括设计问题关闭率、试验完成率等。 在生产启动阶段,模板聚焦过程验证与产能爬坡质量。关键过程包括生产件批准程序(PPAP)、过程失效模式分析(PFMEA)、控制计划(CP)、测量系统分析(MSA)及过程能力研究(Cpk)。控制
敏捷实践指南
实施敏捷三步骤
1. 选择项目生命周期
四种基本的生命周期类型
预测型LC
项目特征
需求明确
顺序执行:定义、设计、建造
一次交付
最有可能适用于无中间交付成果或没有机会进行原型开发的项目
缺点
遭遇变更、需求分歧或技术解决方案变得复杂时,产生无法预测的成本
迭代型LC
项目特征
需求动态
反复执行至修正
一次交付
缺点
整个LC可能需要更长的时间
无法应对技术和需求两者都不确定的状态
增量型LC
项目特征
需求动态
每次执行给定增量
频繁小规模交付
缺点
无法应对技术和需求两者都不确定的状态
优点
尽早提供价值,偏差可接受
Scrum理论
使用迭代和增量方法
非常短的反馈循环
频繁地调整过程
重新进行优先级排序
定期更新计划
频繁交付
基于经验主义和精益思想
三大支柱
透明
检视 Inspection
适应
敏捷型LC
基于迭代的敏捷
基于流程的敏捷
项目特征
需求动态
反复执行至修正
频繁小规模交付
2. 创建敏捷环境
团队从敏捷思维模式开始
有仆人式领导为团队赋权
仆人式领导的特征
提升自我意识
倾听
为团队服务
帮助他人成长
引导与控制
促进安全、尊重与信任
促进他人精力和才智提升
仆人式领导的职责
项目经理
促进作用
促进个人各尽所能地思考和工作
促进团队的参与、理解及共同承担
消除组织障碍
审视阻碍敏捷的过程,使其合理化
关注并改变其他冗长的过程
为他人贡献铺路
教育相关方
通过指导、鼓励和帮助为团队提供支持
通过技术项目管理活动
庆祝团队的成功
组建鼓励自我管理的敏捷团队
最有效的团队
100%专职
人数3~9
与仆人式领导一起成长
集中在一个场所工作
分布式团队沟通
鱼缸窗口
远程结对
由T型人才组成
团队中的3种常见角色
跨职能团队成员
包括设计、开发、测试及其他所需的专业角色
Product Owner
产品购买者,根据商业价值对任务进行排序
负责合作,定义产品开发方向
为或与团队一起创建PB Product Backlog
团队促进者
可以是项目经理、Scrum主管、项目团队领导、团队教练或团队促进者
1. 交付价值胜过满足约束
2. 领导团队胜过管理任务
3. 适应变化胜过遵循计划
克服组织孤岛
3. 在敏捷环境中交付
项目章程 Project Charter
项目愿景:为什么要做这个项目
谁受益?如何受益?这一点可能是上述Vision的一部分
项目的发布标准
怎样合作?预期的工作流
团队章程 Team Charter
即团队的社会契约。只要团队知道如何一起工作,制定章程就不需要一个正式的过程
内容
价值观,如可持续的开发pace/核心工作时间
工作协议,如Ready,DoD,时间盒,使用工作过程限制
基本规则,如有关一个人在会议上发言的规定
团队规范,如团队如何对待会议时间
Goal
创造一个敏捷的环境
规定成员互动方式
利益相关方
5种敏捷项目会议
i. 待办事项列表 backlog
how?
以故事形式呈现给团队
who?
PO可能会制作/重新规划一个产品路线图,以显示预期的可交付成果序列
ii. backlog refinement
when?
迭代中期,1~N次
基于流程的敏捷:即时细化
基于迭代的敏捷:1小时/2周
who?
PO与团队合作,为下次迭代准备并细化故事
what?
PO鼓励团队一起撰写故事,确保故事足够小
PO介绍故事的创意及其相互关系
团队讨论故事概念,并细化为许多故事
iii. 每日站会
when?
每天,≤15分钟
who?
SM和开发团队参加+(PO)
how
看板或任务板
看板把信号系统引入进度流程中,根据资源设计一个WIP的上限,完成后再引入新的故事或其他工作内容
不使用严格的迭代长度,并非所有项目都适合
都可以主持站会
基于迭代的敏捷,个人
昨天的完成?
今天的计划?
碰到的障碍?
基于流程的敏捷,团队
需要完成什么?
还需要做什么?
谁在做不在看板上的事情?
工作流程的障碍或者瓶颈?
站会的特征
同辈压力——因为团队靠大家,所以同辈的期望可带动进步
密切的配合——团队应当理解专注的必要性并独立工作
简洁专注——团队应当理解每日站立会议中简洁的必要性,由此团队才有效益
每日承诺——团队应当理解对每人每日承诺的价值所在,并兑现这些承诺
辨别障碍——团队应当集体意识到每个人的困难,由此团队可尝试集体解决
iv. 展示或评审 Review
when?
团队以故事的形式完成特定的功能时
基于流程的敏捷:迭代结束时展示所有已完成的工作项
基于迭代的敏捷:按需,通常在完成的功能累积到足以构成一个连贯组合
what?
PO接受或拒绝故事
for?
频繁地交付工作产品
敏捷项目流程的必要组成部分
v. 回顾 retrospective
when?
迭代评审之后会提示回顾,但团队成员可以决定在其他关键时刻进行回顾:
团队完成一个发布,或加入一些功能
距上一个回顾已过几周
团队出现问题及协作不畅时
达到任何里程碑
1个月的迭代为3个小时
who?
开发团队的所有成员、ScrumMaster和产品负责人
非Scrum团队中的利益干系人或经理
XP在促进团队交付价值上的执行实践 p56
持续集成CI
在不同层面测试
TDD、BDD
ATDD
刺探
敏捷项目的挑战及解决方案
敏捷项目的衡量
倾向于经验指标(如已完成功能)
考虑定性指标
交付功能的业务满意度
团队士气
团队希望跟踪的事项
敏捷三角
I. 价值目标:聚焦于构建可发布的产品
包括产品愿景、商业目标和能力
II. 质量目标:构建可靠的、适应性的产品
III. 约束目标:在接受的约束(范围、时间、成本)内,实现上述目标
敏捷团队的衡量
倾向于基于经验和价值的衡量指标
基于迭代的敏捷 p62
燃起图
燃尽图
速度 pace
能力衡量指标
进度绩效指数 SPI
成本绩效指数 CPI
基于流程的敏捷 p64
交付周期 lead time
周期时间 cycle time
响应时间
可预测的衡量指标
累计流图 p70
一种敏捷实践框架
1. 构想
目的:清晰地确定需要做什么以及如何做
主要活动
I. 产品愿景
产品愿景盒和电梯测试声明
产品体系架构和指导原则
II. 项目目标和约束
项目数据表
III. 项目社区
找到合适的人员
确定参与者
客户团队与开发团队的接口
IV. 方法
流程和实践的裁剪
2. 推演
目的:创造和理解产品结构、能力和故事的待办事项列表,成果是发布计划
主要活动
I. 确定产品及其特性在当前版本中如何演变
II. 平衡预期和加以适应
III. 在项目早期将重点放在价值最高的特性上
IV. 考虑业务目标、项目目标和客户期望值
V. 为管理层提供必要的预算和进度信息
VI. 为权衡决策建立优先级
VII. 协调团队之间的相关活动和特性
3. 探索
目的:交付可运行 + 已测试 + 已接收的故事
主要活动
I. 迭代计划和监督
迭代计划(部门例会?)
团队从发布计划中摘出每个故事卡片,确定实现这个故事的技术任务和其他任务
重新估算工作量,必要时调整本次迭代计划中的故事
开发速度:每次迭代交付的故事合数或点数,表示容量大小
项目或SM并不分派任务,团队成员自己决定,项目领导者的参与通常是教练(提供资源、信息或技术指导)的形式
整个项目团队包括智能经理,都应全部参与迭代计划会议(每1周的迭代持续1~2小时)
工作量管理
设定迭代长度应遵循的标准,或考虑的因素
1. 交付对用户有价值的功能块(故事)
2. 构建和测试故事(可工作的软件)
3. 产品团队对故事的接收
4. 发布时间范围
5. 探索系数
6. 准备和评审时间
7. 学习需要
8. 管理开销
监督迭代进程
II. 技术实践
技术债务
对技术卓越做空头承诺,或仓促工作时产生
它是产品的实际变更成本与最佳变更成本之差额
管理技术债务有助于交付敏捷三角形中的质量
减少技术债务,必须作为一个根本的技术策略
然而它不能防止产品过时,知识让变更成本保持很低的水平
简单设计
目的让工程团队基于已知知识而非未知的预测而设计,这意味着适应比预测更有价值
持续集成
无情的自动化测试
单元测试
QA测试
接收测试
全系列的测试自动化
不失时机的重构
涉及更新产品的内部组件(改进设计)而不改变任何可行的功能
开发流程中应包括系统的产品重构方法
重构既用于测试代码,也应用于执行代码
III. 项目社区
教练和团队开发,项目领导者的责任
聚焦于团队的愿景、目标和交付结果
将一群人塑造成一个团队
相互交流促进创新
头脑风暴
技术设计评审会
走廊交谈
在线小组
结对编程
引导争论和冲突,使它建立信任和尊重
协助团队制定交往规则,或合作协议
发展每个人的能力
使其发挥已具备的能力
为团队提供资源并扫除障碍
教练客户(产品团队)
产品经理必须承担识别、定义、确定优先级和接收功能的责任
使团队的节奏保持一致
参与式决策制定
全员参与决策过程,最终决策由多数票决定
不是让团队妥协,而是重新构思、统一立场
合作与协调
每日站立会议
所有核心团队成员参加
产品经理和项目经理作为对等的参与者出席(非搜集项目状态信息)
团队成员、迭代经理或项目经理引导该会议,后两者的作用是协调(而非状态评审)
其他经理通常不出席,否则也只是观察者
会议目的是提出问题和障碍,而非寻求解决方案
产品团队日常交流
协调利益相关方
4. 适应和收尾
适应措施
客户焦点小组
向产品团队展示最终产品的现行版本
主要是发现和记录客户需求的变更
产品接收测试
定期技术评审
非正式的在迭代交付周期不断出现
正式的至少每个里程碑一次
一般控制在2~6个有能力评估 的人参加
评审产品、选定的文件和数据信息,如缺陷率
团队绩效评估
团队自我评估:达标、不达标、超标
交付绩效
团队行为
项目状态报告
价值和范围状态
强调价值和范围的进展
质量状态
每次迭代的技术质量水平
测试代码相对于可执行代码的增长
项目数据表中的质量目标
进度和风险状态
敏捷性
每次迭代中故事的变化
来自于客户焦点小组的变更请求,及其实施状态
成本状态
项目团队信息
传统上称为监督和控制
收尾活动
最重要的是进行项目回顾
Scrum项目
Sprint
定义:Scrum过程中为期4周的迭代
全部工作内容:排好优先级列表Product Backlog
初期由PO和开发人员一起编写一些较显而易见的功能
后期由PO根据产品发展和客户反馈进行调整和扩充
有技术类任务,也有面向客户的任务
本次迭代内容:从PB中选取的Sprint Backlog
基本概念
用户故事
描述了对用户、系统或软件购买者有价值的功能
帮助定义用户故事的3C:卡片、对话和确认
Card:简述软件特性或改进点,后续用来沟通、对需求内容的组织和优先级排列
Conversation:团队与PO或客户交谈来明确细节,并在这提过程中达到共识和理解的统一
Confirmation:验收标准,每个故事应独立、完整,可单独交付
好的用户故事的标准:INVEST原则
Independent:最好不要彼此依赖
Negotiable:提醒团队成员对话,而非把故事卡片看成确定性的需求
Valuable:具备外部价值,而非仅仅对开发人员有价值
Estimatable:故事规模适中,对应的业务和技术知识得到澄清,规模可估算
Small:即将开发的用户故事足够小,从而便于迭代、优先级调整和需求澄清
Testable:可测试的故事意味着需求是清晰的、可验证的
开发一个用户故事的理想持续时长是2-5天
用户故事通常存放在PB中
故事的组成
一份书面的故事描述,用来做计划和做提示
有关故事的对话,用于具体化故事细节
测试,用于表达和编档故事细节且可用于确定故事何时完成
故事的估算
三角测量
帮助团队故事点含义保持一致
开发人员定义故事点的方式应努力保持一致,估算也保持一致
“速率”代表一个团队在一个迭代中完成的故事点数
故事点是故事复杂度、工作量或工期的相对估算
团队是否使用结对编程对故事点估算没有影响
价值点分析
相对估算(故事点) - 绝对估算(小时数)
亲和估算
可以采用斐波那契数列或者T-shirt尺码。如果需要估算的故事多且团队掌握的信息还不够充分时,最好选择亲和估算,以快速得到估算结果,并且这时很难能得到比较精确的估算。一般估算PB就属于这种情况
宽带德尔菲技术
通过多轮调查/投票的方式整合主题专家的匿名输入
计划扑克
需要估算单一故事时,或者对一个迭代进行估算时,最好使用计划扑克。因为这时需要比较精准的估算,而且故事相对较少。多花点时间也值得。牌被揭露,然后估算被讨论。通过以这种方式隐藏数字,团队可以避免“锚定”的认知偏差。估算扑克是一种变化的宽带德尔菲方法
相对价值点
货币价值点
收入净现值NPV*能力价值百分比 /
优秀故事的INVEST特征
独立的 Independent
故事间的相互依赖会导致优先级的排列或难以估算计划
可讨论的 Negotiable
故事卡只是提醒之后需要进行需求讨论,而非正式的需求承诺或某功能的具体描述
用1、2句短语来提醒客户和开发人员进行对话
几个备注,用来表明在对话中需解决的问题
对用户或客户有价值的 Valuable
用户:软件的使用者
客户:软件的购买者
可估计的 Estimatable
Dev可以估算故事的大小
Dev能估算把故事变成可用代码的时间量
小的 Small
故事太大或太小都无助于制定计划
可测试的 Testable
用户故事地图
User Story Mapping是敏捷需求规划中的一个流行方法
将PB变成一张二维地图,而不是传统的简单列表
1||| Activities用户行为
2||| Tasks用户任务
3||| Sub-Tasks
从上往下,按照重要性或者优先级排序
然后,按照团队开发的速率或其他业务要求,划分不同的发布计划
任务在故事地图中从左向右被组织成为叙述流
团队组成
PO
4~7开发人员
SM
敏捷会议
一、 发布计划会议
Release Planning Meeting,该会议是可选的
项目开始的时候没有这个会议,那么这些工件的缺少将成为一个需要被移除的障碍,解决这个障碍便成为了产品Backlog中的一个条目
确定发布目标、具有最高优先级的产品Backlog条目、重大风险和发布所包含的全部特性和功能
发布计划会议通常不超过组织构建传统发布计划的15-20%时间
确立大致交付日期和费用,估算时采用的是故事点或理想人天
展望整个产品发布过程,促进更好地理解项目的可视化和可行性
促进更好地理解项目的可视化和可行性
概述风险评估和缓解风险
解决进度风险的敏捷项目管理技巧
团队参与计划和估算
尽早获得有关交付速度的反馈信息
不断施加压力以平衡有容量限制的特性の数量和深度
工程团队和客户团队之间密切交流
尽早检测或纠正错误,保持工作产品无缺陷
软件项目中的5个关键风险和解决方案
1. 进度计划固有的缺陷
高层和产品、工程团队对探索阶段涉及的内容的期望合理化
2. 需求膨胀(蔓延)
避免客户或者开发人员随意添加功能
3. 员工流动
交叉培训和文档
结对编程,以在团队内更好地共享知识
4. 技术规范的分解
增加产品经理,其负责就业务流程或规则问题达成一致
团队和PO创建一个可行的技术规范决策流程
5. 生产率低下
找到合适的人员
指导和团队开发
强迫接受项目现实
使用短期迭代
增强团队排列能力和故事优先级的能力
让团队对项目有一个整体的感觉
勾画出产品多个版本的演变,包括业务领域和需要实施的能力,需要几个团队,历时2~3年
回答管理层有关价值、进度和成本的问题
创建一个让管理层和团队都感到舒适的项目状态
创建一份部分部署的计划
1. 业务领域 - 能力 - 特性 - 故事
2. 平台 - 小组 - 组件 - 功能
二、 Sprint计划会议
Sprint开始于计划会议
1个月的冲刺,时长最多8小时(4小时选择故事 + 4小时估算分配)
输入
划分优先级后的PB及其评估
产品介绍
项目团队的速度
迭代开始和结束日期
(发布计划)
会议内容
PO介绍高优先级PB,团队有信心则移入SB
ST团队共同制订要给Sprint Goal
开发者创建符合DoD的增量,通常是将PB条目分解为1天或更小的条目
输出
迭代计划
Sprint Backlog
Sprint Goal + 挑选出的PB条目 + 如何交付的计划
假设
风险
行动
沟通
依赖
参加者:
PO或客户
SM + 开发人员
(项目团队领导/利益相关人)
三、 需求梳理会议
四、 代办事项梳理
目的:
重新估算用户故事(故事点)
增加新用户故事,并估算它
丢弃不相关的故事
对用户故事进行优先级重新排序
将Epic分解为更小的用户故事
Scrum团队经常会面,进行代办事项的梳理或细分
五、 冲刺评审会议
1个月的迭代为4个小时的时间盒会议
开发团队将可交付物开发特性演示给干系人和项目发起人
六、 Sprint 回顾会议
长度一般为3小时
在Sprint评审会议结束之后和下个Sprint计划会议之前
SM鼓励团队对整个迭代中的人、关系、过程和工具顺利、障碍改进
组织层面如何实施敏捷?
组织敏捷性的标志
需求产生时创建新能力的意愿和能力
激励变革的主要因素
加速交付的考验
敏捷方法的应用
组织的变革就绪特征
管理层的意愿
组织改变的意愿
项目、项目集管理职能
专注于短期预算和指标
人才管理成熟度和能力
组织文化
针对分布式团队
首先考虑文化的差异性
也要考虑沟通的多样性
采购合同
组织结构的影响
敏捷PMO
价值驱动型
面向创新型
多学科型
组建大型敏捷团队
组织设计
几个特性团队
一个产品团队
一个架构团队
一个敏捷卓越中心团队
项目领导团队
决策设计
协作/协调设计
应用敏捷原则
知识共享和文档
文档应尽可能非正式
白板
自组织
自律
敏捷方法
是创造并响应计划,从而在动荡的商业环境中创造利润的能力
预见(早期计划)
适应(基于反应做出修正)
太过强调适应将导致返工和时间的拖延
既做计划又做扫描(展望未来以尽快学习未知的东西)
1. 试验模拟
2. 管理风险
3. 监督假设
4. 预见决策
是平衡灵活性和稳定性的能力
敏捷价值观的基本来源
相互依赖声明
1. 通过关注价值的持续流动,来提高投资回报
消耗的成本(资金流出)
产生的价值(资金流入)
时间(流入和流出的时机)
2. 通过让客户参与频繁互动和共享所有权,来交付可靠的结果
3. 通过迭代、预见和适应,来尊重和管理不确定性
4. 通过承认个体是价值的最终来源,并创造使他们有所作为的环境来持续激发创造力和创新力
5. 通过对结果的集体负责制和对团队有效性的责任共担,来促进团队绩效
6. 通过因地制宜的具体策略、流程和实践,来提升有效性和可靠性
敏捷宣言
4大价值观
i. 个体及互动高于流程和工具
ii. 工作的软件高于详尽的文档
iii. 客户合作高于合同谈判
iv. 响应变化高于遵循计划
12大原则
1. 最高目标:通过尽早持续交付有价值的软件来满足客户需求
2. 敏捷欢迎需求变更,并利用其为客户获得竞争优势
3. 经常交付可用的软件,周期越短越好
4. 业务人员与Dev必须通力协作
5. 善于激励项目人员,给与支持和信任
6. 信息传达最有效的方式是面对面的交谈
7. 可用的软件是衡量进度的首要标准
8. 提倡可持续的开发
9. 对技术的精益求精及对设计的不断完善将提高敏捷性
10. 简洁
11. 最佳的架构、需求和设计出自自组织团队
12. 团队要定期反省并响应地调整