在SAP应用看板的经验

在中欧精益看板大会上，Alexander Gerber和Martin Engel分享了它们在SAP应用看板两年多以来获得的经验。他们展示了如何为大型软件企业的开发部实现精益和敏捷过程提供支持。这是中欧对精益和看板的案例研究之一，InfoQ曾经在2013年对此进行过报道。

InfoQ采访了Alexander和Martin，内容包括看板是如何引入SAP并为之所接受、培训方法以及使用看板实践的团队的经验。

InfoQ：之前在LKCE 2011上关于软件看板的演讲中，你们就谈到了在SAP如何开始实行看板。你提到了David Anderson：“开始实行看板的重点在于尽可能小地改变”。很多大型组织都习惯于做大型的变更项目。在SAP，人们是如何接受看板方法的呢？

Alexander & Martin：我们在SAP并没有引入关于看板的大型变更项目，在此之前就已经完成了“大爆炸”：早在2008年我们就开始引入精益思想和敏捷开发方法，其中包括Scrum在内。这对于我们在三年后——大约2011年前后——引入看板是非常重要的基础。

我们遵守了“从你确信了解的地方开始，开始时尽可能小地改变，提交以产生革新，以递增的方式变更”原则，所以没有全面铺开，建议所有开发团队采用看板，而是将其提供给一些特定类型的团队——例如专注于维护或者运营的团队，作为另一种可选的方法。对于公司内大多数专注于开发的团队，我们建议继续使用Scrum作为标准的过程框架。

一般来说，我们提供的看板方法已经被目标受众温和地接受。我们已经培训了大约50个团队，并不断有团队请求为其开展看板培训。另外，我们的“精益和敏捷核心团队”并不是把看板引入SAP的唯一途径：在我们的大型生态系统中，有很多团队自行找到了采用看板的方法，并从其他途径——像会议——学习到了关于看板的知识。然而，一个成功的因素就是，我们在SAP内部组织的所有对看板感兴趣的人都可以参加的关于看板的定期经验交流。

InfoQ：你使用看板从当前所处的状况开始改进。大型组织中的团队在使用的实践方面会有很大不同，通常在经验层次、文化等因素上也会有所不同。你们的看板项目是如何处理这些差异的？

Alexander & Martin：这涉及到我们的培训方法很重要的一个方面：一方面，我们提供了David Anderson标准化了的看板信息；因此我们是“根据书籍来培训看板”，对所有人使用的同样的原则和实践。另一方面，我们所提供的看板培训具有三层架构，特别是我们的“看板工作坊”，对于培训的每个团队的特殊需求和兴趣都留出了足够的空间。所以并没有对所有团队都采用同样的“一种规模适合所有”的解决方案。在下面讨论所提供的看板培训的细节时，我们会对此做更加详细的说明。

因此，我们向团队强烈建议了一些核心内容，像定期做回顾会议，每天（或多或少）召开会议来做简短的信息同步，拥有一位引导师，等等。但对于如何实现这些内容的细节，我们还是非常自由的。例如，大多数团队会从Scrum教练的角色开始看板转型，他会逐渐转变为看板引导师的角色；这项革新在细节上如何完成完全取决于团队，经常最原始的角色任命（像Scrum教练）都会保持不变。类似地，董事会代表权的工作流、过程政策等等，通常都会因为团队不同而不同。

这样，我们试图反映出经验的层次，以及在我们的大型开发组织中创建的不同文化和实践。

InfoQ：改变团队的目标是实现“对精益和敏捷方法稳定而持续地实现”。你们达到目标了吗？ 为了达到目标你们做了什么？

Alexander & Martin：考虑这个问题的一种方式是：“我们团队中的开发者会怎么说？” 回顾一下五年前，当我们开始引入精益思想和Scrum的时候，团队成员提出了很多顾虑，我们的精益和敏捷核心团队（以及其他团队）确实做出了一些工作来回答那些问题，并处理那些顾虑。在早期我们需要努力做的事情，大概可以推测为：在我们的开发组织的很多部门里，对于精益和敏捷，人们会有通用的语言，他们也会有一系列通用的价值观。例如，现在很多人都同意，对于团队来说，非常需要把对产品backlog排序和评估作为工作的基础。这在短期甚至中等长度的期间内都需要，所以这可以被认为是实际的持续改变的标志。在SAP进行了长达五年的精益转型之后，精益和敏捷的想法及方法论，包括看板，已经深深地扎根在开发团队中，更重要的是，也扎根在人们的思想之中。它们已经成为“我们DNA的一部分”。甚至还有一些非开发团队，例如负责产品支持的团队，也越来越希望采用看板。

我们怎样达到这种程度的呢？ 一个因素肯定是我们“实践了宣扬的内容”。所以，我们不仅仅是在倡导Scrum和持续改进，并且在团队中使用了。当然，对于看板也是一样。

