产品负责人 开发团队
√ √ √ √ √ × × × × × × × × √
√*
× × × × × √* √ √ √ √ √* √ √ √
有授权
PwC | page 19
敏捷团队角色及职责
开发团队
拥抱“全部成功或者全部失败” 每个加入团队的成员都有一个角色（开发、测 试、架构等），所有人）
PwC | page 20
敏捷教练
PwC | page 15
敏捷团队角色及职责
Scrum Master
促进团队互动（团队，产品负责人和利益相关者） 消除障碍 主导会议 代表团队对交付日期和预算的承诺 促进敏捷价值观，原则和最佳做法 不是决策者，不分配任务 仆人领袖
PwC | page 16
敏捷团队角色及职责
作为一个…手机银行的用户 我想要…查看我的账户信息 所以…我可以了解我的账户活动情况
验收标准:
给定……我已经登录系统 当……我选择在我的手机银行账户查看账 户信息时 然后……我能根据所选择的账户（账户名 称、投资理财方案、外汇购买等）查看账 户细节
PwC | page 9
故事大小——运用分数进行估计
PwC | page 11
我们怎么追踪进度？——看板
看板是一个“拉拽”的系统，通过优化“系统”中的工作流程，提供重点，可持续发展和频繁交付
为什么使用看板？ • 看板促进流动的概念，以持续为客户/最终用户提供价 值 • 通过可视化工作流程，我们可以为每个人都看到任务， 活动和瓶颈 • 正在进行中的工作（WIP）确保我们专注于提高质量， 增加对任务的关注，并确保我们停止启动并开始整理
3. 敏捷团队架构
敏捷团队构建
为了扩展和拥有多个团队，我们应该考虑关于构建团队和开发用户故事的指导原则
产品代办列表
迭代代办列表
迭代代办列表
迭代代办列表
迭代代办列表
敏捷交付团队A (9)
(专用)
产品负责人(1) Scrum Master (1) 分析 (1) 开发 (3) 测试 (2) 方案架构师* PwC | page 22 速度: X
角色与职责 – Team (团队)
• 以迭代的方式，增量地交付可工作的软件，保证交付的质量 • 积极响应来自PO的高优先级业务和变化 • 协助PO维护产品特性清单，细化需求和验收测试场景 • 进行工作量的估算 • 基于最新的产品特性清单和优先级，考虑团队实际产能，合理得做出迭代交 付承诺 • 在迭代中进行自我管理，全力以赴地完成承诺的内容，达到 DoD 标准 • 在迭代结束，将完成的成果向PO进行演示，获得反馈 • 自我回顾，提高技能，积极寻求更有效的交付实践，持续提高团队产能
• 遵守和维护团队纪律
18
敏捷团队角色及职责
产品负责人（Product Owner）
产品负责人通常是系统的主要用 户，或者是对用户、业务以及当 前开发的系统或系统类型的未来 趋势有深入了解的任何人。
职责
最大化投资回报率 明确工作边界以满足业务的优先级 定义早期版本 - 如MVP 与stakeholders沟通 根据功能/可交付水平对backlog定义优先级 决定“ 候选的用户故事” 的工作 收集/理解非功能性工作 将阶段/用户故事切片为可开发的大小 准备好用户故事到可以开发的程度 在开发过程中与团队合作 验证/接受团队完成的工作 参与计划会议 参与每日站会 参与迭代回顾会
大型组织实施不同框架（或者不同框架的不同部分）的组合，以实现企业级别的敏捷
* 敏捷原则同样适用于产品和项目管理PwC | pae 5Scrum工作机制
PwC | page 6
每个Sprint的活动
Sprint 计划会议
Sprint Demo
Backlog 梳理会议 Sprint 回顾会议
1
2
3
产品负责人(1)
Scrum Master (1) 分析 (1) 开发 (3)
测试 (2)
方案架构师*
速度: Z 速度: K
基于特征的团队优势
优势 描述
增加价值吞吐量
增加学习 简化规划 减少切换浪费 少等待 自我管理；提高成本 和效率 更好的代码/设计质 量 更好的动机 简单的界面和模块协 调 变化更容易 PwC | page 23

敏捷团队培训
Strictly Private and Confidential for the sole benefit and use of PwC’s client September 2017
敏捷实施项目
议程
1 2 3 敏捷工作机制 敏捷团队角色及职责 敏捷团结架构
PwC | page 2
•
•
选择一个中等故事， 给出5分
评估与此相关的其他故事：与此相关的其他故事 一半大 两倍大
•
大一点
使用下面范围的值
用户故事, 接近Sprint
阶段用户故事– 几个Sprint之后
0
.5
1
2
3
5
8
13
20
40
100
∞
PwC | page 10
估分流程
This loop only takes 15 minutes This loop only takes 35 minutes
主要原则： • • • • • • 可视化工作 限制正在进行的工作（WIP） 管理流程 明确制定流程政策 实施反馈回路 协同改进，实验演变
PwC | page 12
2. 敏捷团队角色及职责
敏捷团队角色
角色

