Agile이란?

Agile은 증분 전달, 팀 공동 작업, 지속적인 계획 및 지속적인 학습을 강조하는 소프트웨어 개발에 대한 접근 방식을 설명하는 용어입니다. Agile이라는 용어는 2001년 Agile 선언문에서 만들어졌습니다. 이 성명서는 소프트웨어 개발에 대한 더 나은 접근 방식을 안내하는 원칙을 수립하기 위한 것입니다. 성명서의 핵심은 Agile 운동의 기초를 나타내는 4개의 값 문을 선언합니다. 서면으로 성명서는 다음과 같이 명시합니다.

우리는 다음을 소중히 여겼습니다.

• 프로세스와 도구에 대한 개인 및 상호 작용.
• 포괄적인 문서보다는 작동 소프트웨어를 우선시합니다.
• 계약 협상보다는 고객 협업을 우선시합니다.
• 계획에 따른 변화에 대응.

이 성명서는 이러한 진술의 오른쪽에 있는 항목이 중요하지 않거나 필요하지 않다는 것을 의미하지는 않습니다. 대신 왼쪽의 항목은 단순히 더 가치가 있습니다.

Agile 메서드 및 사례

Agile은 문제가 아니라는 것을 이해하는 것이 중요합니다. Agile은 수행하지 않습니다. 오히려 Agile은 소프트웨어 개발에 대한 접근 방식을 추진하는 사고 방식입니다. 모든 상황에서 작동하는 단일 접근 방식이 없기 때문에 Agile이라는 용어는 성명서의 값 문에 부합하는 다양한 방법과 관행을 나타내기 위해 왔습니다.

프레임워크라고도 하는 Agile 메서드는 DevOps 수명 주기의 단계(계획, 개발, 전달 및 작업)에 대한 포괄적인 접근 방식입니다. 그들은 명확한 지침과 원칙을 사용하여 작업을 수행하는 방법을 규정합니다.

스크럼 은 가장 일반적인 Agile 프레임워크이며 대부분의 사람들이 시작하는 프레임워크입니다. 반면 Agile 사례는 소프트웨어 개발 수명 주기 단계에서 적용되는 기술입니다.

• 포커 계획은 팀 구성원이 수행 의 의미에 대한 이해를 공유하도록 장려하기 위해 고안된 공동 예측 연습입니다. 많은 사람들이 프로세스 재미를 발견하고, 팀워크와 더 나은 추정을 육성하는 데 도움이 입증되었습니다.
• CI(연속 통합)는 코드 변경 내용을 기본 분기에 자주 통합하는 일반적인 Agile 엔지니어링 사례입니다. 자동화된 빌드는 변경 내용을 확인합니다. 그 결과 통합 부채가 감소하고 지속적으로 배송 가능한 기본 분기가 있습니다.

이러한 관행은 모든 Agile 관행과 마찬가지로 Agile 선언문의 원칙과 일치하기 때문에 Agile 레이블을 전달합니다.

Agile이 아닌 것

Agile이 인기를 얻으면서 많은 고정관념과 오해가 그 효과에 부정적인 그림자를 드리우고 있습니다. 책임 없이 "예, 우리는 Agile을 하고 있습니다"라고 쉽게 말할 수 있습니다. 이 점을 염두에 두고 Agile이 아닌 몇 가지 사항을 고려합니다.

• Agile은 카우보이 코딩이 아닙니다. Agile은 소프트웨어 개발에 대한 "우리가 가는 대로 알아낼 것"이라는 접근 방식과 혼동해서는 안 됩니다. 그러한 생각은 진실에서 더 멀어질 수 없습니다. Agile에는 모든 스프린트에서 고객에게 제공되는 완료된 값과 명시적 값의 정의가 모두 필요합니다. Agile은 개인과 팀의 자율성을 소중히 여기지만, 증가된 자율성이 향상된 가치를 창출하도록 조정된 자율성을 강조합니다.
• Agile은 엄격하고 계획적이지 않습니다. 반대로 Agile 방법론과 관행은 일반적으로 계획 분야를 강조합니다. 핵심은 미리 계획하는 것이 아니라 프로젝트 전체에서 지속적인 계획입니다. 지속적인 계획을 통해 팀은 자신이 실행하는 작업에서 학습할 수 있습니다. 이 방법을 통해 계획의 ROI(투자 수익률)를 최대화합니다.

"계획은 쓸모가 없지만 계획은 전부입니다." - 드와이트 디 아이젠하워

