애자일 방법론

"애자일 방법론"은 "애자일"이라고 알려진 제품 개발 철학을 반영하는 개념, 관행, 때로는 도구를 모두 지칭하는 포괄적인 용어입니다.

가상 이벤트 Agility 귀하의 기업을 활성화할 수 있습니다

차례

애자일이란?

애자일 방법

애자일의 이점

차례

애자일이란?

애자일 방법

애자일의 이점

주요 블로그

ITIL 대 Agile: IT 서비스 팀이 각 방법론의 장점을 최대한 활용하는 방법

애자일 운동은 2001년 유타주에서 열린 한 리트리트에서 17명의 미래지향적인 개발자들이 모인 자리에서 시작되었습니다. 이 리트리트에서 확립된 철학과 원칙은 애자일의 기반이 되었고, 이후 초기 작업에서 발전된 애자일 방법론이 탄생했습니다.

"애자일 소프트웨어 개발 선언문"이라는 원본 문서가 발표된 이후, 애자일 방법론은 소프트웨어 개발뿐만 아니라 거의 모든 분야의 조직에 지대한 변화를 가져왔습니다. 린 제품 개발, 반복적인 발견, 변화 중심 개발, 그리고 모든 기업 및 사회 집단에서 수행되는 협업이라는 가치는 전 세계적으로 새롭고 진보된 비즈니스 및 제품 모델의 기반을 형성했습니다.

이 애자일 방법론 가이드는 애자일의 핵심 원칙을 소개하는 개요 역할을 합니다. 2001년 선언문에서 제안된 애자일 방법론의 정의부터 시작하여, 애자일에서 파생된 가장 잘 알려진 파생 기법들을 설명합니다. 마지막으로, 가장 널리 사용되는 애자일 방법론과 도구들을 살펴보겠습니다.

애자일이란?

애자일은 지속적인 변화와 개선에 대한 헌신으로 생각할 수 있는 업무 접근 방식(처음에는 소프트웨어 개발)입니다.

애자일 가치

애자일은 2001년에 원래 애자일 매니페스토 팀에서 작성한 다음 가치에 간결하게 설명되어 있습니다.

개인과 상호작용 프로세스와 도구에 대해
작동하는 소프트웨어 포괄적인 문서에 대해
고객 협업 계약 협상에 관하여
변화에 대응 계획을 너무 많이 따르다

이러한 원칙들을 살펴보면, 애자일은 애자일의 본질뿐 아니라 애자일이 아닌 것으로도 정의된다는 것을 쉽게 알 수 있습니다. 위에 제시된 네 가지 가치는 모두 경직된 결과물보다 반복적인 발견과 협업을 중시한다는 공통점을 가지고 있습니다. 이러한 요소에 집중함으로써 애자일 팀은 낭비를 줄이면서 더 나은 제품을 만들 수 있을 뿐만 아니라, 기능 릴리스를 원활하게 유지하면서 발견을 위한 여지를 확보할 수 있습니다.wing to 최종 고객.
애자일 개발 vs. 워터폴 개발
애자일의 설립자들은 소프트웨어 업계의 전통적인 업무 방식에서 크게 벗어날 것을 제안했습니다. 당시(2001년경) 소프트웨어는 주로 몇 달 전에 설정된 특정 사양을 기반으로 디지털 제품을 제작하는 단일 프로젝트 기반 작업으로 개발되었습니다. 제품에 대한 비전은 컨설턴트, 임원, 관리자로 구성된 그룹이 결정하고, 이들은 경영진에 전달할 요구 사항 목록을 작성했습니다. 경영진은 요청된 소프트웨어의 코딩, 컴파일, 테스트, 그리고 구축 작업을 정해진 예산 내에서 정해진 기간 동안 수행하도록 위임했습니다.

개발자들은 이 시스템을 "폭포수" 방법론이라고 불렀습니다. 소프트웨어 요구 사항과 제공물이 회사 상위에서 핵심 개발 직원에게까지 모두 지시되었기 때문입니다.

