DevOps实战：乐高、巧克力与Scrum游戏

需积分: 9 56 浏览量更新于2024-07-20 收藏 8.54MB PDF 举报

"Introduction.to.DevOps.with.Chocolate.LEGO.and.Scrum.Game" 本书"Introduction to DevOps with Chocolate, LEGO and Scrum Game"由Dana Pylayeva撰写，旨在以一种非传统的方式介绍DevOps理念。游戏通过使用乐高积木、巧克力以及角色扮演卡，让参与者体验开发（Dev）和运维（Ops）的角色及其相互依赖关系。在游戏中，玩家会经历一系列情感变化，学习扩展个人角色边界，培养T型技能，并将Scrum团队扩展至包括运维部门。游戏结合了《凤凰项目》的概念与作者在实际工作中遇到的开发和运维团队所面临的挑战。通过模拟安全漏洞、环境补丁、部署代码冻结以及开发与运维的孤岛等问题，游戏帮助玩家体验端到端的产品交付过程，可视化价值传递流程中的瓶颈。通过三个冲刺阶段，游戏利用所有五种感官来最大化学习效果，引导玩家进行一次寓教于乐的DevOps转型之旅。书中的章节涵盖了游戏介绍、规则、组件、房间设置、时间管理、游戏主持、游戏历史与修改以及关键收获等内容。读者群体主要是对DevOps初学者，如程序员、系统管理员或项目经理，以及想要为团队提供互动式学习体验的DevOps培训师和敏捷教练。书中的标签“DevOps”表明其专注于这一领域的实践和理论。书中的部分内容提到了版权信息，强调了书中可能包含的商标名称、标识和图像，但其使用是为了教学目的，并不意味着与这些商标持有者存在任何关联。通过阅读这本书，你可以： 1. 学习如何玩巧克力、乐高和Scrum的角色模拟游戏。 2. 深入理解DevOps概念，并了解如何将游戏应用于DevOps实践。 3. 通过案例研究，观察这个游戏如何展示DevOps周期。 4. 成为一名游戏大师，掌握游戏的规则和流程，以引导团队参与。 5. 了解如何分析和改进价值交付流程中的瓶颈。这本书提供了一个独特且富有创意的学习方式，使DevOps理念变得生动有趣，适合希望通过互动体验学习DevOps的个人和团队。

Chapter 1 ■ IntroduCtIon

This all changed at the Velocity 2009 conference, when John Allspaw and Paul

Hammond shared their experience of Developers and Operations collaboration at Flickr

in their pivotal presentation “10 + Deploys Per Day.” This presentation had pushed the

limits of what was possible at that time and inspired many followers.

Encouraged by this talk and, at the same time, disappointed that he couldn’t attend

it in person, Patrick decided to organize his own conference. He put together a two-day

event in which Developers and Operations could come together to exchange ideas and to

collaborate. This inaugural DevOpsDays conference brought to Belgium a number of leading

practitioners from around the world, who continued the conversations and collaboration on

Twitter long after the event. Through this massive use in the post-conference conversations,

the original #DevOpsDays Twitter hash tag became too long. The “Days” was dropped.

The #DevOps hash tag and the DevOps movement were born.

The DevOps movement has come a long way since then. At the earlier stages of its

development, DevOps was only for unicorns—the Flickrs, Etsys, Amazons and Netflixes

of the world. Nowadays, DevOps practices, tools, and philosophy have become widely

adopted by large enterprises and small startups alike. The DevOps Enterprise Summit

2016 highlighted success stories from Macy’s, Nordstrom, GE Capital, Disney, Capital

One, the US Department of Homeland Security, and many others.

In spite of the fast-growing popularity of the movement, there is still no single

standard definition of the term DevOps. Is this a tool, a mindset, a new department, a job

title? There are many different definitions of what it is, to the extent that Gartner analysts

in their “Seven Steps to Start Your DevOps Initiative” recommended as step number one:

“Define DevOps for You.”

My personal favorites are the following two DevOps definitions:

“A mix of patterns intended to improve collaboration between

development and operations. DevOps addresses shared goals and

incentives as well as shared processes and tools.”

—Michael Hüttermann, DevOps for Developers

“A movement of people who care about developing and operating

reliable, secure, high performance systems at scale.”

—Jez Humble, https://www.thoughtworks.com/insights/blog/state-devops

DevOps continues to also be a “movement of people who care” to organize local

DevOps meetups in their cities and countries. The people, who continuously learn,

translate DevOps books into their local languages, build communities, and help others to

embrace DevOps culture.

Their impact on DevOps popularization is hard to deny. Take this Google Trends

graph for DevOps in Finland, for example (Figure1-1). In spite of a rising interest in

DevOps worldwide, there was little to no interest in Finland until January 2013, when a

new “DevOps Finland” meetup was founded by Erno Aapa, an engineer and a DevOps

enthusiast from Helsinki. The second spike of interest in November 2014 can be

attributed to DevOps Days Helsinki being organized by local practitioners.

Chapter 1 ■ IntroduCtIon

A few years later, I came across “The Phoenix Project” by Gene Kim, Kevin Behr,

and George Spafford, and I couldn't put the book down! It was describing my experience

and my pain, yet it was showing the way out. It was through the discovery of this new

knowledge and a desire to share it with others, the idea of creating this game was born.

At that time, I was one of the organizers of ThinkShare, a company-wide internal