职责
设定产品愿景和业务重点 确保工作优先级在backlog中体现 参与需求预估 引出并充分记录功能和非功能性需求 代表开发团队和业务交流，代表业务和开发团队交流 促进团队的协作
开发
测试 方案架构师
在业务和IT领域之间的沟通，以支持架构师和指导技术 协助规划和估计活动 确保应用程序/技术与路线图一致 协调敏捷团队内部和整个敏捷团队的开发人员和测试人员 向团队提供技术专长 协调环境，代码升级和环境刷新 技术负责人应该是开发组长
技术负责人
PwC | page 14
专注于应对不断变化的 客户需求。 与Scrum相 比，XP团队的工作时间 通常较短
使所有关键利益相关者 定期合作，提供高品质 的工作，提高可见度和 适应性
不是过程框架，而是通 过增量改进来改变的一 种模型。 结构比Scrum 少
精益消除非增值活动， 增加客户价值。 FDD是 一个模型驱动的短迭代 过程
保护团队不受干扰，并消除团队进步的障碍 推动团队不断改进 软件开发，代码交付 对需求提出开发层面的专业建议，并对未来的设计架构提出 建议 项目交付质量保证 记录缺陷 测试用例和测试数据 确保应用程序套件内的开发流程 负责在开发过程中保持对质量控制的纪律 负责确保NFR测试 开发与测试协调 保护开发团队不受干扰 审查代码以确保符合解决方案架构师的标准
专注于提供客户或市场价值最多的产品
个人和团队学习由于更广泛的责任而增加，并且由于与各方面专家的同事共处 - 对长期改进和加速至关重要;减 少未充分利用的人的浪费 通过向团队提供一个全面的功能，组织和规划变得更加容易 - 例如，不再需要在单一专业功能和组件团队之间 进行协调 由于整个功能团队全部工作（分析，设计，代码，测试），切换显着减少 更快的周期时间 - 减少了等待的浪费，因为切换被消除，并且因为完成客户功能不必等待多方，每个人都在连 续地进行部分工作 Scrum团队不需要项目经理或矩阵管理功能交付，因为协调是微不足道的。团队负责端到端的完成，并与他人 协调工作。数据显示管理人员与发展生产力之间存在负相关关系，而且内部和外部焦点的团队更有可能成功 在共享组件上工作的多个功能团队产生压力，以保持代码清洁，格式化为标准，不断重构，并被许多单元测试 包围，否则将无法使用。另一方面，由于熟悉程度很长，组件团队只能使用混淆代码才能理解 研究表明，如果一个团队觉得他们对一个工作项目有完整的端到端的责任，而当目标是以客户为导向的话，那 么有更高的动机和工作满意度是生产率和成功的重要因素。 一个人或团队更新接口的两侧（主叫和被叫），并更新所有模块中的代码;因为功能团队在所有组件上工作;不需 要团队间协调。
4
5
6
7
8
9
10
每日站会
PwC | page 7
Sprint 会议安排
事件
频率 时间
迭代计划会
每个迭代1次 120分钟 • 确定在即将到来 的冲刺中可以交 付哪些用户故事 • 创建冲刺待办事 项（从产品待办 事项中来的用户 故事） • 将用户故事分解 成任务（“如 何”），并包括 时间预估和人员 分配
产出
产品backlog 产品级别的需求和优先级 用户故事grooming 需求文档 和SME(Subject Matter Experts)互动 用户故事验收标准
产品负责人
Scrum Master
促进团队互动 消除障碍 开展会议 参与需求预估 帮助需出要求并定义最佳设计 提供业务的功能和非功能性要求，同时遵守编码标准 开发单元测试和重构代码 帮助定义需求并协助估算 定义测试用例，脚本和步骤，以完全测试根据需求交付的软件 定义和准备测试数据，进行手动和自动测试 与团队沟通，提供诚实的反馈
敏捷
Extreme Programming 极限编程 (XP)(XP)
Scrum Scrum
Kanban Kanban
敏捷统一流程 (AUP) (AUP) 一个由7个重要原则组 成的迭代增量过程，重 点在于每个步骤中较长 的生命周期和迭代
Agile Unified Process
Lean, FDD, DSDM, 精益 , FDD, TDD,etc. etc