검수요청.png검수요청.png

"애자일"의 두 판 사이의 차이

위키원
이동: 둘러보기, 검색
잔글
(애자일 개발 방법론과 전통적인 개발 방법론)
 
(사용자 2명의 중간 판 6개는 보이지 않습니다)
1번째 줄: 1번째 줄:
'''애자일'''(agile)은 ‘기민한’, ‘날렵한’, ‘민첩한’이라는 뜻 을 가진 형용사로서, 사전에 정해진 단계와 절차에 따라 개발을 진행하는 [[폭포수 모델|폭포수]](Waterfall) 개발방법론과 달리, 변화하는 상황에 맞게 유연하게 대응하는 소프트웨어 [[개발방법론]](SDM)을 말한다. [[스크럼]](Scrum) 방법을 사용한다.
+
[[파일:Agile.png|300픽셀|섬네일|오른쪽|애자일]]
 +
 
 +
'''애자일'''(agile)은 ‘기민한’, ‘날렵한’, ‘민첩한’이라는 뜻 을 가진 형용사로서, 사전에 정해진 단계와 절차에 따라 개발을 진행하는 [[폭포수 모델|폭포수]](Waterfall) 개발방법론과 달리, 변화하는 상황에 맞게 유연하게 대응하는 소프트웨어 [[개발방법론]](SDM)을 말한다. 애자일 개발 프로세스는 소프트웨어 엔지니어링에 대한 개념적인 얼개로, 프로젝트의 생명주기 동안 반복적인 개발을 촉진한다.<ref name="wiki">위키백과, 〈[https://ko.wikipedia.org/wiki/%EC%95%A0%EC%9E%90%EC%9D%BC_%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4_%EA%B0%9C%EB%B0%9C 애자일 소프트웨어 개발 ]〉, 《위키백과》, 2020-07-20</ref>
  
 
==개념==
 
==개념==
'''애자일 방법론'''은 일정한 주기를 가지고 끊임없이 [[프로토타입]]을 만들어내며 필요한 요구사항을 추가 및 수정을 통해 소프트웨어를 개발하는 것이다. 애자일 개발 프로세스는 제한된 시간과 비용 안에서 정보는 불완전하고 예측은 불가능하다는 전제하에 합리적인 답을 내도록하는 것이다.<ref>위키백과, <[https://ko.wikipedia.org/wiki/%EC%95%A0%EC%9E%90%EC%9D%BC_%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4_%EA%B0%9C%EB%B0%9C 애자일 소프트웨어 개발]>, <<위키백과>>, 2020-07-20 </ref>
+
애자일 개발 방법론은 [[소프트웨어 개발 방법론]]]에 있어서 아무런 계획이 없는 개발 방법과 계획이 지나치게 많은 개발 방법들 사이에서 타협점을 찾고자 하는 방법론이다. 계획이 없는 방법론의 경우, 앞으로의 일을 예측하기 힘들고 효율적이지 못하다는 점에서 취약점을 가지고 있다. 반대로 계획에 의존하는 경우 형식적인 절차에 따르는 데 필요한 시간과 비용을 무시할 수 없으며 전체적인 개발의 흐름을 느리게 하는 단점을 가지고 있다. 그러므로 애자일 개발 방법론은 계획을 통해 주도하는 과거의 방법론과 달리 앞을 예측하며 개발하지 않고, 일정한 주기를 가지고 끊임없이 [[프로토타입]]을 만들어내며 필요한 요구사항을 추가 및 수정을 통해 소프트웨어를 개발하는 것이다. 애자일 개발 방법론은 제한된 시간과 비용 안에서 정보는 불완전하고 예측은 불가능하다는 전제하에 합리적인 답을 내도록 하는 것이다.<ref name="wiki"></ref>
 +
 
 +
==개발 배경==
 +
애자일 개발 방법론 배경에는 소프트웨어 개발 자체가 다른 공학적인 방법론과는 큰 차이가 있음을 인지하는 데에서부터 시작되었다. 이는 소프트웨어 위기의 원인과 해결방안을 찾는 데에서부터 시작되었다. 90년대 후반까지의 소프트웨어 공학과 개발방법론은 장기간에 걸쳐 많은 사람을 투입하고 충분한 비용을 투입하여 진행하는 다른 공학의 프로세스와 비슷한 맥락에서 진행되었다. 그러나 소프트웨어는 유동적이고 개방적이다. 또한, 요구사항의 변경에 따른 작업량을 예측하기 힘들다. 그래서 이미 고전적인 소프트웨어 공학이나 관리 기법만으로는 대처할 수 없게 되었다. 이런 문제에 대한 기술적인 해결책으로 객체지향이 있다. 객체지향 기술은 그동안의 개발 문제를 적절하게 대처해 주었다. 그리고 객체지향 개발을 하기 위해서는 그에 적합한 개발 프로세스가 필요했다. 그래서 수많은 애자일 개발 프로세스가 이러한 필요에 따라 만들어졌다. 따라서 애자일 개발 방법론의 상당수는 객체지향 기술을 기반으로 한다. 애자일 개발 방법론은 제한된 시간과 비용 안에서 정보는 불완전하고 예측은 불가능하다는 전제를 가진다. 그리고 그 전제 아래에서 합리적인 답을 내도록 하는 것이 애자일 개발 방법론이다.<ref name="wiki"></ref>
 +
 
 +
==특징==
 +
* 고객과 개발자의 지속적인 소통을 통하여 요구사항의 변화를 이행한다.
 +
* 개발자 개인의 가치보다는 팀의 목적을 우선시하며 고객의 의견을 가장 우선시한다.
 +
* 주기적인 회의를 통한 프로젝트를 점검한다.
 +
* 진행하면서 프로그램을 시행해보고 고객으로부터 피드백을 받는다.
 +
* 비용절감에 힘쓰는 동시에 프로그램 품질 향상을 위해 노력한다.<ref>SD아카데미 , 〈[https://m.blog.naver.com/sundooedu/221193074730 애자일(Agile)방법론에 대해서 알아보자]〉, 《개인블로그》, 2018-01-25</ref>
 +
 
 +
애자일 방법론을 사용하면 점진적으로 테스트할 수 있어 [[버그]]를 빠르게 발견할 수 있다. 수정과 변경에 유연하다. 프로젝트를 시작할 때 계획에 소모되는 시간을 줄일 수 있다. 서비스가 더 빨리 출시된다.<ref>심재철 , 〈[https://medium.com/@simsimjae/%EC%95%A0%EC%9E%90%EC%9D%BC-%EB%B0%A9%EB%B2%95%EB%A1%A0-753368aa3058 애자일 방법론]〉, 《Medium》</ref>
 +
 
 +
==애자일 개발 방법론과 전통적인 개발 방법론==
 +
전통적인 개발 방법론들은 [[폭포수 모델]]과 계획 기반 개발을 따르지만 애자일 개발 프로세스는 전통적인 개발 방법론에 반한다는 점이 큰 차이를 가진다. 전통적인 개발 방법론들은 계획적 개발을 기반으로 개발을 진행한다. 이는 이해와 사용이 쉬운 바람적인 기법이지만 계획대로 진행되지 않을 때 가장 큰 부작용이 발생하게 된다는 단점이 있다. <ref name="wiki"></ref>
 +
 
 +
===애자일 소프트웨어 개발 선언===
 +
{{인용문|
 +
:우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서
 +
:소프트웨어 개발의 더 나은 방법들을 찾아가고 있다.
 +
:이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다.
 +
 
 +
:* 공정과 도구보다 개인과 상호작용을
 +
:* 포괄적인 문서보다 작동하는 소프트웨어를
 +
:* 계약 협상보다 고객과의 협력을
 +
:* 계획을 따르기보다 변화에 대응하기를
 +
 
 +
:가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만,
 +
:우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.<ref>agilemanifesto , 〈[https://agilemanifesto.org/iso/ko/manifesto.html 애자일 소프트웨어 개발 선언]〉, 《agilemanifesto》, 2001</ref>
 +
}}
 +
 
 +
===애자일 소프트웨어 개발 12대 원칙===
 +
{{다단2|
 +
* 고객 만족
 +
* 변화 수용
 +
* 자주 납품
 +
* 팀으로 작업
 +
* 동기 부여
 +
* 대면 소통
 +
|
 +
* 가동성 측정
 +
* 속도 일정 유지
 +
* 품질 최우선
 +
* 복잡하지 않게
 +
* 설계 진화
 +
* 규칙적 반영
 +
}}
 +
 
 +
==애자일의 핵심==
 +
애자일의 핵심에는 협력과 피드백이 있다.
 +
 
 +
===협력===
 +
프로젝트 실패의 경우는 기술 외적인 것도 크다. 특히 소프트웨어 개발의 불확실성이 높을 때는 협력을 통해 이를 프로젝트의 실패를 방지해야 한다.
 +
 
 +
====내부적 협력====
 +
소프트웨어을 개발한 팀 안에서 하는 협력을 말하며 특히, 직무 역할을 넘어선 협력을 의미한다.
 +
#협력을 통해 한 사람의 좋은 통찰을 다른 사람도 함께 얻을 수 있다.
 +
#예상하지 못했던 기회를 잡을 수 있다. 예를 들어 개발속도가 빠른 사람의 코드 협력의 시스템에서 문제가 발생할 수 있을 때, 협력을 통해 해당 문제점을 찾아 개선할 수 있고 이로 인해 팀 전체의 개발 속도 빨라지고 더 나은 발전 점을 찾을 수 있다.
 +
#문제점이나 예상하지 못했던 문제를 방지할 수 있다. 예를 들어 한 명의 생각이나 관점으로 찾을 수 없는 문제나 오류들을 협력을 통해 다른 사람의 생각이나 관점에서 바라볼 수 있어 해당 문제점들을 찾고 빠르게 해결할 수 있다.<ref name="feedback">heejeong Kwon, 〈[https://gmlwjd9405.github.io/2018/05/26/what-is-agile.html 애자일이란]〉, 《개인블로그》, 2018-05-26</ref>
 +
 
 +
===피드백===
 +
피드백은 학습의 가장 큰 전제조건으로 어떻게 했는지 확인하며 학습해야 한다.
 +
모르는 것이 많을수록 빨리 배워야 하므로 소프트웨어 개발의 불확실성이 높을수록 학습은 중요하다.
 +
====내부적 피드백====
 +
직접 개발한 프로젝트가 어떻게 됐는지 확인하는 것이다.
 +
====외부적 피드백====
 +
직접 개발한 프로젝트를 고객이나 다른 부서가 사용해보고 그것을 통해 또 다른 것을 배우는 것이다.<ref name="feedback"></ref>
  
 
==종류==
 
==종류==
아래의 개발 방법론에는 서로 다른 특징과 적용범위가 있으며, 조합도 가능하다.
+
개발 방법론에는 서로 다른 특징과 적용 범위가 있으며, 조합도 가능하다.
 +
 
 +
===익스트림 프로그래밍===
 +
[[익스트림 프로그래밍]](Extreme Programming, XP)은 애자일 개발 프로세스의 대표적인 개발 방법론으로 애자일 개발 방법론 보급에 큰 역할을 담당했다. 이 방법론은 클라이언트와 함께 2주 정도의 반복 개발을 하고 테스트 우선 개발(TDD)을 특징으로 하는 명시적인 기술과 방법을 가지고 있다.
 +
 
 +
===스크럼===
 +
[[스크럼]](scrum)은 30일마다 동작 가능한 제품을 제공하는 스프린트(Sprint)를 중심으로 하는 개발 방법론이다. 매일 정해진 시간과 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심의 방법론이다.
 +
 
 +
===크리스털 패밀리===
 +
[[크리스털 패밀리]]는 프로젝트의 규모와 영향의 크기에 따라 여러 종류의 방법론을 제공한다. 그중 가장 소규모 팀에 적용하는 크리스털 클리어는 익스트림 프로그래밍만큼 엄격하지도 않고 효율이 높지 않지만, 프로젝트에 적용하기 쉬운 개발 방법론이다.
 +
 
 +
===Feature-Driven Development===
 +
[[Feature-Driven Development]]는 feature마다 2주 정도의 반복 개발을 진행한다. Peter Coad가 제창하는 방법론으로, UML을 이용한 설계 기법과도 밀접한 관련이 있다.
 +
 
 +
===적응형 소프트웨어 개발===
 +
[[적응형 소프트웨어 개발]](Adaptive Software Development)은 소프트웨어 개발을 혼란으로 규정하고 혼란을 대전제로 그에 적응할 수 있는 소프트웨어 방법을 제시하기 위해 만들어진 방법론이다. 내용상으로는 다른 방법론들과 유사하지만, 합동 애플리케이션(Joint Application Development, 사용자나 고객이 설계에 참가하는 개발 방법론)을 사용하는 것이 다르다.
  
* [[익스트림 프로그래밍]](Extreme Programming, XP)
+
===익스트림 모델링===
* [[스크럼]]
+
[[익스트림 모델링]](extreme modeling)[[UML]]을 이용한 모델링 중심 방법론이다. 다른 모델링 방법들과는 달리 언제나 실행과 검증할 수 있는 모델을 작성하는 공정을 반복해서, 최종적으로 모델로부터 자동적으로 제품을 생성하게 한다.
* [[크리스털 패밀리]]
 
* [[Feature-Driven Development]]
 
* [[Adaptive Software Development]]
 
* [[익스트림 모델링]]
 
  
 
{{각주}}
 
{{각주}}
  
 
==참고자료==
 
==참고자료==
* 위키백과, <[https://ko.wikipedia.org/wiki/%EC%95%A0%EC%9E%90%EC%9D%BC_%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4_%EA%B0%9C%EB%B0%9C 애자일 소프트웨어 개발]>, <<위키백과>>, 2020-07-20
+
* 위키백과, [https://ko.wikipedia.org/wiki/%EC%95%A0%EC%9E%90%EC%9D%BC_%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4_%EA%B0%9C%EB%B0%9C 애자일 소프트웨어 개발 ], 《위키백과》, 2020-07-20
 +
* SD아카데미 , 〈[https://m.blog.naver.com/sundooedu/221193074730 애자일(Agile)방법론에 대해서 알아보자]〉, 《개인블로그》, 2018-01-25
 +
* 심재철 , 〈[https://medium.com/@simsimjae/%EC%95%A0%EC%9E%90%EC%9D%BC-%EB%B0%A9%EB%B2%95%EB%A1%A0-753368aa3058 애자일 방법론 ]〉, 《Medium》
 +
* heejeong Kwon, 〈[https://gmlwjd9405.github.io/2018/05/26/what-is-agile.html 애자일이란]〉, 《개인블로그》, 2018-05-26
 +
* agilemanifesto , 〈[https://agilemanifesto.org/iso/ko/manifesto.html 애자일 소프트웨어 개발 선언]〉, 《agilemanifesto》, 2001
  
 
==같이 보기==
 
==같이 보기==
 +
* [[폭포수 모델]]
 
* [[개발방법론]]
 
* [[개발방법론]]
  
{{프로그래밍|토막글}}
+
{{프로그래밍|검토 필요}}

2021년 4월 20일 (화) 01:05 기준 최신판

애자일

애자일(agile)은 ‘기민한’, ‘날렵한’, ‘민첩한’이라는 뜻 을 가진 형용사로서, 사전에 정해진 단계와 절차에 따라 개발을 진행하는 폭포수(Waterfall) 개발방법론과 달리, 변화하는 상황에 맞게 유연하게 대응하는 소프트웨어 개발방법론(SDM)을 말한다. 애자일 개발 프로세스는 소프트웨어 엔지니어링에 대한 개념적인 얼개로, 프로젝트의 생명주기 동안 반복적인 개발을 촉진한다.[1]

개념[편집]

애자일 개발 방법론은 소프트웨어 개발 방법론]에 있어서 아무런 계획이 없는 개발 방법과 계획이 지나치게 많은 개발 방법들 사이에서 타협점을 찾고자 하는 방법론이다. 계획이 없는 방법론의 경우, 앞으로의 일을 예측하기 힘들고 효율적이지 못하다는 점에서 취약점을 가지고 있다. 반대로 계획에 의존하는 경우 형식적인 절차에 따르는 데 필요한 시간과 비용을 무시할 수 없으며 전체적인 개발의 흐름을 느리게 하는 단점을 가지고 있다. 그러므로 애자일 개발 방법론은 계획을 통해 주도하는 과거의 방법론과 달리 앞을 예측하며 개발하지 않고, 일정한 주기를 가지고 끊임없이 프로토타입을 만들어내며 필요한 요구사항을 추가 및 수정을 통해 소프트웨어를 개발하는 것이다. 애자일 개발 방법론은 제한된 시간과 비용 안에서 정보는 불완전하고 예측은 불가능하다는 전제하에 합리적인 답을 내도록 하는 것이다.[1]

개발 배경[편집]

애자일 개발 방법론 배경에는 소프트웨어 개발 자체가 다른 공학적인 방법론과는 큰 차이가 있음을 인지하는 데에서부터 시작되었다. 이는 소프트웨어 위기의 원인과 해결방안을 찾는 데에서부터 시작되었다. 90년대 후반까지의 소프트웨어 공학과 개발방법론은 장기간에 걸쳐 많은 사람을 투입하고 충분한 비용을 투입하여 진행하는 다른 공학의 프로세스와 비슷한 맥락에서 진행되었다. 그러나 소프트웨어는 유동적이고 개방적이다. 또한, 요구사항의 변경에 따른 작업량을 예측하기 힘들다. 그래서 이미 고전적인 소프트웨어 공학이나 관리 기법만으로는 대처할 수 없게 되었다. 이런 문제에 대한 기술적인 해결책으로 객체지향이 있다. 객체지향 기술은 그동안의 개발 문제를 적절하게 대처해 주었다. 그리고 객체지향 개발을 하기 위해서는 그에 적합한 개발 프로세스가 필요했다. 그래서 수많은 애자일 개발 프로세스가 이러한 필요에 따라 만들어졌다. 따라서 애자일 개발 방법론의 상당수는 객체지향 기술을 기반으로 한다. 애자일 개발 방법론은 제한된 시간과 비용 안에서 정보는 불완전하고 예측은 불가능하다는 전제를 가진다. 그리고 그 전제 아래에서 합리적인 답을 내도록 하는 것이 애자일 개발 방법론이다.[1]

특징[편집]

  • 고객과 개발자의 지속적인 소통을 통하여 요구사항의 변화를 이행한다.
  • 개발자 개인의 가치보다는 팀의 목적을 우선시하며 고객의 의견을 가장 우선시한다.
  • 주기적인 회의를 통한 프로젝트를 점검한다.
  • 진행하면서 프로그램을 시행해보고 고객으로부터 피드백을 받는다.
  • 비용절감에 힘쓰는 동시에 프로그램 품질 향상을 위해 노력한다.[2]

애자일 방법론을 사용하면 점진적으로 테스트할 수 있어 버그를 빠르게 발견할 수 있다. 수정과 변경에 유연하다. 프로젝트를 시작할 때 계획에 소모되는 시간을 줄일 수 있다. 서비스가 더 빨리 출시된다.[3]

애자일 개발 방법론과 전통적인 개발 방법론[편집]

전통적인 개발 방법론들은 폭포수 모델과 계획 기반 개발을 따르지만 애자일 개발 프로세스는 전통적인 개발 방법론에 반한다는 점이 큰 차이를 가진다. 전통적인 개발 방법론들은 계획적 개발을 기반으로 개발을 진행한다. 이는 이해와 사용이 쉬운 바람적인 기법이지만 계획대로 진행되지 않을 때 가장 큰 부작용이 발생하게 된다는 단점이 있다. [1]

애자일 소프트웨어 개발 선언[편집]

우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서
소프트웨어 개발의 더 나은 방법들을 찾아가고 있다.
이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다.
  • 공정과 도구보다 개인과 상호작용을
  • 포괄적인 문서보다 작동하는 소프트웨어를
  • 계약 협상보다 고객과의 협력을
  • 계획을 따르기보다 변화에 대응하기를
가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만,
우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.[4]

애자일 소프트웨어 개발 12대 원칙[편집]

  • 고객 만족
  • 변화 수용
  • 자주 납품
  • 팀으로 작업
  • 동기 부여
  • 대면 소통
  • 가동성 측정
  • 속도 일정 유지
  • 품질 최우선
  • 복잡하지 않게
  • 설계 진화
  • 규칙적 반영

애자일의 핵심[편집]

애자일의 핵심에는 협력과 피드백이 있다.

협력[편집]

프로젝트 실패의 경우는 기술 외적인 것도 크다. 특히 소프트웨어 개발의 불확실성이 높을 때는 협력을 통해 이를 프로젝트의 실패를 방지해야 한다.

내부적 협력[편집]

소프트웨어을 개발한 팀 안에서 하는 협력을 말하며 특히, 직무 역할을 넘어선 협력을 의미한다.

  1. 협력을 통해 한 사람의 좋은 통찰을 다른 사람도 함께 얻을 수 있다.
  2. 예상하지 못했던 기회를 잡을 수 있다. 예를 들어 개발속도가 빠른 사람의 코드 협력의 시스템에서 문제가 발생할 수 있을 때, 협력을 통해 해당 문제점을 찾아 개선할 수 있고 이로 인해 팀 전체의 개발 속도 빨라지고 더 나은 발전 점을 찾을 수 있다.
  3. 문제점이나 예상하지 못했던 문제를 방지할 수 있다. 예를 들어 한 명의 생각이나 관점으로 찾을 수 없는 문제나 오류들을 협력을 통해 다른 사람의 생각이나 관점에서 바라볼 수 있어 해당 문제점들을 찾고 빠르게 해결할 수 있다.[5]

피드백[편집]

피드백은 학습의 가장 큰 전제조건으로 어떻게 했는지 확인하며 학습해야 한다. 모르는 것이 많을수록 빨리 배워야 하므로 소프트웨어 개발의 불확실성이 높을수록 학습은 중요하다.

내부적 피드백[편집]

직접 개발한 프로젝트가 어떻게 됐는지 확인하는 것이다.

외부적 피드백[편집]

직접 개발한 프로젝트를 고객이나 다른 부서가 사용해보고 그것을 통해 또 다른 것을 배우는 것이다.[5]

종류[편집]

개발 방법론에는 서로 다른 특징과 적용 범위가 있으며, 조합도 가능하다.

익스트림 프로그래밍[편집]

익스트림 프로그래밍(Extreme Programming, XP)은 애자일 개발 프로세스의 대표적인 개발 방법론으로 애자일 개발 방법론 보급에 큰 역할을 담당했다. 이 방법론은 클라이언트와 함께 2주 정도의 반복 개발을 하고 테스트 우선 개발(TDD)을 특징으로 하는 명시적인 기술과 방법을 가지고 있다.

스크럼[편집]

스크럼(scrum)은 30일마다 동작 가능한 제품을 제공하는 스프린트(Sprint)를 중심으로 하는 개발 방법론이다. 매일 정해진 시간과 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심의 방법론이다.

크리스털 패밀리[편집]

크리스털 패밀리는 프로젝트의 규모와 영향의 크기에 따라 여러 종류의 방법론을 제공한다. 그중 가장 소규모 팀에 적용하는 크리스털 클리어는 익스트림 프로그래밍만큼 엄격하지도 않고 효율이 높지 않지만, 프로젝트에 적용하기 쉬운 개발 방법론이다.

Feature-Driven Development[편집]

Feature-Driven Development는 feature마다 2주 정도의 반복 개발을 진행한다. Peter Coad가 제창하는 방법론으로, UML을 이용한 설계 기법과도 밀접한 관련이 있다.

적응형 소프트웨어 개발[편집]

적응형 소프트웨어 개발(Adaptive Software Development)은 소프트웨어 개발을 혼란으로 규정하고 혼란을 대전제로 그에 적응할 수 있는 소프트웨어 방법을 제시하기 위해 만들어진 방법론이다. 내용상으로는 다른 방법론들과 유사하지만, 합동 애플리케이션(Joint Application Development, 사용자나 고객이 설계에 참가하는 개발 방법론)을 사용하는 것이 다르다.

익스트림 모델링[편집]

익스트림 모델링(extreme modeling)은 UML을 이용한 모델링 중심 방법론이다. 다른 모델링 방법들과는 달리 언제나 실행과 검증할 수 있는 모델을 작성하는 공정을 반복해서, 최종적으로 모델로부터 자동적으로 제품을 생성하게 한다.

각주[편집]

  1. 1.0 1.1 1.2 1.3 위키백과, 〈애자일 소프트웨어 개발 〉, 《위키백과》, 2020-07-20
  2. SD아카데미 , 〈애자일(Agile)방법론에 대해서 알아보자〉, 《개인블로그》, 2018-01-25
  3. 심재철 , 〈애자일 방법론〉, 《Medium》
  4. agilemanifesto , 〈애자일 소프트웨어 개발 선언〉, 《agilemanifesto》, 2001
  5. 5.0 5.1 heejeong Kwon, 〈애자일이란〉, 《개인블로그》, 2018-05-26

참고자료[편집]

같이 보기[편집]


  검수요청.png검수요청.png 이 애자일 문서는 프로그래밍에 관한 글로서 검토가 필요합니다. 위키 문서는 누구든지 자유롭게 편집할 수 있습니다. [편집]을 눌러 문서 내용을 검토·수정해 주세요.