Scrum之外至少两个精益/敏捷开发框架并解释它们的价值
一、大规模敏捷开发框架LeSS
参考 https://less.works/zh-CN
LeSS is Scrum applied to many teams working together on one product.
LeSS is Scrum—Large-Scale Scrum (LeSS) isn’t new and improved Scrum. And it’s not Scrum at the bottom for each team, and something different layered on top. Rather, it’s about figuring out how to apply the principles, purpose, elements, and elegance of Scrum in a large-scale context, as simply as possible. Like Scrum and other truly agile frameworks, LeSS is “barely sufficient methodology” for high-impact reasons.
Scaled Scrum is not a special scaling framework that happens to include Scrum only at the team level. Truly scaled Scrum is Scrum scaled.
applied to many teams—Cross-functional, cross-component, full-stack feature teams of 3–9 learning-focused people that do it all—from UX to code to videos—to create done items and a shippable product.
working together—The teams are working together because they have a common goal to deliver one common shippable product at the end of a common Sprint, and each team cares about this because they are a feature team responsible for the whole, not a part.
on one product—What product? A broad complete end-to-end customer-centric solution that real customers use. It’s not a component, platform, layer, or library.
“LeSS is Scrum applied to many teams working together on one product.”简单说LeSS依然是Scrum，依然是那三个角色，三个工件，五个会议。LeSS框架想要解决的问题是如何将Scrum的原则，元素尽可能简单够用的使用到多个团队，合作开发一个产品的场景里去。LeSS框架分为两类：LeSS以及LeSS Huge，超过8个Scrum团队的时候使用LeSS Huge框架。当然在实践的过程中需要考虑产品负责人以及Scrum团队成熟度适当调整，理论总是要联系实际。
1、长期稳定存在，长期的合作利于打磨高效团队，质量和效率稳定可预见。
2、跨技能，团队成员技能中包含前端，开发，测试等多种技能。
3、跨组件，团队覆盖的范围同时横跨多个组件。
4、团队能独立完成客户价值交付。
5、团队间协调合作从项目管理域转移到代码技术域。
团队自身结构设计好了，接下来需要考虑团队间沟通协调方式。团队间沟通协调方式会受到产品需求组织方式的影响。团队将要开发的DevOps平台是一个非常复杂的产品，涉及的需求领域很多，比如环境管理，应用管理，版本管理，持续集成等，同时这是一个从0到1的过程，每个需求领域都有着充足而稳定的产品需求，并且每一个领域都需要一定的领域背景知识才能更好的设计实现产品，所以笔者决定划分为4个产品需求领域：环境，应用，版本，持续集成。在LeSS里是没有需求领域的，需求领域是LeSS Huge里的概念，当团队个数大于8个的时候建议使用LeSS Huge，并且区分需求领域，每一个需求领域里依然是LeSS工作方式，同时增加APO角色负责一个需求领域。
Scrum是敏捷世界里广泛使用的一个框架，简单，易懂但难于掌握。LeSS是大规模敏捷开发世界里一个常用的框架，它的本质上依然是Scrum，它想要解决的问题是如何将Scrum的原则，元素尽可能简单够用的使用到多个团队，合作开发一个产品的场景里去。组织的很多问题根源在于组织结构设计，相同的结构设计上往往存在相同的问题。没有合理的团队设计让产品研发事倍功半，而有了合理的团队设计让团队事半功倍。团队设计是影响团队绩效的一阶因素。世界上没有所谓的最佳实践，没有所谓的银弹，有的仅仅是在特定的上下文里合适的实践和方法。
二、大规模敏捷框架SAFe
参考 https://www.scaledagileframework.com/safe-lean-agile-principles/
Scaled Agile Framework® (SAFe®) empowers complex organizations to achieve the benefits of Lean-Agile software and systems development at scale.
企业敏捷 Scaled Agile Framework (SAFe) 是一个大规模敏捷框架，它不仅包括团队敏捷，还包括了价值流、投资组合、项目集等层级的敏捷管理方法和架构。它基于精益和敏捷的最佳实践。SAFe 框架可以分解为团队层、项目集层、投资组合层、价值流层。
1、基于精益和敏捷原则。
2、为企业价值流、投资组合、项目集和团队提供详细的实施指导。
3、最大限度为企业利益相关者提供价值。
SAFe 可以处理大规模复杂的应用开发，使用 SAFe 可以获得以下好处：
1、生产效率提升 20-50%。
2、质量提升大于 50%。
3、产品发布缩短 30-75%。
4、员工满意度度和忠诚度提升。
大规模敏捷框架（SAFe）的适用条件：
1、实施敏捷的范围包括多个投资组合、多个项目组团队。
2、多个项目团队都在实施敏捷研发，项目组经常遇到障碍、延迟、甚至失败。
3、多个项目团队之间的工作任务相互依赖。
4、想在整个组织范围内实施敏捷，但又无法确定需要什么角色和岗位。
5、想在整个组织范围内实施敏捷，但又不知如何在业务部门、投资组合层、项目集层、研发团队之间建立连续一致的策略。
6、组织想提高产品研发效率，在同行业竞争中获得优势。
SAFe 和其他敏捷实践的差别：
1、SAFe 是一个免费使用的敏捷框架。
2、AFe 有大量的说明材料可以获得。
3、SAFe 是一个经过实践证明实用的敏捷框架，适合大规模应用。
4、SAFe 会经常根据实际的实践经验进行更新。
5、SAFe 对于敏捷实践可扩展性强。
6、SAFe 适用于团队和整个企业。
7、SAFe 为这个软件研发生命周期提供了蓝图。
8、SAFe 对于组织的各个层面都是可视化的。
9、FAFe 可持续推进软件质量的提升，并获得反馈。