애자일 협력자들은 여러 가지 이유로 이러한 형태의 소프트웨어 개발을 거부했습니다. 첫째, 폭포수형 개발 방식은 개발 중 변할 수 있는 고객 요구에 대응하기에는 너무 경직되어 있었습니다. 둘째, 폭포수형 제품 설계는 모든 혁신을 프로젝트 시작 전에 고안해야 한다는 것을 의미했습니다. 이러한 경직된 프레임워크는 출시가 완료될 때까지 새로운 기능 가능성을 발견할 여지를 거의 남기지 않았습니다. 더 나아가, 소프트웨어가 의도한 대로 작동하지 않을 수 있기 때문에, 폭포수형 프로젝트에서 개발 도중 이러한 문제를 발견하는 것은 막대한 비용 손실을 초래하는 지연을 의미했습니다.

애자일의 창시자들은 발견, 혁신, 그리고 반복에 열려 있는 소프트웨어 개발 방식을 제안했습니다. 모든 기능이 완벽하게 갖춰진 소프트웨어 전체를 특정 날짜에 출시하는 대신, 기능별 빌드를 점진적으로 출시할 수 있었습니다. 이를 통해 출시 기간을 단축하고, 모든 개발 예산을 한꺼번에 책정하는 대신 단계적으로 배정할 수 있었습니다.

가장 중요한 것은, 애자일 개발 원래 구상했던 제품이 고객과 회사 자체에 기대 수준의 가치를 제공하지 못할 수도 있음을 인정합니다. 빌드 단계에서 작업하면 새로운 아이디어를 추가하거나 제품 전략을 변경할 수 있으며, 이를 통해 개발 과정에서 워터폴 방식으로는 불가능한 방식으로 대응할 수 있습니다.

애자일 원칙

워터폴 방식의 단점을 극복하기 위해 애자일 철학은 회사 내 모든 곳에서 아이디어를 도출하도록 장려합니다. 또한, 제품 개발 주기를 반복적인 변경 사항에 집중하고 자주 제공하는 것이 중요합니다. 기능적 빌드를 만드는 데 몇 달 또는 몇 년이 걸리는 주요 제품 출시와는 대조적입니다.

그룹은 기존의 "폭포수" 관리 중심 개발 주기를 대신하여 당시로서는 급진적이었던 다음과 같은 작업 방법을 제안했습니다.

새로운 소프트웨어를 만들 때는 포괄적인 성과물보다는 간단한 개념과 아이디어부터 시작하세요. 개념이 고객과 내부 이해 관계자에게 가치를 제공할 수 있는 잠재력을 보여주는 실용적인 개념 증명 프로토타입을 개발하세요.
사업가와 개발팀이 협업하여 작업 프로토타입을 더욱 견고한 버전으로 발전, 개선, 발전시키는 방법을 결정합니다.
진행 상황을 파악하고 제품 개선을 위한 새로운 기회를 모색할 수 있도록 개인과 팀원 간의 직접 대화를 위한 시간과 공간을 매일 확보하세요. 이는 간단한 스탠드업 미팅이나 긴 스크럼 미팅의 형태로 이루어질 수 있습니다.
새로운 작업 버전의 소프트웨어를 자주 제공하고, 새로운 변경 사항을 라이브 프로덕션 환경에 지속적으로 통합하고 배포합니다. 변경된 각 버전은 이전 버전의 개선된 버전을 나타냅니다.
각 작업 기간(스프린트)의 결과를 되돌아보고, 배운 교훈을 활용하여 이후 개발을 개선합니다.
직접 설문 조사나 간접 데이터 신호를 통해 고객에게 프로세스에 대한 의견을 전달하여 제품을 지속적으로 개선합니다.

애자일 및 린 제조

