导图社区 ACP敏捷
- 39
- 0
- 0
- 举报
ACP敏捷
这是一篇关于ACP敏捷思维导图，总结了以价为驱动交付工作、千系人参与、团队绩效、适应性计划等。
编辑于2024-01-09 15:54:08- 敏捷
- 相似推荐
- 大纲
ACP敏捷
1. 敏捷原则与思维模式
敏捷是什么？
敏捷宣言：
p
1. 个体互动 胜过 流程工具
右项也有价值，但是左项价值更大
2. 可工作的软件 胜过 面面俱到的文档
3. 客户合作 胜过 合同谈判
4. 响应变化 胜过 遵循计划
以人为本，适应变化
敏捷12原则：
1. 目的：我们最高的目标是通过尽早和持续地交付有价值的软件来满足客户
尽快交付
2. 态度：即使在项目开发后期，仍然欢迎对需求提出变更。敏捷通过拥抱变化，帮助客户创造竞争优势
拥抱变化
3. 关注：要不断交付可用的软件，周期从几周到几月不等，且越短越好。
持续交付
4. 合作：在项目过程中，业务人员与开发人员要每天一起工作
集中办公
5. 核心：要善于激励项目人员，给他们所需要的环境支持，并相信他们能够完成任务
正向激励
6. 沟通：团队内部和各团队之间，最有效的沟通的方式是面对面沟通
面对面沟通
7. 标准：可工作的软件是衡量进度的首要指标
成果衡量进度
8. 倡导：敏捷过程提倡可持续开发。项目方、开发人员和用户应该能够保持恒久、稳定的进展速度
可持续作业
9. 追求：对技术卓越和好的设计的持续关注有助于增强敏捷性
持续改进
10. 根本：尽量做到简洁，尽最大可能减少不必要的工作，这是一门艺术。
极简工作
11. 团队：最佳的架构、需求和设计自组织团队
自组织团队
12. 调整：团队要定期回顾和反省如何能够做到更有效，并相应调整团队行为
定期总结
敏捷阶段：
构想：确定产品构想，项目范围，项目团队以及团队共同工作的方式。
立项
推测：制定基于功能的发布计划，里程碑和迭代计划，确保交付产品构想的产品。
计划
探索：在短期内提供经过测试的功能，不断致力于减少项目风险和不确定性。
设计
适应：审核提交的结果，当前情况以及团队绩效，必要时做出调整。
迭代
结束：终止项目。交流主要学习成果并庆祝。
收尾
2. 以价值为驱动交付工作
概念：敏捷的主题就是最大价值交付，风险等于反价值，最大价值化必须最小风险化。
评估价值：
投资回报率（ROI）
利润/投资额
越大越好
内部收益率（IRR）
项目内部为收回投资每年的净收益率
越大越好
净现值（NPV）
收入现值-支出现值
越大越好
投资回收期
越小越好
规划价值
项目章程
承认项目合法性，认可其价值
价值流图
流程中，每一步骤的价值量化
价值优先级
简单模式
P1
P2
P3
MoSCow
M-must have：必须有
S-should have：应该有
C-could have：可能有
W-won't have this time：希望有，但不是现在
虚拟价值
给项目发起人虚拟货币，要求将货币进行分配。
100点法：
每个干系人100点，进行投票。
卡诺分析（Kano）：
p
魅力属性：给的多，满意高
期望属性：持续给，持续高
反向属性：给的多，满意低
无关紧要属性：给的多，难满意
产品路线图
风险调整待办事项
风险管理
规划风险管理
识别风险
实施风险定性分析
实施风险定量分析
控制风险
规划风险应对
风险-价值矩阵（风险处理顺序）：
高风险，高价值：优先处理
低风险，高价值：其次处理
低风险，低价值，最后处理
高风险，低价值，不予处理
风险Spike（刺探）
技术预研
敏捷合同：
金钱无用
当待办事项中已经没有充足的投资回报率来保证未来迭代时，就尽早终止项目。
自由变更
PO可以在每个迭代结束重新调整待办事项的优先级，如果总的合同工作没有改变，那么变更就是免费的。
七大浪费：
部分完成工作
额外的流程
额外的属性
任务切换
等待
移动
缺陷
交付价值
任务和看板面板
数据预测准确性增加
干系人交互障碍
限制WIP（在制品）
限制数量
限制大小
追踪和报告价值：
挣值管理：
完工预算（BAC）
实际成本（AC）
挣值（EV）
计划价值（PV）
成本偏差（CV=EV-AC）
进度偏差（SV=EV-PV）
成本绩效指数(CPI=EV/AC)
进度绩效指数（SPI=EV/PV）
燃尽图
燃起图
累计流量图（CFD）
p
累计流量图对于追踪和预测敏捷项目。
约束和瓶颈
风险燃尽图：
风险严重等级=风险发生的概率 x 风险的影响
项目愿景
愿景作用
指明方向
明确方向
激发潜力
评判标准
构建愿景
确定目标
创建初稿
确定愿景
发布愿景
愿景原则：
共享愿景
全员参与
简短清晰
基本产品
简介明了
避免愿景笼统
避免过多细节
商业论证
作用
向客户/高层证明
判断继续/终止
衡量项目成功
内容
商业需求
成本效益分析
有利于企业
合理性
确定宏观的边界
已知风险
3. 干系人参与
哪些是干系人：
高管及项目发起人
管理者
项目团队
用户
供应商
其实，项目中自认为是项目干系的，那就是干系人。
识别干系人
线框图
用户故事：
三要素：
角色、目标、可达到的商业价值
作为一名<角色>，我想<功能or目标>，这样就可以<商业价值\益处>
3C
Card：
故事写在卡片上，起到交流提示的作用。
Conversation（会话）：
故事中的细节需要通用户协商确当。
Confirmation (证实)：
故事包含验收标准和环节，以确保背正确实现。
INVEST
Independent 独立的
Negotiable 可协商的
Valueable 有价值的
Estimate 可估算的
Small 小的
Testavle 可测试的
颗粒度：
史诗
基于产品的长期战略方向而被提出，颗粒度级别最大，通常为可独立使用的一个产品模块
特性
作为某个史诗的子需求（比史诗更具象）和若干个用户故事的集合，承上启下，需要多轮迭代才能完成交付
用户故事
从用户的角度来描述用户渴望被满足的需求，颗粒度级别最小，且能在一个迭代中开发完成
任务
需求是用户维度，任务是开发维度。需求是一个完整的用户故事，具有独立性的功能，可测试可交付。任务是在需求下拆分的具体任务，比如一个需求分成前台开发任务和后台开发任务，两个任务共同完成需求才可交付。需求有父子需求多层级展示，需求分类树形展示，自定义工作流状态，流转权限控制，需求统计等。而任务没有这些功能
干系人分析
用户故事地图
p
客户价值优先级排序工具，提供了一个关于功能何时交付的产品路线图。
解决了
大量文档难以维护
跳跳框框的东西非常耗费资源
不足：
只见树木，不见森林
大项目排序困难
不能显示聚焦
不能方便了解功能的完整性
不能方便了解工作量，价值流
不能方便递增、迭代、确定发布计划
干系人价值排序
把发起人和用户的优先级纳入到项目的优先级中并执行，结合干系人的优先级来进行项目优先级排序，让干系人价值具体化，确保不要做一些干系人不支持或没有价值的功能。
干系人管理
沟通方法
面对面沟通
信息发射源
图标、可视化信息
燃尽图/燃起图
速度
速度是每个迭代中对团队能力的度量。这个度量帮助我们就一个迭代完成的故事点数评估后续的工作能力。
这里速度是指：这个团队的工作速度快不快，是一个量词
敏捷建模
用例图形
数据模型
屏幕设计
原型
频繁讨论“完成”
对每个阶段的完成去定义：
已测试
所有单元测试，已完成。
集成测试，已完成
用户测试，已完成
此处类似DOD，但是DOD通常表示团队内部对完成的定义
DOD（定义完成）
好处
共同协商，自我承诺
清晰交流，低技术债务风险
保持专注，消除臆测
关键点
团队自协商
有层次
任务、story、sprint、发布都要达到标准
制定过程
头脑风暴
分类
排序整合
生产DOD
DOD与AC区别
AC是针对每个需求定义的，DOD是针对任务、story、sprint。AC更微观7
软技能
授权
谈判
冲突解决
p
第一级：解决问题
第二级：争论
第三级：竞赛
第四级：战斗
第五级：世界大战
PMP中冲突的解决办法：
p
合作/解决问题
协调不同意见，达成共识（开会）
强制/命令
PM使用权力指导解决方案（尽量不用，除非紧急时候）
妥协/调解
为了暂时或部分解决冲突，寻找能让各方在一定程度上的满意方案
缓和/包容
强调一致而非差异（求同存异）
撤退/回避
从实际或者潜在冲突中退出，将问题推迟到准备充分的时候，或推给其他人
积极聆听
内容聆听
专注聆听
全局聆听
参与式决策
简单投票
拇指法则
决策光谱
Fist-of-Five
一个指头，完全支持
两个指头，支持观点
三个指头，我有观点
四个指头，反对观点
五个指头，立即停止
有效领导：
服务型领导
保护
保障
保持
保姆
分布式团队
解决知识共享问题
解决时差问题
解决文化认同问题
4. 团队绩效
理解团队绩效
塔克曼模型：
形成
震荡
规范
成熟
解散
情商：
自我觉知
自我调控
自我激励
识别他人情绪
处理人际关系
组建高效团队
敏捷型人才
T型人才。
自组织
团队内的事宜可以由团队自行决定。
步骤：
氛围：团队成员可以在个人层面上了解他人以此营造社区氛围
反馈：提供反馈指导，肯定和感谢团队成员工作，为团队成员的能力提升提供指导训练
授权：授权团队成员做关键决策，信任团队能力。
打造高效团队
每日站会
教练
头脑风暴
安静书写
循环法
每个人轮流阐述自己的想法，允许在他人的想法上改进更新自己的想法。
自由讨论
作战室
利：
渗透式沟通
弊：
缺少私有空间
潜规则知识
管理分布式团队
知识共享
如果跨时区，跨国际，首要解决的是文化
敏捷工具：
低科技，高接触工具
数据化工具
WIKI
5. 适应性计划
敏捷计划概述：
追求真实，重复初始计划
敏捷计划贯穿整个项目，不仅仅是前期工作
敏捷是移动打靶，需要及时调整中期计划
敏捷计划的层次
敏捷愿景
what：这个项目是什么？（项目愿景，任务，目的、目标的高层级描述）
why：为什么要这么做（商业论证）
when：什么时候开始？什么时候结束（项目开始日期和结束日期）
who：那些人需要参与项目？（干系人列表）
where：产品应用在哪里？（产品应用场景和部署要求）
How：如何进行开发？（对方法的描述）
注意：how不是如何开发，是如何进行开发。
产品路线图
p
特性优先级排序、特性归类、和粗略的时间框架确定工具
类似里程碑计划
故事地图，也属于产品路线图。
发布计划
迭代计划
每日站会计划
敏捷计划的工具
时间盒
即：时间约束，如：计划会：8小时，每日站会15分钟，评审会4小时，回顾会3小时，
渐进明细
滚动规划技术
最小可售功能(MMF)
最小可行功能（MVP）
基于价值分析
基于价值的分解与排序
敏捷游戏：
修剪产品树
记住未来
快船
效益成本比
买功能
都是为了找需求，挖掘需求，确认需求
敏捷估算
估算方法
宽带德尔菲
匿名投票
避免光环效应
计划扑克牌
耗时长
亲和估算
就是类比，锚定价值，进行对比然后扩大或缩小，使用T-shirt算法
大型产品待办列表
估算单位
故事点数
理想时长
估算步骤：
第一步：使用估算点或理想时长来确定项目规模。
第二步：通过确定团队的有效性和生产力，使用小时或人天为单位来计算工作量。
第三步：在考虑团队规模、所需资源以及依赖的情况下，将工作量转换成时间计划。
第四步：通过计算劳动力价格并添加其他项目费用的方法来计算项目费用。
6. 发现与解决问题
问题概述：
收集问题、分析问题、解决问题
发现问题
每日站会
回答问题，来发现问题。
循环时间
一项工作从开始到完成的实际差就是他的循环时间。一个项目的循环时间是偶有的工作项目循环的平均值。
限制WIP
循环时间=在制品数量/团队吞吐量
平均任务工时，监控这个值来发现问题
故障泄露
根据已发现故障泄露的数量，来分析故障产生的原因。
质量标准
监控质量
趋势图
趋势预测
控制图
一个控制界限，一个规格界限，七点原则：连续七个点失控。
解决问题：
解决问题的方法
持续集成
减小颗粒度，快速发现问题
风险探测
小规模实验，探测风险
频繁确认与验证
测试驱动开发（TDD）
测试、编码、重构
验收测试驱动开发（ATDD）
探索性测试
解决问题的步骤：
收集数据
时间轴
三五成型
颜色标识
寻找优势
满意直方图
团队雷达
分析原因
头脑风暴
名义小组
五问法
连问五次为什么
鱼骨图
采取行动
简单主题
SMART目标
7. 持续改进（产品、流程、人员）
理解持续改进：
敏捷持续改进：
计划——开发——评估——学习
戴明环PDCA：
计划——执行——检查——行动
回顾类型：
改进生产力
改进能力
改进质量
改进技能
回顾步骤：
1. 预设会议基调
签到
ESVP（每个人匿名写下自己的身份）
Explors（探索者）
探索者渴望新的主意和灵感，他们想学会所有可以学到的。
Shoppers(采购者)
采购者会研究得到的信息，高新的把有用的新观点带回家。
Vacationers(度假者)
度假者对回顾会不感兴趣，他来参加会议，只是觉得日常工作无聊。
Prisoners(囚徒)
囚徒觉得是被迫来参加回顾会的，身不由己，不远参加。
2. 收集数据
3. 分析原因
4. 采取行动
5. 回顾收尾
8. 敏捷实践
精益（LEAN）
Eliminate Waste（消除浪费）
Build Quality In（嵌入质量）
Create Knowledge（创造知识）
Defer Commitment（延迟决策）
Deliver Fast（快速交付）
Respect People（尊重他人）
Optimize the Whole（整体优化）
看板（Kanban）
可视化
限制在制品（WIP）
管理流动
极限编程（XP）
价值观
沟通（Communication
简单（Simplicity）
反馈（Feedback）
勇气（Courage）
五个原则
快速反馈
简单性假设
逐步修改
提倡更改
优质工作
十三个最佳实践
1. 现场客户 ( On-site Customer )
2. 代码规范 ( Code Standards )
3. 每周40小时工作制 ( 40-hour Week )
4. 计划博弈 ( Planning Game )
5. 系统隐喻 ( System Metaphor )
6. 简单设计 ( Simple Design )
7. 测试驱动 ( Test-driven )
8. 代码重构 ( Refactoring )
9. 结对编程 ( Pair Programming )
10. 集体代码所有制（Collective Ownership）
11. 持续集成 ( Continuous Integration )
12. 小型发布 ( Small Release )
Scrum
三大支柱
透明
建立信息安全感，信息可视化透明化；对每个术语理解一致，对每个决策达成共识
检验
监控迭代进展，识别项目偏差；测试内建于开发；及时发现问题
适应
持续改进的基础，依据检验结果，调整团队行为，调整项目目标
迭代
原则：
迭代开发是有节奏的小步快跑，但建立在坚实的基础之上。
迭代过程中，迭代目标不变，质量目标不变
及时暴露问题，及时消除风险，及时反馈
谁参加：
SM，TEAM参加，PO不参加
何时：
迭代计划会之后开始
何地：
驻厂开发
输入：
迭代待办列表
输出：
潜在可交付产品交付增量（PSI）
3355：
三个角色：
PO
SM
Scrum Team
三个工件：
Product Backlog
Sprint Backlog
Increment
五个事件：
迭代
迭代计划会
每日站会
迭代评审会
迭代回顾会
五个价值观：
尊重
开放
勇气
承诺
专注
跨职能团队
动态系统开发（DSDM）
模型
前期阶段
功能模型
设计建造
实施
最后阶段
核心概念
活动用户参与
团队具备决定权
频繁发布
迭代开发
高层次定义
商业需求
集成测试
协作
20%-80%原则
水晶（Crystal）
七大特征
经常交付
反思改进
渗透式沟通
个人安全
焦点
与专家用户建立联系
自动化配置管理，经常集成
水晶矩阵
p
透明、黄色、橙色、红色
特性驱动（FDD）
5大过程：
开发整体模型
构建功能列表
计划功能开发
按照功能设计
按照功能构建
最佳实践
领域对象建模
按照特征开发
类（代码）拥有权
特征小组
审查
定期构建
配置管理
可视化进度报告
验收驱动测试
讨论、提取、开发，示范
9. 考试冲刺
1. 漏筛缺陷：是指测试没有发现，但被终端用户发现的缺陷
2. 保证团队、干系人、商业管理者协作的角色是SM，可以翻译成项目领导者、项目管理者、敏捷教练、敏捷项目经理，总的来说就是Scrum Master
3. WIDETOM可以用于记录不同种类的浪费
W - 等待 waiting
I - 库存 inventory
D - 缺陷 defect
E - 额外流程 extra processing
T - 运输 transportation
O - 过度生产 over-production
M - 动态 motion
4. 通常计划扑克的参照用户故事是中码或均码
5. 不知道的就选Scrum
6. 产品质量问题不由PO澄清，由团队澄清
错题整理
1. 文件
项目章程
包含：使命、前景、任命、成标标准
愿景说明书
包含：目标，愿景
故事地图
产品路线图
商业论证
包含：目标
2. 计划
复杂项目用“滚动计划”
只包含接下来几个迭代中需要完成的工作
发布计划
迭代计划
3. 沟通
集中办公
不能集中办公，可以使用内部网站
不能集中办公，可以使用远程视频会议。
渗透沟通
信息在互相搭配工作的团队成员之间无意识的进行共享。
积极倾听
4. 质量
敏捷中，质量标准是可裁剪的。
迭代中，质量是不能改变的。
5. 用户故事
1. 估算
计划扑克参照用户故事是：中码
小，中，大码是亲和估算，用于大型产品待办事项
宽带德尔菲，是会后的，总的来说还是将就匿名。
用户故事估算时，必须考虑复杂度、工作量、风险与依存关系。
当估算为0时，说明用最小的努力来设计、开发、测试。
2. 优先级
排优先级的原因
提供早期投资回报率
排优先级方法：
MoScow
Kano
3. 用户故事的起源是来自，XP极限编程
4. 用户故事最初定义是在迭代发布计划期间
5. 用户故事包含：书面描述、对话、测试标准
6. 用户故事的规则：角色、目标、可达到的商业价值
6. DOD
用户故事验收标准可以再迭代计划期间定义，只要是编码开始前定义就行，
用户故事验收标准记录在卡片背面。
7. 速度
速度不能用于跨团队进行比较。
ACP中，用速度表示一个团队在一次迭代中能完成的故事点数。
8. 冲突
冲突的定义是：解决团队成员之间的冲突
冲突鼓励自组织解决（即，自己解决），出现严重影响时，需要干预
冲突并不是所有冲突都是有害的。有效的冲突可以提升团队能力。
9. 每日站会
1. 遇到问题，会议之后单独安排会议解决，会议不讨论具体问题
2. 站会可以每日通报障碍
3. 站会帮助团队成员：识别障碍、感受同辈压力、专注焦点、密切配合
4. 站会三个问题：昨天完成了什么，今天要完成什么，遇到什么问题。
5. 站会不讨论细节问题
10. 信息发射源
1. 信息发射源不会提高开发组效率
11. 极限编程（XP）
代码完成后，应当马上迁入代码库，迁入代码库之后进行测试（集成测试）
结对编程
结对编程是提高写作的有效方法
12. Scrum
对于看不懂的，不知道的，就选Scrum
13. 图表
停车场图
停车场图是按主题进行分类管理，展示故事点完成百分百的进度图表。
风险燃尽图
记录随着时间风险严重情况的图表
WIP限制
已经完成了一个，就是限制减1
14. 授权团队
授权团队会进行自我决策以适应管理的复杂性，专注价值交付
团队做重复工作导致士气下降，可以让团队成员结对编程，互相学习，研究新技术
15. 其他
频繁进行验证，
不是因为需求频繁变化，而是因为增量交付（持续交付）所以要频繁验证
频繁验证有助于产品质量。
验证和确认的区别？
验证满足规格（注重过程）
烧热水洗澡，给个热得快
确认满足用途（注重结果）
其实我想要个热水器
敏捷是一种平衡灵活性 与 稳定性的能力。
产品负责人可以决定停止开发，既然已经对用户不重要，那就可以停止
中心主题
1. 敏捷原则与思维（9）
在项目团队和组织范围内探索、接受、应用敏捷原则和概念
1. 倡导敏捷的准则和价值观，在整个团队乃至客户与团队之间形成共同的理念。
2. 推动并确保每个人对敏捷价值观和原则达成共同理解，对敏捷实践和术语有共同认知，从而有效工作。
3. 通过对组织教育和对过程、人员和行为的影响，支持系统或组织层面的变更，从而让组织更高效。
4. 进行可视化管理，维护高度可视化的信息发射，显示团队真实的进展和绩效，从而增强透明度与信任度。
5. 营造一个安全、信任的团队氛围，允许每个人犯错，因为这样能够让他们从学习中不断改进工作方式。
6. 尝试新技术和新想法、探索更高效的工作方式，提高创新能力。
7. 通过协助共处鼓励团队成员分享知识、降低知识孤岛风险、并减少障碍。
8. 构件一个安全、尊重的环境，鼓励团队内部的自发领导，尝试工作方式的持续改进，培养自我组织和授权意识。
9. 践行服务（仆人）式领导，支持并鼓励团队的努力，让他们可以发挥最高水平并持续改进。
2. 价值驱动交付
通过优先级排序、增量交付和风险管理，使得商业价值最大化
1. 定义积极的正向价值
1. 定义可交付成果时，识别增量产出的内容，最大化对干系人的价值，减少非价值工作。
2. 针对功能的可接受标准达成共识，及时调整优化需求，从而交付价值
3. 根据项目和组织的特点及团队经验来进行过程定义，从而优化价值交付
2. 避免潜在负面影响
1. 规划小发布的增量交付计划，讲需求划分为MMF/MVP，尽早实现确认和交付价值
2. 限制增量交付的大小，增加干系人评审的频率，从而以最低的成本尽早识别和干预风险。
3. 持续评审增量交付，寻求客户的反馈，从而确认提高商业价值。
3. 定义优先级
1. 与干系人紧密协作，确定工作单元的优先级，从而最大化交付物的价值。
2. 频繁的评审和维护工作成果，品质为先，从而降低增量开发的总成本。
3. 持续识别和调整环境因素，经营因素和基础设置的优先级，以改进质量，提升交付的价值。
4. 增量式开发
1. 组织干系人进行运行评审和定期检查，从而获取对过程中和计划中的反馈及修正。
2. 将价值和风险均放入待办事项，兼顾可交付物的开发以及风险减少，最大化价值。
3. 定期更新需求的优先级，以响应环境和干系人的需求变化，从而实现价值的最大化。
4. 考虑应用环境，找出调整非功能性需求的优先顺序，从而将失败的可能性降到最低。
5. 通过检查、评审和测试，频繁的对工作产品进行评审，从而进行产品和过程的改进。
3. 干系人参与
理解干系人的期望，鼓励干系人的参与，保持干系人的信息畅通
1. 理解干系人需求
1. 识别并让授权的干系人参与定期评审，确保团队了解干系人的期望和需求。
2. 在项目实施中，通过尽早的、贯穿始终的知识分享，识别并让所有干系人（当前及未来的）参与，确保信息和价值流不受阻。
2. 确保干系人需求
1. 通过在关键干系人中形成一种工作协定去建立干系人关系，促进干系人参与和有效协作。
2. 持续评估项目和组织中的变化，持续适度的干系人联络，确保干系人能适当参与项目。
3. 通过培养团队决策和冲突解决的能力，在团队成员之间建立协作，从而提高决策的质量，减少决策时间。
3. 管理干系人期望
1. 通过发展高层次的愿景和一系列的目标。来建立多种项目增量（产品、交付物、发布、迭代）从而和干系人期望保持一致并建立信任。
2. 通过促进干系人之间的意识，来建议和维持对成果的标准、交付物、可接受折中等事项的共同理解，从而使期望保持一致并建立信任。
3. 通过对团队进度、工作质量、障碍和风险的沟通，让工作状态透明可见，从而有助于主要干系人做出有效决策。
4. 提供详略适当的决策，兼顾确定性和适应性，让干系人更有效的制定计划。
4. 提升团队绩效
组建团队，充分授权，团队承诺推动协作
1. 组件团队
1. 与团队成员一起制定规则和流程，从而培养团队凝聚力，加强团队对共同成果的承诺。
2. 组件拥有项目所需的基本人际关系和技术技能的团队，从而如期创造商业价值。
2. 团队授权
1. 鼓励团队成员成为通才专家，从而缩小瓶颈，打造高绩效的跨职能团队。
2. 授权团队并鼓励自发性领导，实现团队自组织，从而产生有效的解决方案并管理复杂性。
3. 持续挖掘团队和个人的激励因素及不满因素，确保团队在整个项目中奥驰高涨的时期和高效的产出。
3. 团队协作和承诺
1. 通过共同办公或使用协作工具，在团队内部及相应的外部关系人直接保持紧密沟通，减少误解和返工。
2. 减少干扰因素，创造可预测的产出，最大化交付价值。
3. 分享项目愿景，协调项目目标和团队目标、确保团队理解如何将个人目标融入整体目标。
4. 鼓励团队通过跟踪和测量之前迭代或者发布的实际表现来测量他们的速度，以便更好的了解他们的能力并进行更加准确的预测。
5. 适应性规则
进行估算，创建多层级计划，获取反馈，更新计划
1. 计划的层次
1. 在各个不同层面（战略、发布、迭代），每日进行详略适当的计划，采用滚动式计划和渐进明细的方法，兼顾产出可预测性以及开拓机会的能力。
2. 鼓励关键干系人参与计划，公布计划结果使计划活动公开化、透明化，从而增强团队的承诺，减少不确定性。
3. 项目实施期间，设立并管理干系人的期望，在各个层级做出相应承诺，确保大家对预期的可交付成果达成一致理解
2. 适应性
1. 定期回顾项目可交付成果的特点、大小、复杂度、重要性、根据回顾结果调整节奏和计划过程，最大化交付的价值
2. 根据团队学习、交付经验、干系人反馈、产品缺陷等情况，检查并调整项目计划，对应需求时间、预算、优先级等方面的变更，从而实现商业价值最大化。
3. 敏捷估算
1. 使用渐进明细的技术估算项目大小，不受团队速度和外部变量的约束。
2. 综合考虑运维需求和其他因素去调整生产能力，制定或更新估算区间。
3. 预计当前对项目所需投入的概略理解，制定一个初始范围，进度，成本估算区间。从而确定项目管理的起点。
4. 基于对项目所需投入的最新理解，调整范围、进度、成本区间，从而管理项目
5. 持续关注资源生产力，项目规模，速度指标等方面的变化，用这些数据来评估剩余的估算。
6. 问题探索与解决
通过回顾和实践，对于产品、过程和人进行各方面提升
1. 通过鼓励对话和实验去营造一个开放、安全的环境，将影响团队速度或妨碍交付价值的问题和阻碍展露无疑。
2. 在项目的各个节点上教育和鼓励团队参与，识别威胁和问题并在合适的时机解决。改进导致这些问题的生产过程。
3. 确保问题由合适的团队成员去解决，对于无法解决的问题，重新设定期望，从而最大化价值交付。
4. 维护一个课件的、实时检控的、按优先级排序的威胁和问题列表，加强责任意识，鼓励采取行动，跟踪责任人和解决状态。
5. 通过维护威胁列表将相关活动整合到工作待办事项当中，达到对威胁和问题状态的沟通，保持透明度。
7. 持续改进
鼓励团队进行整体统筹以及风险的解决
1. 通过定期评审和整合团队实践、组织文化及交付目标、制定和调整项目过程，确保在组织规划与标准的框架内实现团队效能
2. 经过进行回顾和改进试验，改善团队过程，进而不断增强团队、项目和组织的效能。
3. 通过增量交付和频繁演示，寻求反馈，从而交付产品价值。提供让成员提升技能的机会
4. 营造持续学习的环境，提供让成员提升技能的机会，从而打造一个通才型专家的富有成效的团队。
5. 审查当前的过程元素，进而价值流分析并消除浪费，提升个体效率和团队效能。
6. 在团队和组织之间传播知识和实践，推动系统改进，防止同类问题再次发生，提升组织整体效能。
中心主题
痛点1团队目标或任务不明确
敏捷章程中关于目标部分
愿景、使命 和使命测试
主题
主题