掌握数字转换:案例研究(上)

关于软件开发方法的争议已结束。敏捷组织设置为自己建立自己主导组织形式．当前的文献，特别是与敏捷软件开发相关的文献，在实证研究和理论中都令人印象深刻地证明了这一点。(在加速[1]、Forsgren、Humble和Kim给出了敏捷/DevOps方法与业务成功之间联系的强有力的经验证据。在[2]d中，Reinertsen提出了基本原则．)然而，要想让一个组织变得敏捷或数字化，仅仅了解事实是完全不够的。

在这个分两部分的系列文章中，我们以一个特定的客户项目(“一触零售”- OTR)为例，展示了我们如何使用敏捷方法推进汽车制造商戴姆勒的数字化转型。我们希望鼓励你们面对数字化转型的挑战——因为结果是值得的。虽然有挑战和障碍，你的组织将发展所需的新技能和创造价值。一旦你体验了新的敏捷工作方式，就没有回路了。

概述

在戴姆勒与Thoughtworks合作的多年转型过程中，我们了解到，我们需要同时解决几个范式转变(关键词:188bet宝金博app下载敏捷软件开发、DevOps、设计思维)．为此，戴姆勒管理层的支持一直是至关重要的。我们在许多领域重新设计了我们的项目结构，并使用了现代基础设施和控制工具（关键字：云,精益PMO)．最终，我们利用这一点开发了一个以反馈为中心的环境，使我们能够对新需求做出极其快速的响应，并在此过程中开发出用户喜欢的产品。

我们对这个转型项目的主要见解是:

• 无光我们到目前为止所学到的，以及从根本上改变我们日常工作方式，都需要参与其中的每个人都拿出相当大的勇气。
• 开始小．我们从小步骤开始，然后迅速扩大规模。
• 别玩了，认真点!和它!对于数字化转型，重点是应用敏捷原则，而不是顽固地遵循特定的方法。
• 使用商品基础设施让我们更快。
• 专注于自组织、跨职能的产品团队。
• 我们通过将离岸团队视为等于等等，我们实现了更大的效益。

思考模式的转移

数字化不仅仅是一种技术变革。它要求在许多领域进行深远的范式转变和新的思维方式。此外，它不是一次性的活动或简单的学习经验，而是一种根深蒂固的思维模式和日常行为的持续调整。我们认为，这涉及到五个不同的范式转变:

1. 从瀑布式方法到敏捷软件开发
2. 从项目到产品
3. 从发展和操作到DevOps
4. 从需求分析到设计思考
5. 从IT服务管理到关注业务价值

在我们看来，同时处理这些个人范式的变化是有意义的(即使从变更管理的角度来看这似乎是矛盾的，因为众所周知，在一个公司同时进行太多的变化会导致“组织变更疲劳“，见[3]。）毕竟，右侧的许多范例使用彼此补充和支持的惯例，工具和架构。这些范式转变的基础是一种开放，信任和分享（例如责任）的文化，谦卑（例如，主题专家不能且不必知道一切）和包容。

“一个触摸零售”

OTR项目是一个多年的数字转型，是戴姆勒最佳客户体验计划，见[4]。我们设定了为销售人员开发创新和直观的数字助理来取代当前的遗产系统。目的是使销售过程更有效。与此同时，它将允许戴姆勒的销售人员在客户身上更加重点。新的OTR平台也将灵活，使其适应汽车市场的不断变化。

一个分布在德国、印度和中国各地的全球团队正在开发这位新的销售助理。德国团队正在为德国市场开发该系统，同时与印度开发中心的同事密切合作。与此同时，中国队正在开发一个类似的助理这是对中国市场量身定制的（见[5]）。

改变现状

我们(作者以及由戴姆勒和Thoughtworks员工组成的联合项目团队)使用OTR在许多领域实施戴姆勒的IT战略。188bet宝金博app下载例如，在生产环境中，我们将软件发布的频率从每月一次部署增加到每天几次部署，从而实现了一个连续交货的过程。IT架构从n层方法转换为微服务架构，而基础设施从本地安装更改为使用基于云的组件。以前的手动测试已被完全自动化测试所取代，这最终实现了连续部署流程。因此，我们使用DevOps方法执行了一个从瀑布方法到敏捷软件开发的完全转变。此外，我们现在使用免费和开源软件(FOSS)来代替专有解决方案。我们依赖于跨功能产品团队中最大可能的集成，而不是业务和IT功能的清晰分离。

戴姆勒的革命

数字化转型中最重要、同时也是最困难的一个方面是建立一种新的工作文化。戴姆勒目前正在经历从汽车制造商向移动服务提供商的转型。当然，这对我们在OTR项目中的工作也有具体的影响。要求更快的速度，更快的学习和敏捷——关键字”# TwiceAsFast“（[6]和[7]） - 正在进入聚光灯。这也是基于认可，即汽车工业的客户受益，特别是在移动性作为服务（MAAS）的领域，可以通过数字产品果断地改进。然而，产品质量取决于他们适应新客户要求的能力，并从客户行为中吸取教训以及他们的速度。

在这方面，我们将现代软件技术视为创新的驾驶员，重点关注加速开发过程并缩短反馈周期的技术。正是这种能力构成了基础微观创新（参见[8]微型创新与宏观创新的好处）。

在这方面，我们也看到了范式的转变。在OTR项目开始时，我们经常遇到这样的态度:“我们非常了解用户的需求——我们已经这样做了20年了!”，但我们已经越来越多地采取设计思维方法。我们开始进行定期的用户和客户调查(研究)，已经发展了一个新开放（见[9]对于史库恩或初学者的思想，常用于设计思维的术语），并实现了我们根本无法了解每个要求。

戴姆勒的四个催化剂策略

这种向设计思维的范式转变得到了四个催化剂的支持:

1. 彻底的流程简化降低了任务的复杂性和重复性，从而允许更简单的流程实现更大程度的自动化。
2. 重点从项目转移到产品本身。目标是使用数据来降低成本，增加收入，发展知识产权和用户基础。
3. 用速度作为战略优势，例如，通过持续交付将客户需求迅速实施。
4. 无畏地质疑现有规则和流程，并从错误和反馈中学习的意愿。

从项目到数字产品的重点转移也会改变IT部门的自我形象，因为他们在IT服务管理（ITSM）的感觉中远离服务提供商（也参考ITIL[10])和对平等的合作(见[11])。在OTR项目中，我们在跨职能团队的日常工作中经历了这一点。例如，业务产品所有者与IT产品所有者一起工作，他们都在平等的基础上合并他们的观点和技能。

