写点什么

在 SAP 应用看板的经验

  • 2014-01-05
  • 本文字数:3677 字

    阅读完需:约 12 分钟

中欧精益看板大会上,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

2014-01-05 19:342366
用户头像

发布了 340 篇内容, 共 129.1 次阅读, 收获喜欢 13 次。

关注

评论

发布
暂无评论
发现更多内容

基础差在web培训班学习前端技术有合适吗

小谷哥

抖音二面:计算机网络-应用层

Java快了!

计算机网络

【联通】数据编排技术在联通的应用

Alluxio

中国联通 Alluxio 大数据 开源 数据编排 9月月更

雪上加霜,运维部门裁员后,中了勒索病毒……

嘉为蓝鲸

运维 故障 病毒 变更

全面吃透JAVA Stream流操作,让代码更加的优雅

Java-fenn

Java

java培训班选择哪些比较好呢

小谷哥

跟我一起学mybatis之注解开发

楠羽

mybatis 笔记 9月月更

传统BI需要一次新的「革命」

ToB行业头条

详谈 MySQL 8.0 原子 DDL 原理

RadonDB

MySQL 数据库

Java基础 | Java中引用与指针的关系

Java-fenn

Java

2021年中国人工智能软件及服务市场规模超千亿,认知智能增速显著

易观分析

人工智能

ShareSDK Android端渠道下载统计配置说明

MobTech袤博科技

android sdk

软件测试 | 测试开发 | MySQL锁机制总结

测吧(北京)科技有限公司

MySQL 测试

软件测试 | 测试开发 | Python数据驱动测试 unittest+ddt

测吧(北京)科技有限公司

Python 软件测试

大数据培训机构怎么选择

小谷哥

软件测试 | 测试开发 | 使用Fastmonkey进行iosMonkey测试初探

测吧(北京)科技有限公司

测试 软件测试和开发

面试官:如何设计一个短链服务?

Java永远的神

Java 程序员 面试 程序人生 后端

开源交流丨一站式大数据平台运维管家ChengYing安装原理剖析

袋鼠云数栈

阿里巴巴数字商业知识图谱的构建及应用

阿里技术

人工智能 机器学习 知识图谱

直播预告 | PolarDB 开源人才培初级考试备考辅导公开课

阿里云数据库开源

数据库 阿里云 开源 人才培养 polarDB

终于有人把不同标签的加工内容与落库讲明白了丨DTVision分析洞察篇

袋鼠云数栈

普适性强的ERP/MES系统为什么难选?4种挑选方案教你避坑

优秀

MES系统 mes ERP系统

软件测试 | 测试开发 | Uiautomator项目搭建与实现原理

测吧(北京)科技有限公司

软件测试 测试

如何选择靠谱且适合自己的web前端培训课程

小谷哥

【HTML-CSS】总结-6种实现元素 上下左右居中 方法--附演示效果

Sam9029

CSS html 前端 9月月更 水平垂直居中

阿里P8手写Spring Cloud Alibaba实战学习手册,架构师养成必备!

了不起的程序猿

Java spring SpringCloud java程序员 java编程

软件测试 | 测试开发 | 因服务器时间不同步引起的异常

测吧(北京)科技有限公司

软件测试 测试

java学习技术有哪些好的方法呢?

小谷哥

云堡垒机和信创堡垒机主要区别讲解

行云管家

云计算 信创 堡垒机 云堡垒机

入驻快讯|欢迎 SelectDB 正式入驻 InfoQ 写作社区!

SelectDB

数据库 大数据 OLAP Doris 企业号九月金秋榜

走向云原生数据库 - 使用 Babelfish 加速迁移 SQL Server 的代码实践

亚马逊云科技 (Amazon Web Services)

数据库 云原生

在SAP应用看板的经验_精益_Ben Linders_InfoQ精选文章