애자일은 20세기 후반 선진 산업 제조업의 성장기에 개척된 철학인 린 제조(Lean Manufacturing)에서 많은 교훈을 얻었습니다. 린 제조는 제품 생산 과정에서 불필요한 단계를 없애고 생산 속도를 향상시킵니다. 이러한 방법론은 일본 자동차 회사 도요타에서 도요타 생산 시스템(TPS)을 구축하는 데 널리 사용되었습니다.

린에서 얻은 Agile의 주요 교훈은 다음과 같습니다.

가능한 가장 효율적인 프로세스를 만들어 보세요.
여러 공정을 결합하고 더 나은 제품을 만들어내지 못하는 공정을 제거하여 낭비(무다)를 없앱니다.
제품의 품질과 제조 주기가 일관되도록 결과를 엄격하게 측정합니다.
근로자들이 프로세스 개선에 기여하도록 하고, 핵심 인력이 품질, 속도, 효율성 목표를 달성하도록 돕습니다.
지연이나 품질 저하에 기여하는 프로세스 단계를 파악하고 이러한 "흐름" 문제를 해결하여 원활하고 효율적인 프로세스를 통해 신뢰할 수 있는 기반에서 일관된 제품을 만들어냅니다.

애자일 방법론이란 무엇입니까?

애자일 방법론은 2001년에 처음 체계화된 애자일의 이상을 모두 반영하는 일련의 작업 방식입니다. 따라서 "애자일 방법론"이라는 범주에는 실제로 여러 방법론이 포함될 수 있습니다. 이러한 방법론은 가장 널리 사용되는 애자일 방법론을 구성하며, 각 방법론에 대한 자세한 내용은 아래에서 설명합니다.

애자일 방법론은 다음과 같은 특징으로 정의됩니다.

팀은 조직의 다양한 부서에 속한 전문가로 구성됩니다(기능 간 팀).
교차 기능 팀은 팀 자체와 고객 피드백, 제품 전략 팀에서 얻은 혁신적인 아이디어를 바탕으로 소프트웨어/제품 개념의 프로토타입 버전을 구축하는 책임을 맡습니다.
그런 다음 소프트웨어 제품은 더 많은 기능, 특징, 개선 사항 및 수정 사항을 추가하기 위해 짧은 "스프린트"를 통해 개정됩니다.
제품 변경 및 개선에 대한 아이디어는 회사 전체에서 수집됩니다. 이러한 문제에 대한 논의는 자주 이루어집니다.
교차 기능 팀은 매일 짧은 "스탠드업" 회의를 통해 업무 진행 상황, 과제, 우선순위 및 새로운 기회에 대해 논의합니다.
스프린트가 완료되면 스프린트 중에 생성된 변경 사항이 현재 버전의 제품에 통합됩니다.
정기적인 테스트와 고객 피드백 반영을 포함한 품질 관리가 프로세스 전반에 걸쳐 시행됩니다. 특정 릴리스의 문제점은 새 릴리스의 통합 및 배포 전에 발견되어 (이상적으로는) 처리됩니다.
각 스프린트가 끝날 때마다, 교차 기능 팀은 결과와 프로세스 진행 상황을 되돌아보는 시간을 갖습니다. 학습한 내용을 바탕으로 새로운 목표와 이정표가 설정될 가능성이 높습니다.
여러 기능팀이 참여하는 새로운 스프린트가 구성되며, 이를 통해 새로운 기능, 개선 사항, 수정 사항이 추가됩니다.

애자일 방법에는 어떤 유형이 있나요?

애자일에는 여러 가지 인기 있는 버전과 파생된 방법론이 있으며, 애자일 선언문보다 앞서 존재했지만 그 가치를 공유하는 방법론들도 있습니다. 스크럼, 린, 칸반, 익스트림 프로그래밍(XP), 기능 주도 개발(FDD), 동적 시스템 개발 방법론(DSDM), 그리고 크리스탈 등이 있습니다.

