4种规模化敏捷法比较:LeadingAgile,SAFe,LeSS,DaD

不仅是小公司团队在敏捷转型，如今大型企业也想更加敏捷。本文比较了LeadingAgile规模化敏捷开发的几种方法，分别是SAFe 、LeSS、DaD。了解它们的优缺点，何时发挥作用，如何进行选择应用。

当大型企业争相把敏捷软件开发应用于企业面临的挑战时，了解不同方法的优缺点十分重要。比较LeadingAgile 大规模敏捷 开发的几种方法： SAFe 、LeSS、DaD。全面了解它们的优缺点和作用。

2001年，当敏捷宣言正式面世时，它将几种方法（有时称为“轻量级方法”）组合在一个旗帜下。Scrum、DSDM、ExtremeProgramming（XP）和Crystal都是“敏捷”的，因为它们符合宣言的精神。这些方法使小团队能够尽其所能地完成工作，摒弃低效的文字沟通，将客户的声音融合到日常工作中。

小团队适用的方法自然只适合小团队。如今，一些大公司也希望向更敏捷的方法迈进。他们感兴趣的是传统方法的延伸，拓展为更大的团队和更强的协调能力和更严谨的监督系统。他们也在方法中引入了风险。对于整个IT部门来说，一个进行了几个月的涉及整个IT部门的实验失败了比只涉及一个团队的实验失败了要可怕得多。

多数大型组织致力于单一的软件开发框架。而那些极力想要同时采取所有方法的最好部分的公司，仍然抱有这样的愿景。无论如何，作出正确选择的前提都需要先理解这些所有方法，清楚知道它们的优劣势，以及何时和如何让方法发生作用。（Runwis能提供什么？敏捷管理训练营或许能给你和团队一些思考和快速实践）接下来，让我们了解更多。

一、Scrum和极限编程（XP）

一个团队一次只执行一个项目（至少，我们希望他们这样做）。然而一家企业可能同时进行几个项目，大项目将由部门下大多个团队或多个部门下的众多团队共同完成，这些团队可能在不同的地方工作。这类工作将需要协同合作。大型企业通常希望松散、紧密的耦合：让团队自由创新、同时又能够创造足够多的共同目标，使跨团队协作变得更容易。这时，管理项目的进程、计划、项目整个工期都将变得更加复杂。

接着是转换到敏捷方法所遗留下来的历史问题。某《财富》500强连锁酒店中一位高级经理将开发进程描述为“一次电话会议上，十几个人在5小时内不断上线下线”。

二、SAFe（Scaled Agile Framework）可扩展的敏捷框架

Dean Leffinwell的规模化敏捷框架（SAFe）的流行使得寻找培训或咨询变得更容易。网上有许多关于可扩展敏捷开发的文章、教程和视频，认证过程清晰且成熟。对于企业而言，转向SAFe并非难事。SAFe也会清晰地告诉企业应该干什么。

一位来自《财富》500强公司的项目经理评论说，如果不了解每个保险箱的优点，高级管理层往往会采用所有的IT，包括团队工作、项目工作、“业务史诗”、“技术史诗”、各个级别的指标和一系列其他要求。所有这些额外的部分实际上都会增加组织的复杂性，这与采用敏捷的目标背道而驰。一位来自《财富》500强企业的项目经理评论说：在不了解SAFe所有优点的情况下，企业高管倾向采用全套SAFe，包括团队合作、项目合作、“业务Epics”、“技术Epics”、不同级别的衡量标准及其他要求。所有这些额外的部分会增加企业的复杂性，这与采用敏捷开发的目的背道而驰。

 

容易。这时，管理项目的进程、计划、项目整个工期都将变得更加复杂。

接着是转换到敏捷方法所遗留下来的历史问题。某《财富》500强连锁酒店中一位高级经理将开发进程描述为“一次电话会议上，十几个人在5小时内不断上线下线”。

三、LeSS （Large Scale Scrum）敏捷框架

大规模Scrum（LeSS）实际上是扩大Scrum中的活动，将其应用于部门层级。在LeSS中，大规模的计划需要每个团队一到两名成员召开第二次会议；每天会有与Scrum相同的每日站会。“整体回顾会”在冲刺结束后的一周进行，同样，它从每个团队中抽调代表来讨论整个项目的问题。除此之外，LeSS还增加了开放空间、市政厅会议等协调沟通活动。

两到八个团队的正式规则放在页面的前面和后面；一千人的产品团队的版本不太大，也不太大。LeSS的联合创始人克雷格拉曼（Craig Larman）声称，大型组织通过单一功能组、工作交接和缓慢的反馈增加了不必要的复杂性。“与其引入一种方法在上面的方法中添加创可贴，不如尝试改变组织设计，创建全能型功能团队。这些想法与传统的部门形式的组织设计是相互矛盾的。

四、DaD 规范敏捷交付

Scrum设定了一个正在工作的团队，但没有说明该团队从哪里来或者如何做出“零迭代”决策，比如基础技术平台、编程语言和结构。

这就是Scott Ambler的规范敏捷交付（DaD），包括项目的开始、结构和团队形成，到最后的产品生成、运营使用和支持。Scrum致力于让团队处于维护模式，而DaD则不，DaD给团队时间来决定平台、构建工具、做项目计划和准备迎接产品开发和维护时所面临的挑战。

