看到了新版本的SAFe 5.1的推出，且我确实需要对此做了解和学习。翻译一篇以前的文章（2014年2月），在学习之前简单了解下它的，至少是它前身的弊端。也许对我其的学习能有所帮助，翻译的内容不属于我的观点。我也不是拿来当武器来抨击谁，仅仅是闲来无事。仅做参考用，不喜也勿喷！

原文地址：

https://ronjeffries.com/xprog/articles/issues-with-safe/?lipi=urn%3Ali%3Apage%3Ad_flagship3_pulse_read%3Bx5bJkmlYTD609ClpFPJ%2BNg%3D%3D

最近推特上的对话促使我拿出一些我对SAFe的困惑，并（在此）进行讨论。（已经更新了建议）

SAFe并不如想象中那么好

当然没有什么能和想象中一样美好。随着越来越多的支持者和培训师，使SAFe有了极好的资本与胡夫匹敌。对于它的投资表明它可以做的更好。既然它有能力做的更好，要求它变的的更好是公平的。

然而对于我来说，诘问。我将会用斜体来提出建议。

SAFe确实允许改进。以目前的形式是不现实的。

我们再三反复保证SAFe一直是在改进中的，而且SAFe的拥趸期望SAFe的实施能改善他们的工作。首先我并没有看到任何证据，致使我认为目前的SAFe是强烈反对现场变更的。

提供更多的方法以彰显SAFe的敏捷性。指出那些可能的敏捷焦点变更的方向。那些在本问中提及的其他想法就是示例。

SAFe强调至上而下。

SAFe的中的教学和结构均是自上而下的。所有的重要的东西都被归结到投资组合层中。所有的功能都被归结于项目群层中。现在小子们来构建和测试吧！

这种关注显而易见的会吸引公司，尤其是他们中那些相信高层的人会比实际干活的人更了解应该做什么，以及如何去做。

然而，这种想法是直接和敏捷以及现代管理理论相悖的。在组织中责任和授权最好向下推进。SAFe显然缺少甚至没有这种关注。

首先将重点放在将授权和责任从高管中剥离，仅仅留给他们那些做好工作的最低限度即可。

SAFe用错误的方式来“对齐”

SAFe给人印象是它推荐了最好的方式。在我有些经验和深思熟虑的观点看来，它所推荐这些玩意，充其量就是让你在以自己的方式达到最佳的磨合之前的权宜之计。结果它提供的权宜之计好似给了最终答案一样。

SAFe宣称“训练所有人”。它的价值在于“对齐”，这意味着或被解释为“每个人都这么做”。实践中，我料想我们无法看到更多从SAFe到更好的东西的变革。

事实是，即使是单Scrum团队也不会太大发展。在我看来，很大成都上是由于管理层命令必须使用Scrum造成的。（当然还有很多其它的因素。）SAFe更有可能导致管理层强加架构，导致团队无法向更好的方向发展。如果他们尝试，很可能被“一致性”的球拍狠命一击。

认识到一致性仅仅是众多有价值工具中的一种，且在众多案例中是一种低下的工具。敏捷原则重视无论大小规模的多样性，并且通过共同目标和远景来实现一致性。SAFe应当遵循这种风格。

团队结构不利于敏捷性。

SAFe所谓的“ScrumXP”团队被称为“跨职能的定义-构建和测试”团队。对于跨职能的结构，人们只是口头上说说而已，但团队被描述为由开发人员和测试人员组成。团队定义似乎体现在产品负责人身上。Scrum团队的最佳状态是让产品负责人给团队带来问题然后由来团队解决问题。

真正的关注在跨职能团队，把更多的责任分发给团队。

你很大，故你规模化

SAFe呼吁大型组织的简单化思维大体上是他们需要去标准化事物，因为他们是很大的，他们是不同的。它既没有提供测试来确认哪里组织真的需要“扩展”，甚至不承认你组织的很大一部分可能根本不需要它。

组织的大部分工作已经由一个团队完成。这些团队并不需要SAFe。但团队可以做更多的事情。在那种情况下可能最好的是去组建一个团队。同样，这个团队可能也不需要SAFe。最好的处理剩下的工作的方式可能是由特性团队去完成，尽管很多大型组织倾向于创建组件团队。特性团队并不需要从SAFe中获得什么。

更多地关注在组织结构向更敏捷的结构的转化，而不是让所有人保持步调一致。

你需要发布火车。

发布火车是作为最终解决方案提出的一个权宜之计的示例。发布火车的需求是将工作划分到团队的结果，因此需要协调讲它放回到一起。SAFe并没有急着消灭问题：它仅仅给了一个调解方案。

明确敏捷发布火车是一个权宜之计，将精力主要集中在持续集成和持续发布上。

基于节奏，按需发布和敏捷列车冲突

SAFe培训花费了大量的时间在“敏捷发布火车”，这是一个5次迭代的周期。最后的迭代是HIP（强化、创兴、计划）。发布火车的焦点是将计划中所有5个迭代的所有事情完成。这将会集中在这段时间内交付。

显而易见的是交付价值越早越好。SAFe口口声声声称“基于节奏，按需发布”，但是它的培训和焦点是在于推动同步，而不是持续交付。

更加关注在持续发布，将敏捷发布列车作为一个权宜之计实践它。更明确强化需求是一个待改进项。

依赖是常规模式

