애자일 및 DevOps: 친구인가 적인가?

DevOps는 소프트웨어팀 외에도 적용되는 애자일 방법입니다. 그러나 진정한 문제는 비교했을 때 이 더 나은가입니다.

Ian Buchanan Ian Buchanan

Atlassian에는 주변 친구들에게 익스트림 프로그래머로 알려진 공인 스크럼 마스터가 있습니다. 애자일한 모습 때문인지 아이들에게는 덜렁대는  아빠지만 말입니다.

한편에는 IaC(Infrastructure as Code)를 지속적으로 배포하는 린 문화라는 기계가 있습니다. 왼팔의 이름은 Dev(개발)이며 오른팔의 이름은 Ops(운영)죠. 바로, DevOps입니다!

Although I've taken the hype to an extreme, the sound bites about Agile and DevOps can make them sound like very different ideas. Compounding the confusion, both concepts seem to defy definition, even as they have their own jargon and slogans. As the elder, Agile may be less vague, but it's certainly common for people to become frustrated with the myriad of definitions for DevOps. The lack of definition has lead to some common conflation. 

Many people think Agile means Scrum and DevOps means Continuous Delivery. This oversimplification creates an unnecessary tension between Agile and DevOps so you may be surprised to find that they are best friends!

There's no denying the historical connection between DevOps and Agile. When Patrick DuBois and Andrew Clay Schafer tried to connect at the Agile 2008 Conference about "Agile Infrastructure", the connection to DevOps was born. Although Patrick later coined the term "DevOps", the Agile Conference continues to honor this connection with a DevOps track. But let's dive deeper than history and consider the practical connections between Agile and DevOps, when we look below the surface of Scrum and Continuous Delivery.

애자일에는 스크럼만 있는 것이 아닙니다

몇몇 팀에게 스크럼은 끊임없는 힘든 투쟁을 생산적이며 보람 있는 팀 업무로 바꾸는 열쇠입니다. 다시 말해, 스크럼은 회사 내 정치적 문제와 낭비를 객관성과 집중으로 대체합니다. 스크럼은 신조처럼 받아들여질 수도 있습니다. 비즈니스의 제약 또는 업무 자체로 인해 무언가 다른 것이 필요할 때 애자일 팀은 기본 스크럼 원칙을 활용하여 팀의 절차를 점검하고 더 효과적인 업무가 가능하도록 조정합니다. 이는 스크럼이 소프트웨어 개발 컨텍스트 외로 적용되는 경우 특히 중요합니다.

계획하지 않은 업무를 계획하기

In the DevOps community, those with Agile experience acknowledge that scrum is useful for tracking planned work. Some work in operations can be planned: releasing a big system change, moving between data centers, or performing system upgrades. But much of the work of operations is unplanned: performance spikes, system outages, and compromised security. These events demand immediate response. There's no time to wait for the items to be prioritized in a backlog or for the next sprint planning session. For this reason, many teams that have come to embrace DevOps thinking, look beyond Scrum to Kanban. This helps them track both kinds of work, and helps them understand the interplay between them. Or, they adopt a hybrid approach, often called Scrumban or Kanplan (kanban with a backlog).

In many ways, the key to Scrum's wide adoption may be that it prescribes no technical practices. Scrum's lightweight management practices often make a big difference for a team. Where there was once competing priorities from multiple masters, there is now a single set of priorities in the backlog. And where there was once too much work in progress, there is now a plan constrained by what time has shown is really possible. In combination, these can take a team to new levels of productivity. However, the team may find themselves constrained by the lack of technical practices, such as coding reviewsautomated acceptance tests, and continuous integration.

익스트림 프로그래밍과 같은 기타 애자일 프로세스에는 기술 절차를 통해 팀이  지속 가능한 속도를 유지하고 관리팀 및 이해 관계자에게 투명성과 가시성을 제공하는 역량을 지원하는 것과 관련된 강력한 옵션이 있습니다. 몇몇 스크럼 팀은 기술 작업을 백로그에 저장하는 방법에 의지하고 있습니다. 이 방법을 사용하는 경우 스크럼 가이던스 내에서는 문제가 없지만 제품 소유자가 기능에 대해 가지는 편견 등의 현실적인 문제에 즉시 마주하게 됩니다. 제품 소유자가 상당한 기술적인 지식을 보유하지 않은 이상 기술 절차 비용/이점을 평가할 스킬이 없을 수 있습니다. 기술 작업이 운영으로 확장되어 안정성, 성능, 보안을 지원함에 따라 제품 소유자가 이러한 스킬을 갖추기가 더 어려워지고 있습니다.