我们还始终如一地实施OTR项目中戴姆勒战略的其他元素：

• 使用免费和开源软件
• 基于云的操作，使DevOps能够
• 通过API可以实现微服务的实现
• 在动态群体中工作
• 使用戴姆勒标准安全供应商

所有这些项目组件都直接为戴姆勒的IT战略做出了贡献。

我们始终如一地在OTR项目中实施戴姆勒的IT战略。

工作方式

从一开始，我们的目标是为团队的每个成员创建一个安全的工作环境：一个允许任何人制作和学习的人受控环境中的错误(关于改善文化的深入讨论，请参阅[12])。这种对错误的开放在两个层面上起作用。首先，我们促进知识获取和创新。其次，通过实验更容易引入新的(如敏捷)实践;即提出假设，进行实验来测试它们，并衡量它们的成功或失败改变方向．在这里，我们也应用了小批量的原则，这意味着我们定期对工作方式进行小的更改，而不是首先设计一个新的工作方式的细节，同意这个设计，然后通过更改管理活动实现它。这样，当实现范式转换时，我们也可以应用敏捷工作方法的原则。

质疑基本价值观和工作方式和非学习实践需要大量的努力。以下情况有助于我们接近转型：

• 汽车工业目前正经历着一个根本性的转变(例如，参考[13])。这背后的社会、技术和经济动荡现在在公共话语中如此普遍，因此采取行动的必要性是显而易见的。虽然转换一方面代表了挑战甚至是威胁，但另一方面它也支持这种类型的更改项目。
• 在OTR项目开始时，我们遇到了关于敏捷方法和前面提到的范例转换的巨大开放性。甚至在最初两周的初始阶段，我们反复听到“信任过程”的口号。这表明了戴姆勒项目员工对我们的信心——他们以前很少接触敏捷方法。

开放性，透明度，常规回顾，以及为桌子带来甚至难以困难的机会有助于我们保留这种信任，以培养它，并保持变革的势头。

回顾一下

团队设置和能力

数字产品开发基于团队或组织单位必须拥有的整体能力范围。为了以真正成功的软件开发方式实现敏捷方法，简单地引入Scrum远非充分。除了熟悉的敏捷开发实践外，其他要求还包括测试自动化，连续交付，微服务和基础设施作为代码。也需要设计思维或DEVOPS等方法。为了让我们概述团队内的这些能力，我们将它们组成为六类：组织设计，产品设计，技术，战略和文化（在[14] D. Freess技术，组织设计，产品设计和战略中（最高额在[1]),福斯格伦，汉博和金提出分类为连续交付，架构，产品和过程，精益管理和监测）。下图显示了最重要的能力的选择，其中许多是相互支持的或增强其他人的积极影响（在[15]中马丁指出“[…所有这些东西都融合在一起。极限编程最重要的一点是，极限编程的个人实践是相互加强的”)。

