作者：袁翠

2019年1月20日，这是一个周日的晚上，尽管如此，来参加沙龙的人还是不少，与其在家无所事事，不如来一场知识的火花碰撞。

按照惯例，先是进行自我介绍。如果说这次自我介绍与以往有任何不同的地方，那就是，自我介绍人员要站到台前来跟大家介绍自己。由于此次的主题是大规模敏捷框架的介绍，很多来参加沙龙的人员并不是非常熟悉，都希望对其有更进一步的了解。

话题导入

此次的主题是大规模敏捷框架 – Essential SAFe介绍，主讲嘉宾是Ella Yao。本次的分享分为两大部分：

● 敏捷与Scrum介绍

• 什么是大规模敏捷
• 什么是SAFe

● Essential SAFe overview and assessment

• Essential SAFe overview
• 自我评估

Ella首先抛出的讨论问题是：大家对敏捷的理解是什么。有的学员认为敏捷就是以最低的成本得到最大的价值；有些学员则认为敏捷就是“忽悠”，提高效率；有些认为敏捷适用于产品的迭代而不是定制型的项目，如果有一个原型或功能需要叠加，按照轻重缓急来做，则更适合用敏捷，但是不是所有的甲方需求都能接住，如果按照人天来做，可能没问题，如果需求固定，又不按照人天来算的话，那么可能就接不住了；也有学员立马提出了反对意见，项目本身就是要定好时间/范围/需求，而敏捷也是需要在PO会议上划范围/时间/成本，再形成Sprint，不同点就在于敏捷是不断进行交付，更有利于及早发现产品是否满足客户的需求，不能单纯说敏捷更适合于产品的迭代等等。

不同的人对敏捷的理解不同，有人认为它是方法论，有人认为这是一个JIRA工具，是最佳实践的集成；也有人认为它是先进的管理方法/理念，并且概念在不断扩大。

敏捷与Scrum介绍

首先Ella对敏捷的发展史进行了简单介绍。Scrum的概念首次提出是在1980年代，中文并无Scrum的对应翻译，Scrum的愿意是橄榄学的术语，表示并列争球的意思。在1990年代，Kan & Jeff，Scrum之父真正使用到Scrum的方法，当时传统的瀑布模式不太适用，市场瞬息万变，用户需求在不断变化，或者是有新的产品时，还不一定知道用户群。在2001年，敏捷宣言首次提出，并有了更大的发展；在2009+，形成了大规模敏捷的概念，其他理念如LeSS也相继提出。Scrum本身其实是一个框架，只是解释了一个团队怎么去做敏捷，建议的团队成员通常是7+/-2，没有设定具体的流程。

敏捷宣言引用如下：

• Individuals and Interactions over processes and tools
• Working Software over comprehensive documentation
• Customer Collaboration over contract negotiation
• Responding to Change over following a plan

That is to say, the items on the left are valued more than the items on the right.

要强调的是，左边标黑的比右边更重要，但并不是代表右边的不要做。

Scrum 框架

接着，Ella对整个Scrum框架进行了讲解。PO从干系人那边得到需求作为输入，跟开发团队保持紧密沟通，清楚想做的特征在技术上能否实现，风险怎样。得到输入后，需要将其转化为需求列表product backlog（需求列表是动态的，PO可以随时更新；按照优先级排序；渐进明细，高需求的颗粒度较小。基本只要几天的工作量，排在下面的就是简单描述，需求还不是很明确）。Development team是开发团队。一个大圈（通常1-4周），最开始定义好一个圈是几周。迭代第一天会有sprint planning，PO跟团队解释前面几条具体要做什么。结束后，输出，团队在固定的sprint里面能做完几条需求。Scrum master的角色有点类似于项目经理，但还是有区别；scrum master会进行协调组织，每天会有15分钟的站会，会后更新燃尽图，识别问题风险；sprint最后有两个会，sprint review 迭代评审会，叫PO过来给他演示进行验收；sprint retrospective 迭代回顾会：流程/工具/合作/沟通/人/，哪些做得不错，哪些需要改进；有些改进项可能会进入sprint backlog。

