前面SAFe的那些“大事儿”是不是够你喝一壶的？
不用担心，SAFe里的“大人”们，会......
让你更抓狂的......
曾经看到一个负责培训SAFe的朋友吐槽，自己都记不住SAFe里到底有多少角色......
蹭个热点，这是不是也算“内卷”的实例之一呢？我们要做的就是扒开“卷子”，看看里面放的是葱花还是白糖......Let's Go！
不知道SAFe的发明者Dean Leffingwell是不是也读过老子的《道德经》：“道生一，一生二，二生三，三生万物”。在笔者看来，SAFe的很多角色都跟“三”有关系。我把它称之为SAFe的“三三制”。^_^
笔者认为，在SAFe中，“道”为敏捷思想，“一”为单个个体，“二”为敏捷团队，“三”即为SAFe中的“万物”了。所以如果我们把敏捷团队视为SAFe的基本元素，那其他组织都是敏捷团队的拓展，其他角色也自然而然可以对应到单个敏捷团队中去。
大家应该还记得SAFe的四个分层吧：团队层，项目群层，价值流层，投资组合层。我们由下至上，由易到难，一个一个的看SAFe的“三三制”。
团队层
SAFe的团队层中基础的工作单元是敏捷团队。
关于敏捷团队，我们也反反复复讲过那么多了，相信大家对于Scrum/敏捷团队的三个角色都烂熟于心了，那就是：抽烟，喝酒，烫头......
咳，最近听于老师的相声有些上头......咦，于老师也是“三”大爱好......这么神奇么？......
言归正传，应该是PO，Team，Scrum Master。关于这几个角色的职责，这里不打算详述（我们这个专栏毕竟是从单个敏捷团队的话题开始的对吧，详细内容请参考前文），我们简单看看SAFe的描述。
PO（Product Owner）
是团队与客户之间的接口，负责与产品管理人员以及其他利益相关者（包括其他PO）协作来确定团队待办事项列表中用户故事的优先级，以便解决方案能够有效处理项目群优先级事项，同时保持技术的完整性。
职责包括筹备和参加PI计划会议，项目群执行，检视和调整。在SAFe里，推荐每个产品负责人最多可以负责1~2个敏捷团队的待办事项列表。
大鼻子解读：SAFe的PO其实就是在单个敏捷团队PO的基础上拓展了对于项目群层支持的工作：因为单个团队的待办事项列表及优先级，是根据项目群的优先级事项拆解而来的。
Team
最主要的职责是确保迭代执行，完成迭代目标。另外，Team是在ART（Agile Release Train）上的，一定需要更多的与其他团队协作，更与的参与协同类的活动和讨论。
大鼻子解读：在SAFe中，除了有效的局部迭代执行，Team还有一个更远大的使命，即优化项目群执行。从更系统的视角来优化整体实践和流程，而不仅拘泥于局部调优。
Scrum Master
会协助团队达成他们的交付目标。是基于团队的管理代理人和仆人式领导，他通过有效的敏捷实践，帮助团队实现自组织、自我管理和交付工作。
大鼻子解读：除了单个敏捷团队的职责之外，Scrum Master帮助协调ART上各团队的协作。比较有意思的是，看的出来，SAFe也倾向于Scrum Master是专职的角色，能够同时支持2~3个敏捷团队。但也提到了“Scrum Master不再做开发或者测试的工作，看起来不太经济。可能在团队有机会证明这个角色的价值之前，这种变革就已经胎死腹中了”。所以也不排除团队成员兼任。SAFe还是挺接地气的。
项目群层
项目群层最重要的活动就是PI，由PI来驱动ART的运行，确保最终价值的交付。火车不可能自发组建和驾驶，它需要被指引和给出方向，这样团队就可以对齐到共同的使命，在统一的架构设计和用户体验指导下完成工作。
项目群层同样有三个非常重要的角色。如果说把项目群层的组织也看做一个大的敏捷团队，那么这一层的“三个角色”的职责对应的关系就比较好理解了。
产品管理者（Product Mgmt）
SAFe也称之为产品经理，可看成是客户需求在组织内部的代言人，他们和客户以及PO一起理解和沟通需求、定义系统的特性，并参与验证。他们是项目群待办事项列表的负责人。
大鼻子解读：Product Mgmt就是项目群层的PO，一个Product Mgmt需要和团队的PO协同工作。一个Product Mgmt对应最多4个PO。
系统架构师/工程师（System Arch/Eng）
是一个独立的个人或者一个小型的多功能团队，他们真正运用系统思考来定义整个系统架构，从而有助于定义非功能需求，决定主要的系统部件和子系统，同事他们还协调定义接口和接口之间的协作关系。
大鼻子解读：System Arch/Eng就是项目群层的研发Team。在项目群层中，这个角色更多的是关注系统架构方面的实现与演进。架构是统一研发理解和实现的重要工件。
插个广告，我们先看一个有趣的图：
“如果我们让架构师主导，他们将一直重新架构到地老天荒，然后我们就失业了。”
“如果我们让产品经理来主导，他们将糊弄这件事直到地老天荒，然后我们就失业了。”
为了解决上述困境，SAFe给出的解决方案是：以上这两个角色共同决定使能任务和特性任务的优先级分配！
发布火车工程师（Release Train Engineer）
是ART上的仆人式领导和首席Scrum Master。他协助团队在项目群中使用各种机制优化价值流，这些机制包括项目群看板、检视和调整工作坊、项目群增量计划等。
大鼻子解读：就是项目群层的Scrum Master。负责清除项目群层的各种障碍，优化项目群层交付价值流，让项目群层的Planning（PI计划），站会（SoS和PO同步会），Demo & Retro（检视和调整工作坊）等活动（对应单个团队的4大活动）顺利开展。
项目群层的“三三制”和团队层很像嘛！
嗯，同意。背后的逻辑似乎都是一个。但需要的技能和视角是更为全面和系统的，要不为啥层级高一点点呢？
BTW，这一层还需要介绍一下“跨层级面板”中出现的支持ART正常运转的角色。
DevOps
通常包括系统管理员、数据库管理员、运维工程师、网络工程师和存储工程师等，拓展一下，也可以是制造行业的专家，以及其他传统行业中负责部署或生产制造解决方案并保持解决方案运行的人员。
大鼻子解读：就是检修和维持火车线路正常运作的团队。确保ART的工作环境可靠和稳定。
系统团队
是敏捷发布火车或者价值流中的特殊敏捷团队，通常在构建和使用敏捷开发环境基础设施方面提供帮助，包括持续集成以及整合来自敏捷团队的资产，执行端到端的解决方案的测试。
大鼻子解读：负责火车装箱、卸货，并让这些环节更高效的团队。同时，需要考虑必要的时候将火车从“和谐号”改造成“复兴号”（速度更快）。
发布管理
对于版本发布具有权威的治理授权，发布管理者包括解决方案管理者，以及来自相关职能部门的高级代表。发布管理者定期举行会议，来评估发布的内容、进度和质量。
大鼻子解读：排火车班次的专业人员。到站装什么货，什么时间卸货（发布），避免撞车等。
共享服务
这种角色的具体形式会比较散，包括但不限于数据库建模，企业架构，敏捷、内建质量教练，信息安全等等。
用户体验
代表用户对系统各个方面的感知，建立一个能够深度理解用户需求的系统是用户体验设计的焦点。一句话，这么多团队输出的东西，在用户体验上应该是统一和一致的。
大鼻子解读：上面两类角色的作用就是把公共的支持的工作专业化，提供更高效更统一的支持输出。亦是目前比较火的所谓”中台能力”的一种具象化的表现。
价值流层
价值流层是可选的，专门应对复杂的大型业务。与项目层级的“三三制”类似，价值流层也有三个重要的角色。
解决方案管理者（Solution Mgmt）
代表客户需求和投资组合愿景的战略主题。他们同ART的产品管理者协作，对能力进行拆分并将他们分解成特性。负责管理价值流产品待办事项列表及其按优先级排序，同时负责创建经济框架来管理ART和敏捷团队的决策过程。
大鼻子解读：就是更加复杂业务的产品负责人，需要将多个ART（含硬件、固件团队）甚至供应商的交付物整合成系统级的解决方案，交付给用户。类比一下，这个角色就是给多条火车线路下达营运指标，要运多少人，多少货，挣多少钱。
解决方案架构师/工程师（Solution Arch/Engineer）
是一致负责定义总体架构的团队，总体架构将不同ART的解决方案连接起来。
大鼻子解读：通过合理的架构将不同解决方案适配在一起。类比一下，运用什么技术手段和调度策略支持火车系统最高效的达成营运指标。
价值流工程师 （Value Stream Engineer）
是价值流层的仆人式领导。负责价值流的平稳运行，以及发现并解决整体价值流中的瓶颈问题。负责引导价值流层的会议，以及监控价值流看板并通过相应度量指标确保价值流健康运行。
大鼻子解读：价值流层的Scrum Master。类比一下，确保火车系统的高效运行，并及时反馈给上述两个角色，努力不断提升和优化火车系统效率。
投资组合层
到了这一层，依然是个“铁三角的”配置。我们来看一下。
史诗负责人（Epic Owner）
职责是通过投资组合看板系统对投资组合史诗进行看护，制定业务论证，并且当史诗被批准后与关键利益者一起工作，在相关价值流中最终实现史诗。
大鼻子解读：虽然不是太合适，可以简单类比为企业的COO或者单个业务的COO(总经理)。
企业架构师 （Enterprise Architect）
对企业解决方案和开发举措维护高层次的整体愿景；通过使能史诗帮助定义支持预算的关键技术举措；参与构建和维护企业架构跑道的战略；影响共同的建模、设计和编码实践......
大鼻子解读：虽然不是太合适，可以简单类比为企业的CTO或者单个业务的CTO(架构师)
精益-项目群投资组合管理（Lean Portfolio Mgmt）
项目群投资组合管理（PPM）表示在框架中拥有最高层战略和受托决策权的组织。在大型企业里，会有多个SAFe投资组合，每个投资组合管理一些列组织层面的大型活动，这些活动通常实在业务单元或者部门层级上。通常项目或项目群管理办公室有义务协助他们，共同担当指导项目群执行和治理的职责。
在SAFe里，用精益的方式去实现PPM而已。
大鼻子解读：虽然不是太合适，可以简单类比为企业战略落地实施组织或者PMO。
大家看看？只要你理解了单个敏捷团队的三个角色，SAFe这几个层级里出现的角色，是不是也没那么难记？“三三制”一贯到底嘛！
再附赠大家一个小抄。^_^
除了以上SAFe各层明确的角色，笔者还想就基础层的角色再啰嗦几句。
基础层
公司高层
SAFe非常强调公司高层对于SAFe支持的重要性。公司高层是非常重要的精益-敏捷领导着的角色之一。
同时，公司高层的角色需要有“精益-敏捷”的思维转变：引领变革；知晓方法，强调终身学习；发展员工；鼓舞和遵循使命，最小化约束；去中心化决策；释放知识工作者的内在动力。
其实是希望公司高层能够正视“软件交付“的行业规律，拥抱变革，拥抱敏捷。
开发经理
开发经理作为与研发团队交集最多的角色之一，其实也面临着“敏捷的转变”：以往在传统方式中对于员工每天具体活动的指导就不在需要了；包括与ART类似的财务预算的规划工作。
但，这些事情并没有凭空消失，只是在SAFe中落到了那些在新环境中，能够适应、调整和成长的人身上，或者通过显性的机制确保这些事情一定会被集体决策和执行掉。
那也不要慌，仍有些责任仍是开发经理需要承担，其实也是本身这个角色最为擅长的：
1. 对其直接下属进行辅导和个人发展的责任，也负责消除障碍，并积极地参与到员工的系统开发工作中；
2. 人员和团队的发展；
3. 项目群执行；
4. 协调一致，透明；
所以，角色以及思维的转变是必不可少的。
实践社区
聪明的人会从自己犯的错误中学习，更加聪明的人会从别人犯的错误中学习，最聪明的人会从别人取得的成功中学习。
实践社区是指在企业或者项目群的环境中，由团队成员和相关的专家组成的非正式的组织，其使命是在某个或相关领域中进行实践知识的分享。
实践社区既不是新兴事物，也不是敏捷开发所特有的。
我们认为，随着时间的推移，通常会让精益企业从垂直的职能型组织，转型成更加灵活的基于横向业务的组织，这样可以更快的交付价值。
所以，在实际的工作过程中，来自于不同项目群中的成员可能来自相同的部门，他们会经常见面沟通，并且由管理者和领域专家带领，提升相应的专业技能。
虽然单个敏捷团队是跨职能的团队，显而易见的，开发人员需要与团队外的其他开发人员交流，测试人员也需要同其他测试人员交流，产品负责人也需要与其他敏捷团队产品负责人交流，Scrum Master？同样不例外......
实践社区支持这种跨团队的沟通，在职能团队和组织之间，通过非正式的工作小组进行有效的知识分享和探索。
可以把实践社区看做是一个专业性比较相似的自组织团队。其实它的诞生也是顺理成章的：你都强调敏捷团队自组织了，那么更有共同“专业共鸣”的角色为啥不能自组织起来？!
毫无疑问，SAFe同样认为，实践社区是解决大规模团队横向沟通的另一个非常有效的保障机制。
SAFe里的角色大抵如此。多乎哉，不多也！
虽然SAFe是个“大家庭”，角色众多，但是不是通过笔者“三三制”的方式介绍会容易理解很多？
更何况，又给了你小抄......我只能帮你到这里了！^_^