另一个重要的成功要素是，我们同时与管理层以及团队成员合作。我们组合了自顶向下和自底向上的方法，这对我们起到了很大帮助，一方面为我们在培训所讲授的内容搜集了经验并确立了反馈循环，另一方面，在像我们这么大的公司中获得了所需要的强有力的管理层支持。

InfoQ：可否请你们说明一下，是如何使用回顾会议来改善看板的？

Alexander & Martin：我们一般会基于Derby和Larsen在《敏捷回顾会议（Agile Retrospectives）》一书中所建议的方法。通常，我们会每两周做一次回顾会议，但我们并不会完全严格按照这样执行，有时它会被取消，或者有时会在户外举行，大家一起享受冰淇凌。在回顾会议中，我们的目标一直是要确定改善的小区域，并定义清晰的动作项以及决定。有时，我们会为回顾会议做特别的准备（例如，提供看板执行表中特定的数据），有时我们只是收集每个人头脑中“疯狂、悲伤、高兴”的事情。然后会把条目分组并按优先级排序。有时，我们很容易找到对策，有时我们还会使用像“五个为什么”之类的技术。但我们还经常会使用回顾会议作为开放的讨论（控制在一小时之内），其中每个人都可以提出它们关注的问题，但不需要得出接下来要做的任务。对于“团队情绪”，这些非常没有结构的会议会非常有效。

InfoQ：你们是如何进行看板培训的？ 为什么要采取哪种方式？

Alexander & Martin：如果一个团队想要寻找替换纯粹Scrum的方法（例如，维护负担很高的团队、行政团队或者其他非开发团队），我们就会为其提供培训。然而我们不会像Scrum培训那样提供带有详细培训计划和所有内容的结构化培训。我们依赖于一件事物口口相传的效果，另外，看板培训也可以通过我们的标准培训渠道获得。这就是同事们了解看板培训的方式。

培训本身分为三个部分：首先，我们会提供两个小时的信息部分（info session），其中我们会和大家介绍基本的看板话题，像看板的历史（它从何而来，谁是它的发明者），基本的实践以及引入看板的原则。我们使用了交互式的培训方式，它基于Sharon Bowman的《Training from the back of the room》一书。信息部分的目的是让大家得到一些基本信息，从而决定是否想要开始应用看板。如果他们想要应用，那么我们会提供一整天的工作坊，在其中我们会花费大部分时间为这个特定的团队创造出特定的制品（他们的工作流程看起来是什么样子，那可以如何使用看板来建立模型，最初版本的表单看起来是什么样子，要使用哪些度量等等）。这个工作坊的目的是要支持他们达到一种程度，可以在工作坊之后就能够开始应用看板。

最后，我们在工作坊之后还提供了指导，让他们可以克服最初的一些障碍。这可能意味着要参加他们的会议，改善回顾会议，指导团队的引导师等等。总之，这些指导看起来很有用，因为它给了团队一种低投入的方式来发现看板在特定的情境下是否真的帮助了他们。

InfoQ：在演讲的最后，你们提出了一些经过验证的实践。这些实践是什么，是如何帮助到你们的呢？

Alexander & Martin：正如之前已经提到的，回顾会议是最重要也最有用的一种实践。此外，我们还使用“团队宪章”来制定团队的规则，那是一些规范和协议，透明且总是可见（宪章被打印出来并贴在团队房间的一面墙上）。这有助于坚持我们的协议和决定，尽管在某种程度上看起来是一种挑战（确实要做到你的决定…）。有时，我们还会花费一些时间在公司外的地点，进行更深层次的工作坊，例如，当我们需要为下半年制定目标和策略的时候。一旦我们把这和“大规模回顾会议”组合在一起：就意味着我们不仅要回顾过去两周发生的事情，还要回顾在过去一年中发生的最重要的事件、问题和需要着重强调的事情。

另外，我们只是在最近才尝试的另一件事（并且重复了两次）是管理顾问Fredmund Malik建议的一种实践，叫做“减少系统化浪费（Systematic waste reduction）”。它的想法是，对于想要生存的组织，避免“浪费”极为重要。这还会应用在团队和其他组织单元中。所以我们查看了所有执行的活动，并问我们自己：哪些是我们现在不会再做的事情。所以，那不是要发现过去的错误，而是要严格地确定使用你当前的知识，当前做了什么工作。我们在2013年初的一个三小时会议中做过一次，作为计划过程的一部分。非常有挑战！ 由于很多原因，决定停止做一些事情非常困难。但是，以后这就是每次重要的排序过程的基础。

此外，我们还拥有了一些常见的看板实践，像使用累积流图（Cumulative Flow Chart）跟踪WIP，或者使用执行图来跟踪工作项的交付时间等等。

查看英文原文：Experiences from Applying Kanban at SAP