스크럼

스크럼 반복적인 애자일 개선을 완료하기 위해 공격적인 스프린트를 활용하는 데 중점을 둡니다. 스크럼 팀은 스프린트 기간 동안 주요 작업을 완료하기 위해 협력하며, 각 스프린트는 릴리스의 품질과 무결성을 저해하지 않으면서 중요한 작업을 완료할 수 있도록 계획됩니다.

스크럼은 "스크럼 마스터"와 "제품 책임자"라는 역할을 도입한 것으로 유명합니다. 두 역할 모두 모든 작은 프로세스가 모여 바람직한 결과를 도출하도록 감독하는 역할을 합니다. 또한, 다음 스프린트에 도입할 적절한 기능, 개선 사항, 그리고 수정 사항을 나타내는 "제품 백로그"라는 개념도 중요합니다.

스크럼 방법론은 800명 이상의 직원을 보유한 대규모 조직의 여러 팀으로 확장 가능한 것으로 입증되었습니다. 자세한 내용은 Digital.ai Agility, 이전에는 VersionOne이 지원되었습니다. 스크럼 스프린트 계획 제품 백로그를 관리하기 쉽게 만들어줍니다.

린

위에서 부분적으로 설명한 린 제조는 예측 가능한 작업 "흐름"을 통해 지속적이고 일관된 가치 창출을 우선시합니다. 개발 워크플로의 속도와 효율성을 강조하며, 프로그래머와 고객 간의 빠르고 신뢰할 수 있는 피드백에 의존합니다. 린 제조는 고객 요청을 통해 작업 결과물을 "끌어오는" 방식을 사용합니다. 연구 결과에 따르면 계층적 제어 흐름보다 빠르고 효율적이기 때문에, 린 제조는 개인과 소규모 팀에게 의사 결정 권한과 역량을 집중시킵니다.

린은 또한 팀 자원 사용의 효율성에 집중하여 모든 사람이 최대한 많은 시간 동안 생산적으로 일할 수 있도록 합니다. 린은 동시 작업과 팀 내 워크플로우 종속성을 최소화하는 데 중점을 둡니다. 또한 린은 자동화된 단위 테스트를 코드 작성과 동시에 작성할 것을 강력히 권장합니다.

Kanban

칸반은 린(Lean)의 역사와 밀접하게 연관된 생산 관리 방법입니다. 칸반 방식은 주로 "칸반 보드"를 활용하여 현재 작업 항목의 양과 진행 상황을 추적합니다. 칸반 보드는 스티키 노트(또는 가상 메모)를 사용하여 프로세스의 각 단계에서 현재 작업 항목의 수를 추적합니다. 작업 항목이 완료되면 스티키 노트는 프로세스의 다음 단계로 이동합니다.

칸반은 개발 주기 내에서 현재 작업 항목의 양과 진행 상황을 시각화하여 흐름을 강조합니다. 많은 작업 항목이 단일 단계에 쌓이는 경우, 스프린트 또는 작업 그룹을 완료로 이끌기 위해 진행 중인 작업(WIP)의 양을 즉시 처리해야 한다는 신호입니다. WIP가 제거되면 새로운 용량이 확보되므로 백로그에서 새 작업 항목을 "풀"해야 한다는 신호로도 작용할 수 있습니다.

익스트림 프로그래밍(XP)

익스트림 프로그래밍(Extreme Programming), 즉 "XP"는 90년대 후반 애자일 매니페스토(Agile Manifesto)의 공동 연구자인 켄트 벡(Kent Beck)에 의해 만들어졌습니다. 애자일과 마찬가지로, XP는 높은 고객 참여, 신속한 피드백 루프, 지속적인 테스트지속적인 계획과 긴밀한 팀워크를 통해 일반적으로 1~3주 간격으로 작동하는 소프트웨어를 제공합니다.