五、Leading Agile 规模化敏捷

LeadingAgile成立于2010年，其总部在亚特兰大，作为一家负责提供敏捷转化的大型企业，迅速得到国际盛誉。

与“大规模敏捷开发”不同，LeadingAgile提供了一个“转化框架”，这个框架首先评估企业的规划目标，负责预测可能性和测试适应性。这种方法需要了解产品功能是可体现（基于市场的需要）还是不可体现（在固定的时间间隔推出一定的需求和功能）。

然后LeadingAgile根据当前的业务驱动因素提供指导，进而提升交付，同时打下基础以实现IT部门支持未来业务的目标。

该企业组织的团队称为“远征队”，通过“Basecamps”循序渐进，通过提升自身必备的技能来慢慢提高业务水准。LeadingAgile的首席执行官Mike Cottmeyer称这是一幅“转换路线图”，因为LeadingAgile的重点在于调整目标，创造透明度和提高业务水准，而不是用抽象难懂的框架和规则。

 

六、 大规模敏捷 框架的缺点

项目投资管理和策略顾问Adam Yuret指出，大规模框架不能阻止企业高管亲自研究说明书和故障表。

 

七、 大规模敏捷 框架的替代品

在前文介绍完三巨头和LeadingAgile之后，接下来介绍一些小型的缩放框架和方法。Sam Laing的动态小型Scrum（Slim），针对LeSS所设计。

本文作者也是企业可持续文化敏捷发布（SCARE）的创建者。SCARE是基于成功的可伸缩项目所研发出来的，它约束了敏捷理论的应用。Ron Quartel最近在敏捷会议上宣布了他的“快速敏捷”，主要关注于通过使用类持续性开放规划会议来提高大型团队的集成速度，从而减少浪费。

八、谁会使用 大规模敏捷

项目投资管理和策略顾问Adam Yuret指出，大规模框架不能阻止企业高管亲自研究说明书和故障表。

他补充道：“他们不仅是在浪费时间，而且作为一位高层，这样的行为容易给企业中层管理人员带来不良影响，让他们觉得他们也可以这么做。最后导致程序员从不同人的口中得到不同的指令。”Yuret的解决方案不是提供一个框架，而是战略部署。在战略部署中，领导层把工作意图说清楚，然后相信自己的团队能把任务完成。

其他几位领导人，包括Arlo Belshee、Matt Barcomb和Alistair Cockburn，已经提出了“大规模缩框架”的替代品。“团队之间不会一味地依赖技术。每个团队都能体现自己的价值。团队在工作时不会为内部带来麻烦。他们研究出来的产品都是完美无瑕的。”

并不只有Belshee持有这一种观点。

一位叫Matt Barcomb的敏捷教练，同时也是Taxware前产品开发副总，他指出虽然“大规模”问题听起来很难解决，但是这通常意味着：传播、协调或联盟。

Barcomb解释道，我们所认为的大企业的问题，是很好解决的。“他们都在某一领域已经获得成功，并且需要更大的团队帮助他们获取更大的成功（这就是传播）；或者他们有一个多团队项目问题，需要用到Rothman的书或者投资看板方法和给基于流的路线图的概念去解决问题（这就是协调）；再或者企业高管因为下属没有完成目标或者绩效不及格而感到沮丧（这就是联盟）。他们通常会多加控制，通过更多的方法‘框架’来解决问题，但是结果往往背道而驰。”

类似于领导敏捷，Barcomb的方法就是识别差别所在，并通过逐渐的提升来减少差距。

最后来介绍的就是Alistair Cockburn，他组织了雪鸟会议。敏捷宣言正是在雪鸟会议上制定出来的，而Alistair Cockburn也被认为是贯穿雪鸟会议整个过程的主导人物。

起初谈论到大规模敏捷开发框架时Cockburn有些犹豫。后来，谈到“敏捷的核心”，就是在企业中敏捷的核心为：

不管在什么情况下，如何加强合作？考虑到其他的因素，你如何增加潜在客户和实际用户？如何让人们放下手上的事情思考周边发生的一切？员工如何在企业的不同部门获得进步？

上述问题的目的在于帮助企业在追求敏捷性的同时，作出该做哪些改变的决定，同时这些改变是立足于企业实况的，而不是依赖于其他人的建议。简而言之，他们专注的是应对一切突如其来的改变，而不是按部就班地执行计划。

 

九、几种方法融会贯通

领先的SAFe为大型IT企业提供了可以变身成为大型的敏捷团队的方法。LeSS也如此，不过更多的是关注于改善团队之间的沟通。Belshee建议从建立配置高的敏捷团队开始，团队可以定期发布软件，改善规模问题。而其他敏捷顾问则更多地建议企业作出小改变以此更好地适应敏捷转型。

只要我们真正找出企业真正想要解决的问题，那么任何一个方法都比其他更有用。

文章来源：

《SaFE vs LeSS vs DaD vs LeadingAgile: Comparing scaling agile frameworks》Matt Heusser，2015-08-21 05：49 AM

更多推荐阅读