敏捷管理有以下几个领域

1. 敏捷原则和理念 Agile Principles and Mindset
2. 价值驱动交付 Value Driven Delivery
3. 干系人参与 Stakeholder Engagement
4. 团队绩效 Team Performance
5. 适应性计划 Adaptive Planning
6. 问题探测与解决 Problem Detection and Resolve
7. 持续改进 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 可测试的：验收标准可测试

用户故事分层

用户故事地图 

用户故事大小

 计划会议---规划会议

1. 确认做什么：团队承诺完成什么
2. 确认怎么做：拆分用户故事（两周迭代：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

标签：故事,迭代,---,ACP,交付,敏捷,团队,PO
来源： https://blog.csdn.net/wlhjkl/article/details/120809933