转载

Andreas Schliep问答：关于ScALeD——大规模敏捷和精益开发

Andreas Schliep提到，在组织中引入和集成敏捷方法，应该认为是一个敏捷项目，并相应地去对待。ScALeD的意义是大规模敏捷和精益开发（Scaled Agile and Lean Development），它提供了一系列原则，可以根据它们来检验敏捷方法或框架。Andreas把ScALeD称为“一种参与者驱动的活动，可以帮助企业找到一种合理且平衡的方法来进行敏捷转型，解决大规模的问题”。

Andreas将会在企业大规模敏捷会议2015 （将于2015年1月22日在比利时布鲁塞尔举办）上发表关于ScALeD的演讲。这次会议由比利时敏捷联盟发起，UNICOM主办。InfoQ将会参加这次会议，采访并发布新闻和文章。

InfoQ采访了Andreas，谈到了试图实施大规模敏捷时的陷阱，还讨论了ScALeD，以及它和Agility Path、LeSS、SAFe和DaD之间的对比，此外还涉及到持续改进和大规模回顾会议。

InfoQ：在组织试图实施大规模敏捷的时候，会出现一些陷阱，可否请你对其进行一下描述？

Andreas：变得更加敏捷是一种挑战，而且是一项很危险的任务。很多组织都没有意识到这一点。有人听说在其他组织中获得了非常大的成功，所以想要在他们自己的环境中也引入并应用“成功攻略”，然后会很奇怪为什么没有得到想要的结果。这种努力和当年采用精益的历史类似，那时很多公司都试图复制丰田生产系统的实践，但却不知道其中的原则，也就没能获得想要的价值。精益和敏捷不一样，但在本质上却是一致的。缺少理解会导致在自身的环境中不适用，特别是在经常变化的环境形势下。对变化的情境做出快速调整的能力可以叫做敏捷性。如果你采用了这个流行语，但并不了解它的意义，那么任何不稳定的因素都会打破你看上去很美的结构。

一些典型的扩展陷阱都是由于缺少理解和不想变得敏捷造成的，如下：

因为过程而进行角色分配：产品所有者并非真的是产品的所有者。Scrum教练并不真的是要帮助自组织的团队变得更加成功，而只是项目经理戴了一顶新帽子。
角色“优化”：大规模扩展看起来是一个很好的机会，可以节省“支持性”角色的成本。我们可以让一名Scrum教练支持四个团队。我们可以把团队主管和产品所有者的职责合并。
远程控制：大规模扩展经常出现在分布式的工作情境之下。几名Scrum教练和产品所有者不会在同一地方和他们的团队一起工作，而是要和位于不同地点的团队协作。尽管这对产品所有者可能还有效，但对于Scrum教练和敏捷教练来说，肯定是不行的。
不易变化的职位：某些敏捷方法，像Scrum，要求组织从本质上改变。这是不可能的，这至少会受到层级关系和不同的职级的阻碍，像企业架构师、高级业务分析师、首席安全专家和项目经理等。
错误的关注点：大规模敏捷或者对敏捷扩展都是可能做到的。但那可能并不是真实问题的解决方案。对很多公司来说，如果降低规模或者重新组织一下开发团队，就会变得好一些。敏捷产品开发是关于构建正确的产品来让客户惊喜的，而不是产出更差劲儿的产品。

InfoQ：在企业大规模敏捷大会上，你会发表关于ScALeD的演讲。可否请你简单说明它是什么？

Andreas：首先， ScALeD即大规模敏捷和精益开发（Scaled Agile and Lean Development）并不是另一种大规模敏捷的框架。我们认为，ScALeD主要是一种参与者驱动的活动，可以帮助企业找到一种合理且平衡的方法来进行敏捷转型，解决大规模的问题。它受到了精益和敏捷价值观的启发，由原则驱动，并通过各种实践和框架来完成。我们主要的任务是让组织中的人们意识到敏捷性意味着什么。

ScALeD的核心是十三条原则，分为五大支柱。ScALeD的支柱或者概要重新组合了主要的精益价值观：

激动的客户
幸福而高效的员工
全员优化
支持性的领导
持续改进