• Agile은 로드맵이 부족하다는 변명이 아닙니다. 이 오해는 아마 전반적으로 Agile 운동에 가장 큰 해를 끼쳤습니다. Agile 접근 방식을 따르는 조직과 팀은 현재 진행 중인 위치와 달성하려는 결과를 절대적으로 알고 있습니다. 프로세스의 일부로 변경 내용을 인식하는 것은 매주, 스프린트 또는 월마다 새로운 방향으로 피벗하는 것과 다릅니다.
• Agile은 사양 없이 개발되지 않습니다. 어떤 프로젝트에서든 팀이 왜 그리고 어떻게 작업하는지에 맞게 조정해야 합니다. 사양에 대한 Agile 접근 방식에는 사양 의 크기가 올바른지 확인하고 팀이 작업 순서를 지정하고 제공하는 방법을 적절하게 반영하는 것이 포함됩니다.
• Agile은 계획되지 않은 작업 및 기타 중단을 수용할 수 없습니다. 일정에 따라 스프린트를 완료하는 것이 중요합니다. 그러나 사이드트랙 개발 문제가 발생한다고 해서 스프린트가 실패해야 한다는 의미는 아닙니다. 팀은 문제 및 예기치 않은 문제에 대한 리소스를 미리 지정하여 중단을 계획할 수 있습니다. 그런 다음 이러한 문제를 해결할 수 있지만 개발을 계속 진행할 수 있습니다.
• Agile은 대규모 조직에 적합하지 않습니다. 일반적인 불만은 Agile 방법론의 핵심 구성 요소인 협업이 대규모 팀에서 어렵다는 것입니다. 또 다른 단점은 Agile에 대한 확장 가능한 접근 방식이 유연성을 손상시키는 구조와 메서드를 도입한다는 것입니다. 이러한 오해에도 불구하고 Agile 원칙을 성공적으로 확장할 수 있습니다. 이러한 어려움을 극복하는 방법에 대한 자세한 내용은 대규모 팀으로 Agile 크기 조정을 참조 하세요.
• Agile은 비효율적이지 않습니다. 고객의 변화하는 요구에 맞게 개발자는 각 반복 시간을 투자하여 작업 제품을 시연하고 피드백을 수집합니다. 이러한 노력은 개발에 소요되는 시간을 줄이는 것이 사실입니다. 그러나 초기에 고객 요청을 통합하면 상당한 시간이 절약됩니다. 기능이 고객의 비전에 맞게 유지되면 개발자는 주요 점검을 피합니다.
• Agile은 데이터 스트리밍을 중심으로 하는 오늘날의 애플리케이션에 적합하지 않습니다. 이러한 프로젝트에는 일반적으로 사용자 인터페이스보다 더 많은 데이터 모델링 및 ETL(추출-변환-로드) 워크로드가 포함됩니다. 이 때문에 일관되고 촉박한 일정으로 사용 가능한 소프트웨어를 입증하기가 어렵습니다. 그러나 개발자는 목표를 조정하여 Agile 접근 방식을 계속 사용할 수 있습니다. 개발자는 각 반복 작업을 수행하는 대신 데이터 실험 실행에 집중할 수 있습니다. 몇 주마다 작업 제품을 제공하는 대신 데이터를 더 잘 이해하는 것을 목표로 할 수 있습니다.

왜 Agile인가요?

그렇다면 민첩한 접근 방식을 고려하는 이유는 무엇일까요? 지난 10-15년 동안 소프트웨어 빌드에 대한 참여 규칙이 근본적으로 변경된 것은 분명합니다. 대부분의 활동은 비슷하게 보이지만, 이를 적용하는 풍경과 환경은 눈에 띄게 다릅니다.

• 오늘날 소프트웨어를 2000년대 초반과 비교해 보세요. 사람들이 비즈니스 소프트웨어를 구입하기 위해 매장으로 얼마나 자주 운전합니까?
• 제품에 대한 고객의 피드백을 수집하는 방법을 고려합니다. 팀은 소셜 미디어 전에 사람들이 자신의 소프트웨어에 대해 어떻게 생각했는지 어떻게 이해했습니까?
• 팀이 제공하는 소프트웨어를 업데이트하고 개선하려는 빈도를 고려합니다. 연간 업데이트는 더 이상 현대 경쟁에 대해 실현 가능하지 않습니다.

Forrester의 Diego Lo Guidice는 자신의 블로그 인 Transforming Application Delivery (2020년 10월)에서 가장 잘 말합니다.

"모든 것이 크게 바뀌었습니다. 녹색과 클린 외에도 지속 가능성은 오늘날 우리가 구축하는 것이 내일 쉽고 빠르게 변화해야 한다는 것을 의미합니다. 전략적 계획은 단기적이고 계획과 변화는 지속됩니다." - 디에고 로 구이디스, 포레스터

규칙이 변경되었으며, 전 세계 조직은 이제 이에 따라 소프트웨어 개발에 대한 접근 방식을 조정합니다. 민첩한 방법과 관행은 모든 문제를 해결할 것을 약속하지 않습니다. 그러나 협업, 지속적인 계획 및 학습을 통해 솔루션이 등장하고 고품질 소프트웨어를 더 자주 제공하려는 욕구를 통해 솔루션이 등장하는 문화와 환경을 구축할 것을 약속합니다.

다음 단계

Agile 경로를 소프트웨어 개발로 가져가기로 결정하면 DevOps 프로세스를 개선할 수 있는 흥미로운 기회가 발생할 수 있습니다. 한 가지 주요 고려 사항은 Agile 개발이 조직의 현재 접근 방식과 비교하고 대조하는 방법에 중점을 둡니다.