원래 XP 레시피는 단순함, 소통, 피드백, 그리고 용기라는 네 가지 단순한 가치에 기반합니다. 또한 12가지 핵심 지원 관행을 통해 기능합니다.

계획 게임
소규모 릴리스
고객 수용 테스트
심플한 디자인
쌍 프로그래밍
테스트 주도 개발
리팩토링
지속적인 통합
집단 코드 소유권
코딩 표준
은유
지속 가능한 속도

기능 중심 개발 (FDD)

기능 중심 개발 (FDD) 애자일 방법론의 한 변형으로, 기능별로 개별적으로 수행해야 하는 구체적이고 매우 짧은 작업 단계를 설명합니다. 여기에는 도메인 워크스루, 설계, 설계 검사, 코드, 코드 검사, 그리고 빌드로의 승격이 포함됩니다.

FDD의 기본 개념은 모델을 사용하여 제품의 의도된 미래 상태를 묘사할 수 있으며, 기능에 대한 작업은 "클라이언트의 눈에 유용한" 것으로 표현되는 전체적인 제품 모델을 구축하는 데 도움이 된다는 것입니다.

FDD는 "정기 빌드" 및 "컴포넌트/클래스 소유권"과 같은 구체적인 프로그래머 관행을 권장합니다. FDD 지지자들은 FDD가 다른 접근 방식보다 확장성이 뛰어나고 대규모 팀에 더 적합하다고 주장합니다.

동적 시스템 개발 방법(DSDM)

DSDM은 1994년에 처음 설명된 Agile의 또 다른 초기 조상입니다. DSDM의 생성의 씨앗은 표준화를 목표로 하는 신속한 애플리케이션 개발(RAD)에서 나왔습니다. 소프트웨어 제공 프레임워크. 애자일(Agile)이 등장한 이후, DSDM은 더욱 발전하고 성숙되어 애자일 프로세스 및 반복적 소프트웨어 개발 프로젝트의 계획, 관리, 실행 및 확장을 위한 포괄적인 기반을 제공하게 되었습니다.

DSDM은 비즈니스 요구/가치, 적극적인 사용자 참여, 역량 강화된 팀, 빈번한 배포, 통합 테스트, 그리고 이해관계자 협업을 중심으로 하는 9가지 핵심 원칙을 기반으로 합니다. DSDM은 특히 "비즈니스 목적 적합성"을 시스템 제공 및 수용의 주요 기준으로 삼고 있으며, 20%의 시간 안에 구축 가능한 시스템의 80%의 유용성에 중점을 둡니다.

DSDM은 시간 상자 모델을 사용하여 특정 성과물의 우선순위를 정하고, 우선순위가 낮은 항목은 시간 상자 마감일을 맞추기 위해 미리 선택되어 제쳐두어집니다.

Crystal

크리스탈 방법론은 소프트웨어 개발에 있어 가장 가볍고 적응력이 뛰어난 접근 방식 중 하나입니다. 크리스탈 방법론의 핵심 원칙에는 팀워크, 소통, 단순성, 그리고 프로세스를 자주 조정하고 개선하기 위한 성찰이 포함됩니다. 다른 애자일 프로세스 방법론과 마찬가지로, 크리스탈 방법론은 작동하는 소프트웨어의 조기 및 빈번한 제공, 높은 사용자 참여, 적응성, 그리고 관료주의나 방해 요소 제거를 촉진합니다.

크리스탈은 실제로 크리스탈 클리어, 크리스탈 옐로, 크리스탈 오렌지 등과 같은 애자일 방법론들로 구성되어 있으며, 각 방법론의 고유한 특성은 팀 규모, 시스템 중요도, 프로젝트 우선순위 등 여러 요인에 의해 결정됩니다. 이 크리스탈 방법론들은 각 프로젝트마다 고유한 특성을 충족하기 위해 약간씩 맞춤화된 정책, 관행, 프로세스가 필요할 수 있다는 점을 인지하고 있습니다.