애자일 소프트웨어 개발

소프트웨어 개발 방법론에는 크게 정보공학 개발 방법론 / 객체지향 개발 방법론 / 컴포넌트 기반 개발 방법론 / 애자일 방법론 이렇게 4가지로 나눌 수 있습니다. 각각의 방법론에서 파생된 방법론도 있고, 그 외에 폭포수, 프로토타입 개발 방법론 등이 있습니다.

 

개발 방법론에 대해선 흔히 들어왔지만 추상적으로만 알고있던 "애자일 방법론" 이 무엇인지 책 내용을 중심으로 정리해보고자 합니다.

 

- 애자일 개발 선언문

 

• '프로세스와 도구' 보다는 '개인과 상호작용'

• '포괄적인 문서화' 보다는 '동작하는 소프트웨어'

• '계약 협상' 보다는 '고객과의 협력'

• '계획 준수' 보다는 '변화에 대응'

 

왼쪽도 가치가 있지만, 오른쪽에 있는 것들에 좀 더 많은 가치를 둔다는 것입니다.

 

- 애자일 유래와 정신

 

2001년 2월 경 경량 프로세스라고 떠오르는 경향에 대해 토론하기 위해 17명의 사람들이 모였고, 이들은 부실한 프로세스 때문에 실패하는 많은 프로젝트를 보며 방법론을 검토하는 좋은 수단이 있어야 한다고 느꼈습니다. 이익이 적은 중요하지 않은 것에 대해 그만 강조하고, 더 중요한 것에 집중하는 길을 찾는 것입니다.

 

이들이 '애자일' 이라는 용어를 만들고 소프트웨어 개발에서 새롭게 집중해야할 접근 방법을 설명하기 위해 애자일 선언을 공표했습니다.

이 접근 방법은 사람 / 협조 / 반응성 / 동작하는 소프트웨어 를 강조합니다.

 

애자일한 방식이란 프로젝트의 끝으로 테스트를 미루지 않는다는 것을 뜻합니다.

코딩을 시작하면서 요구사항과 피드백을 모으는 일을 멈추지 않아야 합니다.

 

- 일시적이 아닌 지속적인 개발

 

프로젝트의 전 생애 주기동안 개발, 통합, 피드백 반영등의 모든 활동을 계속 실행해야 합니다.

사실 이 부분은 조금 애매한 표현이긴 하지만, 사람들이 소프트웨어를 사용하는 한 소프트웨어는 절대로 완료되지 않기 때문에 끊임없는 개발과 피드백이 수반되어야 한다는 얘기입니다.

 

아직 상대적으로 고치기 쉬울 때 빨리 찾아서 고친다, 이것이 애자일 실천방법의 전부입니다.

 

어떤 사람들은 애자일 개발 방법이 단지 위장된 위기관리 방법일 뿐이라고 비판합니다. 하지만 이들은 어떠한 문제들이 곪도록 방치된 후에야 뒤늦은 위기관리를 합니다. 

 

애자일 방법론에선 문제가 아직 작을 때 부딪치고, 많은 것을 투자하기 전에 불명확한 것에 대해 조사하고, 그 와중에 진실이 발견되면 지금까지의 모든 것이 잘못되었다고 인정할 준비가 되어있어야 합니다.

 

- 애자일 실천방법

 

'애자일 개발은 고도의 협력적인 환경에서 지속적인 조정을 위해 피드백을 사용한다'

애자일의 유용한 정의는 위와 같습니다.

 

대체로 애자일 팀은 작거나 몇개의 작은 팀으로 나눠집니다. 작성하는 코드에서 끊임없이 피드백을 얻고, 자동화를 사용해서 끊임없이 프로젝트를 빌드하고 테스트합니다. 그 과정에서 기능은 그대로인 채 계속해서 코드의 일부를 설계하는 '리팩토링' 이 계속 필요하고, 결국 이는 개발하면서 계속되어야 하는 것입니다. (코드에는 완성이란 없다..)

 

일은 반복 주기 안에서 진행되는데, 반복 주기란 기능들의 집합을 확인하고 구현하는 데 필요한 시간의 작은 묶음을 말합니다.

이 반복 주기 안에서 피드백을 얻기 위해 자주 전체 버전 배포가 진행되어야 합니다.

 

- 애자일 툴킷

 

애자일한 프로젝트에서 공통으로 사용하는 기본적인 도구들 몇 가지를 얘기하겠습니다.

 

• 위키

• 버전 관리 : git, ...

• 단위 테스트 : JUnit, Jest, Mocha, ...

• 빌드 자동화 (= 지속적 통합) : Jenkins, Code-Deploy, ...

 

- More Details...

 

다음 포스팅부터 애자일 실천방법에 대해 더 자세히 남기도록 하겠습니다. 이어질 내용은 아래와 같습니다.

 

• 애자일 시작

• 애자일 기르기

• 사용자들이 원하는 내용 제공

• 애자일 피드백

• 애자일 코딩

• 애자일 디버깅

• 애자일 협력

 

 

출처 : 애자일 프랙티스(책)