敏捷管理有以下几个领域
- 敏捷原则和理念 Agile Principles and Mindset
- 价值驱动交付 Value Driven Delivery
- 干系人参与 Stakeholder Engagement
- 团队绩效 Team Performance
- 适应性计划 Adaptive Planning
- 问题探测与解决 Problem Detection and Resolve
- 持续改进 Continuous Improvement
ACP考试建议
TKSC Topic：读懂题 Key：迅速找到考点 Source；准确找到出处 Chose：找到合适的
逃离陷阱：冷静、沉稳、能屈能伸、懂得放弃、贪多嚼不烂
敏捷宣言
左侧更为重视，右侧不需要忽视，适当进行
敏捷原则
自组织是后期表现，能团队自己解决的时候，尽可能不去寻求外部支持
敏捷最常用框架：SCRUM
3个角色
1）产品负责人(ProductOwner PO)：
- 客户/业务代表
- 定义所有产品功能：必须参与所有的产品梳理会，如果不能参与，需要调整时间，如果PO仍旧没有时间，需要找他的全权代理人（Backup）参加，如果还不行，那必须更换PO
- 决定产品发布的内容及日期
- 对产品的投入产出负责
- 根据市场变化对需要开发的功能排列优先顺序：只听PO的
- 合理的调整产品功能和迭代顺序
- 认同或者拒绝迭代的交付
- 确保开发团队知道产品待办事项列表
2）Scrum Master(SM)：
- 项目早期SM和PM相对统一（制定规则、管理期望、管理干系人、制定沟通策略、管理承诺等）
- 项目执行起来则SM和PM进行切割（不做决策）
- 鼓励言论*
- 保证仪式的完整性
- 团队有问题，优先内部讨论解决
- 保护团体一个整体
3）开发团队(Dev Team):
- 自主选择：自主决策问题解决的方式方法
- 全职能：技能复制，团队成员技能能力差不太多
- 全职：全勤投入到团队工作中
- 跨团队本身不进行解决：去中心化，高级带低级，提升技能，但并不分配任务
- 决策在团队内
- 平级
3个工件：
1）产品待办事项列表 Product Backlog---排了序的需求池
- 产品需求的列表
- 包含业务需求、技术需求、NFR非功能性需求（技术优化、合规需求）等
- 理想情况下，每一个待完成的工作都将对客户产生价值
- PO对该列表进行优先级排序
- 每个迭代开始前，优先级排序还需要再修正
- 待办事项列表中的条目以用户故事的形式呈现
遵循DEEP模型：
- Detaild---适当的详细程度
- Estimated---被估算的：PO & SM 预先估算
- Emergent---涌现的
- Prioritized---排了优先级的
2）迭代待办事项列表 Sprint Backlog---迭代完成的需求列表
- Product Backlog的子集，只记录当前迭代的工作
- 将用户故事拆分成任务，团队成员主动领取任务
- 团队成员有共同的迭代目标，未交付可工作的成果而努力
- 团队成员可以添加、删减或者更改迭代中的任务
- 迭代列表中的任务进行了估算，剩余工作量的估计每天需要更新
DOD（Definition Of Done完成的定义）
核心就是做到什么样就是完成了
可以通过流程或者本身交付物来进行限定
3）产品增量 Product Increment---交付物
- 团队在迭代内完成交付成果，集成到以往的迭代成果中，形成增量式的交付
- 每次交付的用户故事必须符合验收条件
- 每次交付的增量成果必须处于可用状态，而不管PO是否决定发布这个用户故事（交付和上线）
5个活动（仪式）
时间箱
固定时间、固定活动
优势：专注、增加创造力、时间的价值实现程度、可用时间比较多
待办事项梳理会（DEEP）
- 增删改查用户故事
- 估算规模
- 故事优先级排序
- 拆解用户故事
- 可以邀请利益相关者来进行参与和评审
- 可以有技术相关的讨论
用户故事
As a【User Role】，作为【用户角色】
I want 【Activities】，我想要【活动】
So that 【Reason/Value】以便【原因/价值】
3C Card卡片 Conversation 交谈（语言要一致）， Confirmation 确认
Acceptance Criteria
- Given（在什么样的情景或条件下）
- When（做了什么操作，采取了什么行动）
- The（得到了什么结果）
遵循INVEST原则
- Independent 独立的：可独立交付
- Negotiatable 可协商的：可以沟通协商
- Valuable 有价值的
- Estimable 可估算的
- Small 小的：适当大小
- Testable 可测试的：验收标准可测试
用户故事分层
用户故事地图
用户故事大小
计划会议---规划会议
- 确认做什么：团队承诺完成什么
- 确认怎么做：拆分用户故事（两周迭代：2小时选择故事，2小时估算分配；1个月的迭代：两周迭代的加倍）
燃尽图
计划会之后画出来，否则就证明计划会没有开成功
站会
鸡和猪都可以参加，但是只有猪可以说话
这个活动是用来做每日承诺的，而不是讨论会议。
评审会议
和外部交互的会议：邀请外部相关方参与
原则上是计划会议时间的一半（2小时---两周迭代 or 4小时---月迭代）
这个活动输出的是一份修订的产品待办事项列表
这个活动在迭代最后倒数第二个去执行
这是为了和利益相关方的步调一致
回顾会
除站会外时间最短的活动（一般双周迭代40分钟）
这个活动在迭代最后执行
这个活动的参与者：开发团队、PO、SM，企业利益相关者整个团队
建议：只有开发人员参与，PO可选，其他人不要参加
5个价值观
公开化，透明化，人尽皆知
敏捷实践之精益、极限编程
看板
区分：看板和Kanban系统
这是用来进行透明的，管理干系人的希望有促进
燃尽图、燃起图、看板或任务板、风险看板等
KANBAN
重点关注：KANBAN没有时间箱的概念。
- 工作流程可视化
- 限制在制品
- 度量和管理流动（Scrum故事点的估算，看板依赖数据）
- 显示化规则
- 建立反馈环路
- 在协作及试验中改进
极限编程
重点实践：
持续集成
TDD
结对编程：老带新，技能复制（一件事情两个人做）
代码集体所有权
小型发布
CI的工作流程
- 提交代码到代码库
- CI server监听代码库的变更
- CI server触发自动化构建
- CI server触发自动化测试
- 通知相关方
累计流图：
度量整体状态
利特尔法则
Little‘s Law & Cumulative Flow