제품 소유자 및 서비스 소유자

Atlassian은 운영하는 제품에 각기 다른 2개의 역할이 있는 것이 좋다는 점을 알고 있습니다. Atlassian의 제품 소유자는 사용자에게 필요한 기능은 잘 파악하지만, 이러한 기능을 성능, 안정성, 보안 등 기능 외 특성과 비교해 보는 것에는 서툽니다. Atlassian의 일부 SaaS 제품에는 또한 이러한 기능 외 특성의 우선순위를 지정하는 서비스 소유자가 있습니다. 이 두 소유자가 '흥정'을 해야 하는 경우도 가끔 있지만 대부분의 경우 독립된 팀이 이러한 업무를 수행합니다. 이는 운영팀의 '피드백을 확대'하는 유일한 방법이 아닐 수 있지만, 제품 소유자가 기능에 대해 흔히 가지는 편견을 극복하는 데 도움이 됩니다. '두 소유자' 접근 방식은 DevOps로 향하는 유일한 길이 아닙니다. 중요한 점은 이러한 기능 외 특성을 '기능'으로 이해하고 다른 기능 사용자 스토리처럼 계획 및 우선순위를 지정할 수 있다는 것입니다.

궁극적으로 스크럼에 관한 이러한 문제는 온전히 스크럼 그 자체만의 문제는 아닙니다. 모든 애자일 방법과 마찬가지로 스크럼에는 회고라고 하는 기본으로 제공되는 '프로세스 개선' 메커니즘이 있습니다. 그러므로 일부 스크럼 팀에서는 DevOps를 영감의 원천으로 활용하고 스크럼 회고를 DevOps를 목표로 정비하고 조정하는 기회로 활용한다고 생각해도 괜찮습니다. 그러나 대부분의 팀에는 외부의 아이디어가 필요한 것이 현실적입니다. DevOps가 업무 중심으로 자리 잡지 않는 한(이를 가르쳐 주지 않는 한), 스크럼을 통해 자연스럽게 생겨나지는 않습니다. 애자일 또는 DevOps 코치와의 협업은 이들에게 소프트웨어 빌드, 테스트, 구축에 대한 자동화 경험이 있지 않은 한 그다지 중요하지 않습니다.

DevOps에는 지속적 배포만 있는 것이 아닙니다

When done well, the discipline of Continuous Delivery (CD) helps to limit work in progress, while the automation of deployment helps to elevate constraints. In this way, CD helps a software team deliver more frequently and with higher quality, instead of having to choose between the two. However, just as teams focusing only on Scrum can miss the broader context of Agile, so too can teams focusing on Continuous Delivery miss the broader context of DevOps.

The practice of CD does not directly address problems in communication between the business and a software team. If the business has a year-long, budget-driven planning cycle, then a team delivering every commit into production may still have to wait months before the business can react. All too often those reactions come as step-functions, like canceling the project, or worse doubling the project team (because a large influx of new people is disruptive).

The Agile Fluency Model indicates the first level of fluency as "Focus on Value", where teams focus on transparency and alignment. Without this fluency, CD can easily devolve into an endless cycle of technical improvement that yields no appreciable value to the business. A team might get good at delivering fast with high quality, but for a product that has low value for end-users or the business. Even when there are many users who say good things, that assessment of low value might only be possible at a larger business portfolio level. Without this important fluency, it is hard to weigh technical practices against features. This is particularly important for a team with a legacy codebase, that may not have automated tests or a design suitable for frequent deployment. In a legacy context, a CD transformation may take years. So it's that much more important to be able to demonstrate business benefit.

세 가지 방법

DevOps는 배포 파이프라인을 자동화하는 것 그 이상입니다. John Allspaw의 말을 빌자면 DevOps는 "개발팀처럼 생각하는 운영팀, 운영팀처럼 생각하는 개발팀"이라고 말합니다. Gene Kim은 이러한 사고방식에 대해 DevOps의 원칙으로서의 세 가지 방법을 설명합니다.