基本SAFe概览

Ella对上图做了详细介绍，简单摘要如下：

• SAFe的全称是Scaled Agile Framework enterprise
• 上图黄色柱形中的每一个小圈代表的是一个scrum迭代，共有五个迭代。两个小圈中间的省略号。。。的意思是有很多团队在跑迭代。SAFe有两层，Team层和program层（很多团队之间的依赖比较大，人数为50 - 125）。Team 层包含有scrum master, PO, 开发测试人员。Program 层也称作火车层，跟team层一一对应。
• RTE：release train engineer 发布火车工程师，类似于chief scrum master的角色
• Product manager: 可以理解为管理所有PO
• System architecture: 系统工程架构师
• Business owners: 老板/客户业务方的老板/研发的老板，会给PR的价值打分数
• 版本火车：在发布周期很短的情况下，不按照以前的项目方式（如果在截止日期前没做完，则延期），而火车的发车时间是固定的，如每月发一版。但是每个月发布的内容是不固定的，这么处理的目的就是为了建立快速发布的能力；真正达到敏捷，敏捷的范围scope是可以变的，如果这个版本没赶上，下个版本再发，客户那边也比较容易接受
• 版本火车+feature 开关：如果有代码没写完，有开关
• PI planning: 通常是会有上百个人开两天会，有非常详细的会议议程。首先Business Owner会就将来的战略/目标进行发言，接着架构师就公司的架构技术进行发言。接下来会进行scrum分解来计划这五个迭代要做什么；在开会之前，PO和product manager要商量哪些特征feature要做的,怎么拆分成更小的故事story；第一天会议结束后，会就风险/问题/依赖关系进行分心并讨论计划是否要变；第二天在继续做分解讨论，最后进行信心投票；business owner会进行价值value 打分；做完之后大家按照计划来执行。在执行过程中，在团队层（Team level）面，会有每日站会；火车层（Program level）也会有相应的会议，要注意两者之间要进行互通/同步
• 在全部五个迭代中，前四个迭代有冤圆圈表示，最后一个没有圆圈，而是写着IP （也即innovation and planning创新计划）迭代；五个迭代中通常留出最后一个做创新/回顾，但是不做新的需求；在开始计划的时候，前四个迭代真正完成所有需求
• Enabler: 技术方面的故事
• 红色折线：架构跑道；技术类的基础工作，需要技术/架构团队经常做系统/架构优化，支持实现新的feature或者换届由新的业务造成的系统压力
• DevOps: 开发和运维，怎样更好地进行合作，打破中间的裂缝
• 等等……

在讲完框架之后，Ella也分别介绍了Essential SAFe的十个元素是什么，如果没有，会造成什么后果。

自我评估

最后，Ella就敏捷，SAFe与LeSS之间的不同谈了她自己的见解：

• 敏捷 - 只是定义了一个框架，看似简单，实际做的时候容易有比较多的问题；一般都是根据自己的需要来做，运用比较自由
• SAFe – 内容其实更多是精益和敏捷的东西，最大的贡献是有这样一个框架，除此之外还有细化的流程，引用Ella的话， “不仅有架子，还有肉” ，现在最受欢迎，因为每一个步骤很详细，都有模板，角色定义也非常清楚
• LeSS - 关注系统思考；首先要考虑组织架构的调整，要求比较高，应用相对没这么广泛

其实不管运用哪种，都需要历经守破离这三个阶段。

至此，本次活动圆满结束。其实，参加沙龙只是给大家提供一个更好的平台来进行交流，在参加沙龙之前，如果可以多做做功课，带着更多的问题来进行探讨的话，那么相信收获也会更大。让我们一起期待下一期的活动吧！