本文继续介绍LeSS与SAFe的不同点。
区别三：关于公共/赋能团队的存在
LeSS没有诸如架构、业务分析、配置管理、持续集成支持、“质量和流程”或PMO等支持/公共/赋能团队：LeSS组织倾向于通过扩大现有特性团队的责任（例如敏捷团队成员的角色包含需求分析师、UX（用户体验）、架构师、开发、质量、配置工程师、系统工程师等）来涵盖这类支持工作，而不是创建包含各种专门小组的更复杂的组织。因为专门的支持小组往往拥有自己的领域，这会导致他们变成一种瓶颈。
LeSS更强调在团队迭代完成的时候交付更完整的产品，包含产品说明书等。很多需要敏捷团队完成的工作，但是暂时无法在团队中完成的工作，定义为“团队未完成的工作”暂时由未完成部门完成，这些部门是要被逐渐优化掉的。例如：诸如QA、架构或业务分析等未完成部门永远不应存在于小型LeSS框架组织中，而应该一开始就集成到特性团队。
LeSS更注重用户视角的产品或者业务特性，关于系统的本身的健壮性（例如架构整体设计、基础平台建设等、DevOps等）的工作更多交给敏捷团队的积极主动。关于跨团队技术标准/协议的建立，设计的优化等工作，鼓励建立相应的社区来互相讨论交流，比如架构社区，但社区不能为团队做出决策定，其产生的内容，由团队决定是否去采纳。
在SAFe中重点考虑了使能特性（关于系统的健壮性）与业务特性平衡的问题，他将架构团队、系统工程团队、共享服务、PMO等团队合法化，作为需要存在的角色，并保留了项目的概念。
SAFe中强调了架构跑道的重要性，扩展架构跑道相应的使能由各层级的架构师/系统工程师负责。这种跑道为开发业务举措和实现新特性或能力提供了必要的技术基础。
敏捷开发提倡浮现式设计的概念——敏捷架构演进流程提倡仅仅在需要的时候，才对设计进行发现和扩展，从而可以实现和验证下一个功能的增量。
这种实践方法在一定程度上工作得非常好。但是随着敏捷实践成熟度的提高，越来越多的大型团队和规模化团队采纳了这种方法后，一些问题也相应出现了。主要体现在浮现式设计对复杂的大规模系统开发的反馈不足。以下问题也就逐渐暴露了出来：1）过度的设计返工和延迟，出现了流动瓶颈问题2）使用不同的架构组件支持相同的能力，增加了维护成本3）团队之间的协作和同步减少了4）速度降低了5）系统很难进行集成和验证6）系统的质量退化（非功能性需求）7）系统组件可重用性低，实现中出现了冗余最终结果导致解决方案性能低下，经济效益差，产品上市时间缓慢。
让敏捷团队预测发生在他们所处环境之外的变化是不可能的，同样让单个团队理解整个系统来避免冗余生产和设计实现的冲突也是不现实的。简而言之，一个大型企业中的团队是不可能看到全局的，让团队去预见未来发生的变化也是不合理的，因为很多变化在他们的可控范围之外。
SAFe中基于这种原因，提倡团队进行意图架构——这是一组有目的的、计划好的架构，能够提高解决方案的设计、性能和可用性，同时为跨团队设计和实现同步提供指导。这些使能可以创建/扩展所需要的架构跑道，有助于团队更快、更可靠地交付业务价值。使能通常由架构师或者不同级别的系统工程师来定义，在价值流层和项目群层由系统和解决方案架构师/工程师来负责，在投资组合层由企业级架构师来负责。
意图架构和浮现式设计结合起来，就可以促进项目群创建和维护大规模的解决方案。
以上内容参考自：
1《大规模Scrum：大规模敏捷组织的设计》作者：克雷格·拉尔曼巴斯·沃代
2https://www.scaledagileframework.com/#，和《SAFe4.0 参考指南》
未完待续。。。
