敏捷SAFe的本质是什么?-shalloway

20-09-03 banq

现在有3种流行的软件工程方法:

  1. 简单的:不能真正解决问题的简单方法 -Scrum
  2. 复杂的:可任意选择解决方案 -SAFe
  3. 1&2的混合:LeSS

现在我们正在踏步于SAFe第二阶段,未来可能更需要第三步,第2步的SAFe到底是什么?有什么问题?

 

观点:

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

              

猜你喜欢