这里有几个理论可以证明这些关系:

• 如果团队是自主工作的，那么必要的能力，以及个人，必须在团队中可用。这不可避免地导致了跨职能团队。
• 敏捷产品团队的扩展需要减少团队之间的依赖关系。微服务可以帮助加强这种自主权。
• 微服务基础设施的引入和操作需要使用自动化部署管道(CI/CD)、基础设施自动化、监控等功能(参见m·福勒[16]）。
• 假设驱动的发展是基于犯错的可能性。安全的工作环境是必要的。
• 设计思维需要创造力，而创造力又得益于多样性。
• 实现敏捷原理需要测试自动化，因为手动测试不可能频繁部署。这是通过实施a实现的测试金字塔(详情请参阅Hermann Vocke[17])。

相互支持能力概述

在OTR项目中，我们利用了这些能力之间的交互，并实现了上图中几乎所有的能力。

然而，敏捷软件开发只是领先的软件公司目前使用的能力范围的一小部分。因此，处于数字化转型初期的组织需要外部支持。对我们来说，这里的重点不是培训或指导。我们的经验表明，通过实际项目中的协作，范式转换可以实现得更快、更有效益。重要的是要让项目的员工参与进来积极地生活阐明这些原则和能力。

生活敏捷

根据一项麦肯锡调查[18]，敏捷软件开发现在是现有技术。Martin Fowler [15]，I188bet宝金博app下载nslicalWorks的首席科学家支持这个理论，但也有关于他所谓的现象的报道“人造敏捷“（其他作者称之为假的敏捷(见[19])货物崇拜敏捷(见[20]))。作者经常遇到这样的情况:团队自豪地宣称他们按照敏捷方法工作。从积极的意义上说，这与罗恩·杰弗里斯所描述的还相差甚远黑暗的Scrum(见[21])．因此，我们想要强调的是，基于Scrum分配角色、维护待办事项、组织每日站立式，以及与粘性人员一起工作只是开始。我们认为更重要的是集中精力敏捷原则（参见[22]）比严格遵循Scrum，Kanban或Safe（Scaled Agile Framework）等方法。这些原则侧重于为客户提供的价值和自组织，交叉功能，自治团队，以短暂的间隔提供工作软件。

一种基本原则是让个人团队在某些指南内确定特定的工作方法，使用工具，甚至编程环境。这是促进的microService架构(参见[23])。例如，在OTR项目中，一些团队使用Clojure，而另一些团队在后端使用Kotlin作为编程语言。一些团队使用两周的sprint，而另一些团队使用持续交付原则或看板。一些团队用描述点来估计用户描述的大小，而另一些团队则采用夜时候方法。

我们相信，这种自由最终可以提高发展速度。戴姆勒的方法更多地使用免费和开源软件这里也有积极的影响(见[24])。

另一个原则是工作方式的不断调整和进一步发展。我们定期向戴姆勒感兴趣的同事展示我们的工作方式。一周又一周，我们看到办公室墙上的变化:例如，看板的结构发生了变化，路线图取代了精益价值树，技能矩阵上周没有了，等等信息散热器，这意味着我们使用大的表面来直观和交互地展示信息，参见[25])。

从根本上改变程序的一个结果是上线，或者我们称之为交接．我们很多人都很熟悉这个过程事件这通常发生在周末或晚上，以便在应用程序不太使用的时候安排所需的停机时间。

在OTR项目中，我们将应用程序切换实现为没有事件．在此过程中，我们通过电子邮件发布该应用程序并通知用户此内容。这是可能的，因为它的最新状态几乎总是在生产环境中可用连续送货方式(见[26])。其他职能的交接也以同样的方式进行。我们使用功能切换（参见[27]）以激活新组件，然后通知用户此问题。

总结与展望

在本文的第一部分，我们确定了数字转型的范式转变，解释了案例研究 - 一个触摸零售（OTR）项目 - 提出了戴姆勒正在使用该方法来解决转型，讨论了基于的敏捷方式案例研究，并调查了我们如何避免人造敏捷。

在里面第二部分我们将进入更多的深度，包括澄清管理的角色，介绍跨职能团队的工作示例，看看仪式，讨论在寻找创造性解决方案中的多样性的贡献，了解另一个范式转换客户以客户为中心，并提供关于数字转型进一步进展的前景。

参考文献

