SAFe和LeSS不同思路之思辨
2019-12-17
来源：IBM敏捷服务 赵卫David
式，带来的后果是增强回路的效应。而SAFe是如何做到的呢？它是通过“没有强调突出特性团队”，以及使用项目群增量（Program Increment, PI）计划（PI Planning）的方式来管理依赖。而如果是组件团队那么PI下的多个迭代是可能的，并且还比较容易同步到一个PI，可是并不可能总是同步到一个PI。
LeSS解决大规模敏捷，团队间的依赖问题，思路是采取平衡回路2的方式。LeSS是如何做到的呢？它是通过“强调LeSS就是特性团队”，通过组织重新设计形成特性团队，而特性团队就避免团队之间的依赖。
什么是SAFe和LeSS
我的看法是，SAFe和LeSS都是尝试解决规模化问题的方法，SAFe偏重于企业/组织级别，方方面面都去考虑，给出方法，所以它的定义比较厚重；而LeSS偏重于对准需求开发直接开动，面向产品和需求领域，讨论扁平化的组织，核心角色是管需求的PO和APO，管实现的Feature Teams以及推动敏捷的ScrumMaster等。我认为吕毅老师在对待这两种解决团队间依赖方法的看法有些偏差和对SAFe有一些误解。
首先SAFe4.0是一个三层（团队层，项目群层和投资组合层）或者四层（团队层，项目群层，价值流层和投资组合层）的结构。它最重要的基础就是团队，SAFe4.0中强调团队可以是一个自组织、跨职能的Scrum团队或者看板团队，并且强调团队通过“故事”交付价值，没有任何东西可以击败这样的一个团队，也就是说没有“好人”是不行的。另外在SAFe中没有直接定义团队为特性团队，而是以“复杂”的企业和产品上下文为基础，来探讨各种纯组件团队，纯特性团队，以及混合团队的不同场景。但是仍然强烈推荐和倾向于特性团队。
其次SAFe在敏捷团队建立之后，如何解决多团队间依赖问题呢？它采用对齐产品/解决方案的愿景，统一的以及不同层级的Backlog(Epic->Capability->Feature->Story)，同步的、节奏相同的迭代，这个开发叫做按节奏开发。并且在相对一个迭代较长周期的时间盒PI，规划发布计划，而这个发布计划和PI时间盒是解耦的，这个发布叫做按任意时间发布（SAFe4.0以前叫做按需发布）。并透明的识别、可视化管理团队间的依赖。
最后SAFe在做计划的时候，是将50-125人相关的各敏捷团队以及利益相关者组成一个敏捷发布火车（Agile Release Train, ART )，整个火车上的人一起进行为期2天的项目群增量计划，在这个期间，识别各团队之间的依赖以及里程碑和项目群风险。
所以吕毅老师针对SAFe不是特性团队的理解有些误解，尤其是提到的一个案例是采用SAFe的时候是组件团队，后来采用LeSS组成特性团队，这是完全不可思议的一件事情，因为无论什么方法，任何一个敏捷团队或者Scrum团队，我们敏捷实践者都会将团队默认为特性团队（看板方法除外，它没有定义团队），除非有很强烈的原因进行妥协，例如平台战略，那么有可能是一个小团队是组件团队做平台，而多个其他团队是特性团队，每个团队都会依赖于这个平台。
并且SAFe定义团队是Scrum团队（或者看板团队），而在Scrum Guide里面没有定义特性团队，同时LeSS定位自己为纯的Scrum，所以从这个角度来SAFe和LeSS的方法都是基于Scrum的。所以不能说因为没有强调特性团队，就说不是Scrum，也不能说管理团队依赖不对，因为LeSS也采用了一些方法管理依赖和协调，例如会议，尽管它强调不要由Scrum Master来管理，而是团队的责任，并由团队定义协调机制；而在SAFe4.0里明确提出ART Sync同步协调机制，如SoS
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
