现在有3种流行的软件工程方法：
- 简单的：不能真正解决问题的简单方法 -Scrum
- 复杂的：可任意选择解决方案 -SAFe
- 1＆2的混合：LeSS
现在我们正在踏步于SAFe第二阶段，未来可能更需要第三步，第2步的SAFe到底是什么？有什么问题？
观点：
- 我阅读“团队拓扑”越多，我认为将SAFe称为改进的瀑布，不如将其称为差的敏捷更合适。创建ART只能容纳依赖关系，并且价值创造结构不佳。3个月的效绩指标不是敏捷的，但要好于年度。
- 一家公司每次采用SAFe时，上帝都会杀死2只小猫。
- 我正在与正在实施SAFe的组织中的一位高管进行交谈，我询问高管他们希望从中获得什么。他说，他们无法就下一步最重要的事情达成共识，并希望SAFe能够促进这些讨论。
- 我将SAFe视为工具箱。SAFe的最大问题是，它很少关注演化和组织成熟度。此外，它还以“敏捷的银色子弹”的形式推销自己。它也仅适用于如何适应依赖关系，而不适用于如何通过团队改革来避免依赖关系。
- SAFe是一个较新的RUP，通常总是使用“阶段关口”来实现……这实际上只是功能更强大的瀑布，只有公司才能并行执行阶段，这实际上耗尽了WIP的能力。
- 我想知道为什么很少有公司实现“真正的敏捷” ...我的猜测是，对于指定规模的任何公司来说，敏捷意味太大的改变。某些框架（如SAFe）会尝试缩小这种目标与现实的差距，这样公司可以迈出敏捷的第一步。