learning forum that enabled a cross-pollination of knowledge among various technology

groups. Our October agenda was wide open and it turned out to be a perfect opportunity

to play-test the MPV (minimum playable version) of the game.

Greatly improved since then, the game now starts with the end-to-end simulation of

issues experienced by many organizations, specifically the ones that implement Scrum

framework on the development side, but keep operations function as an organizational

silo. Trapped in waterfall land, the operations team becomes a bottleneck in a flow of

value through the organization. Lack of timely customer feedback due to the limited

number of releases, misalignment of goals between the groups: these are just some of the

systemic problems highlighted by the game.

If your organization is considering DevOps, a great way to start is by generating some

interest and excitement around the topic. Using the Chocolate, Lego and Scrum game

as part of your DevOps adoption strategy will help you popularize the DevOps ideas and

make them digestible at all levels of organizations.

The game combines ideas from “The Phoenix Project” with the experience gained

from real-life challenges encountered by development and operations teams in many

organizations. Security vulnerabilities, environments patching, deployment code freeze,

development and operations silos: the game helps simulate an end-to-end product delivery

process and visualize the bottlenecks in the value delivery flow. The gamified format helps

create a safe place for participants and facilitates their experimentation and learning.

Why LEGO and Chocolate?

Studies at Martinos Center for Biomedical Imaging, Department of Radiology,

Massachusetts General Hospital, and Harvard Medical School found that our brain

assembles the data received from sensory inputs into a complete picture that becomes

a memory of an event. Engaging multiple senses while learning helps amplify learning

effectiveness. Additionally, when we experience an emotional reaction, it becomes a part

of the memory, strengthening it dramatically. Sharon Bowman in her “Training from

the Back of the Room” work emphasized positive emotional experiences, multi-sensory

stimulation and novelty among the elements used in brain-friendly trainings.

The Chocolate, LEGO and Scrum game is designed to engage all five senses and

tap into the emotional side of the brain. Working with LEGO and Chocolate, participants

experience the downside of local optimization and learn to expand their view to

include the entire system. Using avatars, personas, and role cards, participants gain an

understanding of Dev and Ops roles as well as their interdependencies. They try out a

mindset of each role for the duration of the game.

Throughout the game they experience a range of emotions and learn to expand the

boundaries of individual roles, acquire T-shaped skills and expand the Scrum-team circle

to include Operations. They build new environments, protect them from Hackers’ attacks

and work with demanding customers, trying to satisfy their ever-changing demands. The

game takes players through a gamified DevOps transformation journey, facilitating their

first baby steps towards embracing the DevOps culture.

Chapter 1 ■ IntroduCtIon

Why Scrum?

According to 10th Annual State of Agile Survey from VersionOne, Scrum remains the

number one Agile development methodology practiced by organizations around the

world. While the survey reports that 68% of respondents practice Scrum or Scrum/XP

hybrid in 2015, it also highlights an interesting trend. When asked about Agile techniques

they use, a number of respondents reported a decreased use of iteration planning.

Instead, organizations began experimenting with transitioning towards flow-based

methods.

Why is this important?

Planning and developing features in iterations significantly improved an

organization’s ability to deliver these features to its customers (as compared to a

traditional, sequential development model). However, with the accelerating speed of

innovation and fluctuating market demands, the customers are no longer willing to wait

weeks or months for a feature they need now.

Customers expect innovation and speed. They expect their service providers to

deliver value continuously and judge digital service quality based on their overall

experience.

Just like a slow-loading page of a travel site can cause consumers to go to another site

and book their vacation there, a company that can’t accelerate speed to market can lose

its customers to the competitors.

One other benefit of faster delivery is in its enablement of an accelerated feedback

loop. With timely feedback from the end-users, product development organizations

increase their likelihood of delighting the customers with their product. This experience

is well simulated in the Chocolate, Lego and Scrum game.

Starting from a common baseline of the Scrum framework, participants experience

firsthand some of the bottlenecks that iterative planning creates. They begin to

realize that through practicing Scrum, the development team creates large batches of

“potentially shippable increments.” These increments, if not deployed into production

in time, may lead to outdated features, incompatible code and potential service outages

after deployment. Thus a development process, locally optimized with Scrum, has all the

potential to cause global degradation in the overall flow of value.

Who is this game for?

It is for you, if you are working with an organization exhibiting at least one of the following

dynamics:

• Agile practices and principles are used in the development

organizations only, while Operations continues to use a plan-

driven waterfall approach.

• Your developers have no idea about the post-deployment

performance of their software.

• Delayed, infrequent deployments of “potentially shippable

product increments” cause service disruption in production.

剩余145页未读，继续阅读

ramissue

粉丝: 354
资源: 1487

DevOps实战：乐高、巧克力与Scrum游戏

Introduction to DevOps with Chocolate, LEGO and Scrum Game.pdf

Agile.Application.Lifecycle.Management.Using.DevOps.epub

Dinnerchicke.github.io：DevOps

wcm-io-devops.github.io:devops.wcm.io网站

devopsautomators.github.io:DevOps 自动化网站

devopsmercenaries.github.com:Devops Mercenaries 演示页面

hawaiideveloper.github.io:全栈和DevOps专业人士

devopsweeklyarchive.github.io：Devops每周新闻通讯的公共档案

octoops.github.io:OctoOps是DevOps的理想之地

AzureDevOps.WikiPDFExport:将Azure DevOps Wiki导出为PDF

最新资源