让组织动起来——规模化敏捷框架SAFe
2019-12-05
来源： BoostAgile 王威
敏捷理念已经成为成为软件开发业界的共识。敏捷已经从个别小团队的自行实践，扩展到组织层面的转型。然而目前最广为人知的敏捷框架——Scrum，是针对小团队的；对于如何在组织层面上实施敏捷，Scrum仅仅是语焉不详地提了一句“可以做Scrum of Scrums”。这对于一个几百上千人的组织系统地采纳敏捷，是远远不够的。
因此近五年来，一些敏捷先驱者和思想领袖经过实践，提出了几种规模化敏捷开发框架。其中比较有代表性的有Scaled Agile Framework （SAFe）、Disciplined Agile Delivery （DAD）、Large Scale Scrum （LeSS）等。与其它几种规模化敏捷框架相比，SAFe有着无可比拟的优势，这体现于：
详尽的在线文档：SAFe全部内容都可以在其网站（http://www.scaledagileframework.com）上免费获得，每一个概念和实践都有系统的阐述；
大量案例分析：目前有千余家大型组织采用SAFe框架，许多组织都把其采纳SAFe的过程和心得记录下来，分享在SAFe网站上，对于新采纳SAFe的组织而言，这是很有价值的信息；
成熟的培训体系：全球几百名经验丰富的SAFe培训师，可以提供4个级别的培训，帮助组织快速进入敏捷变化通道；
让组织动起来：SAFe最大的价值之一是，它将产品管理团队（Product Management Team）、架构师、发布管理团队、运维团队、以及高层管理者等角色都纳入到其框架当中，为其描述了如何在敏捷框架下高效地工作，与开发团队一起更快地交付高价值、高质量的产品增量。
SAFe从三个层次上描述了如何采纳敏捷开发：团队级别、项目集（Program）、项目组合（Portfolio）。
SAFe在团队级别上采用的是Scrum+部分XP实践的方式。对于小团队的敏捷实践，Scrum是非常成熟且行之有年的框架，许多小团队都采用Scrum或类Scrum的方式运作。因此从小团队的Scrum实践，扩展到多团队协作的SAFe实践，团队的学习成本是很低的。为了保证团队能够协作，SAFe在团队中强制性引入了几个极限编程实践：持续集成、自动化测试、测试驱动开发。这些实践能够确保开发质量，进而交付速度。
在项目集上，SAFe将中层管理和非开发团队纳入了敏捷框架，这是SAFe对敏捷的重要贡献，也是其它规模化框架所不具备的。在以Scrum为首的小团队敏捷框架中没有中层管理者的位置，这让他们显得非常尴尬：不采纳敏捷是不对的，采纳敏捷就要干掉自己的饭碗。因而中层管理者和产品管理团队往往被比喻为敏捷改进中的“永冻层”。SAFe把这些角色纳入到敏捷框架中，重新定义了其职责，并描述了这些角色与开发团队之间的关系和协作模式。当中层管理者们看到了其在敏捷框架中的位置和价值，“永冻层”自然也会融化，使得整个组织都积极地朝着敏捷前进。
项目集层面上，所有的团队、中层管理、产品管理团队、架构师、运维团队等都在一个敏捷发布火车（Agile Release Train, ART）上。所有的成员都朝着一个目标（产品的愿景和开发路线图）前进，同时启动（Sprint计划会议），同时停止（Sprint Review + Retro）；以每5个迭代/10周为一个增量（Program Increment, PI），协调团队之间的协作与依赖关系，确保及早发现风险和问题。SAFe把架构设计也纳入到敏捷发布火车，提出了架构跑道（Architectural Runway）的概念，很好地解决了敏捷社区争论已久的“过渡设计 vs. 涌现式设计”困扰。
在项目组合层面上，SAFe描述了高层管理者应该如何管理组织未来3 - 5年的战略规划。战略规划转化为预算，获得预算的敏捷发布火车按照战略规划制定愿景和路线图。火车高速前进的同时，通过SAFe推荐的度量模型，高层管理者可以从员工参与度、客户满意度、生产效率、敏捷性、发布时间、质量等多个方面得知团队和项目集的运作状况。提高透明度有助于提高团队和敏捷发布火车的自组织性，进而帮助组织真正地用敏捷的方式工作（即Being Agile），而非把敏捷当成流程（所谓的Doing Agile），从而确实地从敏捷中获得价值和益处。
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