[1]妮可福斯格伦，JEZ谦卑und基因金：“加速”，IT革命，波特兰，2018年
[2]唐纳德G. Reinertsen：“产品开发流程原则：第二代精益产品开发”，Celeritas Publishing，Redondo Beach，2009年
[3]维基百科:“组织变革疲劳”，https://en.wikipedia.org/wiki/Organizational_change_fatigue
[4]戴姆勒：“最佳客户体验4.0” - 在海牙的新闻演示：豪华经验中的启动4.0：梅赛德斯 - 奔驰全球销售战略的下一章“最佳客户体验”，https：//媒体.daimler.com / marsmediasite / Ko / EN / 43937825,2019
[5]思188bet宝金博app下载考方式：“未来销售经验的创新软件开发”，//www.pumpym.com/clients/daimler，2017
Jan Brecht:“2018年我在梅赛德斯-奔驰公司最关注的IT三大重点”，LinkedIn, https://www.linkedin.com/pulse/my-top-three-priorities-mercedes-benz-focus-2018-jan-brecht/， 2018
[7] Jan Brecht:“#TwiceAsFast:如何建立学习型文化”，领英，https://www.linkedin.com/pulse/twiceasfast-how-implement-learning-based-culture-jan-brecht/， 2019
[8] Daniel Newman：“为什么微型创新应该是你的数字转型的核心”，福布斯，https://www.forbes.com/sites/danielnewman/2016/02/02/2016/02/02/2016/02/02/2016/02/02/2016/02/02/2016/02/02/2016/02/02/2016/02/02/2016/02/02/2016/02/02/2016/02/02/60-Micro-innovation-应该是 - 核心 - 您的数字转换/＃5405b0837684,2016
[9] Jesse Russel Morgan：“UX设计中的初学者思想”，https://uxdesign.cc/beginners-mind-in-in-ux-design-with-shunryu-suzuki -11a00787c8a9?gi=f923553c2102,2018
[10]维基百科:“ITIL”，https://en.wikipedia.org/wiki/ITIL
[11] Mark Schwartz:“A Seat at the Table: IT Leadership in the Age of Agility”，IT革命，波特兰，2017
[12] David J. Anderson:“看板，你的技术业务的成功进化变化”，Sequim，华盛顿，2010
[13]麦肯锡：“汽车革命 - 迈出2030”，https://www.mckinsey.com/industries/automotive-and-assembly/our-insights/disruptive-trends-that-vill-transform-the-auto-行业/ de-de，2016
[14] Dino Frese:“它是多么的现代，就像俄罗斯方块，以及TOPS是如何理解一切的”，Thoughtworks, https://www.thoughtworks.188bet宝金博app下载com/insights/blog/how-modern-it-tetris-how-tops-makes-sense-everything, 2018
[15] Martin Fowler:“2018年敏捷软件的状况”，https://martinfowler.com/articles/agile-aus-2018.html, 2018
[16] Martin Fowler：“微服务先决条件”，https://martinfowler.com/bliki/microserviceprequisites.html，2014
[17] Hermann Vocke:“实用测试金字塔”，MartinFowler.com, https://martinfowler.com/articles/practical-test-pyramid.html, 2018
[18]麦肯锡:“如何创建一个敏捷组织”，调查，https://www.mckinsey.com/business-functions/organization/our-insights/how-to-create-an-agile-organization, 2017
[19]史蒂夫丹宁：“了解假敏捷”，福布斯媒体，https://www.forbes.com/sites/stevedenning/2019/05/23/23/23/untersing-fake-agile/#35870f914bbe，2019
[20]维基百科：“货物崇拜科学”，https://en.wikipedia.org/wiki/cargo_cult_science
[21]罗恩·杰弗里斯:《黑暗Scrum》，https://ronjeffries.com/articles/016-09ff/defense/， 2016
[22]敏捷宣言：“敏捷宣言后面的原则”，https://agilemanifesto.org/principles.html，2001
[23] Sam Newman:“构建微服务”，O 'Reilly Media, Sebastopol, CA.， 2015
Torben Stephan, Ludger Schmitz“Interview with Vlado Koljibabic, CASE IT主管in Daimler”，Data Center Insider, https://www.datacenter-insider.de/wir-kennen-die-vorteile-von-open-source-a-708188/， 2018
[25] Kasandra Fcong“用一个伟大的信息散热器改变会议”，Thoughtworks, https://www.thoughtworks.188bet宝金博app下载com/de/insights/blog/transform-meetings-great-information-radiator, 2016
[26] Jez Humble和David Farley“持续交付:通过构建、测试和部署自动化的可靠软件发布”，Addison Wesley, 2011
[27] Pete Hodgson:“Feature Toggles (aka Feature Flags)”，https://www.martinfowler.com/articles/feature-toggles.html, 2017