애자일 방법론 뜻과 개념에 대해서 이야기해봅시다.
애자일 방법론 뜻과 개념 알기
애자일 방법론 뜻(Agile Software Development)은 빠르고 변화에 유연하게 대응할 수 있도록 적응적인 접근 방식(Adaptive Approach)으로 짧은 반복 주기를 통해 개발을 진행하는 방법론을 의미합니다.
애자일 방법론(Agile Software Development)은 변경되는 요구 사항들을 최대한 반영하고 프로젝트에서 “가치(Value)”를 더 자주 빈번하게 제공하기 위해서 반복형 생애주기(Iterative Approach)와 증분형 생애주기(Incremental Approach)의 특징을 조합한 방법론입니다.
애자일(Agile)은 “날렵”하고 “민첩한” 의미를 내포하고 있습니다.
애자일 방법론은 개발 프레임워크(Framework)보다는 더 광범위한 개념이지만 적응형 접근 방식(Adaptive Approach)로 간주되는 방법론입니다.
애자일 방법론(Agile Software Development)에서는 제품에 대한 명확한 비전을 수립한 후 초기 요구사항들을 백로그(Backlog) 문서에 작성하고 요구사항에 대해서는 반복 주기를 진행할 때마다 사용자의 피드백과 프로젝트의 환경 변화에 따라 지속적으로 변경하고 구체화시키는 방식으로 진행됩니다.
애자일 방법론에서는 보통 1주에서 2주 기간의 반복 주기를 통해서 진행되며 각 반복이 종료되는 시점에는 프로덕트 오너(Product Owner)와 개발 팀이 리뷰를 통해서 성과를 입증하게 됩니다.
애자일 방법론 뜻과 개념 설명
애자일 방법론 뜻(Agile Software Development)은 개발 대상을 여러 개의 작은 기능으로 분할하여 하나의 기능을 하나의 반복 주기 안에서 개발하는 개발 방법론을 의미합니다.
애자일 방법론(Agile Software Development)은 워터폴(Waterfall) 방법론과 대비되는 방법론입니다.
애자일 방법론에서는 반복 주기를 계속 반복해나가면서 하나씩 기능을 추가하여 개발을 진행하게 됩니다. 그리고 각각의 반복은 소규모 소프트웨어 개발 프로젝트와 유사하다고 볼 수 있습니다.
애자일 방법론에서는 프로젝트 기획 후 여러 번의 스프린트 단위로 프로젝트가 진행됩니다. 여기서 스프린트(Sprint)는 반복(Iteration) 주기나 시간 상자(Time-Boxed) 주기를 의미합니다. 스프린트는 애자일(Agile) 방법론 중에서 스크럼(Scrum) 방식에서 사용하는 개념이기도 합니다.
애자일 방법론의 세부 종류로는 스크럼(Scrum), 익스트림 프로그래밍(XP), 크리스탈(Crystal), PSDM 등이 있습니다. 이중에서 스크럼과 익스트림 프로그래밍이 가장 대표적이고 유명합니다.
애자일 방법론에서 프로젝트 기획 단계에서는 프로젝트 기획, 프로젝트와 제품 비전의 정의, 프로젝트 승인을 진행합니다. 최초의 스프린트 단계에서는 요구사항을 분석하고 제품 백로그를 작성하며 릴리즈 계획을 수립합니다. 이 때 계획은 상위 수준의 일정 계획입니다.
그 이후 스프린트에서는 스프린트를 계획하고 분석, 설계, 개발, 테스트, 리뷰, 회고를 반복해서 진행합니다. 회고(Retrospective)는 스프린트 종료 시점에 진행 결과를 검토하고 학습한 내용을 활용하여 개선 포인트를 찾는 애자일에서 매우 중요한 회의입니다.
애자일(Agile) 방법론에서는 프로덕트 오너(Product Owner)의 역할이 매우 중요합니다. 프로덕트 오너는 비즈니스 정의와 요구사항을 전달하는 주체로 고객을 대표하는 역할을 수행합니다. 프로덕트 오너는 요구사항을 정의하고 요구사항을 추가하거나 변경하고 구체화하고 우선순위 조정을 담당합니다.
애자일(Agile) 방법론은 기존 워터폴(Waterfall) 방식의 소프트웨어 개발 방법론의 문제점을 개선하기 위해서 등장한 방법론입니다.
기존 소프트웨어의 개발 방법론의 문제점은 다양하게 존재합니다.
첫 번째, 기존의 프로젝트 방식은 “갑과 을”과 같은 관계의 문화가 지배적이기 때문에 서로 윈-윈(Win-win)하는 관계가 아니라 윈-루즈(Win-lose)의 제로 섬 게임(Zero-sum game)을 유도하는 방식이었습니다.
갑의 입장에서는 적은 예산으로 최대한 많은 기능을 빨리 얻고자 하여 밀어 붙이게 됩니다. 반대로 을은 많은 예산으로 적은 기능을 여유 있는 일정으로 진행하길 원합니다. 프로젝트가 착수하게 되면 비즈니스 목표 보다는 프로젝트 계획서나 계약서 이행이 중요한 목표가 되는 부작용이 발생하는 것입니다.
두 번째, 문서를 너무 중시합니다. 궁극적으로 필요한 결과물은 시스템이나 소프트웨어 입니다. 최종적으로 완성된 소프트웨어를 통해서 고객과 이해 관계자들의 니즈를 충족시켜주는 것이 중요하며 문서는 의사소통할 수 있는 하나의 수단인 것입니다. 하지만 문서로 의사소통하는 것에는 많은 한계점이 있습니다. 하지만 프로젝트 진행 과정에서 문서가 없으면 새로운 불안감을 주기 때문에 프로젝트가 잘 진행되는지를 확인하기 위해서는 문서를 만들게 됩니다.
세 번째, 성과가 나쁜 것에 대해서는 계획이나 통제의 실패가 원인이 되었다고 인식하는 경향이 있습니다.
이러한 문제점을 해결하기 위해서 애자일 방법론이 등장한 것입니다. 그래서 현재는 프로젝트 방법론에 대해서 워터폴 방법론의 진영과 애자일 방법론의 진영으로 분리됩니다.
애자일에서는 애자일을 위한 사고 방식과 마인드 셋이 중요합니다.
애자일에서는 4가지 가치와 12가지 원칙으로 구성됩니다. 애자일 진영에서는 2001년에 애자일 선언(Agile Manifesto)를 발표하였습니다.
애자일 선언문(Agile Manifesto)
"프로세스나 도구에 앞서 개인과의 상호 작용을
Individuals and interactions over processes and tools
정리를 위한 포괄적인 문서에 앞서 작동하는 소프트웨어를
Working sofware over comprehensive documentation
계약 협상에 앞서 고객과의 협력을
Customer collaboration over contract negotiation
계획 준수에 앞서 변화에 대한 대응을
Responding to change over following a plan
우리는 왼쪽 항목의 가치를 인정하면서도 오른쪽 항목을 더 중요하게 여긴다.
That is, while there is value in the items on the right, we value the items on the left more"
즉, 애자일 선언은 크게 4가지 가치를 가지고 있습니다.
프로세스와 도구 보다는 개인과 상호 작용을 중요시 하는 것이며 포괄적인 문서화 보다는 동작하는 제품을 중요시 하고 계약 협상 보다는 고객과의 협업을 중요시하며 계획을 따르기 보다 변화에 대응하는 것을 더 큰 가치로 둔다는 것입니다.
애자일(Agile) 방법론의 12가지 원칙을 가지고 있습니다.
애자일의 12가지 원칙
1. 우리는 가치 있는 소프트웨어를 "빠르고 지속적"으로 전달하여 고객을 만족시키는 것을
최우선 순위로 한다.
2. 비록 개발 후반부일지라도 요구 사항 변경을 기꺼이 환영한다.
애자일 방법론은 "고객의 경쟁력 우위"를 위해 변경을 원동력으로 사용한다.
3. 동작하는 소프트웨어를 2주에서 2개월 주기로 가능한 더 "짧은 주기"로 인도한다.
4. 프로젝트 기간 내내 개발자들은 "사업에 관련된 사람"들과 매일 함께 일해야 한다.
5. "동기 부여된 개인들"로 프로젝트를 구성하라.
그들에게 필요한 환경과 지원을 제공해주고 업무를 완료할 것이라 믿어라.
6. 개발 팀 내부에서 정보를 전달하고 공유하는 가장 효율적이고 효과적인 방법은 직접
얼굴을 보면서 대화하는 것이다.
7. "동작하는 소프트웨어"가 진척 상황을 측정하는 가장 중요한 척도이다.
8. 애자일 방법론은 지속할 수 있는 개발을 장려한다.
후원자, 개발자, 사용자는 일정한 속도를 계속 유지할 수 있어야 한다.
9. 기술적 탁월함과 좋은 설계에 대한 끊임 없는 관심은 "기민성"을 강화시킨다.
10. 안 해도 되는 일을 최대한 하지 않는 "단순함"이 핵심이다.
11. 최고의 아키텍처, 요구사항, 설계는 "자율 구성 팀"으로부터 나온다.
12. 팀은 정기적으로 더 효과적으로 일할 수 있는지를 돌아보고,
이에 따라 행동 방식을 조율하고 조정한다.
애자일(Agile) 방법론의 12가지 원칙은 애자일 방법론을 가장 잘 설명하는 내용들입니다.
고객에게 가치 있는 소프트웨어를 조기에 지속적으로 제공함으로써 고객을 만족시키는 것을 애자일 방법론에서는 최고의 우선순위로 두고 있습니다. 그리고 비록 개발 후반부일지라도 워터폴 방식의 프로젝트에서는 할 수 잘 할 수 없는 요구사항 변경들을 기꺼이 수용하도록 하고 있습니다. 애자일 프로세스는 변화를 활용하여 고객의 경쟁력에 도움이 된다면 하도록 되어 있습니다.
애자일(Agile)에서는 1주에서 2주의 반복 주기로, 작동하는 소프트웨어를 자주 전달하게 됩니다. 품질 상의 이슈가 하다도 없는 소프트웨어입니다. 애자일은 더 짧은 기간을 선호하는 방법론입니다. 프로젝트 전반에 걸쳐서 비즈니스 담당자인 프로덕트 오너(Product Owner)와 개발팀, 그리고 개발자들은 매일 함께 작업하도록 되어 있습니다.
애자일은 동기 부여된 개인들을 중심으로 프로젝트를 구성하는 것이 중요합니다. 하기 싫은 사람들을 억지로 구성한다면 작동되지 않는 방식입니다. 그리고 동기 부여된 개인들이 필요로 하는 환경과 자원들을 적극적으로 제공해야 하고 담당 업무를 잘 완료할 것임을 신뢰해야 합니다.
개발 팀 내부에서는 정보를 전달하는 가장 효율적이고 효과적인 방법은 대면하여 대화하는 것으로 보고 있습니다. 그리고 애자일에서는 “완료율”이라고 하는 개념이 없습니다. 작동하는 소프트웨어가 진척의 주된 척도가 되는 것입니다. 작동하면 100% 달성한 것이고, 작동하지 않으면 0% 인 것입니다.
애자일 프로세스들은 지속 가능한 개발을 장려하고 있습니다. 그래서 프로젝트에서 스폰서와 개발자, 사용자는 일정한 속도를 유지할 수 있어야 합니다. 소화가 안되는 수준으로 너무 급하고 빠르게 진행하면 개발자들과 멤버들이 지칠 수 있는 방법론입니다.
애자일 방법론을 적용하기 위해서는 팀원들이 실력이 좋아야 합니다. 지식과 경험을 갖춘 팀원들로 구성되어야 합니다. 기술적 탁월성과 좋은 설계에 대한 지속적인 관심이 프로젝트의 “민첩성”을 높일 수 있습니다.
애자일 방법론에서는 단순성이 필수적입니다. 불필요한 업무는 최대한 없애야 합니다. 멀티 태스킹을 하지 않아야 하며 보고서 작성은 최소화되어야 합니다. 프로세스를 간소화 시키고 일할 수 있는 시간을 충분하게 확보해주어야 합니다. 그리고 역할과 일에 집중하도록 합니다. 안 하는 일의 양을 최대화 하는 기술이 필요한 것입니다.
애자일에서는 최고의 아키텍처, 요구사항, 설계는 “자율 구성팀”에서 비롯된다고 보고 있습니다.
애자일에서는 프로젝트 팀은 정기적으로 더 효과적인 방법을 찾아서 반영하고 그에 따른 업무 활동을 조율하고 조정합니다. 그래서 회고는 애자일에서 매우 중요한 세션입니다.