周末参加了SAFe培训，学习了下，在学习之前，对它的印象就是

1.解决大规模企业如何敏捷交付

2.有标志性的版本火车

3.敏捷界很多人批判SAFe，说这是伪敏捷。这点我没法评论，因为不懂。但是曾经看到过一句很有道理的话，“很多人跟风喷SAFe，但是都不知道为啥应该喷，只是跟风”，潜台词就是，你要懂它，才有自己的判断，这点我认可，也是我学习SAFe的最大原因。

两天的课程时间排的很满，午休时间也短，还要做饭吃饭刷碗，很累，学的也不是特别投入，以下是印象深刻的一些点。

印象部分

• SAFe核心价值观

• SAFe精益屋

流：从项目到产品

创新：鼓励要到一线去看实际

不懈改进：始终保持危机感

领导力：以身作则

• SAFe精益敏捷原则：

• 什么时候去中心化的决策更好

• 质量内建的实践

• PI计划会议的流程：

• Program看板

• ART火车和团队级迭代关系

感受：

• 课程内容包含的很多，但是和其他认证类似，大杂烩，啥都包含，敏捷宣言、原则、Scrum、DevOps、精益、看板，以及敏捷培训常涉及到的其他方面，比如以客户为中心，设计思维，成长型思维，全职能团队等等。对于有一定经验的敏捷教练来说，这个课堂的一大半时间的收益很小，都是老生常谈的东西。所以在第一节重点印象内容里都没放这些。大
• 规模框架的特有流程方面的时间及实践比较少，比如ART火车开动从头到尾讲的不够细致，比如PI planning会议花了一定的时间，但是时间依旧少，并且中间的很多环节并没有做到位，感受不深。这些反而是我要上SAFe课的目的之一，没有达到预期。曾经团队自学LeSS的时候，我们写了个剧本，大家按照那个去演，遇到一些没想到的问题，离实际情况更近一步。感觉既然课堂上没有做的那么充分，课后如果一起听课的小伙伴们有兴趣，可以再好好玩玩这个。
• 教材是官网直接下载的，老师版本和学员版本差不多，在时间有限的情况下，老师的发挥空间有限，那么积累足够的知识和实践的前提下，拿着官方的材料去讲课，对讲师的要求比其他课降低了很多。
• 考试不难，毕竟开卷，很快能答完，但是答题的过程中就发现了，自己只会答题，很多有用的点还是学的不明白。

第一、二点更多的是针对SAFe课程的看法，而SAFe框架，感受不深，没有好好研究框架，对于ART火车，感觉和SOS、LeSS的实践差不多。

最后，回到前面提到的自己对该课程的最大的目标，讲出哪方面SAFe不够敏捷（以及结合到其他人对它抨击的方面），哪方面它又做的比较好，它又有什么局限性呢？

不够敏捷：

• ART火车量级很重，虽然说是在过程中，依然相应变化，但是众多团队协作的情况下，相应变化的成本也高了，会降低相应变化的速度和决心。那么在10周内不发生变化的可能性是多大呢？
• PI planning会议尝试用两天的时间搞定，但是既然选择了大规模敏捷，那么复杂度也会高一些，但是需求的澄清和计划竟然作为一部分，在这两天的会议里完成，那么多内容和项目，真的搞得定？看上去就是在用不变的思维来做计划。
• 出发点是说单独一个故事交付没有价值，所以需要一些故事一起交付给客户才有价值。我想到了熊捷老师举过的一个例子，具体说不清了，大致的意思是，MVP没法贯穿始终的情况下，你先做出前半部分的内容，后半部分用轻量级的手工或者mock的形式，让你能完成始终的效果，但是重点看前半部分的实现，进而小团队很快的拿到了反馈，当时这个例子是说如何验证。那我放这里，是否可以说明，大规模敏捷的出发点是不必要的？

局限性

• SAFe对于团队和工具的要求很高，团队自己的Scrum要玩的好，其次包括DevOps持续交付流水线在内也都做好了，然后再搞SAFe框架，否则那么多团队直接开火车，就会出现互相拖累的情况
• 还有很多细节上的问题，比如BO来参加两天的PI planning，如果他中间有事，缺少了半天的参与，会怎么样呢？诸如此类，在这个复杂的系统下，出现任何问题都很难解决，同时，相比于团队级敏捷，它会出现更多的问题。

合理性

• 对于领导来说，这样一个摸得着的框架，他会更放心
• 对于大规模的团队来说，这是一个目前可用的框架，其他的，除非你给个通用的解决方案出来。注意，这里说是大规模敏捷，而不是敏捷规模化，之前交流过的敏捷教练们说，相比于SAFe，他们用敏捷规模化来实施。

最后的最后，本文只是个人学习后的心得，并不意味着我支持或者抨击哪个言论，目前我对SAFe的实施还是有一些意见，可能更多的原因是我没真正参与实施过，就像一个瀑布开发出来的人，听到别人介绍了一节课的敏捷，就下断言一样，可能是片面的，有机会再多接触接触吧。

两天的课程能帮助你通过考试，但是无法帮助你学会。