本文探讨了DevOps在团队合作上的积极影响，但其主要关注技术层面的价值交付。作者提出了一个新概念——BizDevOps，旨在解决敏捷DevOps团队与业务之间的鸿沟，实现真正敏捷的外包并减少业务主与开发者间的冲突。
Or: Why DevOps Success Needs a Successor
或者：为什么DevOps成功需要接班人
DevOps实践对团队合作产生了巨大的积极影响。 但是，DevOps范式主要关注团队整体交付价值的更多技术方面。 在2019年阿姆斯特丹DevOpsDays之后提出的一个问题说明了这个问题： 我们到现在为止了，但是业务在哪里 ？ 在本文中，我将分享我们如何超越DevOps的成功来解决敏捷DevOps团队与业务之间的鸿沟。 我们发现我们的方法可以进行真正的敏捷外包，同时又避免了企业主与开发人员之间的典型摩擦，我希望启发您自己尝试使用BizDevOps的方法。 (DevOps practices have had a huge positive impact on teamwork. However, the DevOps paradigm mainly focuses on the more technical aspects of delivering value as a team. A question posed after DevOpsDays Amsterdam 2019 illustrates the issue: we’ve come so far, but where is the business? In this article, I will share how we are trying to go beyond the success of DevOps to tackle the divide between agile DevOps teams and the Business. We have found our approach makes it possible to do true agile outsourcing while still avoiding much of the typical friction between business owners and developers, and I hope to inspire you to try our approach to BizDevOps yourself.)
All too often, business stakeholders are unexpectedly involved in the development process, and business requirements tend to get lost in translation. This is why the solution provided by the development team often scarcely addresses the needs of the business, and little value is delivered. How can we best bridge that dominant divide between the Business and IT?
很多时候，业务利益相关者出乎意料地参与了开发过程，并且业务要求往往在翻译中迷失了方向。 这就是开发团队提供的解决方案通常几乎无法满足业务需求并且几乎没有交付价值的原因。 我们如何最好地弥合业务与IT之间的主要鸿沟？
Recently I stumbled on this picture. It struck me that, if anything, our spacecraft have become more technically complex over time. Yet, somehow, we have managed to remove this complexity from sight over the years. At least it looks as if everyone could control a (SpaceX) spaceship nowadays.
[R ecently我无意中发现了这张照片。 令我惊讶的是，如果有的话，我们的航天器变得越来越 随着时间的推移，技术上变得复杂。 但是，多年来，我们设法以某种方式消除了这种复杂性。 至少现在看来 ，每个人都可以控制(SpaceX)太空飞船。
When technology is hidden, it tends to become accessible for a broader public (this is known as democratization). Where public cloud technology (e.g. AI, ML, Deep Learning, blockchain—feel free to complete your own buzzword bingo card) from Microsoft, Google and Amazon is still targeting professionals, their respective low-code platforms—PowerApps, AppSheet and HoneyCode—are designed for citizen developers: those who ‘create new business applications for consumption by others using […] shared services, fourth-generation language (4GL)-style development platforms and cloud computing services’ (source). The same applies to the low-code platforms from Mendix, Betty Blocks, and others. Moreover, programming tools such as IFTTT, Apple’s Shortcuts, and good old Excel can easily be used by the average consumer.
当技术被隐藏起来时，它就易于为更广泛的公众所使用(这被称为民主化 )。 来自微软，谷歌和亚马逊的公共云技术(例如，人工智能，机器学习，深度学习，区块链-可以自由完成自己的流行语宾果卡)仍以专业人士为目标，他们各自的低代码平台PowerApps，AppSheet和HoneyCode专为公民开发人员设计：那些“使用共享服务，第四代语言(4GL)风格的开发平台和云计算服务来创建供其他人使用的新业务应用程序”的人( 来源 )。 Mendix，Betty Blocks等的低代码平台也是如此。 而且，普通消费者可以轻松使用诸如IFTTT，Apple的Shortcuts和良好的旧Excel之类的编程工具。
With all this technology becoming available for a wider public, products and services are increasingly impacted. It’s not only internal or secondary business processes that are impacted: the customer-facing, primary processes of businesses are increasingly changing because of the driving force of technology and innovation. Just look at the premier provider of postal and parcel services in the Netherlands, PostNL, which has developed a digital alternative for postage stamps. Regardless of how this trend will develop precisely — it’s happening. Under these circumstances the business expects more from teams than ‘just’ doing their ‘DevOps trick’: they expect teams to understand that it’s all about creating value. If they don’t do that, the chances are that ‘the business’ will swipe their credit card and starts building themselves. That last point is an important difference compared to the business-IT gap in the 1980s.
随着所有这些技术可供更广泛的公众使用，产品和服务受到的影响越来越大。 影响的不仅是内部或辅助业务流程：由于技术和创新的推动力，面向客户的主要业务流程正在不断变化。 看看荷兰领先的邮政和包裹服务提供商PostNL，它已经开发出一种数字化邮票替代品。 无论这种趋势将如何精确发展，它都在发生。 在这种情况下，企业对团队的期望不只是“仅仅”做“ DevOps窍门”：他们希望团队理解这一切都在于创造价值。 如果他们不这样做，“企业”很可能会刷卡并开始自己的建设。 与1980年代的商业IT差距相比，最后一点是重要的区别。
Because the thing is, today, IT is mostly still totally separated from the business. It’s separated within organisations (different departments, islands, silos) as well as between organisations (when IT is being outsourced to a third party). Neither side understands the other, yet both expect the other to do more to understand them. There’s a lot of finger pointing and, as a result, real fortresses are built. A corporate immune system is delaying innovation and delays smart people finding an answer to the question how are the company’s products and services going to be impacted/changed/improved by all these new technologies?
因为事实是，今天，IT基本上仍然与业务完全分离。 它在组织内部(不同部门，岛屿，孤岛)以及组织之间(当IT外包给第三方时)是分开的。 双方都不了解对方，但双方都希望对方能做更多的事情来理解他们 。 有很多指责，因此，建立了真正的堡垒。 公司的免疫系统正在延迟创新，并延迟聪明的人找到答案，以解决所有这些新技术将如何影响/改变/改进公司的产品和服务？
The hierarchical structure of many organizations doesn’t help. It creates a comfort zone that discourages transparency and vulnerability. As an attempt at diplomatic cooperation, external consultants, project managers, agile coaches, and/or so-called ‘thought leaders’ are hired to function as translators between the two sides. Clearly this only addresses the effects of the divide, and fails to tackle its cause. Worse: it just introduces more overhead.
许多组织的层次结构没有帮助。 它创建了一个舒适区，阻止了透明度和脆弱性。 为了进行外交合作，雇用了外部顾问，项目经理，敏捷教练和/或所谓的“思想领袖”作为双方的翻译。 显然，这仅解决了鸿沟的影响，而未能解决其根源。 更糟糕的是：这只会带来更多开销。
So, how do we bridge the gap between those who write code and those who write emails? Maybe I can share a bit about how we work together at Schuberg Philis, and what I’ve learned during my time there.
S 0，我们应该如何弥合这谁写的代码和那些谁写邮件之间的差距？ 也许我可以分享一些关于我们在Schuberg Philis的合作方式以及在那段时间我学到的东西。
Imagine the collection of blue dots on the right is a team. Developers, Engineers, and Sales are roles that are typically represented in the dedicated customer teams of Schuberg Philis. When we’re about to embark on a journey with a customer, one of the first things we do is think about the roles we need those in the business to play (the yellow circles). What responsibilities do we expect? And which roles seem to fit those responsibilities? Do these roles generate the required mandate? Who do we need to contact to get this approved and arranged on the customer side?
想象一下右边的蓝点集合是一个团队。 开发人员，工程师和销售人员是通常在Schuberg Philis的专用客户团队中代表的角色。 当我们要与客户一起旅行时，我们要做的第一件事就是考虑我们需要业务中的角色(黄色圆圈)。 我们期望什么职责？ 哪些角色似乎适合这些职责？ 这些角色会产生所需的授权吗？ 我们需要与谁联系才能获得批准并在客户方面进行安排？
Once all the roles are allocated, before the start of the project, we go and sit together in a room. We close the door. Call it a cross-functional team, self-steering team, X-team or even co-creation—the name doesn’t really matter. It’s about putting the people with the right knowledge, expertise, vision, and passion together.
分配完所有角色后，在项目开始之前，我们一起坐在一个房间里。 我们关上门。 称它为跨职能团队，自我指导团队，X团队，甚至是共同创建的组织，这个名称实际上并不重要。 这是将具有正确知识，专业知识，远见和激情的人们聚集在一起。
We call this “whole system in a room”. In this setting, there’s not much hierarchy. It’s all about getting unnecessary management out of the way and putting experts in the lead.
我们称其为“ 房间中的Kong系统”。 在此设置下，层次结构不多。 这一切都是为了消除不必要的管理，并让专家处于领先地位。
The idea is to then cross over in each other’s space and commit to mutual bridge-building—to share the responsibility for building a bridge to the other side. Ideally, IT has someone from the business who talks their language, appreciates them, and even can be an advocate for them. The business then takes more ownership of tech decisions and understands better what‘s needed. Since both sides are involved in a single team, there’s no finger pointing.
然后，想法是跨越彼此的空间，致力于相互之间的桥梁建设，共同承担建立通往另一边的桥梁的责任。 理想情况下，IT部门中的某个人会说他们的语言，赞赏他们，甚至可以成为他们的拥护者。 然后，企业将拥有更多的技术决策所有权，并更好地了解需要什么。 由于双方都参与了一个团队，所以没有指责。
So the challenge is to find people from IT and the business who can operate in the purple shaded area and won’t meet resistance from the business and IT sides, respectively. This is not a walk in the park. It really is more work and it can be very demanding to go over to ‘the other side’. We see from our colleagues, too, that they find it difficult to cross the space sometimes and show respect to either business or IT people. Each side has its own language and practices. Screaming ‘#noestimates!’ isn’t really helpful if business is trying to cope with milestones, budgets and release deadlines. Yelling ‘#justdoit!’ is just as unconstructive when engineers are trying to understand ‘the why’ before sharing their advice, let alone committing to a deadline. I think that, at the end of the day, bridging the gap boils down to things like vulnerability, honesty and transparency. Getting out of your comfort zone. Genuinely trying to understand the other person. When such an atmosphere is established, there’s no finger pointing—and the other party praises you for the partnership you’ve created together (this then replaces the more usual transactional customer/supplier relationship).
因此，面临的挑战是从IT和业务部门中找到可以在紫色阴影区域操作并且不会遇到业务和IT方的阻力的人员。 这不是在公园散步。 这确实是一项艰巨的工作，转到“另一端”可能非常困难。 我们也从同事那里看到，他们发现有时很难跨越空间并表示对业务或IT人员的尊重。 双方都有自己的语言和习惯。 尖叫“ #noestimates！” 如果企业试图应对里程碑，预算和发布截止日期，那么它并没有真正的帮助。 大喊'#justdoit！' 当工程师在分享建议之前试图理解“为什么”时，这同样没有建设性，更不用说约定期限了。 我认为，归根结底，弥合鸿沟归结为脆弱性，诚实和透明性。 走出您的舒适区。 真正试图了解对方。 建立这样的氛围后，您就无需指责了，并且另一方称赞您与您一起建立的伙伴关系(这将取代更常见的交易客户/供应商关系)。
Getting into the same room with the right roles and disciplines can be very valuable for sharing project updates (think of the Sprint Review, for instance). In addition, we’ve found it to be a powerful way to kickstart projects. Getting into the same room from Day One creates an atmosphere of trust and transparency, which helps us realise short time-to-value together. Let me introduce the Proof of Value Pressure Cooker™. This consists of five phases that are typically executed in 1–2 weeks. These phases are detailed below.
摹 ETTING进入同一个房间合适的岗位和学科可以共享项目更新(认为Sprint评审的，例如)非常有价值的。 此外，我们发现它是启动项目的有效方法。 从第一天起进入同一房间将营造一种信任和透明的氛围，这有助于我们一起实现短时间的价值实现。 让我介绍价值证明压力锅™。 这包括五个阶段，通常在1-2周内执行。 这些阶段将在下面详细介绍。
1.准备 (1. Prepare)
Well begun is half the work. This phase typically starts before the pressure cooker starts and is performed by the more solution- and/or technically oriented team members. It involves getting to the heart of the matter:
好的开端是工作的一半。 此阶段通常在压力锅启动之前开始，并由具有更多解决方案和/或技术要求的团队成员执行。 它涉及到问题的核心：
- So what is this really about? 那么这到底是什么呢？
- Why (why, why) are we doing this? Are we doing this? 我们为什么(为什么，为什么)这样做？ 我们在做这个吗？
- (How) can we be successful? (如何)我们能成功？
Only if all questions have a satisfactory answer, can the team continue to the next phase.
只有所有问题的答案都令人满意，团队才能继续进行下一阶段。
2.思想 (2. Ideate)
This phase is where the business takes the stage, and shares their knowledge, experience, frustrations, wishes, ideas. IT is listening, in an emphatic way, trying to ask smart questions. In addition, the technical team members should ask themselves:
此阶段是业务阶段，并分享他们的知识，经验，挫败感，愿望，想法。 IT部门正在以认真的方式倾听，试图提出明智的问题。 此外，技术团队成员应自问：
- Do we understand? 我们懂吗
- What are we missing? 我们缺少什么？
- Shall we start? When do we start? 我们可以开始了吗？ 我们什么时候开始？
3.素描 (3. Sketch)
After the problem domain has been laid out by the business, it’s time for IT to reflect and share how they understood the explanation made by the business. Visualizing this interpretation helps mutual understanding. Moreover, sketching initial screens helps the team keep the final goal in mind, while answering the following questions:
在企业确定了问题领域之后，IT部门应反思并分享他们如何理解企业的解释。 可视化此解释有助于相互理解。 此外，绘制初始屏幕草图有助于团队牢记最终目标，同时回答以下问题：
- Is this what you mean? 你是这个意思吗？
- What should be changed? 应该改变什么？
- Is this going to bring you value? How? Why? 这会带给您价值吗？ 怎么样？ 为什么？
4.原型 (4. Prototype)
This is where the magic happens. Based on all the notes, drawings, sketches, and other input from the previous phases, an initial prototype is built. As a prototype makes the results of the pressure-cooker process much more concrete and tangible, it implicitly asks these questions:
这就是魔术发生的地方。 基于前一阶段的所有注释，工程图，草图和其他输入，可以构建初始原型。 当原型使压力锅过程的结果更加具体和切实时，它隐式地提出了以下问题：
- What are the most important requirements? 最重要的要求是什么？
- Is it clear enough who are our audience and who are the end-users? 是否足够清楚我们的受众是谁，最终用户是谁？
- What are we going to deliver? And, equally important, what are we not going to deliver? 我们要交付什么？ 同样重要的是，我们将不交付什么？
5.决定 (5. Decide)
After the prototype phase—and lots of coffee—the prototype is presented to the business. It’s essential to ensure that the business understands what’s been demo’d and delivered (as well as the effort that went into it :-)). This phase is about asking and answering these questions:
在原型阶段(包括大量咖啡)之后，将原型提交给企业。 确保企业了解演示和交付的内容(以及其中所付出的努力:-)至关重要。 此阶段是关于以下问题的解答：
- To which extent was value delivered? 价值传递到什么程度？
- If so: what does it mean to go live? 如果是这样：那么上线意味着什么？
- If not: what needs to be improved? 如果不是：需要改进什么？
To be clear: my intention is not so much to introduce a new way to kickstart a new project. There are many more ways to do this. The thing is: if you start a project with The whole system in a room, you get an early notion of what you can expect during the actual project in terms of collaboration, communication, creativity and critical thinking. If it hurts, do it more early, right?
需要明确的是 ：我的意思是不是要介绍给启动一项新项目的新途径。 有很多 更多 的方式来做到这一点。 关键是：如果您在一个房间中使用整个系统来 启动一个项目，那么您将对协作，沟通，创造力和批判性思维方面的实际项目有一个较早的认识。 如果疼的话， 早点做吧？
A pressure cooker gives you early insights. Either you know the whole thing is not going to work like this—e.g. the problem was not clearly defined, the business was not sufficiently present, feature creep is already occurring, and descoping is needed, or you have a quick, transparent way to add actual value, which could serve as a kickstart for the way of working during the rest of the project: BizDevOps.
压力锅可为您提供早期见解。 您要么知道整个事情不会像这样正常工作，例如，问题未明确定义，业务不充分，功能爬行已经发生，需要进行范围划分， 或者您可以通过快速，透明的方式添加实际值，可以作为项目其余部分中的工作方式的起点：BizDevOps。
With BizDevOps, it all starts with a business need. Within the team, the business defines that need in the form of requirements, which should be detailed and refined enough for the technical members of the team to plan and build them. After testing (it’s best if this is done by the business, too), release and deployment, monitoring data from both the technical and functional operations create primary input for the team — and the business in particular—to form new functional and non-functional wishes and requirements.
有了BizDevOps，一切都始于业务需求。 在团队内部，业务部门以需求的形式定义需求，需求的细节和细化程度应足以使团队的技术成员进行计划和构建。 经过测试(最好也由企业完成)，发布和部署，监视来自技术和职能运营的数据，为团队(尤其是企业)创建主要输入，以形成新的职能部门和非职能部门的愿望和要求。
BizDevOps not only means getting together during the start or design of a project: it also means getting together during the run phase. Sit behind the desk of end users. Feel what they are experiencing when they have to wait five seconds during each and every login.
BizDevOps不仅意味着在项目的开始或设计期间聚会，而且还意味着在运行阶段聚会。 坐在最终用户的办公桌后面。 在每次登录期间必须等待五秒钟时， 您会感到自己正在经历什么。
The product owner (or component owner, value stream owner, …) basically forms the glue between the three disciplines depicted above and he/she proves to be quite crucial for the success of this way of working. The product owner is virtually a mini-CEO who should be fully mandated to make decisions on behalf of the business. What’s more, this role should be respected by all other disciplines.
产品所有者(或组件所有者，价值流所有者，…)基本上构成了上述三个学科之间的粘合剂，并且他/她被证明对于这种工作方式的成功至关重要。 产品所有者实际上是一个微型首席执行官，应被完全授权代表企业做出决策。 而且，所有其他学科都应尊重这一角色。
So, to sum up:
因此，总结一下：
DevOps Needs a Sequel ♻️We need to repeat the DevOps success of bringing Development and Operations together, with the Business. We need to double down on the DevOps approach of bridging gaps, and now work to bridge the gap between the business and IT. Different roles, beings, and struggles are involved. But the struggles are real.
DevOps需要续集♻️我们需要重复DevOps在将开发和运营与业务结合在一起方面取得的成功。 我们需要加倍缩小差距的DevOps方法，现在要弥合业务与IT之间的差距。 涉及不同的角色，存在和斗争。 但是斗争是真实的。
Hierarchy = Comfort 🛋Rethink your way of working, governance, and reporting. Get in the same room with at least three different roles: tech, business, project management/facilitation/delivery. Don’t even start if these 3–4 roles are not sufficiently established.
层次=舒适🛋重新考虑您的工作方式，治理和报告方式。 至少要扮演三个角色，进入同一个房间：技术，业务，项目管理/促进/交付。 如果这3–4个角色没有充分建立，甚至不要开始。
Technology is Everyone’s Business 🚀Doing ‘just the DevOps trick’ alone isn’t going to cut it anymore. Business wants to be involved. BizDevOps is about organizing a short time-to-value, and it actually reduces risk as it allows things to fail early, and to fail fast—together with the business. After all, technology is now everyone’s business.
技术是每个人的事🚀仅仅做“仅DevOps技巧”就不会再减少它了。 企业希望参与其中。 BizDevOps旨在组织较短的价值实现时间，它实际上降低了风险，因为它使事情可以及早失败，并快速失败(与业务一起)。 毕竟，技术已成为每个人的事。
This story is based on my keynote talk at DevOpsDays Amsterdam 2020. In case you have any questions, remarks or suggestions: please feel free to comment below or drop me a line!
这个故事是基于 我在2020年阿姆斯特丹DevOpsDays 上的 主题演讲 。 如果您有任何疑问，意见或建议，请随时在下面发表评论或 给我 留言 ！
扫一扫
953
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