SAFe假设你的计划中会有依赖。显而易见，解决方案是将其放到看板上，并用红线将他们连接起来，然后发送卡片给其它团队，告诉他们你和他们有依赖。所有的都会在两天的神奇群众会议（翻译者：猜测是PI计划前会议）中解决。（也许这不是它的名字。）

依赖不是“常规模式”。他们是障碍。他们应当被移除。通过消灭组建团队和转化到特性团队来消灭他们。特性团队是众所周知的。

强调特性团队和其它减少依赖的结构作为目标安排，而不是将他们留给大规模会议。

所有都要以这种方式完成。

任何的公司的大部分工作都可以由一个简单的跨职能团队完成。没有必要做大规模计划、发布火车或那些SAFe的机制。也许SAFe已经承认了这个事实，但是它肯定不会任其发展到这个境地，甚至不会建议你首先将那些你不需要的SAFe的所有东西裁剪掉，然后将SAFe应用到其余部分。相反的，其只会振臂高呼高，“每个人都应接受SAFe培训“。

首先专注于消除一致性需求，然后再开始考虑那些遗留下来的内容。

项目群计划是大计划的前提

在每个发布火车之前，每5个迭代就有一个新计划。为此，项目群层级别的项目经理和产品负责人通过当前发布列车中的工作，来制定下个发布列车的计划。

据我所知，所有这些计划是在很少或者没有开发人员反馈的情况下完成的。可以想见，这个由全体会议表决的计划将会是糟糕的。为期两天的会议确定了十周的功能计划？

首先吧所有的可能的项目排除出固定计划和发布火车周期。对于那些剩下的，做分布式连续计划，而不是做大爆炸计划。

自上而下的功能分发是必由之路

SAFe的项目群级别的计划设想产品计划需要由一些专门指定的项目经理和产品负责人来创建和调整。实际上，我们所知的最有效的团队需要紧密协作，但并不是在经理和其它经理之间，而是在产品负责人和他们的团队之间。SAFe可以将集中计划作为权宜之计，并推动去中心话。可事实上它并没有。

教导权利下放和持续计划和发布。消除无必要的同步。在它发生的地方提供补救方式。

一个两天的全体会议可以解决我们过去十周以来搞砸的任何事情。

它期望所有人，字面上的所有人，会参加这个为期两天的会议。在会议中工作会被轮换、依赖关系会被辨识、为未来十周团队计划会被创建出来。

一百人左右的会议不会解除在没有开发人员反馈下的前十周的计划所犯下的不可避免的错误。SAFe本可以推动持续计划。因为它是如此专注在一个长节奏，所以它并没有如此做。

为大部分的工作做持续计划。减少自上而下推动的计划，而通过更多的愿景和需求表达。

这不可能发生。

当你读完以上的观察和建议，显然这些事情不可能发生。SAFe的优势在于吸引那些不敏捷的大型组织。它证实了那些大人物知道这些事情，所有的小人物都需要火急火燎的完成那些他们被告知的事情。

SAFe告诉那些企业大鳄，楼下的那些弱小的哺乳动物没什么可担心的。反过来说，敏捷却认为哺乳动物才是答案。

SAFe的设计者和拥趸可能会承认很多困惑。我知道有些人确实如此。他们会说是，在SAFe里有所有的敏捷原则和想法，并且欢迎改进。一旦我们进入了，敏捷可以随着他们的学习弥漫到组织中去。

嗯嗯，啊。我身体会把我口香糖饮食和饼干转化成肌肉和干净的动脉。

尽管如此，我任然相信SAFe的创造者和拥趸不是愤世嫉俗的邪恶之辈。他们真诚的认为他们的产品可以有所帮助。至少一定程度上有所帮助。我认为这可能会是更好的产品和更多的帮助。我认为他可以提供不同的想法且帮助更多。这由他们来决定应该做什么。我们所有人都可以出售那些我们想要出售的东西。

不过，不过，不过，我们意思是好吧！！！

对于这些问题的回应主要以下形式：

不过，不过。。。SAFe总比什么都没有强

那就是。它没有推荐那些不难做且通常认为更好的方法和实践。SAFe也许比没有强。它并不尽如人意。

不过，不过。。。SAFe不能包含所有东西。

是的，他不能。既然如此，为什么不能有最好的，或者第二好的？

不过，不过。。。人们可以改善SAFe。我们甚至已经告诉过他们了。

是的，他们可以，而且你做了。历史表明，这些经常不会发生。SAFe没有包括一份详细描述的持续改进的方法来超越本身。因为SAFe是如此的规范，这是急需的。

不过，不过。。。Scrum也不是那么的完美。

你也一样。我也在做那个。SAFe对我来说不过是个副业。

不过，不过。。。你就是不明白。

我参加了课程。阅读了相关材料，我和那些实施SAFe的人交谈。我努力思考此事。我的智商还是处于平均值之上的。如果我做错了，我也许会，那么很多其它人可能也会。

不过，不过。。。自己找借口吧

它始终是一个借口。对于你没能成为应该成为的那么好，确实没有什么好借口。好吧，我们没人是。这始终是一个借口。

底线：SAFe并不安全。

SAFe通常选择第二或者第三好的方法。他的至上而下的理念迫使组织无法超越它。它没有必要这么做。它本可以卖的更好如果它更好。我提供这些内容做为工作。我甚至已经帮忙了。