团队层介绍
详述
敏捷团队采用SAFe ScrumXP或团队看板，同时应用内建质量的实践，确保最终产品质量。每个团队有5～9名团队成员（ScrumXP），并包括所有必要的角色，确保在每一次迭代中构建一个高质量且有价值的发布增量。ScrumXP角色包括Scrum Master、产品负责人、全职工作的团队成员，以及其他能为团队创造价值的资源。团队应该完全有能力在每次迭代中定义、开发、测试和交付可以工作并经过测试的系统。
项目群增量和迭代
所有团队遵循相同的迭代起止日期和时间周期，也就是有相同的迭代和项目群增量（PI）边界，以便与ART上的其他团队保持同步和集成。每个PI都起始于团队的PI计划，他们构建团队的PI目标，再汇总成项目群的PI目标，这些目标有助于指导团队的迭代执行。
每个迭代提供有价值的新功能增量，迭代过程按照以下模式循环进行：迭代计划、承诺交付一些功能、通过构建和测试用户故事执行迭代、演示新功能、执行迭代回顾，在下一个迭代再重复进行这些活动。
每个PI的迭代数量
经验表明，PI持续时间一般是在8～12周的效果最好，并且倾向于最短的持续时间。
用户故事和团队待办事项列表
团队使用用户故事来交付价值，产品负责人负责用户故事的创建和接收。用户故事承载客户的需求，通过价值流进入到实现阶段。团队待办事项列表由用户故事和使能故事组成，其中大部分故事是在PI计划中，当产品经理向团队展示愿景、路线图和项目群待办事项列表时进行确定的。在团队层基本的需求管理流程是：用户故事的识别、排序、排期、细化、实施、测试和接收。
敏捷团队
SAFe敏捷团队是一个跨职能小组，他们有能力和权力来定义、构建和测试解决方案价值，所有的这些活动都在一个短迭代的时间盒内完成。
敏捷团队是由专职成员组成的一个小团队（在Scrum中是5～9人），他们具有一些必备技能，可以在短时间盒内定义（细化和设计他们的组件/特性）、构建（实现这些组件/特性）以及测试（运行测试用例并验证组件/特性）价值增量。
角色和责任
价值的交付：
● 团队负责管理自己的工作。
● 团队估算工作的大小和复杂度。
● 团队在架构指导下根据所关注领域决定技术设计。
● 团队承诺在迭代或项目群增量时间盒中完成的工作。
● 团队负责价值和构建，从而持续提升交付成果的质量。
● 团队承诺不断地提升工作方式。
紧密合作
团队最好能够在同一地点，每小时、每天、每周都进行沟通。
标准的团队会议可能包括每日站立会议、迭代计划、团队演示，以及每个迭代最后的回顾。
每个团队成员都完全专注于单一的团队。
团队成员之间的关系彼此信任，持续反馈提高团队的合作。
敏捷团队共同计划、共同集成和演示、共同学习
共同计划
所有团队共同参加PI计划会议（如果可能的话，所有的团队成员最好都要参加）。在计划会议上，大家一起计划和承诺一系列的PI目标。大家都有一个共同的愿景和路线图，共同协作以达成目标。在计划和执行中，有清晰的工作授权。
共同集成和演示
团队在内部和这个火车上，都应用了内建质量并在迭代内进行持续集成，同时所有团队共同协作，从而可以在每个迭代完成时进行系统演示。
共同学习
团队也会参与更大的检视和调整会议，通过这种方式识别优先级，按优先级对改进故事进行排序，并将其放入后续的PI计划会议中进行处理。
学习也是在实践社区中不断发生的，实践社区的建立可以帮助个人和团队不断提升本职能和跨职能的技能。
产品负责人
产品负责人（Product Owner, PO）是团队的一员，负责定义用户故事和确定团队待办事项列表的优先级，从而衔接项目群优先级事项的执行，并维护团队所负责的特性和组件在概念和技术上的完整性。产品负责人是质量保证的关键人物，并且是团队中唯一有权力接收已完成用户故事的人。对于正在向敏捷方式转型的企业来说，产品负责人是一个新的并且非常重要的角色。产品负责人通常是全职的，一个产品负责人通常可以支持一个团队（最多两个团队）。
产品负责人是敏捷团队的成员之一，他是团队与客户之间的接口，负责与产品管理人员以及其他利益相关者（包括其他产品负责人）协作来确定团队待办事项列表中用户故事的优先级，以便解决方案能够有效处理项目群优先级事项（特性/使能），同时保持技术的完整性。
责任
SAFe产品负责人的主要责任如下。
筹备和参加PI计划会议
● 作为产品管理团队的一员，产品负责人积极参与项目群待办事项列表细化和准备PI计划会议的工作，同时也积极参与PI计划。在PI计划之前，产品负责人更新团队待办事项列表，审查和参与制订愿景、路线图和进行内容展示。
● 在PI计划期间，产品负责人参与用户故事定义，为团队澄清产品需求，以便团队进行用户故事估算和用户故事排序，并为项目群增量起草团队目标。
迭代执行
● 待办事项列表梳理
● 迭代计划
● 准时制（Just-in-Time, JIT）的用户故事细化
● 支持ATDD——产品负责人参加用户故事接收标准的制订和起草，并提供示例以支持ATDD（Acceptance Test-Driven-Development，接收测试驱动开发）规范制订。
● 故事接收——产品负责人是唯一可以接收用户故事完成的团队成员。
● 理解使能工作
● 参加团队演示和回顾
项目群执行
● 迭代和团队都服务于一个更大的目标——频繁、可靠和持续地发布以便实现解决方案的增值。
● 产品负责人在为项目群和价值流利益相关者进行演示的过程中也起到关键作用。
检视和调整
● 团队可以在PI的检视和调整工作坊上来处理那些较大的障碍。在工作坊中，各团队产品负责人协同工作来定义和实施改进故事，以提高项目群的速度和质量。
● PI系统演示在检视和调整工作坊中进行，产品负责人在为项目群利益相关者进行PI系统演示时发挥重要作用。
● 产品负责人也参与PI系统演示的准备，以确保能够为利益相关者展现解决方案的最关键环节。
内容授权
产品经理、产品负责人和敏捷团队的人员配比
每个产品经理通常可以支持最多4个产品负责人，每个产品负责人最多可以负责1～2个敏捷团队的待办事项列表。
PM/PO的人员比例模型
Scrum Master
Scrum Master的角色由团队中的一员承担，主要职责是帮助自组织、自我管理的团队实现其目标。Scrum Master通过教学和指导SAFe，实施并支持SAFe的原则和实践，识别和消除不利因素的影响，引导流动。
在团队中的责任
优秀的SAFe Scrum Master是基于团队的仆人式领导：
● 展现精益-敏捷的领导力
● 支持规则
● 引导团队向着目标前进
● 领导团队进行持续改进
● 引导会议
● 支持产品负责人
● 消除障碍
● 宣传推广SAFe质量实践
● 建立高效团队
● 保护和沟通
在敏捷发布火车上的责任
Scrum Master帮助协调团队之间的合作，以便团队真正地成为“在火车上的团队”。
● 与其他团队进行协调
● 引导敏捷发布火车仪式的准备和就绪
● 协助估算
ScrumXP
详述
ScrumXP敏捷团队是一个包括5～9人的自组织、自管理的跨职能团队，并且尽可能工作在一起。
团队是跨职能的，因此具备用于交付增量的所有角色和技能。
Scrum定义了两个特殊的角色：产品负责人和Scrum Master，他们是SAFe ScrumXP团队的成员，各自被赋予特定且具体的职责。
产品负责人（PO）
每个ScrumXP团队有一个产品负责人负责团队待办事项列表。
Scrum Master（SM）
Scrum Master是团队的引导者和敏捷教练，其主要职责包括：确保团队遵循开发流程，向团队提供Scrum、XP和SAFe实践的培训，以及提供持续改进的环境。
Scrum流程
Scrum流程本身是一个轻量级的项目管理框架，能够促进快速、迭代式高级解决方案能力的构建，并且有利于持续改进以支持更高效的产能和更好的交付。
迭代计划
迭代开始于迭代计划，该计划也是一个遵循时间盒（不超过4小时）的会议，产品负责人可以展示迭代相关的故事。
可视化工作
团队采用大型可视化信息雷达（big visual information radiators, BVIR）掌握并跟踪迭代执行过程。
协调每日站会
团队每天都举行一个正式的仪式——每日站会（Daily Stand up Meeting, DSU），用于了解团队目前的状况，提出问题，以及向其他团队成员寻求帮助。在会议中，每个团队成员描述昨天做了什么，今天将要做什么，以及遇到的任何阻碍。
价值演示和过程改进
在演示过程中，团队展示迭代中每一个完成的故事，其总和就是此次迭代团队的价值增量。
团队进行一个简短的回顾，反思在迭代过程中，哪些地方做得好，以及当前有什么阻碍。
内建质量
内建质量需要从代码和组件层面抓起，由此生成解决方案；5种来自于极限编程（XP）中的工程和质量实践，用以扩充Scrum项目管理实践。它们是：持续集成、测试先行、重构、结对工作和集体代码所有权。
ScrumXP团队“在火车上”
作为敏捷发布火车的一部分，ScrumXP团队共同计划、共同集成和演示、共同学习，如图所示。
ScrumXP团队领导力
团队管理人员的日常管理职责存在一个质的转变，即从指导团队具体技术实现的专家管理者，转变为使能员工、发展员工的精益-敏捷领导者。
团队看板
看板（Kanban，意为“可视化的信号”）的本质是一个用于可视化和管理工作的方法。
一般来讲用于开发的看板系统包括以下几个主要方面：
● 系统包含一系列需要经历的工作状态的定义；
● 所有的工作都是可视化的，每个任务的进度都会被跟踪；
● 团队对于每个工作状态的在制品（WIP）限制数达成一致，并在必要时更改WIP以优化工作流；
● 团队制订工作管理政策；
● 度量流动。工作项从进入系统开始被跟踪，直至离开；这样就可以持续地指示在制品数量以及当前的前置时间（Lead Time，一个工作项通过系统所需的平均时间）；
● 通过分配服务等级进行排序，而服务等级是由延迟成本决定的。
团队初始看板示例
度量流动
为了更好地理解和改进流动与流程，看板团队采用客观的度量，包括平均前置时间、WIP、吞吐量。其中常用的一种度量方式是累积流图（Cumulative Flow Diagram, CFD），如图所示。
每一个工作项都是有时间戳的，包括其进入工作流的时间（从团队待办事项列表拉入开始实施状态）及完成时间。“到达曲线”表示拉入工作流的工作项数量，“离开曲线”表示完成并被接收的工作项数量。两条曲线在X轴的差值是平均前置时间——也就是一项工作通过系统所花费的时间。在Y轴的差值是WIP——也就是在任何时间点上，系统中所有工作项的数量。吞吐量——指在给定时间段内完成的工作项数量，它也是一个非常关键的指标。
通过服务等级改进流动
1．标准——大部分工作项都属于这个服务等级：
2．固定日期——有固定日期的工作项意味着里程碑和预先设定日期的依赖关系。其延迟成本是非线性的。
3．加速——“加速”类别工作项有着难以接受的延迟成本，因而需要立即引起团队关注。
SAFe看板团队“在火车上”
估算工作内容
为估算建立一个共同的起点
计算“导出”速度
估算大的工作项
团队待办事项列表
待办事项列表的定义：
1．隐藏在舒适表面下的大型列表
2．未完成的任务或未处理资料的聚集
● 待办事项列表需要包含所有要做的事情，如果工作项处于列表中，那么就需要被完成；如果工作项不在列表中，那么就不会被完成。
● 待办事项列表是一个“希望实现工作项”的列表，而不是一个承诺。
● 待办事项列表有唯一的责任人——团队的产品负责人。
● 所有的团队成员都可以将自己认为重要的用户故事放入待办事项列表。
● 待办事项列表包含用户故事、使能故事和“改进故事”，其中“改进故事”是从团队迭代回顾会议的结果中识别出来的改进内容。
团队待办事项列表的三个主要来源。