첫 번째 방법 시스템 사고 emphasizes the performance of the entire system, as opposed to the performance of a specific silo of work or department — this can be as large as a division or as small as an individual contributor.
두 번째 방법 피드백 루프 확대 오른쪽에서 왼쪽으로 이동하는 피드백 루트를 만듭니다. 거의 모든 프로세스 개선 이니셔티브의 목표는 피드백 루프를 단축하거나 확대하여 필요한 수정이 계속 이루어지도록 하는 것입니다.
세 번째 방법 반복 실험 및 학습 문화 반복 실험을 통해 위험을 감수하고 실패를 통해 배우며, 전문적 지식을 습득하려면 반복과 연습이 반드시 필요하다는 것을 이해하는 문화를 만듭니다.

 

CD(지속적 배포)는 첫 번째 방법에 집중하여 개발에서 운영으로 가는 흐름을 자동화합니다. 자동화는 배포 시스템을 가속화하는 데 확실한 역할을 합니다. 그러나 시스템적 사고에는 자동화만 있는 것이 아닙니다.

The Second Way is characterized by the practice, "Devs wear pagers too."  Although the literal use of pagers may not be necessary, it means pulling developers into operational issues. This helps developers understand the consequences of their development choices. For example, that can inspire developers to put log messages in better places and to make those messages more meaningful. It's not just about awareness. Developers also bring their internal understanding of the system to troubleshooting efforts, so a resolution can be found and implemented faster.

The Third Way is about making incremental experiments in the system as a whole, not just as changes to the application moving through the pipeline. In other words, it's relatively easy to see how long automation takes and to use increasingly powerful infrastructure to keep improving it. It's harder to understand how the hand-offs between roles or organizations introduces delays. This means teams "inspect and adapt" across the whole delivery workflow, looking for opportunities to improve human collaboration. For that matter, CD requires a habit of adapting and improving. If the team doesn't reflect on how to become more effective, and then tune and adjust its behavior on anything else, then CD will not grow and thrive either. The team needs to feel empowered to solve their own problems.

스크럼에서 회고를 수행할 때마다 절차와 도구를 개선하는 기회를 얻을 수 있습니다. 그러나 팀이 단기 및 장기 기술 문제를 해결하는 데 이러한 기회를 활용하지 않는 경우에는 제품 소유자가 CD 작업을 백로그에 기록할 때까지 기다려야 하는데, 그런 일은 일어나지 않습니다.

DevOps는 소프트웨어팀 외의 팀에도 적용되는 애자일입니다

스크럼은 주로 다음과 같은 애자일 원칙에 매핑됩니다. "개발하기에 늦었다 하더라도 요구 사항 변화를 적극적으로 받아들인다. 애자일 프로세스에서는 고객의 경쟁우위를 위해 변화를 활용한다."

지속적 배포는 주로 다음과 같은 애자일 원칙에 매핑됩니다. "우리의 가장 높은 우선순위는 유용한 소프트웨어의 빠른 지속적 배포를 통해 고객을 만족시킨다."

이는 애자일이 스탠드업 및 스프린트 계획과 같은 형식보다 오가는 변화를 받아들이는 것과 더 관련이 있음을 의미합니다. 실제로 애자일 성명에는 기타 10개 원칙 이 있습니다. 해당 원칙 중 몇 가지만 선택하기보다 모든 원칙이 전반적으로 고려되어야 합니다. 이러한 원칙들은 변화에 대한 태도를 나타내며, 이는 애자일 및 DevOps에 모두 공통적으로 적용됩니다.

DevOps 팀원들은 취약한 시스템을 실행하던 중 문제를 겪고 있습니다. 이 시스템은 비즈니스에 있어 매우 중요한 시스템이기 때문에 긴급한 변경이 필요한 상황입니다. 이처럼 변경을 수용하는 애자일 아이디어는 '변경를 위한 변경'이 아닙니다. 개발팀이 이러한 변경의 품질을 책임지는 동시에, 비즈니스 가치를 제공하는 전반적인 능력을 개선하는 것입니다. 이렇게 비즈니스 가치에 집중하는 것은 애자일과 DevOps가 공유하는 또 다른 측면입니다.

Finally, neither Agile nor DevOps are business goals in and of themselves. Both are cultural movements that can inspire your organization with better means for achieving your goals. Agile and DevOps work better in combination, than as adversaries. The trick to avoiding confrontation between these two ideas is to understand the deeper values and principles upon which they are formed. Quick, but narrow, definitions lead to siloed thinking. Now that you know there's more to Agile than Scrum, and there's more to DevOps than CD, you're ready to try the powerful Agile + DevOps combination.