原则来自于精益、敏捷软件开发宣言、Scrum和系统化思考。不管你的组织生产的是什么，也不管它有多大，对于给定的情境，原则都可以应用。如果你阅读他们的话，会发现其中甚至都没有说太多关于大规模扩展的内容。所以，ScALeD本身不会告诉你如何处理二十个团队共同开发一个产品的问题。但它可以帮助你确定，你的方法是否支持或者违反了基本原则。

InfoQ：团队和组织可以做些什么来保证，在试图实施大规模敏捷的时候持续改进？

Andreas：敏捷过程依赖于短促的反馈周期。即便你不想要或者不需要产品开发迭代，但我仍然强烈推荐定期进行检查和调整。这一般是通过回顾会议实现的。依据ScALeD，以及下面将会提到的多种大规模框架，这种改善周期不能仅限于团队级别。把敏捷方法引入和集成到一个组织中，不应该依据计划实施一个框架，而应该认为其本身就是一个敏捷项目，并依此对待它。敏捷组织级开发假设下一次总有机会可以在某些方面做得更好。敏捷组织级开发需要一位负责人以及一位产品所有者，后者会关注并负责变化的规模和频度。它需要一个经常维护、按优先级排序的改善选项的有序backlog。然后组织级的开发团队会以自组织的形式，解决那些改善方法、问题、事件，并为更好的组织产出产品的增量。

InfoQ：对于大规模敏捷有多种框架，像Agility Path、LeSS、SAFe和DaD。可否请你提出建议，组织可以选择哪个来使用，从而调整和实施大规模敏捷？

Andreas：这些框架中有些从总体看起来非常好！ ScALeD总体上是空白的，但这真的是有原因的。我们建议每个人都要首先理解价值观和原则，然后再看框架和过程。在这些框架中有大量知识和智慧，但它们并不是“可以安装”的即时可用的产品，你可以买过来就能用。正如George Box所说：“所有模型都是错的，但有些有用。” 所有这些模型都有用。DaD很强调软件的质量。SAFe更适用于传统型组织，它有助于协调不同的组织模型。Agility Path很强调原则驱动，在持续改善方面更强大。LeSS和我们的ScALeD想法最为接近，Bas Vodde和Craig Larman对ScALeD的基础有很大启发。

然而，所有这些模型都面对的是已经敏捷的组织，就像是塑化模型和真正的人体之间的关系。它们可以对其有启发，可以告诉你很多关于结构和解剖学的知识，但如果你对活体器官不了解，那么就无法正确地做事。然而，从另一个方面看，你仍然可以从SAFe和其他框架获得很多实践试验以及最初的组织设定方面的知识。我们总结出一些结果，根据他们对ScALeD原则的实现状况来对比大规模框架，那可以让你对每个框架的优势和弱点有初步的认识。例如，这个比较结果在持续改善方面会把Agility Path放在DaD前面，因为Agility Path把持续改善作为主要的敏捷转换开发周期，而DaD主要在团队级别包含了回顾会议，更依赖于经理和指标。

InfoQ：你对在大规模敏捷环境中使用回顾会议有何建议？

Andreas：对于成功的团队和组织范围内的持续改善来说，回顾会议是核心元素之一。为了更好地使用这种工具，我们需要确保在各个层级拥有技能丰富、训练有素的引导师。仅仅拥有企业敏捷教练、CSC什么的并不够，他们只是偶尔会和整个产品组织一起执行很好的回顾。Jimdo是正规回顾会议引导师教育的很好例子。不管特定的过程如何，每个团队都至少有一名成员能够执行回顾会议。团队回顾会议可以为组织级的变更backlog提供基础信息。理想状况下，他们会得到整理好的改善故事，以及“组织级的验收测试”。转型或者变更团队可以直接使用它们，对其排序，以获得组织中最好的可能出现的积极影响。

我的愿景是把“行为驱动组织级开发”确立为基本的PDCA循环。团队会提出改善建议。建议会在团队代表、利益相关者以及转型团队成员之间讨论。他们都会深刻了解执行项目，并且有清晰的验收测试。变更是由转型团队“创建”的，并给组织演示，以找到新的改善机会。这个循环会花费不超过二到四周。在演示了实现的组织变更之后，转型团队当然也会举行自己的回顾会议。这对于确保工作模型没有变得僵化依然敏捷非常重要。从而可以在组织级的情境中对意料之外的变更做出响应。

Andreas为想要了解更多大规模敏捷和精益的人推荐了以下阅读链接：

正文到此结束